O que é SLI, SLO, Error Budget e como isso evita a falência do SLA

8 min readFeb 7, 2022

Seguindo com a série de assuntos fundamentais de SRE (Site Reliability Engineering) esse artigo explica os conceitos de SLI (Service Level Indicators), SLO (Service Level Objectives), Error Budget e como essas ferramentas complementam a visão de medição de nível de serviço para evitar a falência do SLA (Service Level Agreegment).

Há algum tempo venho notando algumas deficiências na medição de serviços de TI apenas quando baseada no SLA (Service Level Agreegment). Vivemos em um mundo de serviços que estão cada vez mais complexos e distribuídos num emaranhado de diferentes tecnologias e arquiteturas de soluções de TI. É arquitetura baseadas em eventos de um lado, microserviços de outro, misturado com soluções monolíticas com várias tecnologias de gerenciamento de filas, sistemas operacionais, banco de dados e por ai vai. Sem falar que essas soluções podem ser onpremise, em cloud ou, de novo, tudo misturado.

E toda essa complexidade faz com que o SLA não consiga, sozinho, trazer as medições necessárias para TI entender a real saúde dos níveis dos seus serviços. É nesse cenário que entram os reforços: SLI, SLO e Error Budget.

Tá bom, mas o que é SLA?

SLA é um acordo entre o provedor e cliente para garantir que um determinado nível de serviço seja atingido. Ele é importante mas, quando sozinho, tem algumas fragilidades:

1- Normalmente o SLA é um contrato onde se estabelece o tempo mínimo de resposta do provedor de serviço para resolução de problemas. Até ai parece justo, porém, essa visão ilhada gera coisas do tipo: os atendimentos aos tickets estão todos com respostas dentro do tempo contratado, porém, o cliente continua insatisfeito com a solução de TI, pois apesar do SLA de atendimento estar ok o tempo de resposta para carregar o site do Ecommerce ou o tempo de processamento dos pagamentos (só para dar alguns exemplos) estão abaixo do que é esperado pelo cliente ou negócio;

2- Quando o SLA não é atingido é muito comum penalizar o provedor do serviço de forma financeira (multa). Isso acaba gerando um ecosistema de TI negativo e com silos, provedores defendendo apenas seus serviços e se protegento das multas e as organizações clientes achando que a penalização faz justiça. Na ponta fica o cliente, no meio dessa confusão de silos e com uma TI miope, sem capacidade de olhar todo o stack de confiabilidade do serviço e preocupada e ocupada na criação de notificações extrajudiciais sem fim.

E como ter uma TI que olha os serviços de forma holística, com um viés construtivo e proativo e alinhada com a expectativa do cliente ou negócio?

É aqui que entra o SLI, SLO e Error Budget como ferramentas complementares ao SLA para medir os serviços de TI.

O livro "Implementing Service Level Objectives" de Alex Hidalgo propõe a figura abaixo como stack de medição de confiabilidade dos serviços de TI:

SLI (Service Level Indicator)

A base do stack de confiabilidade é o SLI. O SLI é uma medição que é determinada através de uma métrica, ou uma coleção de dados, que representa alguma propriedade do serviço. O bom SLI é capaz de medir os serviços da perspectiva dos clientes.

É através do SLI que a TI é capaz de entender, de forma binária, se os serviços estão bons ou ruins. Por exemplo, o negócio pode entender que o tempo máximo para carregar a página de Ecommerce é de 2 segundos. Então é possível fazer uma conta básica da quantidade de acessos com menos de 2 segundos para carregar a página divido pelo total de acessos, algo como:

Acessos < 2 segundos: 79.987

Total de acessos: 81.876

SLI = Acessos < 2 segundos (79.987) / Total de acessos (81.976) = 0,9757 (97,57%).

E com esse tipo de cálculo você pode desenhar todo o value stream para um determinado serviço e definir os pontos de medição e como a medição será efetuada. Você pode medir coisas do tipo: respostas de sucesso de um http ou API, tempo de resposta, taxa de sucesso de processamento de arquivos, etc. Muito importante: é preciso entender qual é o intervalo de tempo dessa medição (para ser possível colocar isso em uma linha de tempo), mapear todo o value stream daquele serviço com os pontos de medições e ser capaz de explicar ou traduzir, do ponto de vista do negócio, o propósito e o resultado das medições.

SLO (Service Level Objectives)

O próximo nível do stack de confiabilidade é o SLO, que são informados pelos SLIs. O SLO nada mais é do que o alvo da porcentagem que o cliente ou o negócio espera do SLI. É o nível apropriado de confiabilidade visado pelo cliente ou negócio para o serviço.

Para exemplificar, voltaremos ao exemplo do SLI. Nele o valor calculado foi de 97,57%. Se o SLO para essa medição tiver o alvo de 97% então o tempo de carregamento da página, que foi calculado em 97,57%, está bom o bastante.

Um erro que já vi e que já presenciei é a definição de sucesso de 100%. Sistemas de TI dão erro, incidentes ocorrem, coisas param de funcionar. Obviamente definir qualquer SLO em 100% é um erro e um alvo que não será atingido.

No final, SLO indica quanto o serviço pode falhar ou não funcionar apropriadamente sem significar que os usuários ou o negócio ficarão chateados.

Como os SLIs, os SLOs também devem ser chancelados pelo cliente ou negócio.

Error Budget

Na descrição mais simples possível, o Error Budget é a representação de quanto um serviço pode falhar em um período de tempo.

Existem duas abordagens para realizar o cálculo do Error Budget:

1- Baseado em eventos: aqui você pensa em eventos "bons" e eventos "ruins". Que no final das contas é a quantidade de eventos "ruins" você pode ter antes de desapontar os usuários e gerenciar isso.

2- Baseado em tempo: o conceito aqui é sobre o "intervalo ruim de tempo". Por exemplo, se você define que em uma janela de 30 dias seu SLO tem o target de 99,9% significa que você pode ter 0,1% do tempo nesse período com falhas, ou, 43 minutos.

O poder do Error Budget está nas ações que podem e devem ser tomadas ao ultrapassar o limite de SLO da medição de algum serviço. Por exemplo, caso você atinja duas medições em um determinado período de tempo ultrapassando o limite do SLO você pode decidir parar todo o time e focar nas tarefas e backlog que vão trazer ganhos de confiabilidade. Ou, se o seu Error Budget estiver positivo, pode decidir colocar em produção alguma nova funcionalidade que conhecidamente pode trazer mais riscos de confiabilidade.

A figura abaixo representa o conceito dessa discussão. Ela foi retirada do livro "Implementing Service Level Objectives" de Alex Hidalgo.

Usando Error Budget para dirigir as discussões e decisões

Resumão em uma Figura

Então nesse exemplo (que confesso ser bastante simples) o SLI medido está em 97%, o SLO é de 95% e o Error Budget é de 5%. Ou seja, essa medição está acima da expectativa do cliente ou negócio.

Conclusão

Os conceitos de SLI, SLO e Error Budget são essenciais em para os SREs e para uma TI moderna e alinhada com o negócio. Através dessas medições é possível antecipar ações de estabilização de um serviço e guiar discussões e decisões em focar o time em entregas de novas funcionalidades (quando temos Error Budget sobrando) ou em ações de estabilização do serviço (quando temos Error Budget faltando). Conheço organizações onde se decidiu que em caso de atingimento do SLO, a squad interrompe os trabalhos de lançamentos de novas funcionalidades imediatamente e todos se voltam para a estabilização do serviço (praticamento o conceito de "corda de andon" do sistema Toyota).

Para finalizar, alguns pontos que eu considero importantes sobre SLI, SLO e Error Budget:

Todas as definições de números devem ser alinhadas com o cliente ou negócio;
Todas as medições devem ser documentadas com informações do tipo: de onde são coletadas, de quanto em quanto tempo, quem são os responsáveis pelo serviço, descrição de fácil entendimento ao negócio e o que será feito em caso de atingimento do SLO (isso gera transparência);
Não se engane, dependendo da complexidade do ambiente de TI o investimento em ferramentas de medição é considerável;
Não se engane parte II: implementar SLI, SLO e Error Budget é um processo e não um projeto, pois as necessidades do negócio pode mudar, o comportamento do cliente pode mudar… então é uma disciplina que precisa de constante e vigilante evoluções;
Não se engane parte III: provavelmente você vai precisar alterar algumas aplicações para que elas consigam disponibilizar as informações para montar as métricas, tem muita aplicação que não usa nenhuma biblioteca padrão de metrificação e logs, com isso fica bem difícil coletar as métricas para ter uma visão realmente completa do serviço. Nesse caso não existe outra escolha: é preciso evoluir a aplicação;
Os números devem ser de fácil entendimento e acessíveis ao cliente ou negócio, gerando assim um sentimento de responsabilidade compartilhada;
Não caia na tentação de criar mais silos, não crie um time de analistas de monitoração cuja a única responsabilidade é "configurar" os SLIs, SLOs e Error Budget nas ferramentas. Invés disso, crie uma governança sobre as ferramentas de medição e dê autonomia e responsabilidade para o time de SRE configurar, adicionar ou remover as métricas.

Siga a série de conceitos básicos de SRE:

Guia dos Conceitos Básicos (https://medium.com/@mclortizz/guia-dos-conceitos-b%C3%A1sicos-do-sre-ab91f0b7531d).
Vídeo sobre os Conceitos Básicos: https://www.youtube.com/watch?v=9uvS6WeCuVg&t=172s
SLOs e Error Budget (esse aqui).
Observabilidade (https://medium.com/@mclortizz/1e60194cc337).
Redução de Toil (https://medium.com/@mclortizz/o-que-%C3%A9-toil-quais-suas-caracter%C3%ADsticas-quais-s%C3%A3o-os-passos-para-a-redu%C3%A7%C3%A3o-d8e640fcb265).
Aprendizagem com a falha (e sem culpa) (https://medium.com/@mclortizz/post-mortem-sem-culpa-5a36f27b885b).

Algumas indicações de leitura:

Livro: Engenharia de Confiabilidade do Google (https://sre.google/sre-book/table-of-contents/)
Livro: The Site Reliability Workbook (https://sre.google/workbook/table-of-contents/)
Livro: Implementing Service Level Objectives (https://www.amazon.com.br/Implementing-Service-Level-Objectives-Practical-ebook/dp/B08FBP3ZRH/ref=sr_1_1?__mk_pt_BR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3MIYCGB33B6CT&keywords=implementing+service+level+objective&qid=1644255773&sprefix=implementing+service+level+objective%2Caps%2C201&sr=8-1&ufe=app_do%3Aamzn1.fos.25548f35-0de7-44b3-b28e-0f56f3f96147)
Artigo "Measuring and Evaluating Service Level Objectives" (https://serhatcan.medium.com/measuring-and-evaluating-service-level-objectives-slos-84b0dc740a0a)

Muito obrigado e fiquem ligados, em breve mais conteúdo sobre SRE!

Marcelo Ortiz
Engenheiro da Computação, mestrando em Ciência da Computação