O documento discute os conceitos fundamentais da Engenharia de Confiabilidade de Sites (SRE), incluindo: (1) medir indicadores de desempenho e disponibilidade para garantir os níveis de serviço; (2) definir objetivos e indicadores de nível de serviço para monitorar o desempenho; (3) usar orçamentos de erro para equilibrar novas funcionalidades e disponibilidade.

1. SRE
Site Reliability Engineering
Engenharia de confiabilidade

2. Introdução
O que é SRE?

3. O que é SRE?
● Engenharia de confiabilidade de sites (SRE) é uma abordagem da engenharia de software
às operações de TI.
● O propósito do SRE é agregar confiabilidade ao sistema.
● Criar sistemas para realizar o trabalho feito manualmente (Toil) ou por equipes de operações.
● Buscar a maior velocidade de mudança sem violar um SLO (Service Level Objective)
● Monitoramento
● Resposta a emergências. MTTF (Mean Time to Failure) e MTTR (Mean Time to Repair)
● Eficiência e Performance

4. Capítulo 1
Medir e Garantir

5. Medir e Garantir
● Medir indicadores de performance, risco, custo, entrega, qualidade e
disponibilidade de uma aplicação e/ou produto.
● Avaliar 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.
● SLO`s, SLI`s e SLA`s e Error Budgets.

6. SLA (Service Level Agreement)
Acordos de nível de serviço.

7. SLA (Service Level Agreement)
● Nível contratual, explícito ou implícito, que um provedor, de qualquer coisa,
IaaS, PaaS, SaaS estabelece com seu cliente referente a disponibilidade. Esse
contrato nunca deve ser 100% de disponibilidade. Inclui consequências por
deixar de atender aos SLOs que eles contêm.

8. SLO (Service Level Objective)
Objetivos de nível de serviço

9. SLO (Service Level Objective)
● É o contrato interno, entre os times e produto. Normalmente ele é muito mais
apertado e rígido que o SLA. É 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 para mais.
● SLOS devem especificar como são medidos e as condições como são
validados.
○ 95% das chamadas GET dos clientes interessados em throughput serão construídas em < 1s
○ 99% das chamadas POST com payload <1kb dos clientes interessados em latência serão
concluídas em < 10ms

10. SLO (Service Level Objective)
● Engenheiros são um recurso escasso até mesmo nas maiores organizações. O
tempo da engenharia deve ser investido nas características mais importantes
dos serviços mais importantes

11. SLO (Service Level Objective)
● Um SLO adequadamente definido deve ser documentado em um local de destaque onde outras equipes
e partes interessadas possam revisá-lo. Esta documentação deve incluir as seguintes informações:
○ Os autores do SLO, os revisores (que verificaram a precisão técnica) e os aprovadores (que
tomaram a decisão comercial sobre se esse é o SLO correto).
○ A data em que foi aprovado e a data da próxima revisão.
○ Uma breve descrição do serviço para dar contexto ao leitor.
○ Os detalhes do SLO: os objetivos e as implementações do SLI.
○ Os detalhes de como o orçamento de erro é calculado e consumido.
○ A lógica por trás dos números e se eles foram derivados de dados experimentais ou
observacionais. Mesmo que os SLOs sejam totalmente ad hoc, esse fato deve ser
documentado para que futuros engenheiros que leiam o documento não tomem decisões
erradas com base em dados ad hoc.

12. SLI (Service Level Indicators)
Indicador de nível de serviço

13. SLI (Service Level Indicators)
● São as métricas que vamos utilizar para acompanhar como nossa situação
atual está em relação aos SLO's.
● Para seus primeiros SLIs, escolha algo que requeira um mínimo de trabalho de
engenharia.
● Seus SLIs devem ser específicos e mensuráveis.
● Sua primeira tentativa de SLI e SLO não precisa ser correta.
● exemplos:
○ Número de solicitações HTTP bem-sucedidas / total de solicitações HTTP (taxa de sucesso)
○ Número de chamadas gRPC concluídas com êxito em <100 ms / total de solicitações gRPC

14. Error Budget
Orçamento de Erro

15. Error Budget
● Margem de erro que temos para trabalhar nos nossos serviços. Normalmente
calculado como (100 - SLO) = Error Budget. Como 100 - 99,9 = 00,1% de erros
são aceitáveis.
● Uma forma justa de equilibrar novas features e preservar a disponibilidade
(equilibrar esforço versus riscos.).
● Error Budget oferece uma métrica clara e objetiva, onde os dois lados tenham
concordado.
● Uma vez que você esgote seu orçamento de erro (ou chegue perto de
esgotá-lo), você deve fazer algo para restaurar a estabilidade do seu sistema.

16. Error Budget
● Para adotar uma abordagem baseada em orçamento de erro para a Engenharia de Confiabilidade, você
precisamos atingir um estado em que o seguinte seja verdadeiro:
● Existem SLOs que todas as partes interessadas na organização aprovaram como adequados
para o produto.
● As pessoas responsáveis por garantir que o serviço atenda ao seu SLO concordaram que é
possível atender a este SLO em circunstâncias normais.
● A organização se comprometeu a usar o orçamento de erros para a tomada de decisões e
priorização. Esse compromisso é formalizado em uma política de orçamento de erro.
● Existe um processo em vigor para refinar o SLO. (Como melhorar o SLO?)

17. Error Budget
● A política de orçamento de erro também deve ser documentada e deve incluir as seguintes
informações:
● Os autores, revisores e aprovadores da política
● A data em que foi aprovado e a data da próxima revisão
● Uma breve descrição do serviço para dar contexto ao leitor
● As ações a serem tomadas em resposta ao esgotamento do orçamento
● Um caminho de escalonamento claro a seguir se houver desacordo sobre o cálculo ou se as
ações acordadas são apropriadas nas circunstâncias
● Dependendo do nível de experiência e especialização do público em orçamentos de erros,
pode ser benéfico incluir uma visão geral dos orçamentos de erros

18. Next
Como SRE se relaciona com DevOps
Medidas de controle
Cultura pós-morte: aprendendo com o fracasso

19. https://sre.google/sre-book/embracing-risk/
https://sre.google/sre-book/service-level-objectives/
https://blog.estabil.is/sre-error-budget/
https://www.nanoshots.com.br/2019/12/sre-slo-slis-nao-sabe-por-onde-com
ecar.html

20. https://fabriciogoncalves.com/
@espigah
https://www.linkedin.com/in/fabricio-goncalves-919a4424/