Salve jovens!! Se você é de uma time DevOps, SRE ou de um time de Observability que lida com ferramentas de monitoração eu posso apostar que você já viu em algum lugar ou alguém já te pediu pra gerar as métricas de SLA, SLI e SLO de algum produto ou de alguma infraestrutura.

Sss o que Léo?!? SLA, SLI e SLO, calma, calma eu explico. Para começar, SLAs, SLIs e SLOs são siglas que em inglês significam: SLA (Service Level Agreements), SLI (Service Level Indicators) e SLO (Service Level Objectives), calma jovem tem mais coisas. Apesar das siglas, SLA, SLI e SLO são ferramentas utilizadas para garantir a confiabilidade e o desempenho de serviços em ambientes de tecnologia. Cada uma delas desempenha um papel distinto, veja:

• SLA (Service Level Agreements) Os SLAs são contratos formais entre um provedor de serviços e seus clientes. Elas definem as expectativas de desempenho de um serviço, as responsabilidades das partes e as consequências em caso de não cumprimento, além de estabelecer um padrão de qualidade e fornecer uma base para medir a satisfação do cliente. Por exemplo, a energia da sua casa é constante ou é comum as interrupções? Eu moro em SP, basta um ventinho mais forte que cai a energia e demora a voltar, logo, a concessionária tem uma SLA muito ruim. As SLAs servem para definir claramente as expectativas do cliente, também fornecem uma estrutura para gerenciar e resolver problemas, procedimento em caso de falha, tempo de resolução e por fim estabelecem responsabilidades e penalidades em caso de falhas no serviço.

• SLI (Service Level Indicators) Os SLIs são métricas quantificáveis que medem o desempenho de um serviço, elas fornecem dados objetivos sobre a qualidade do serviço, além de permitem monitorar o desempenho ao longo do tempo e identificar tendências e problemas. Com as SLIs é possível obter dados para avaliar o desempenho do serviço, identificar áreas de melhoria e com esses dados trabalhar na detecção e resolução de problemas. São métricas que medem aspectos específicos do desempenho de um serviço, por exemplo, taxa de erros de uma interface, latência de um canal de comunicação e disponibilidade de um componente.

• SLO (Service Level Objectives) Antes da definição formal, é importante saber. SLOs e SLIs alinham os times internos em torno de metas comuns de desempenho, garantindo que todos estejam trabalhando para os mesmos objetivos, blz? Times internos guardem isso, blz? Os SLOs são indicadores de desempenho que impactam a experiência do usuário que as equipes definem para cumprir os requisitos do SLA. Eles são baseados nos SLIs e representam o nível de desempenho desejado, elas fornecem um foco para os esforços de melhoria e permitem monitorar o progresso em direção às metas. Os times usam os SLOs como metas claras e mensuráveis para o desempenho do serviço, monitorando o progresso em direção às metas e ajudando nas definições de investimentos e prioridades.

Em resumo, resumido: Os SLIs medem o que está acontecendo. Os SLOs definem o que deve acontecer. Os SLAs documentam o que foi acordado entre as partes e fornecem meios para uma parte cobre da outra a qualidade do serviço prestado.

Definindo as métricas

Entendi esse lance de SLI, SLA e SLO. Como eu aplico isso aeee lá onde eu trabalho? Ótima pergunta. vamos pensar assim; faz de conta que você é responsável por uma API de pagamento, blz? Como a gente cria as SLIs, SLAs e SLOs para sua aplicação?

Primeira coisa, definir o que é importante para a sua aplicação, vamos definir três coisas muito importantes, pode ter mais coisas, mas para o exemplo vamos ficar só com três. Taxa de sucesso de pagamentos; Latência de resposta e Taxa de erros. Vamos melhorar essa definição, melhorar é claro, as coisas tem que ser específicas, temos que dizer o “O que?” e “O Por que”.

• Taxa de Sucesso de Pagamentos:

  O que? Mede a porcentagem de transações que são processadas com sucesso.

  O Por que? É para garantir que os clientes possam efetuar pagamentos.

• Latência de resposta

  O que? Mede o tempo que a API leva para responder a uma solicitação de pagamento.

  O Por que? Impacta diretamente a experiência do usuário, especialmente em compras on-line.

• Taxa de erros

  O que? Mede a porcentagem de solicitações que resultam em erros (por exemplo, erros de autenticação, erros de processamento).

  O Por que? Indica problemas na API ou em sistemas dependentes.

Muito bem, já temos as nossas métricas definidas, devidamente explicadas agora só falta calcular.

Calculando as métricas

Times de DevOps e SRE não faz só deploy não, a gente precisa fazer umas continhas de vez em quando, não se assusta não é coisa simples.

• Taxa de sucesso de pagamentos: $$( Número de solicitações bem sucedidas / Número total de solicitações) * 100%$$

Unidade de medida em porcentagem

• Latência de resposta:

$$Média = (Σ tempos de resposta) / (Número de solicitações)$$ Unidade de medida em Milissegundo (ms)

