SLI's, SLA's e SLO's :: Não sabe por onde começar com suas métricas? Comece por aqui!

TL; DR;  Um guia pra te levar do 0 ao 1 

Se SRE é hype, então vamos hypar do jeito certo!  Esse é um guia pra quem está começando uma jornada de SRE e tem dificuldades pra entender os fundamentos básicos ou com dificuldade de começar de algum lugar. Elaborei esse artigo pra ser simples, acessível e assertivo pra quem quer entender as principais métricas e descobrir por onde começar a medir e garantir a confiabilidade de seus produtos. 

O que faz um SRE? 

O papel do SRE, de uma forma bem alto nível são somente dois: Medir e Garantir. 

Medir indicadores de performance, risco, custo, entrega, qualidade e disponibilidade de uma aplicação e/ou produto.

Como garantir tudo isso? Avaliando arquitetura de infraestrutura, plataforma, qualidade de código, segurança, fluxos de entrega, implementando monitoramento, alertas que fazem sentido e encontrando pontos de melhoria de disponibilidade dos serviços. 

Mas isso ainda é muito complicado, e você não precisa colocar tudo isso num checklist pra poder começar. Esse artigo serve pra isso,  pra te fazer dar o primeiro passo e sair do 0 pro 1. 

E vamos começar pelo coração do que se considera Engenharia de Confiabilidade, os SLO`s, SLI`s e SLA`s e Error Budgets.

O que são essas siglas?

Parece complexo, muita gente vai escrever artigos com muito tecniquês pra explicar, mas é bem simples, vamos lá. Sem enrolar:

SLA (Service Level Agreement): É o nível contratual que um provedor, de qualquer coisa, IaaS, PaaS, SaaS estabelece com seu cliente referente a disponibilidade. Esse contrato nunca pode ser 100%. Se existe uma certeza nessa vida é que aplicações e serviços vão cair. Independente de tempo, criticidade e etc. O que podemos fazer é sempre adicionar 9`s nos nossos SLA`s, ao 99,999999 e além.

SLO (Service Level Objective): É o contrato interno, entre os times e produto. Normalmente ele é muito mais apertado e rígido que o SLA. Pois o mesmo é focado em melhorias, e adicionar mais 9`s aos nossos serviços. Caso o SLA seja de 99,9% de disponibilidade, seu SLO deve sempre mirar um 99,99 pra mais. Quando se atinge o SLO com segurança, aumente seu SLA público, e assim vai...

SLI (Service Level Indicators): São as métricas que você vai utilizar pra acompanhar como sua situação atual está em relação aos SLO's. Isso independe de ferramentas, pois são cálculos simples.

Error Budget: É a margem de erro que você tem pra trabalhar nos seus serviços.  Normalmente calculado como  (100 - SLO) = Error Budget. Como 100 - 99,9 = 00,1% de erros são aceitáveis.

Resumindo... 

No fim das contas, o SLA é o mínimo disposto em contrato, os SLO`s são os objetivos que você quer atingir além desse contrato, e os SLI são os indicadores que você vai utilizar pra acompanhar como estão o andamento desses objetivos. Fácil né?

E o Error Budget é simplesmente o quanto você pode ter de falhas dentro desse contrato, e como você está posicionado em relação a isso. Se você quer ter 99% de disponibilidade, seu error budget é de 1%,  mega simples né? E você quebra esse 1% em 100% e analisa quanto falta pra atingir esse budget, ou o quanto você passou dele. Não entendeu? Segura ai que a gente já vai te ajudar mais.

E pra que serve tudo isso? Qual a vantagem?

Simples, pra encontrar uma Estrela Guia.

O que seria uma Estrela Guia pro time? Uma, ou algumas poucas métricas, simples e objetivas que são fáceis de acompanhar e entender. E principalmente que façam sentido pra um escopo maior que o seu time.

E por incrível que pareça isso é MUITO difícil. Trabalhar com métricas em times de tecnologia de uma forma enxuta é muito complicado, principalmente entre vários times. Ou porque ninguém sabe o que medir, ou porque tem muita coisa sendo medida e fica difícil pra todo mundo acompanhar, ou porque métricas fornecidas e seguidas pelo time de infraestrutura não fazem sentido pros times de desenvolvimento, redes, produto e vice-versa (várias vezes).

Pra isso foram criados esses conceitos de SLO's, SLI's, Error Budgets e SLA's.

SLO's então. Qual meu objetivo? O quanto eu preciso entregar?

Vamos definir isso em 3 passos, mantendo um mindset de configuração e adaptação. A ideia desse artigo é te fazer começar de algum lugar. Então não se prenda em levantar tantas informações nesses primeiros passos. Vamos lá:


1) Sente, respire e formule duas frases:

• Eu preciso responder todas as requisições em menos de 200 milisegundos (coloque aqui a métrica que o seu coração mandar)
• Eu preciso ter 99% de disponibilidade pra minha aplicação, e vou medir isso semanalmente (coloque aqui a porcentagem e o período que vier na sua cabeça) 

2) Leve isso para o seu time: 

• Pegue essas duas métricas, converse com pessoas próximas do seu time, de outros times, com alguns desenvolvedores, sysadmins, testers, engenheiros de rede, sei lá. 
• Pegue feedback e lapide mais ainda para o que faz sentido pra realidade da aplicação. 

3) Leve isso pra sua gestão, junto com seu time 

• Defina esses acordos com bastante gente, seu time, seu gestor, líder técnico, ou alguém com papel de tomada de decisão, para que o ciclo de feedback seja o mais proveitoso possível.

 Lembrando que essas métricas fazem pouco sentido se não forem adotadas em conjunto. 

O que medir? O que definir como meus SLI`s?

