De Will Tipton, engenheiro de confiabilidade de sites, e Alex Bramley, engenheiro de confiabilidade do cliente

Nas últimas postagens, discutimos a importância da criação de um documento de política explícito que descreva como encaminhar violações de objetos de nível de serviço (SLO) e mostramos um exemplo real de um documento da equipe de engenharia de confiabilidade de sites (SRE) do Google. Nesta última postagem, temos um exercício sobre hipóteses para mostrar alguns cenários que aplicam a política e ilustrar casos extremos. Todos os cenários abaixo supõem um SLO de disponibilidade de "três noves" para um serviço em que metade do seu orçamento de erros é consumido por erros de segundo plano. Em outras palavras, nosso orçamento, ou limite, de erros é 0,1% e 0,05% de erros é considerado "normal".

Primeiro, vamos rever os limites da política:

  • Limite 1: alertas automatizados notificam a SRE de um SLO em risco 
  • Limite 2: os SREs concluem que precisam de ajuda para manter o SLO e encaminham o problema aos desenvolvedores 
  • Limite 3: o orçamento de erros de 30 dias foi esgotado e a causa raiz não foi encontrada. A SRE bloqueia versões e pede mais suporte da equipe de desenvolvimento 
  • Limite 4: o orçamento de erros de 90 dias foi esgotado e a causa raiz não foi encontrada. A SRE encaminha o problema à liderança executiva para alocar mais tempo da engenharia aos trabalhos de confiabilidade

Depois de relembrar esses pontos, vamos examinar as violações do SLO.

Cenário 1: a causa raiz de uma interrupção curta, mas severa, é rapidamente determinada como um problema de dependência

Cenário: uma implementação incorreta de uma dependência crítica gera uma interrupção de 50% por uma hora enquanto a equipe responsável pela dependência reverte a versão que apresentou o problema. Quando a reversão é concluída, a taxa de erro retorna aos níveis anteriores. A equipe identifica e reverte o commit que é a causa raiz. A equipe responsável pela dependência escreve um relatório de análise retrospectiva. Os SREs do serviço contribuem com algumas IAs para impedir a recorrência.

Orçamento de erros: considerando a disponibilidade de três noves, 70% do orçamento de erros de 30 dias foi usado apenas durante essa interrupção. O orçamento de 7 dias foi excedido e, considerando os erros de segundo plano, o orçamento de 30 dias também.

Encaminhamento: a SRE foi alertada para administrar o impacto na produção (limite 1). Se a SRE entender que a classe do problema (má configuração ou push binário) é suficientemente rara ou foi adequadamente reduzida, o serviço é "retornado ao SLO" e a política não determina outro encaminhamento. Isso é intencional. A política prioriza a velocidade de desenvolvimento, e bloquear versões exclusivamente pelo esgotamento do orçamento de erros de 30 dias contraria essa política.

Se o problema for recorrente (ou seja, ocorrer duas vezes na semana, consumindo mais de um quarto do orçamento de erros) ou se a recorrência for considerada provável, é hora de encaminhar para o limite 2 ou 3.

Cenário 2: uma interrupção curta, mas severa, que não tem causa raiz óbvia


Cenário: o serviço tem uma interrupção de 50% por uma hora, sem causa conhecida.

Orçamento de erros: como no cenário anterior, ou seja, o serviço excedeu seus orçamentos de erro de 7 dias e 30 dias.

Encaminhamento: a SRE é alertada para administrar o impacto na produção (limite 1). A SRE encaminha rapidamente o problema à equipe de desenvolvimento. A equipe pode solicitar novas métricas para obter maior visibilidade do problema, instalar alertas de fallback, e o SRE e a equipe envolvidos priorizam a investigação do problema para a próxima semana (limite 2).

Se, mesmo assim, a causa raiz não for determinada, o SRE suspenderá o lançamento de recursos após a primeira semana até que a interrupção saia da janela de medição de 30 dias do SLO. Mais membros das equipes de SRE e desenvolvimento são retirados das tarefas atuais para depurar ou tentar reproduzir a interrupção. Essa passa a ser a prioridade número um até que o serviço retorne ao SLO ou a causa raiz seja determinada. À medida que a investigação progride, as equipes de SRE e desenvolvimento partem para mitigação, soluções temporárias e desenvolvimento de defesas detalhadas. O ideal é que, quando a interrupção sair do horizonte do SLO, a SRE esteja confiante de que será mais fácil detectar a causa raiz em uma eventual recorrência e que ela não terá o mesmo impacto. Nessa situação, a equipe poderá justificar a retomada do lançamento de versões, mesmo sem ter identificado uma causa raiz concreta.

