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