Existem muitas coisas que podem ser medidas e se tornar estrelas guias do time. Mas vamos começar do feijão com arroz e nos limitar a duas métricas simples que fazem sentido na maioria dos casos. Disponibilidade e Tempo de resposta da aplicação. Então vamos começar com o básico e recomendado. O padrão RED, Rate, Errors e Duration. E como eu começo?

Disponibilidade: 

Medir disponibilidade é simples, No caso de um sistema web podemos seguir com o calculo básico de (Quantidade de requisições realizadas com sucesso / Quantidade total de requisições) * 100 

Em outros casos quando você não está tentando medir um sistema web, o calculo seria:  (Quantidade de tempo em uptime / Quantidade de horas acordadas) * 100 .

Response Time:

Response time é mais baba ainda, dependendo da ferramenta que você estiver utilizando pra olhar isso. Mas pode se tornar complexo dependendo do seu cenário. Mas basicamente é o tempo de resposta que o servidor leva pra responder um cliente.

Basicamente o cálculo é a média de http dispatch de todas as requisições. Algo como average('duration').

Exemplo de Dashboard de SLO's e SLI's

Medir response time de um microserviço é simples, mas de uma malha não.

Na minha humilde opinião, o principal ponto a ser medido é sempre a sensação do cliente final, que está "consultando o histórico de vacinas do cachorrinho dele",  ou "cadastrando um novo gatinho no cadastro de pets".  O cliente final não liga pra quantos microserviços estão por trás daquela solicitação enviada.  Por isso, considero o tempo de resposta do cliente final como um todo, por exemplo "o tempo que levou pra tirar tirar o relatório de vacinas" uma métrica mais importante do que medir o tempo em que  microserviço de cadastro de pets leva pra consultar o microserviço de vacinas.

É importante também, mas comece pelo simples e importante. O que for mais fácil e fizer sentido pra você. 

Com o tempo isso pode e deve evoluir. Como por exemplo, começar a tirar métricas da comunicação entre os serviços da malha e atingir objetivos de negócio. Assim como um SLO no futuro pode vir a se tornar algo do tipo: Com meu microserviço de análise de antifraude no ar, quero reduzir o número de chargebacks para menos de 0.05%. E assim vai...

Ainda não sabe por onde começar a medir? Comece com 10. 

O número 10 é um número mágico que veio na minha cabeça agora. Simplesmente porque é ridículo e absurdo. 

10% de erro é aceitável, e quero responder abaixo de 10s. 

Soa ridículo, né? Eu sei. Mas pelo menos vai te ajudar a encontrar onde você está. Essa primeira métrica sendo fácil de bater, vai te ajudar a encontrar a saúde e estado atual da sua aplicação.

Depois que começar a medir e entender o seu cenário, logo após o primeiro ciclo de métricas, abaixe a régua pra onde faz sentido real pra você.

E depois do feijão com arroz...

O que podemos monitorar depois que fizemos o básico? Como podemos evoluir nossas métricas?

• Monitoramento de disponibilidade e error rate por endpoints chaves;
• Quantidade de requisições que passaram do response time acordado, além da média; 
• Custo por aplicação; 
• Disponibilidade por feature, como por exemplo, feature de emissão de boleto, cartão, emissão de notas fiscais, envio de email e etc
• Error rate / Response time / Throughput baseado em padrões em dias do mês ou períodos do ano

Agradeço imensamente a todos que doaram uns 5 minutinhos do seu tempo pra revisar esse texto antes de ser publicado, foi de grande ajuda pra mim e eu agradeço de coração.

Espero que ele te ajude de alguma forma. Se te ajudou, conta pra mim!

Grande abraço!