Como conduzir revisões de incidentes sem culpabilização que aprimorem o aprendizado em engenharia.

Um alerta é disparado às 02h10. Um engenheiro implementa uma alteração de configuração, o serviço de checkout começa a retornar erros e o responsável de plantão reverte a alteração 40 minutos depois. Na reunião de revisão, a primeira pergunta é "Quem implementou a alteração?". Em poucos minutos, a conversa se concentra no julgamento de uma pessoa às 2h da manhã, e ninguém questiona por que a alteração chegou à produção sem um alerta canary, por que o alerta demorou tanto para ser acionado ou por que o manual de procedimentos estava desatualizado.

Este é um cenário ilustrativo, não um caso real de cliente. É reconhecível porque acontece: uma análise de incidente que se concentra na última pessoa a agir produz uma narrativa simplificada e pouco aprendizado.

Este guia destina-se a gestores de engenharia e líderes de capacitação que desejam que as equipes aprimorem suas habilidades em analisar evidências de incidentes e definir melhorias que possam ser testadas. Ele aborda como identificar lacunas de habilidades em relação ao contexto, como estruturar a prática, como realizar o debriefing e como mensurar a eficácia das revisões.

O que significa e o que não significa "irrepreensível"

O livro "Site Reliability Engineering" do Google afirma claramente: para que uma análise pós-incidente seja verdadeiramente imparcial, ela deve se concentrar em identificar as causas que contribuíram para o incidente, sem indiciar nenhum indivíduo ou equipe por comportamento inadequado ou impróprio. O livro também descreve a premissa subjacente: todos os envolvidos agiram com boas intenções e fizeram o que era certo com as informações que possuíam.Livro do Google SRE, "Cultura Pós-Morte: Aprendendo com o Fracasso".)

Sem culpa não significa sem consequências. O mesmo capítulo espera que as análises pós-mortem terminem em ações com prioridade e responsável definidos. A investigação sem culpa ainda exige responsabilização, mas a responsabilidade passa de "quem causou isso" para "quem tornará o sistema mais seguro e até quando". Se suas análises ignorarem a segunda parte, você terá uma conversa agradável, não um processo de aprendizado.

1. Identifique o comportamento e seu contexto.

Comece com o comportamento específico que você deseja mudar. "Nossas análises de incidentes se concentram na última pessoa a agir" é observável. "Nossa cultura é focada em culpar os outros" não é.

Em seguida, questione se o problema reside na habilidade. O treinamento só pode corrigir algumas causas de baixo desempenho. Antes de construir qualquer coisa, separe três possibilidades:

1. Uma habilidade que falta. Os avaliadores não sabem como construir uma linha do tempo, distinguir um fator desencadeante de um fator contribuinte ou perguntar "o que fez com que essa ação parecesse razoável na época?".
2. Incentivos. As avaliações influenciam as discussões sobre desempenho, então as pessoas moldam seus relatos para se protegerem.
3. Gradientes de autoridade e respostas passadas. Um engenheiro júnior que levantou uma preocupação no trimestre passado e foi instruído a parar de ser negativo não levantará nenhuma nesta reunião, por mais bem treinado que seja.

Apenas o primeiro problema é de treinamento. Os outros dois são condições. Se você treinar a habilidade e deixar as condições como estão, as pessoas irão praticar algo que o ambiente de trabalho pune. Considere sua visão atual da causa como uma hipótese e teste-a com algumas conversas com engenheiros e uma análise de documentos de revisão recentes antes de se comprometer com um programa.

2. Defina as condições operacionais para a prática.

A prática só é válida se o ambiente de trabalho a aceitar. Antes de qualquer ensaio, combine esses pontos com as pessoas responsáveis ​​pelas avaliações:

• Responsabilidades aprovadas. Quem facilita, quem elabora o cronograma, quem fica responsável pelas ações de acompanhamento? Deixe os papéis explícitos para que o facilitador não improvise autoridade.
• Como os líderes recebem as preocupações. Se um engenheiro disser "a ferramenta de implantação me permitiu pular o canary", o que o diretor faz em seguida? Decida a resposta antecipadamente, por exemplo: agradeça, registre como um fator contribuinte e atribua uma ação.
• Resposta do supervisor. O treinamento da equipe exige uma resposta correspondente do supervisor. Se você treinar os engenheiros para se manifestarem nas avaliações, mas seus gerentes ainda perguntarem "de quem foi a culpa?", o treinamento será inútil.

Uma breve apresentação aos gestores sobre o processo de avaliação é tão importante quanto a formação para os participantes. Inclua uma declaração clara sobre como os documentos de avaliação são e não são utilizados na gestão de desempenho.

3. Desenhe um percurso de aprendizagem baseado no comportamento.

