A cultura de on-call construída pelo GitHub
(github.blog)O GitHub era um grande sistema monolítico construído em Ruby on Rails.
A parte mais difícil da estrutura de on-call do monólito
-
Como incluía muitos produtos e funcionalidades em grande escala, a maioria dos engenheiros não se sentia confiante de que entendia suficientemente bem a base de código para responder a incidentes durante o on-call. Quando eram acionados, acabavam escalando para outras equipes e se sentindo mais como operadores de encaminhamento do que como engenheiros.
-
O intervalo entre plantões era longo, e cada período de on-call durava 24 horas. Os engenheiros faziam on-call no máximo quatro vezes por ano e não conseguiam adquirir contexto suficiente durante o plantão.
-
O monitoramento e o sistema de alertas estavam distribuídos entre várias equipes e, como a experiência de on-call se limitava a apenas 24 horas por vez, o monitoramento e a documentação de on-call não eram bem mantidos.
-
Como a maioria dos engenheiros não se sentia segura com o on-call do monólito, de 5 a 10 pessoas que conheciam bem o sistema inteiro acabavam participando de todos os incidentes de produção, gerando um desequilíbrio nas responsabilidades de on-call.
Nova cultura de on-call
Obstáculos organizacionais no trabalho
-
Foi criado um catálogo de serviços para deixar a propriedade dos arquivos mais clara, mapeando arquivos para serviços e depois serviços para equipes.
-
Como o monitoramento e os alertas estavam configurados para o monólito inteiro, cada equipe passou a criar o monitoramento da área pela qual era responsável.
-
Como havia muitas equipes para fazer esse trabalho, foi criado um issue no GitHub para cada equipe e fornecido um checklist.
Obstáculos culturais e educacionais
-
A pandemia teve um impacto negativo nas pessoas, então foi preciso adotar uma abordagem ainda mais centrada na empatia do que se imaginava inicialmente.
-
A maioria dos engenheiros não tinha experiência com on-call e também não tinha muita experiência operacional, então foram criados treinamentos. Foram definidos horários com especialistas em on-call, produzidas ferramentas e documentações suficientes e criado um canal no Slack para pedir ajuda.
-
Muitos engenheiros se preocupavam com o quanto o on-call afetaria suas vidas. Sem muita experiência, pode ser difícil ajustar o tempo da vida cotidiana durante o plantão. Para isso, foram reunidas dicas e truques de especialistas em on-call e adotadas medidas como permitir que outra pessoa pudesse dar cobertura caso um chamado fosse perdido. Como isso é um problema de falta de familiaridade, a sensação de conforto virá mais com o tempo e com a repetição de vários plantões do que com treinamento.
-
Havia muita preocupação com a possibilidade de não conseguir responder bem ao on-call, então buscou-se transmitir segurança de que cometer erros é aceitável e que, por melhor que se faça, incidentes inevitavelmente acontecerão.
-
Como cada produto tem um nível de severidade diferente, algumas equipes precisam responder em até 5 minutos, enquanto outras podem tratar isso no dia seguinte. Algumas pessoas dizem que isso é injusto, mas é apenas uma questão de interesses diferentes entre os engenheiros.
-
Ao aplicar mudanças, cada equipe não consegue dedicar muito tempo a melhorar a experiência de on-call. Quando o on-call não funciona adequadamente, é preciso melhorar o processo de on-call. Foi comunicado às equipes que cerca de 20% do tempo deve ser usado para pagar dívida técnica e cerca de 20% para melhorar a experiência de on-call, e isso exige uma visão de longo prazo da liderança.
4 comentários
Não entendo muito bem, em linhas gerais, o que é esse negócio de on-call... Seria algum tipo de pedido de suporte, talvez? Acho que não deve ser atendimento por telefone como acontece aqui no nosso país...
No caso da nossa empresa, normalmente chamamos de on-call o período de cerca de uma semana a cada dois meses em que respondemos em tempo real a falhas do sistema fora do horário de trabalho. Um app muito usado é o PagerDuty; quando ocorre uma falha com severity alta — como o surgimento de dead letters, ou quando a taxa de falha da API ultrapassa certo nível... — chega imediatamente um alerta no celular, e então acessamos pelo laptop da empresa, verificamos os logs e tomamos as medidas necessárias.
Pode pensar nisso como ficar de plantão.
Parece algo como plantão ou revezamento semanal. Ir revezando a resposta a incidentes...