Cenário 3: um consumo lento do orçamento de erros com uma causa raiz mal determinada


Cenário: uma regressão afeta a produção no dia T, e o serviço começa a apresentar 0,15% de erros. A causa raiz da regressão escapa aos SREs e desenvolvedores por semanas. Eles tentam diversas correções, mas não reduzem o impacto.

Orçamento de erros: se não resolvido, o problema consumirá mensalmente 150% do orçamento mensal de erros.

Encaminhamento: o SRE envolvido é notificado via tíquete por volta de T+5 dias, quando o orçamento de 7 dias é esgotado. O SRE aciona o limite 2 e encaminha o problema à equipe de desenvolvimento por volta de T+7 dias. Por conta de algumas correlações com a maior utilização de CPU, as equipes de SRE e desenvolvimento envolvidas criam a hipótese de que a causa raiz dos erros é uma regressão no desempenho. Os desenvolvedores envolvidos encontram algumas otimizações simples e as aplicam. Elas entram em produção em T+16 dias como parte do processo normal de lançamento. As correções não resolvem o problema, mas agora é impraticável reverter duas semanas de lançamentos de código diários para o serviço afetado.

Em T+20 dias, o serviço excede o orçamento de erros de 30 dias, acionando o limite 3. A SRE interrompe o lançamento de versões e encaminha o problema para aumentar o envolvimento do desenvolvimento. A equipe de desenvolvimento concorda em montar um grupo de trabalho de dois desenvolvedores e um SRE, cuja prioridade é determinar a causa raiz e remediar o problema. Sem uma boa relação entre as mudanças no código e a regressão, o grupo começa a criar perfis de desempenho detalhados e remover mais gargalos. Todas as correções são agregadas em um patch semanal maior aplicado na versão de produção atual. A eficiência do serviço aumenta consideravelmente, mas a taxa de erros continua elevada.

Em T+60 dias, o serviço consome o orçamento de erros de 90 dias, acionando o limite 4. A SRE encaminha o problema à liderança executiva, que solicita uma quantidade considerável de esforço de desenvolvimento resolver a falta constante de confiabilidade. A equipe de desenvolvimento faz uma análise detalhada e encontra problemas de arquitetura. Após algum tempo, implementa novamente alguns recursos para eliminar um caso extremo de interação entre o servidor e o cliente. As taxas de erro voltam ao nível anterior. Os recursos bloqueados são lançados em lotes assim que o lançamento de versões é reiniciado.

Cenário 4: excursões transientes e recorrentes da SLI


Cenário: versões binárias causam picos transientes de erro que ocorrem com a versão diária ou semanal.

Orçamento de erros: se os erros não ameaçam o SLO de longo prazo, a SRE é a única responsável por garantir o ajuste correto do alerta. Por isso, considerando este cenário, suponha que os picos de erro não ameaçam o SLO em nenhum período superior a algumas horas.

Encaminhamento: inicialmente, o alerta baseado no SLO notifica os SREs. O processo de encaminhamento prossegue como no caso de consumo lento. Especificamente, o problema não deve ser considerado "resolvido" simplesmente porque a SLI retorna ao normal entre as versões, já que isso é insuficiente para recolocar um serviço no SLO. A SRE pode ajustar o alerta para que um consumo maior ou mais rápido do orçamento de erros acione uma página e pode decidir investigar o problema como parte do trabalho contínuo de confiabilidade do serviço.

Resumo


É importante simular situações de uso da política de encaminhamento em condições severas com cenários hipotéticos para garantir a eliminação de casos extremos inesperados e verificar se a política é clara. Divulgue amplamente esboços da política e use anexos para abordar os problemas detectados, mas não sobrecarregue a política com justificativas dos pontos de mudança escolhidos. Espere discussões prolongadas se seus colegas entenderem que suas propostas são controversas. Lembre-se de que o que mostramos aqui é apenas um exemplo. Uma equipe de SRE real que pretenda atingir a meta de alta disponibilidade provavelmente estruturaria a política de encaminhamento de forma diferente.