Princípios SRE
Escrito por: Alvaro Huanca e Kimmy Wu
Quando pensamos em um novo serviço ou aplicação, geralmente existem três partes envolvidas que chegam em um acordo do que será o entregável. De uma forma bem generalista, é envolvido o time de negócios, time de desenvolvimento e o time de operações. Cada um com o seu escopo de trabalho bem definido. Enquanto o time de desenvolvimento se preocupa com um código de qualidade e entregas rápidas, o time de operações se preocupa em manter o sistema “no ar” e o time de negócios está em busca da definição do escopo que atende o usuário final.
Onde entra o SRE ( Site Reliability Engineering)?
Em uma tradução livre do Benjamin Treynor Sloss “SRE é o que acontece quando você pede a um engenheiro de software para projetar uma equipe de operações.” As equipes de SRE se concentram em como os engenheiros de software executam nossos produtos e criam sistemas para realizar o trabalho que seria realizado, geralmente de forma manual, por sysadmins.
Com o SRE definimos não só metas e objetivos, mas também tentamos comunicar isso a toda a organização, desde desenvolvedores, SREs, colaboradores individuais, até vice-presidentes. Dessa forma, temos um senso compartilhado de responsabilidade pelo serviço e o que faremos se precisarmos desacelerar ou acelerar o seu desenvolvimento. Antes de falar sobre as métricas e objetivos, vamos explorar os 3 princípios do SRE.
Princípio 1 — A funcionalidade mais importante de um sistema é a confiabilidade
Esse primeiro princípio traz opensamento de que a confiabilidade de um sistema deve ser trabalhada durante o desenvolvimento da aplicação. Se durante o desenvolvimento da aplicação e a definição da sua arquitetura, a confiabilidade for tratada e priorizada,garante-se a sua importância.
Um sistema só é válido se ele conseguir ser utilizado pelos usuários, sendo assim, após a implementação é preciso garantir que ele esteja operando conforme o planejado. Dessa forma, ter o time pensando na confiabilidade como uma feature do sistema leva ao desenvolvimento de novas formas para suportar, operar e desenvolver com confiabilidade.
Princípio 2 — Nosso monitoramento não decide a confiabilidade — os usuários definem
Quando pensamos em confiabilidade, pensamos em garantir que umsistema seja confiável, criando uma confiança em quem usa o sistema. Dessa forma os sistemas de métricas vão dar um suporte para a identificação da confiabilidade, porém quem irá definir se um sistema é realmente confiável será o usuário final.
Por que o usuário final? O usuário, como uma pessoa que utiliza o sistema ou um outro sistema que depende do seu, é quem irá “sentir” o impacto da confiabilidade caso a aplicação apresente alguma falha, e é com esse usuário final que é preciso criar uma interlocução para garantir que a aplicação consiga ser utilizada.
Princípio 3 — Um software bem projetado só pode levar você a 99.9%, Operações bem projetadas -> 99.99%, Negócio bem projetado -> 99.999%
Quando pensamos na disponibilidade do sistema é normal receber respostas como: “quero o sistema mais disponível o possível”, “meu sistema precisa estar 100% do tempo funcionando”. É preciso deixar claro que 100% de disponibilidade é geralmente uma meta errada para os sistemas. 100% é recomendado para aplicações em que algo muito grave possa acontecer, por exemplo um marca passo, se tiver alguma falha muito grave isso pode afetar a vida de uma pessoa.
O que quer dizer não ter um sistema 100% disponível? Não quer dizer que o seu sistema vai falhar a todo tempo, mas isso que você terá uma margem para erros. Ter uma disponibilidade próxima de 100% é bem aceitável, e assim expressamos pelo número de “nove” na porcentagem de disponibilidade, como 99.99 (quatro noves de disponibilidade). Com esses “%” que faltam para o 100% podemos trabalhar em novas features, desastres/ falhas que podem acontecer, etc.
Para que o valor de 9 faça sentido para a aplicação, é necessário que o time de desenvolvimento, negócios e operações estejam alinhados, garantindo que o acordo de disponibilidade seja cumprido e que as decisões e ações sejam baseadas neste número.
Definindo os termos do SRE
Com os três princípios, entende-se que as métricas devem estar fortemente ligadas aos objetivos de negócio, para isso define-se o que é disponibilidade e qual o nível adequado, colocando todos na mesma página sobre o que será feito se se essas definições não forem cumpridas.
Os termos SLIs e SLOs são a maneira prescritiva pela qual o SRE pratica o princípio de DevOps de “medir tudo” e o termo SLA é um acordo a nível de negócio que define a disponibilidade do serviço para um usuário final e as penalidades quando se quebra essa disponibilidade.
Esses termos não são apenas abstrações úteis. Sem eles, você não pode saber se seu sistema é confiável, disponível ou mesmo útil, você não terá dados sobre se as escolhas que você faz estão ajudando ou prejudicando seus negócios.
SLI
SLIs são Service Level Indicators ou indicadores a nível do serviço, estas métricas informam sobre a integridade de um serviço, como a latência de solicitação, taxa de transferência de solicitação por segundo (no caso de um sistema em lote) ou falhas por número total de solicitações.
Esses indicadores são agregados ao longo do tempo e normalmente aplicamos uma função como um percentil (ex: P99, P75, P90) ou uma mediana. Os SLIs tem um formato consistente, essa consistência permite que ferramentas sejam construídas como lógicas de alerta e cálculo de orçamento de erros.
Assim, por exemplo, um bom SLI pode estar dizendo: a latência do P99 das solicitações recebidas nos últimos cinco minutos é inferior a 300 milissegundos? Ou, alternativamente, outro SLI pode ser: a proporção de erros em relação ao total de solicitações recebidas nos últimos cinco minutos é inferior a 1%? (Princípio 1).
Na imagem podemos ver um “Menu” de diferentes tipos de SLIs.
SLO
A disponibilidade de um sistema pode ser definida com uma meta numérica precisa, essa meta é o SLO ou Service Level Objective do nosso sistema. Futuras discussões sobre se o sistema está funcionando de forma confiável o suficiente ou quais alterações de design/arquitetura devem ser feitas, devem ser enquadradas em termos de continuar atendendo o SLO.
Os SLOs podem ser considerados limites superiores e inferiores:
- Se você tentar executar seu serviço de forma muito mais “confiável” do que precisa ser, estará retardando o lançamento de novos features que talvez poderia liberar, que deixariam seu cliente mais feliz do que ter um segundo extra de tempo de atividade (Principio 3).
- Em segundo lugar, os SLOs são uma expectativa que você está enviando para seus usuários, que, se de repente você começa a quebrar com muita mais frequência do que eles estão acostumados (porque você executa seu serviço no limite do seu SLO em vez de estar um pouco acima), seus usuários ficarão infelizmente surpresos (Princípio 2).
SLA
Um SLA normalmente envolve uma promessa a alguém que usa seu serviço, um exemplo é o SLA de Cloud Run. O SLO deve atender a um determinado nível durante um determinado período e, se não cumprir, geralmente algum tipo de penalidade é aplicada. Isso pode ser um reembolso parcial da taxa de assinatura do serviço pago pelos clientes para esse período ou tempo de assinatura adicional adicionado gratuitamente.
Se você está cobrando dinheiro de seus clientes, provavelmente precisará de um SLA.
Conclusão
Neste blogpost introduzimos o que é o SRE, explicando sobre os seus princípios e definições de objetivos e métricas.
Um Service Level Objective (SLO) é uma definição do desempenho desejado de um serviço para uma única métrica. Aspectos de um serviço como disponibilidade, latência e completude são todos mensuráveis e refletem características com as quais os clientes se preocupam. Tais medições são chamadas de Service Level Indicators (SLI). Um SLO é um limite de desempenho desejável para uma medição SLI.
SLOs não devem ser confundidos com os Service Level Agreements (SLAs). Um SLA é um contrato legal que contém um ou mais SLOs e especifica uma compensação financeira ao cliente por violar os SLOs.
