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.
"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.
The purpose of SLODLC is to have a process that enables organizations to use SLOs effectively.
The Service Level Objective Development Lifecycle provides a framework to help organizations define, implement, and operate SLOs.
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. The design 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."