As diretrizes do Centro Eberly da Carnegie Mellon sobre objetivos de aprendizagem destacam o ponto importante de que os objetivos, as avaliações e as estratégias de ensino devem estar alinhados entre si (Centro Eberly, Objetivos de AprendizagemIsso é uma orientação de design, não uma evidência sobre qualquer ferramenta ou resultado específico, mas é um bom teste para este programa: se o objetivo é analisar evidências e concordar com melhorias testáveis, então apenas perguntas de memorização não podem ser a avaliação.

A taxonomia de Bloom é útil aqui como uma forma de descrever a demanda cognitiva da tarefa: analisar, avaliar, criar. Ela descreve o que a tarefa exige de uma pessoa. Não explica por que ela faz ou não faz a tarefa, portanto, não a utilize para diagnosticar a motivação.

Uma viagem viável tem três etapas.

Mantenha o caso realista e peça a um engenheiro experiente que o valide. Um caso tecnicamente incorreto ensina os avaliadores a desconfiarem do exercício.

4. Analise o cenário e faça um debriefing.

Eis como uma sessão de prática poderia ser conduzida com o cenário das 02:10. O pacote de evidências contém o log de implantação, a linha do tempo de alertas, a política de paginação, a solicitação de pull e o manual de procedimentos, todos fictícios.

Instrua o participante. "Explique por que o engenheiro insistiu na mudança naquele momento. Cite as evidências que você utilizou. Diga-nos de quais informações ou suporte adicionais você precisaria para ter certeza."

Uma resposta fraca soa assim: "O engenheiro deveria ter verificado o ambiente de teste." Ela menciona uma pessoa, não cita nenhuma fonte e não propõe nenhuma mudança.

Uma resposta mais robusta seria algo como: "O log de implantação mostra que a alteração foi implementada diretamente porque a etapa de canary é opcional na ferramenta. A solicitação de pull request teve um revisor que a aprovou após um período de 20 minutos. A página foi carregada 18 minutos após o início dos erros porque o limite de alerta estava definido para uma média de cinco minutos. Gostaria de saber quantas outras alterações neste mês ignoraram a etapa de canary e se os engenheiros de plantão já foram informados de que essa etapa é opcional. Ações propostas: tornar o canary obrigatório para este nível de serviço, responsável: equipe da plataforma, verificar: tentar uma implantação sem a etapa de canary em ambiente de staging e confirmar que ela está bloqueada; reduzir o período de alerta, responsável: líder de plantão, verificar: reproduzir os erros da semana passada em relação ao novo limite."

Observe o que o torna melhor. Ele utiliza evidências, menciona limitações e incertezas e termina em ações que podem ser testadas.

Agora, o debriefing. Não se limite a atribuir uma pontuação. Pergunte:

1. O que as evidências sustentavam e o que você presumia?
2. Quais das suas ações a equipe teria realmente autoridade para tomar?
3. O que tornaria mais fácil repetir esse comportamento na sua próxima avaliação real? O que tornaria mais difícil?

A terceira pergunta é a mais importante. Ela revela as condições da seção 2. Se três participantes disserem "meu gerente vai perguntar quem fez isso", você identificou uma restrição que o treinamento não consegue eliminar.

5. Avalie o comportamento e a continuidade.

A questão fundamental é: que evidências demonstrariam que os alunos conseguem analisar dados de incidentes e concordar com melhorias testáveis? Aqui está uma rubrica para começar. Trata-se de uma proposta para ser adaptada com um engenheiro experiente, e não de um padrão de prontidão validado.

Defina os erros críticos separadamente, por exemplo, apontar um indivíduo como a causa ou propor uma ação sem responsável. Uma pontuação total alta nunca deve ocultar uma falha crítica.

Em relação à medição em si:

• Qualidade da análise dos fatores contribuintes. Compare avaliações escritas antes do programa com avaliações escritas depois, pontuadas segundo os mesmos critérios por alguém que não sabe quais são quais. Utilize casos de acompanhamento não vistos, bem como casos reais.
• Acompanhamento. Conte a porcentagem de itens de ação que possuem um responsável, um teste e foram concluídos, em relação ao total de itens de ação levantados. Indique o denominador e o período de tempo.
• Combine a observação com as mudanças de processo. Assista a uma avaliação real. Veja o que aconteceu com os itens de ação posteriormente.

Tenha cuidado com o volume de relatos. Se mais preocupações e quase acidentes forem registrados após o programa, isso pode significar que a segurança melhorou, a confiança aumentou ou que uma nova ferramenta facilitou o registro. Uma queda pode significar menos problemas ou menos disposição para falar sobre o assunto. Analise o que mudou no mesmo período antes de atribuir qualquer mudança ao treinamento e evite afirmar um tamanho de efeito que você não mediu.

A orientação de Eberly acima define o alinhamento; não comprova que essa abordagem reduza incidentes. Mantenha seus próprios dados de referência e de acompanhamento e considere-os como evidências locais.

Quais limitações podem persistir mesmo após a melhoria das habilidades?

Seja honesto sobre esses pontos com seus patrocinadores:

1. A análise de documentos ainda pode influenciar as decisões de desempenho.
2. Sob pressão para cumprir prazos, as equipes podem deixar de lado ações que, embora custosas, seriam sensatas.
3. As ações entre equipes podem ficar paralisadas porque ninguém detém o controle total da área.
4. Engenheiros seniores ainda podem dominar a discussão.

Uma análise mais aprofundada não elimina esses problemas. Planeje mudanças de processo específicas para eles.

Colocando em prática com AhaSlides

AhaSlides A plataforma oferece suporte à aprendizagem adaptativa, à aprendizagem interativa e à transição entre o ensino ao vivo e o autodidático. Nesse processo, isso pode incluir uma etapa de preparação individual, uma sessão de estudo de caso ao vivo ou facilitada com perguntas abertas para que todos se comprometam com uma análise antes da discussão em grupo e uma tarefa de acompanhamento após a sessão. As funções específicas de criação, pontuação e geração de relatórios devem ser testadas em uma demonstração com seu próprio caso antes de serem utilizadas, e qualquer recurso que envolva IA, simuladores ou integrações com suas ferramentas de gerenciamento de incidentes deve ser tratado como externo até que seja demonstrado.

Próximo passo: Pegue a rubrica acima e adapte-a com um de seus engenheiros seniores, depois construa o caso que você usará.

Depois de elaborar o estudo de caso e a rubrica, explore como uma versão ao vivo e autodirigida dessa jornada poderia funcionar. AhaSlides.