Por que os times precisam de SLOs, SLIs e Error Budget?
Tags: sre, devops, cloud, braziliandevs
Published: 2024-03-17 18:04:57

Os SLOs (Objetivos de Nível de Serviço) são um instrumento para auxiliar na definição de quais tarefas de engenharia devem ser priorizadas. Ao avaliar o impacto previsto em nosso orçamento de erros (Error Budget), podemos identificar qual projeto trará mais benefícios para os nossos usuários.

## O que um SLO deve ser e o que ele deve abranger.

Um SLO estabelece um nível de confiabilidade alvo para os usuários do serviço. Acima deste limite, quase todos os usuários devem estar contentes com o seu serviço. No final do dia, a satisfação do usuário é o que importa (leia o texto:  [Confiabilidade: um dos recursos mais importantes de um sistema](https://dev.to/rafaelonline/confiabilidade-um-dos-recursos-mais-importantes-de-um-sistema-2pad))

> 100% de confiabilidade é o alvo errado

Alguns motivos para essa afirmação:

-   Mesmo que um sistema tenha 100% de disponibilidade, o cliente não experimenta os 100%. A jornada do cliente geralmente é longa e complexa, e qualquer um dos componentes ao longo do caminho pode falhar. À medida que você passa de 99% para 99,9% para 99,99% de confiabilidade, cada nove extra tem um custo maior, mas a utilidade para seus clientes se aproxima constantemente de zero.

-   Se você conseguir criar uma experiência 100% confiável para seus clientes e quiser manter esse nível de confiabilidade, nunca poderá atualizar ou melhorar seu serviço. A principal fonte de interrupções são mudanças.

-   Um SLO de 100% significa que você só tem tempo para ser reativo.

Uma vez que você tenha uma meta de SLO abaixo de 100%, ela precisa ser de propriedade de alguém na organização que esteja capacitado para fazer compensações entre velocidade e confiabilidade.

Por mais que o time SRE possa ser o guardião do SLO, o time do produto e de negócios devem estar envolvidos em todo o ciclo, sedo co-responsáveis nas definições e ações.

## O que medir: usando SLIs e Error Budget

SLI é um indicador do nível de serviço que você está fornecendo.

Recomendamos tratar o SLI como a razão de dois números: o número de eventos bons dividido pelo número total de eventos. Por exemplo:

> Número de solicitações HTTP bem-sucedidas / total de solicitações HTTP
> (taxa de sucesso)

O SLO é uma porcentagem alvo e o orçamento de erro é 100% menos o SLO. Por exemplo:

> Se você tiver um SLO de taxa de sucesso de 99,9%, um serviço que
> recebe 3 milhões de solicitações em um período de quatro semanas tem
> um orçamento de erros de 3.000 (0,1%) erros nesse período. Se uma
> única interrupção for responsável por 1.500 erros, esse erro custará
> 50% do orçamento.

Sua primeira tentativa de SLI e SLO não precisa ser perfeita; O objetivo mais importante é colocar algo em prática e medir, e configurar um ciclo de feedback para que você possa aprimorar a estratégia.

### Começando a definir SLIs

-   Escolha um aplicativo para o qual você deseja definir SLOs.

-   Decida claramente quem são os “usuários” nessa situação.
-   Considere as maneiras comuns como seus usuários interagem com seu sistema - tarefas comuns e atividades críticas.
-   Desenhe um diagrama de arquitetura de alto nível do seu sistema; Mostre os principais componentes, o fluxo de solicitação, o fluxo de dados e as dependências críticas.

Escolha um aspecto do seu sistema que seja relevante, mas fácil de medir - você sempre pode iterar e refinar mais tarde.

###  Estratégia baseada no Error Budget

Para implementar uma estratégia baseada em orçamento de erros, é necessário alcançar um estado onde:

-   Os SLOs foram aprovados por todas as partes interessadas como adequados para o produto.

-   Os encarregados de assegurar o SLO concordaram que é viável atingir este SLO em condições normais.
-   A organização se comprometeu a utilizar o orçamento de falhas para tomada de decisões e priorização.
-   Um processo para aprimorar o SLO deve ser definido.
    
Caso contrário, a conformidade com o SLO será apenas mais um indicador de desempenho em vez de uma ferramenta de tomada de decisão.

Error Budget é um assunto que merece um texto dedicado sobre o assunto ;)

## Aprimorando o SLO

Durante o processo de revisão de um SLO algumas perguntas podem ser feitas que irão nos ajudar a saber ser estamos no caminho correto ou não:

- Consideramos o SLO determinado como sendo adequado e possível cumprir em circunstâncias normais?

- O SLO tem ajudado a determinar qual trabalho de engenharia priorizar e qual projeto é mais benéfico para nossos usuários?

Ao refinar o SLO pense em como responder sim para essas perguntas.

## Concluindo

A implementação de SLOs, SLIs e Error Budget é uma estratégia essencial para equilibrar a confiabilidade do serviço e a velocidade de desenvolvimento. Ao estabelecer metas de confiabilidade realistas e mensuráveis, as equipes podem priorizar efetivamente o trabalho de engenharia e melhorar a satisfação do usuário.

A chave para o sucesso é a colaboração entre todas as partes interessadas e a adoção de um ciclo de feedback contínuo.

### Conheça os meus outros posts sobre SRE

- [Contribuições de uma equipe de SRE no ciclo de vida de um serviço](https://dev.to/rafaelonline/contribuicoes-de-uma-equipe-de-sre-no-ciclo-de-vida-de-um-servico-l6k)
- [Modelos de engajamentos de um SRE com um grupo de trabalho](https://dev.to/rafaelonline/modelos-de-engajamentos-de-um-sre-com-um-grupo-de-trabalho-11b2)
- [Compromissos de um SRE em um grupo de trabalho](https://dev.to/rafaelonline/compromissos-de-um-sre-em-um-grupo-de-trabalho-1m8f)
- [Razões para monitorar um sistema](https://dev.to/rafaelonline/razoes-para-monitorar-um-sistema-3jbo)