Criando uma cultura de On-Call saudável

• Dicas da SoundCloud sobre “on-call”, em que se designa um engenheiro para ser acionado (paging) e resolver problemas que ocorram fora do horário de trabalho

1. O trabalho de on-call é opcional (Optional, apenas para quem se voluntaria)

2. Como é trabalho fora do expediente regular, é pago com adicional por hora, e há pagamento extra por hora ao responder a um paging

3. Os engenheiros de on-call são organizados em várias rotações

4. Cada rotação

→ é composta por um grupo de engenheiros que representa uma ou mais equipes

→ sempre mantém 1 engenheiro de prontidão para fazer o suporte de 1º nível para problemas de todas as equipes da rotação

→ os demais engenheiros ficam de prontidão para fornecer suporte de 2º nível para problemas relacionados aos serviços de suas próprias equipes

→ o suporte de 2º nível é baseado em best-efforts: a pessoa pode ser acionada a qualquer momento e faz o melhor possível para resolver, mas não é obrigada a responder se não puder

Por que o trabalho de on-call é bom para os engenheiros?

• Colocar em on-call diversos engenheiros além de DevOps e SRE (Site Reliability Engineers) é bom tanto para a empresa quanto para os próprios engenheiros

• Reduz a carga sobre os engenheiros de operações, que normalmente têm muito trabalho fora do horário

• Motiva os engenheiros a construir sistemas estáveis e bem documentados

→ ver os problemas diretamente quando eles acontecem gera insights sobre como melhorar e fortalecer o sistema

• Dar suporte tanto aos próprios sistemas quanto aos de outras pessoas é uma ótima oportunidade de aprendizado para os engenheiros

Boas práticas de processo: cada organização é diferente, mas este é o processo ideal que a SoundCloud encontrou

• Cada rotação tem um ciclo de troca diferente, mas a maioria troca a cada 1 ou 2 dias

• O ideal é entrar em on-call por cerca de 3 dias por mês. Mais do que isso leva a burnout; menos do que isso não é eficiente.

→ ou seja, o tamanho ideal de uma rotação é de 8 a 12 pessoas. Com 10, fica perfeito.

• Dentro da rotação, escolhem-se gestores formais ou informais para administrar a escala, mudanças de pessoal e outros aspectos da rotação

→ ex.) ajustes na escala durante períodos de feriado

As equipes de rotação e as organizações

• A organização da SoundCloud evoluiu ao longo do tempo, com fusões, divisões, criação de novas equipes e movimentações entre departamentos

• No entanto, as equipes de rotação de on-call não evoluíram na mesma velocidade que a organização de engenharia

• Hoje, muitas rotações às vezes parecem grupos aleatórios de equipes sem qualquer relação entre si

• Mas isso não tem sido um problema, e tentativas de mudar isso foram interrompidas após objeções dos engenheiros

Boas práticas culturais: para o benefício dos engenheiros de on-call e da empresa como um todo, é importante cultivar normas e atitudes como estas

• As pessoas que estão em on-call querem estar em on-call. Engenheiros que assumem voluntariamente essa responsabilidade (e são remunerados por isso) ficam mais motivados ao responder incidentes

• Questões como o ciclo de troca são decididas em conjunto pelos engenheiros de cada rotação. A empresa não fornece um procedimento padrão para padrão de troca, horário da troca ou passagem de plantão entre indivíduos

• Engenheiros de on-call frequentemente gastam tempo, durante o expediente regular, investigando para evitar que esses problemas piorem ou que seja necessário acionar outras pessoas fora do horário de trabalho

• Ao responder incidentes, os engenheiros podem chamar outros engenheiros e pedir ajuda. Ninguém gosta de receber um chamado de suporte de 2º nível no meio da noite, mas, se puder, a pessoa responde e ajuda, o que também permite ensinar para que no futuro a mesma situação possa ser tratada sozinha

• Depois de um tempo razoável, é possível passar o trabalho livremente para outra pessoa. Em incidentes graves ou de longa duração, se os engenheiros estiverem cansados demais para trabalhar com eficiência, é melhor transferir em até 4 horas ou até antes disso

• O mais importante é “cultivar uma cultura de aprendizado, não uma cultura de culpa”. É impossível enfatizar isso demais

→ erros são uma parte inevitável da resposta a incidentes, e aprender com eles constrói uma organização de engenharia mais forte e tecnicamente mais capaz

→ se as pessoas forem punidas por erros, os engenheiros passam a ter medo de agir em situações novas, medo de pedir ajuda e medo de transparência

→ no fim, em uma cultura de culpa, as pessoas acabam saindo da rotação de on-call ou deixando a empresa

Quando acontece um grande incidente

• Responder a uma queda total do site ou a um incidente grave é estressante para todos

• Isso também funciona como um teste de estresse da cultura de on-call da empresa

• Mais do que qualquer outra coisa, é fundamental que os engenheiros trabalhem juntos e confiem uns nos outros

• Quando as pessoas conseguem admitir o que não sabem, pedir ajuda, falar honestamente sobre os próprios erros e dizer que estão cansadas demais para continuar, os problemas podem ser resolvidos mais rapidamente

• Estimular esse tipo de comportamento precisa acontecer antes de um grande incidente. Os engenheiros aprendem com a experiência ao responder pequenos incidentes e colaborar com colegas.

→ pequenos incidentes são treino para grandes incidentes

[xguru]

• A cultura de on-call construída pelo GitHub https://pt.news.hada.io/topic?id=3551

• Runbooks de on-call do GitLab https://pt.news.hada.io/topic?id=966

Como startups não têm muita gente, dá a sensação de que é preciso ficar sempre de on-call, mas...

Quando a organização começa a crescer um pouco, só algumas pessoas acabam ficando sempre de on-call, e dá para ver o burnout acontecendo enquanto resolvem problemas à noite e nos fins de semana.

Acho que, no fim das contas, o mais importante é formar bem essa cultura (na verdade, eu mesmo acho que não fiz isso tão bem e estou refletindo sobre isso...)