Skip to main content

SLA-SLO-SLI and DevOps metrics

[PLACEHOLDER]

Companies are in need of the metrics that will allow them to stay in business by making sure they meet the expectations of their customers. The name of the game is higher customer satisfaction by winning their trust and loyalty. To do so, you want to provide good products and services. Therefore you need to find ways to monitor performance, drive continuous improvements and deliver the quality expected by the consumer in this highly competitive market.

Photos from AlphaTradeZone via Pexel and Spacejoy via Unsplash

SLAs, SLOs and SLIs are a good way to achieve the above. They allow clients and vendors to be on the same page when it comes to expected system performance.

If we go one level deeper, vendors/providers work on NFRs (Non-Functional Requirements) when working on their solutions. NFRs define the quality attributes of a system. I bring them up because the relationship between them and the SLAs is that they provide, in a way, foundational aspects for the SLA-SLO-SLI definitions. This is why, by aligning them, organizations can effectively manage and monitor the performance and reliability of their systems. The NFRs are technical focused, while the SLAs are customer focused.

List of NFR groups:

  • Performance
  • Scalability
  • Portability
  • Compatibility
  • Availability
  • Reliability
  • Usability

An example to showcase an NFR and SLA relationship can be found a few paragraphs below in the “An example of aligning SLAs and NFR”. Jump to it, if you like, or continue reading the article until you get there.

The agreements and metrics allow SRE and DevOps teams to have a clear understanding of the performance objectives that are required for the users’ satisfaction, by having a focus on reliability, being customer-centric, aligned with business goals, and, therefore, push for continuous improvement.

DevOps-development-operations

Recommended article

SRE, DevOps and ITOps. If you are wondering what the differences between the SRE and DevOps are, as well as how these roles work with ITOps within an organisation then...

Ok, coming back to SLAs-SLOs-SLIs… what are they?

  • SLA: Service Level Agreement. The agreement between the service provider and the customer that outlines the expected level of service, including specific performance and reliability targets.
  • SLO: Service Level Objective. The targets/objectives to hit.
  • SLI: Service Level Indicator. The actual metrics used to measure the performance and reliability of the system.

In other words, the SLIs are the numbers that will be used to demonstrate that you have met the promises (SLOs) you have agreed upon within the contract/agreement (SLA) with your customer.

It is important to highlight that not every trackable metric should be an SLI.

An example of aligning SLAs and NFR

Let us assume you have the following NFR: 

The CMS database must be backed up on a daily basis. 

This can be a way to align the SLAs with the above NFR:

Database Service Level Agreement (SLA).
Backup and Recovery: Full backups will be performed daily, and incremental backups will be performed hourly. If a failure occurs, the database will be restored to the last backup within thirty (30) minutes.
SLO: Full Backup to perform daily.
Incremental backup to perform hourly. Data restore will be done within 30 minutes from the time of the failure.
SLI: Backup success rate done via monitoring logs.
Backup metrics: backup success rate, backup duration, backup size, restore time and restore success time.

DevOps metrics

With these metrics you can track technical capabilities and team processes around  your software development pipeline. By being able to monitor and identify issues then you are able to efficiently and effectively address it, and discover new automation opportunities that will bring proactiveness to your operations. If you think about it, this is all relatable with principles of continuous improvement which are relevant to the DevOps culture.

There are many DevOps Metrics, which I encourage you to research about them and read them in so many great articles out on the internet. Like many of those articles, I will just highlight 4 key/critical ones (I recommend following  these "breadcrumbs" we are leaving you in this article and reading more about them. You have many options on so many blogs out there! ):

  1. Lead time for changes
  2. Deployment frequency
  3. Mean time to recovery (MTTR)
  4. Change failure rate

 Differences between SLAs and DevOps Metrics

SLAs and DevOps Metrics both look after the quality and performance of the products and services.
This said, they do serve different purposes. SLAs set clear expectations and accountability, making sure providers meet the standards and the promises agreed upon. 

DevOps metrics, on the other hand, help teams improve processes and deliver software effectively and with the quality expected. 

It is common for SRE teams to leverage SLA-SLO-SLIs to ensure reliability metrics are met, and the systems are performing as intended. 

On the other hand, DevOps teams will be focused on leveraging DevOps metrics to measure the success of development and operations processes, and identifying areas of improvement.

You may also like




Trending posts

Democratizing AI

Democratizing AI is all about empowering others to use it, by making it available to them. Audiences, such as marketers in a company, will be able to access AI capabilities as part of their MarTech solutions, without the need of being technical. It could also be schools, where the younger generations are learning how to use it in responsible, secure, innovative, and creative ways. This is the year where companies, after discovery phases and teams experimenting, are looking to activate and take advantage of the AI advances. Generated with Microsoft Designer   And so, questions emerge, such as “What to democratize when leveraging AI?” There are common scenarios, as well as specific ones, that will depend on the company, and the industry they belong to. A common scenario, seen in many industries, when democratizing data is the data visualization and reporting . In digital marketing, as an example, data scientists and data analysts can automate reporting, making them available to the c...

Productivity framework for 2024

Recently I was at a Christmas party and I found myself giving advice to a friend on being more productive. I shared the approaches that I take which helped me become more productive at work and in my personal life. The conversation with my friend inspired me to share my approaches in this blog .  Photo by Moose Photos from Pexels   My productivity framework has five key pillars and to remember them I use the mnemonic, POFOR = P lan your tasks, O rganize yourself, F ocus on your tasks, O ptimize yourself with habits and R eflect to ensure you are being productive on the right tasks. Plan Planning is very crucial as it sets the tone for the rest of the pillars. I always found I was more productive when I planned my tasks compared to when I didn’t, and hence planning has become my rule of thumb. I recommend taking 30 minutes at the end of each day to plan your next day. This means prioritizing your tasks and blocking your calendar accordingly. By not doing so, you are at risk o...

SRE, DevOps and ITOps

 If you are wondering what the differences between the SRE and DevOps are, as well as how these roles work with ITOps within an organisation then you are not alone; and best of all you are on the right blog post. Often enough business units in a company get confused, assigning the ServiceNow or Jira tickets or any other ticketing system of your preference, to the wrong group, and even having the incorrect expectations when doing resourcing. Let us go through definitions, insights and scenarios that will help you understand the difference. DevOps software development operations - AI Generated When it comes to DevOps and SRE, then you might be wondering which practice came first. While SRE may have originated a bit earlier, internally at Google, DevOps came first publicly as a practice and started to be used by companies. A few years later was when Google decided to open SRE to the world after the publication of the "Site Reliability Engineering" book. Therefore, technically sp...

Effective framework to resolve conflict in the Workplace

 Conflicts are a part of our daily lives and are often unavoidable at work. Therefore, it's essential to have the tools to effectively manage conflicts and leverage them to our advantage - to spur new ideas, challenge and strengthen our beliefs, and evolve our perspectives when necessary. However, conflicts often trigger our fight-or-flight response and can cause chronic stress and mental fatigue and diminish our productivity. Having the right tools can help us face conflicts confidently.  AI Generated with Microsoft Copilot + Designer by Beolle   Recently, I took a course from Harvard ManageMentor® * to enhance my conflict resolution skills. I summarized the key takeaways from the course in the framework below to help you better prepare for resolving conflicts. The framework consists of six (6) parts Identify the type of conflict   Identify your own and your counterpart's conflict styles   Determine how you want to address the conflict   Prepare to resolve...

This blog uses cookies to improve your browsing experience. Simple analytics might be in place for pageviews purposes. They are harmless and never personally identify you.

Agreed