Percentis (por exemplo, 95º percentil) é uma métrica usada para entender a distribuição da latência e identificar valores atípicos. O 95º percentil representa o valor abaixo do qual 95% dos tempos de resposta se encontram.

• Taxa de erros

(Número de solicitações com erros / Número total de solicitações) * 100% Unidade de medida em porcentagem (%)

Definindo as SLAs, SLIs e SLOs

Muito bem, já temos as definições de cada métrica. Já sabemos como calcular as métricas. Agora vamos juntar tudo e criamos as SLAs, SLIs e SLOs, para uma API de pagamento, utilizando as métricas que nós definimos.

SLIs

• Taxa de Sucesso de Pagamentos: Métrica: Número de transações de pagamento bem-sucedidas dividido pelo número total de transações de pagamento. Unidade de medida: Porcentagem (%). Exemplo: (Transações bem-sucedidas / Transações totais) * 100%.

• Latência de Resposta: Métrica: Tempo decorrido entre o envio de uma solicitação de pagamento e o recebimento da resposta da API. Unidade de medida: Milissegundos (ms). Exemplo: Tempo médio de resposta, percentil 95 da latência.

• Taxa de Erros: Métrica: Número de solicitações de pagamento que resultaram em erros dividido pelo número total de solicitações de pagamento. Unidade de medida: Porcentagem (%). Exemplo: (Solicitações com erros / Solicitações totais) * 100%.

SLOs

• Taxa de Sucesso de Pagamentos: Objetivo: 99,9% das transações de pagamento devem ser processadas com sucesso. Justificativa: Garante que a grande maioria dos pagamentos seja concluída sem problemas.

• Latência de Resposta: Objetivo: A latência média de resposta deve ser inferior a 200ms, e 95% das requisições devem ser respondidas em menos de 500ms. Justificativa: Mantém a experiência do usuário rápida e responsiva.

• Taxa de Erros: Objetivo: A taxa de erros deve ser inferior a 0,1%. Justificativa: Minimiza a ocorrência de problemas durante o processamento de pagamentos.

SLA

• Disponibilidade:

  • Compromisso: A API de pagamento estará disponível 99,9% do tempo, excluindo janelas de manutenção programadas.

  • Consequência: Em caso de indisponibilidade superior a 15 minutos, o cliente receberá um crédito de serviço de 5% sobre o valor das transações afetadas.

• Desempenho:

  • Compromisso: A API de pagamento cumprirá os SLOs definidos acima (taxa de sucesso, latência, taxa de erros).

  • Consequência: Se a taxa de sucesso de pagamentos cair abaixo de 99,8% por um período de 1 hora, o cliente será notificado e a equipe de suporte investigará o problema com prioridade máxima. Se a latência média exceder 300ms por um período de 1 hora, o cliente será notificado e a equipe de suporte investigará o problema com prioridade máxima. Se a taxa de erros exceder 0,2% em um período de 1 hora, o cliente será notificado e a equipe de suporte investigará o problema com prioridade máxima.

• Suporte:

  • Compromisso: Tempo de resposta para incidentes críticos: 15 minutos. Tempo de resolução: 4 horas.

  • Consequência: Caso os tempos de resposta e resolução sejam excedidos, será atribuído um crédito de 5% sobre o valor das transações afetadas.

• Manutenção:

  • Compromisso: Janelas de manutenção programadas serão comunicadas com antecedência mínima de 24 horas.

  • Consequência: Caso a manutenção não programada cause inatividade da API, será atribuído um crédito de 5% sobre o valor das transações afetadas.

Conclusão

Jovens, acabamos de fazer um mergulho de 15 centímetros de profundidade no oceano de conhecimento do mundo DevOps e SRE e no universo dos SLAs, SLIs e SLOs, desvendando como essas ferramentas são cruciais para garantir a saúde e a confiabilidade de qualquer serviço. Para profissionais de DevOps e SRE, dominar cada etapa desse processo é mais do que um diferencial e uma necessidade.

Os times técnicos tem um vocabulário próprio de trabalho, parece uma linguagem de outro planeta, parece difícil, a gente sofre desse mal eu sei. Pessoas de times DevOps e SRE precisam conhecer a fundo cada um desses conceitos, esses conceitos vão te permitir criar sistemas mais robustos, responder a incidentes com agilidade e otimizar recursos de forma inteligente.

Mais uma coisa, à medida que você vai ficando mais sênior na carreira, você começa a assumir um papel de tradutor do tecnês para as métricas de negócio exercendo uma função vital na comunicação entre equipes técnicas e clientes, traduzindo dados complexos em informações claras, pense nisso pense em novas possibilidades!!

Abraços!

Vida longa e próspera a todos!!

Referências

• https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-sli-vs-slo-vs-sla
• https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-slis-slas-and-slos
• https://sre.google/sre-book/service-level-objectives/

Eu adoraria ouvir suas outras histórias e situações semelhantes ao que acabei de escrever neste post, você pode me encontrar em @infraascode_br ou linkedin.com/in/leonardoml/ .

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- --- As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.