Link: “Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s cal

“Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s called a Chef server. Similarly, ITIL places a strong emphasis on configuration. Teams I have built do the same. All changes to the system are made in code, go through a peer review process, are automatically tested, and rolled out in a recordable, repeatable, and auditable manner. I encourage tracking of all changes that are made to the system. To do that, I use git and I track problems and resolution in a ticketing system. That could be Jira or Zendesk. When it comes to risk management, compliance, and security, again, I turn to the Chef ecosystem. Chef Compliance, as part of the Chef automation system, provides ways to specify compliance requirements as testable specification, which can then be used for audit and management.”

All that configuration management, logging, and automation gives what’s needed for ITIL-level tracking.
Original source: “Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s cal

Link: How to Monitor the SRE Golden Signals

[Summary from the post of metrics to use:]

Rate — Request rate, in requests/sec
Errors — Error rate, in errors/sec
Latency — Response time, including queue/wait time, in milliseconds.
Saturation — How overloaded something is, which is related to utilization but more directly measured by things like queue depth (or sometimes concurrency). As a queue measurement, this becomes non-zero when you are saturated, often not much before. Usually a counter.
Utilization — How busy the resource or system is. Usually expressed 0–100% and most useful for predictions (as Saturation is probably more useful). Note we are not using the Utilization Law to get this (~Rate x Service Time / Workers), but instead looking for more familiar direct measurements.
Original source: How to Monitor the SRE Golden Signals

Link: Full Cycle Developers at Netflix

How Netflix thinks about standardized platforms and tools, plus their adaptation of DevOps and SRE.

“Full cycle developers apply engineering discipline to all areas of the life cycle. They evaluate problems from a developer perspective and ask questions like “how can I automate what is needed to operate this system?” and “what self-service tool will enable my partners to answer their questions without needing me to be involved?” This helps our teams scale by favoring systems-focused rather than humans-focused thinking and automation over manual approaches.”
Original source: Full Cycle Developers at Netflix

Link: Survey Shows Cloud and DevOps Complexity and Culture Concerns

“The findings, based on more than 1,300 responses from DevOps and IT professionals, showed the top barriers to DevOps adoption involve stagnant organizational cultures (according to 22 percent of respondents); managing the jumble of legacy processes, IT infrastructure and newly created cloud environments (21 percent); and growing software complexity that impacts application modernization initiatives (20 percent). ”

And:

“DevOps teams are still highly dependent on IT assistance to help deliver infrastructure, often through a ticket-based process. About 27 percent of those surveyed get access to the necessary infrastructure and environments within one day. But nearly 50 percent must wait up to one month for infrastructure access, while 24 percent wait for more than a month, particularly those with distributed teams.”
Original source: Survey Shows Cloud and DevOps Complexity and Culture Concerns

Link: How to build a business case for DevOps transformation

“Here are a few signs that your company should consider transitioning to DevOps:

Does it take a long time to deliver features?
Are features underutilized?
Do you not know the utilization of features?
Do you have downtime during maintenance or deployment windows?
Do your customers tell you your site is down before you know it?
Do outages occur repeatedly for the same reason?
Are customer feature requests implemented in a way that doesn’t actually fulfill the customer’s needs?”

Original source: How to build a business case for DevOps transformation

Link: DevOps success is about culture, culture culture

As ever, just getting a build pipeline in place is the big, important first step that most need to make: “Continuous integration remains a top priority for development teams with 63 percent of respondents saying they plan to invest in CI tools in 2018. Nearly half of all respondents (47 percent) strongly agree that practicing continuous integration alleviates blockers in the development process. In addition to CI, automation is increasingly top of mind for software professionals as half of respondents report delays in testing, while 58 percent report delays in planning. As a result, 36 percent of IT managers plan to invest in automation tools in 2018 to alleviate these pain points.”

Vendor survey from GitLab: “5,296 software developers, CTOs and software professionals, conducted.”
Original source: DevOps success is about culture, culture culture

Link: Yes, DevOps is all about business growth, especially the digital variety

Vendor survey, but whatever: “A survey of 1,300 executives just released by CA Technologies and Freeform Dynamics finds that while 75 percent recognize that these approaches drive significant business success when implemented together, only a relatively small proportion — about one in five — consider the consistency, depth and breadth of usage of these practices to be high.”
Original source: Yes, DevOps is all about business growth, especially the digital variety

Link: DevOps, Software-Defined Infrastructure, and the CMDB’s Perception Problem

“Unfortunately, the ITSM community often seems to suffer from a collective lack of awareness and understanding of the history and culture of DevOps. There is little dialog between the communities (worryingly to me, I still typically find myself being the only ITSM person at almost every one of these events).”
Original source: DevOps, Software-Defined Infrastructure, and the CMDB’s Perception Problem

Link: Considering “Digital Transformation”

“That’s why agile methodologies such as DevOps are so important, not in themselves (yes, that would be putting the cart before the horse again) but because they give businesses an approach to innovate at high speed.”
Original source: Considering “Digital Transformation”

Link: Considering “Digital Transformation”

“That’s why agile methodologies such as DevOps are so important, not in themselves (yes, that would be putting the cart before the horse again) but because they give businesses an approach to innovate at high speed.”
Original source: Considering “Digital Transformation”

Link: Whither the DBA

“In every case in which a CIO or other executive has driven or authorized substantial investments in service-based database infrastructure, changes in DBA roles have followed. As two financial industry executives put it at a conference in Jersey City and re:Invent, respectively, their DBAs are all being moved to doing more generic DevOps-style roles, roles that involve more architecture and engineering than traditional database administration. This is the logical outcome of a scenario in which making a database fault-tolerant with 6 copies across three availability zones with continuous backup is now merely a product feature instead of a full time job or jobs.”
Original source: Whither the DBA

Link: Creative ways to encourage the integration of DevOps processes

‘Teams come into the dojo with a backlog of real work they are trying to deliver and are paired with DevOps coaches for six weeks. Some managers expect the teams to deliver these projects faster over the course over this period. Sometimes it happens, but Clanton explained it is really about building the skills that will allow them to deliver faster software and with better quality when they return to the office.’

Training by doing.
Original source: Creative ways to encourage the integration of DevOps processes

Link: How value stream analysis unclogs DevOps workflows

“It’s not about productivity; it’s about value-tivity. Productivity represents the capacity to increase output for a given level of input. But this output can also be rubbish, which adds no value to the business.”

Link to original

Good, simple explanation of Service Level Objectives (SLOs)

SLOs are objectives that your business aspires to meet and intends to take action to defend; just remember, your SLOs are not your SLAs (service level agreements)! You should pick SLOs that represent the most critical aspects of the user experience. If you meet an SLO, your users and your business should be happy. Conversely, if the system does not meet the SLO, that implies there are users who are being made unhappy!

Source: Building good SLOs – CRE life lessons

James Governor: The incredible shrinking time to legacy. On Time to Suck as a metric for dev and ops 

Turns out of course it’s not just Developer Time To Suck that is shrinking. Operations is heading the same way. Folks at Pivotal are saying that operating systems don’t matter, as we’ve moved further up the stack. Cloud Native is a proxy for saying much the same thing. But then, something is being written right now that will supplant Kubernetes. If we’re not running our own environments in house, operations disposability become increasingly realistic. Cattle not pets, for everything.

Source: The incredible shrinking time to legacy. On Time to Suck as a metric for dev and ops – James Governor’s Monkchips