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

DevOps at Disney, management lessons learned – Notebook

New types of software and delivery mechanisms (SaaS, mobile) mean new problems and scale:

“We were so used to dealing with tens of servers and suddenly it was hundreds and thousands of servers,” which in turn created more work for the development teams.

More:

“The digital expansion of business equals more work and firefighting,” Cox said.

Less time spent doing dumb-shit:

employees used to spend the eight hours of the park closed every night, manually updating each server. Now only one person can update the whole fleet in 30 minutes.

Some guiding principals and management challenges:

Cox said that leading a change of this order of magnitude involved three crucial ingredients:
1. Collaboration: break down silos, mutual objectives.
2. Curiosity: keep experimenting.
3. Courage: candor, challenge, no blaming or witch-hunting.
But  these can come with its own leadership challenges, including:
• The politics of command and control.
• How new leadership can take a company in a new direction.
• The blame bias of who versus what.

And, some good motivation:

We keep moving forward, opening up new doors, doing more things because we’re curious.

All from Jennifer Riggins’s write-up at TheNewStack

Core DevOps (tech) metrics, from Nicole Forsgren

Everyone always wants to know metrics. While the answer is always a solid “it depends – I mean, what are your business goals and then we can come up with some KPIs,” there’s a reoccurring set of technical metrics. Nicole lists some off:

These IT performance metrics capture speed and stability of software delivery: lead time for changes (from code commit to code deploy), deployment frequency, mean time to restore (MTTR), and change fail rate. It’s important to capture all of these because they are in tension with each other (speaking to both speed and stability, reflecting priorities of both the dev and ops sides of the team), and they reflect overall goals of the team. These metrics as a whole have also been shown to drive organizational performance.

And, then, further summarized by Daniel Bryant:

Key metrics for IT performance capture speed and stability of software delivery, and include: lead time for changes (from code commit to code deploy), deployment frequency, mean time to restore (MTTR), and change fail rate.

Also in the interview, a concise DevOps definition:

I define DevOps as a technology transformation that drives value to organizations through an ability to deliver code with both speed and stability.

See the rest.

Coté Show: Patrick Debois on using serverless for a year and half, defining DevOps vs. SRE vs. design, and meatware over tools

Continuing the DevOpsDays Austin interview series, Barton and I talked with Patrick Debois on a variety of topics:

Check out the full show notes for more and podcast subscription options.

Scaling DevOps in large organizations – My April Register column

apololypse_now_smell_of_napalm_in_the_morning

My The Register column this month is on scaling DevOps/cloud-native teams to the entire organization. It’s easy to build one team that does software in a new and exciting way, but how can you move to two teams, five teams, and then 100’s? It goes over the amalgamation of a few case studies and plenty of over-the-top gonzo analogies, per usual.

Check it out, and check out past ones if you’re curious for more.

Pivotal Conversations: How microservices enable DevOps, with Josh Long by Pivotal Conversations

It was a pretty good episode:

In preparation for his DevOpsDays Atlanta talk, Josh and Coté (well, mostly Coté) talk about the relationship between microservices and DevOps. They use the CAMS framing to go over how microservices could provide the architectural requirements to make DevOps possible.