Service-Level Objectives Mature with OpenSLO, SLODLC

The process of defining service-level objectives is getting more standardized with the launch of the OpenSLO 1.0 standard and the Service Level Objective Development Lifecycle framework at SLOconf 2022.

Sean Michael Kerner, Contributor

May 13, 2022

4 Min Read
SLOconf logo
Nobl9

The practice of using service-level objectives as part of an approach to enable site reliability engineering (SRE) for ITOps and DevOps is continuing to mature.

At the SLOconf 2022 virtual event held from May 9-12, hosted by SLO vendor Nobl9, a series of announcements were made to underscore the growing maturity and adoption of service-level objectives. One was the release of the OpenSLO 1.0 specification, providing users and vendors with an open standard to help define and share SLO information. To help facilitate the adoption of service-level objectives, Nobl9 released the Service Level Objective Development Lifecycle (SLODLC), which is a framework and a process designed to help organizations adopt SLOs.

Also released at the event was the State of Service Level Objectives 2022 report, which found that there is growing adoption of SLOs.

"Of those organizations not currently using SLOs, 71% plan on adopting them," Brian Singer, founder and chief product officer at Nobl9, said during a SLOconf session. "That would bring SLO adoption pretty much to the entire industry."

OpenSLO Standard Hits 1.0 Milestone

A key highlight at the SLOconf event was the release of the OpenSLO 1.0 standard, which was developed as an open specification with the participation of multiple vendors.

Related:2022 State of SRE Report Identifies Site Reliability DevOps Challenges

"OpenSLO is an effort to build a vendor-agnostic service-level monitoring standard," Andrew Newdigate, distinguished engineer at GitLab, said during a session at the conference. "It provides a way of defining SLOs with a standard YAML schema."

Part of OpenSLO is Oslo, a tool for validating definitions against the standard and checking that they're correct, according to Newdigate. The overall goal of OpenSLO is to allow companies to adopt a standard terminology for service-level monitoring, he added.

The effort to define OpenSLO began at last year's SLOconf, and with the 1.0 release, the expectation is that adoption will grow.

"We now have an official 1.0 release that we can put a flag in, which I think is important because now we don't have a moving target," Ian Bartholomew, site reliability engineering manager at Nobl9, said. "We now have a stable version that we can build upon and build our tooling around."

Enabling the Service-Level Objective Lifecycle with SLODLC

Going a step beyond just have an SLO specification, Nobl9 also announced its Service Level Objective Development Lifecycle initiative at SLOconf.

"SLODLC is an open-source methodology that includes a handbook, examples, and templates for building SLOs," Kit Merker, chief operating officer at Nobl9, said during a SLOconf session.

Related:How DevOps Roles and Site Reliability Engineer Roles Differ

The purpose of SLODLC is to have a process that enables organizations to use SLOs effectively.

Service Level Objective Development Lifecycle

SLO-Development-Lifecycle

The SLODLC, Merker said, has a number of primary phases:

  • Initiate. The first phase is the initiate phase. This is where organizations figure out why they are starting off with an SLO. In this phase, short documents are created that explain why there is a need to create service-level objectives and what the business benefit will be.

  • Discovery. The discovery phase is where teams try to understand what the services need to do and make it a structured process for asking the right questions in order to generate good SLOs.

  • Design. Thedesign phase is where the IT team takes what has been learned about services and tries to build out SLOs for them.

  • Implement. This is the phase where the SLOs have to actually turn it into a real system. Using OpenSLO to define SLOs at this stage can be useful.

  • Operate. After implementation, services needed to be operated in alignment with service-level objectives.

"If there's one thing to take away from this, it's that observability without action is just storage," Merker said. "What we want to do is not just observe the system, but really take action, and this is what SLOs are all about."

 

About the Author

Sean Michael Kerner

Contributor

Sean Michael Kerner is an IT consultant, technology enthusiast and tinkerer. He consults to industry and media organizations on technology issues.

https://www.linkedin.com/in/seanmkerner/

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like