- Status: Publicado
- Autor: Steven Thurgood
- Data: 19-02-2018
- Revisores: David Ferguson
- Aprovadores: Betsy Beyer
- Data de Aprovação: 20-02-2018
- Data de Revisão: 01-02-2019
Visão geral do serviço
O Serviço de Jogo Exemplo permite que usuários de Android e iPhone joguem uns com os outros. Novas versões do código do backend são lançadas diariamente. Novas versões dos clientes são lançadas semanalmente. Esta política se aplica tanto aos lançamentos do backend quanto aos dos clientes.
Metas
As metas desta política são:
- Proteger os clientes de falhas repetidas nos SLOs
- Oferecer um incentivo para equilibrar a confiabilidade com outras funcionalidades
Não-metas
Esta política não tem a intenção de servir como punição por falhas nos SLOs. Interromper mudanças é indesejável; esta política dá às equipes permissão para se concentrar exclusivamente na confiabilidade quando os dados indicam que a confiabilidade é mais importante do que outras funcionalidades do produto.
Política de falha em SLO
Se o serviço estiver operando dentro ou acima de seu SLO, então os lançamentos (incluindo mudanças de dados) prosseguirão de acordo com a política de lançamentos.
Se o serviço tiver excedido seu error budget na janela de quatro semanas anterior, interromperemos todas as mudanças e lançamentos, exceto para problemas P01 ou correções de segurança, até que o serviço esteja de volta dentro de seu SLO.
Dependendo da causa da falha no SLO, a equipe pode dedicar recursos adicionais para trabalhar na confiabilidade em vez de no desenvolvimento de novas funcionalidades.
A equipe deve trabalhar na confiabilidade se:
- Um erro de código ou erro de procedimento causou o serviço a exceder o error budget.
- Um postmortem revela uma oportunidade de suavizar uma dependência crítica.
- Erros mal classificados não consumiram o orçamento que teria feito o serviço falhar no SLO.
A equipe pode continuar a trabalhar em funcionalidades não relacionadas à confiabilidade se:
- A interrupção foi causada por um problema de rede de toda a empresa.
- A interrupção foi causada por um serviço mantido por outra equipe, que também congelou lançamentos para resolver seus problemas de confiabilidade.
- O error budget foi consumido por usuários fora do escopo do SLO (por exemplo, testes de carga ou testadores de penetração).
- Erros mal classificados consomem o orçamento, embora nenhum usuário tenha sido impactado.
Política de interrupção
Se um único incidente consumir mais de 20% do error budget ao longo de quatro semanas, a equipe deve realizar um postmortem. O postmortem deve conter pelo menos um item de ação P0 para abordar a causa raiz.
Se uma única classe de interrupção consumir mais de 20% do error budget ao longo de um trimestre, a equipe deve incluir um item P0 em seu documento de planejamento trimestral para tratar das questões no trimestre seguinte.
Escalation Policy
No caso de um desacordo entre as partes sobre o cálculo do error budget ou as ações específicas que ele define, a questão deve ser escalada ao CTO para que uma decisão seja tomada.
Contexto
Esta seção é um modelo, destinado a fornecer uma visão sucinta sobre error budgets para aqueles que não estão familiarizados com o conceito.
Error budgets são a ferramenta que o SRE usa para equilibrar a confiabilidade do serviço com o ritmo de inovação. Mudanças são uma fonte importante de instabilidade, representando aproximadamente 70% das nossas interrupções, e o trabalho de desenvolvimento para funcionalidades compete com o trabalho de desenvolvimento para estabilidade. O error budget forma um mecanismo de controle para desviar a atenção para a estabilidade conforme necessário.
Um error budget é 1 menos o SLO do serviço. Um serviço com SLO de 99,9% tem um error budget de 0,1%.
Se nosso serviço recebe 1.000.000 de requisições em quatro semanas, um SLO de disponibilidade de 99,9% nos dá um orçamento de 1.000 erros durante esse período.