Cultura Postmortem: Aprendendo com o Fracasso

Escrito por John Lunney e Sue Lueder
Editado por Gary O ’Connor

O custo do fracasso é a educação.

Como SREs, trabalhamos com sistemas distribuídos, complexos e de grande escala. Aprimoramos constantemente nossos serviços com novos recursos e adicionamos novos sistemas. Incidentes e interrupções são inevitáveis devido à nossa escala e velocidade de mudança. Quando ocorre um incidente, corrigimos o problema subjacente e os serviços voltam às suas condições normais de operação. A menos que tenhamos algum processo formalizado de aprendizado com esses incidentes, eles podem ocorrer ad infinitum. Se não forem verificados, os incidentes podem se multiplicar em complexidade ou até mesmo evoluir em cascata, sobrecarregando um sistema e seus operadores e, por fim, impactando nossos usuários. Portanto, postmortems são uma ferramenta essencial para SRE.

O conceito de postmortem é bem conhecido na indústria de tecnologia. Um postmortem é um registro escrito de um incidente, seu impacto, as ações tomadas para mitigá-lo ou resolvê-lo, a(s) causa(s) raiz(es) e as ações de acompanhamento para evitar que o incidente se repita. Este capítulo descreve os critérios para decidir quando realizar postmortems, algumas práticas recomendadas sobre postmortems e conselhos sobre como cultivar uma cultura postmortem com base na experiência que adquirimos ao longo dos anos.

Filosofia Postmortem do Google

Os objetivos principais de escrever um postmortem são garantir que o incidente seja documentado, que todas as causas raiz contribuintes sejam bem compreendidas e, especialmente, que ações preventivas eficazes sejam postas em prática para reduzir a probabilidade e/ou impacto de recorrência. Uma pesquisa detalhada das técnicas de análise de causa raiz está além do escopo deste capítulo (em vez disso, consulte o artigo “Root cause analysis for beginners”); no entanto, artigos, práticas recomendadas e ferramentas são abundantes no domínio da qualidade do sistema. Nossas equipes usam uma variedade de técnicas para análise de causa raiz e escolhem a técnica mais adequada para seus serviços. Postmortems são esperados após qualquer evento indesejável significativo. Escrever um postmortem não é punição – é uma oportunidade de aprendizado para toda a empresa. O processo postmortem apresenta um custo inerente em termos de tempo ou esforço, então somos deliberados ao escolher quando escrever um. As equipes têm alguma flexibilidade interna, mas os gatilhos postmortem mais comuns incluem:

• Tempo de inatividade visível ao usuário ou degradação além de um certo limite
• Perda de dados de qualquer tipo
• Intervenção do engenheiro de plantão (liberação de rollback, redirecionamento de tráfego etc.)
• Um tempo de resolução acima de algum limite
• Uma falha de monitoramento (o que geralmente implica descoberta manual de incidentes)

É importante definir os critérios de postmortem antes que ocorra um incidente, para que todos saibam quando um postmortem se faz necessário. Além desses gatilhos objetivos, qualquer parte interessada pode solicitar um postmortem para um evento.

Postmortem sem culpa é um princípio da cultura SRE. Para que um postmortem seja considerado realmente inocente, ele deve se concentrar em identificar as causas que contribuem para o incidente, sem indiciar qualquer indivíduo ou equipe por comportamento ruim ou inadequado. Um postmortem escrito sem culpa pressupõe que todos os envolvidos em um incidente tiveram boas intenções e fizeram a coisa certa com as informações que possuíam. Se prevalecer uma cultura de apontar o dedo e envergonhar indivíduos ou equipes por fazerem coisas “erradas”, as pessoas não revelarão os problemas por medo de punição.

A cultura da não culpabilização se originou nas indústrias de saúde e aviação, onde erros podem ser fatais. Essas indústrias nutrem um ambiente onde cada “erro” é visto como uma oportunidade para fortalecer o sistema. Quando postmortems passam de atribuição de culpa a investigação das razões sistemáticas pelas quais um indivíduo ou equipe tinha informações incompletas ou incorretas, planos de prevenção eficazes podem ser implementados. Você não pode “consertar” pessoas, mas pode consertar sistemas e processos para melhor apoiar as pessoas que fazem as escolhas certas ao projetar e manter sistemas complexos.

Quando ocorre uma interrupção, um postmortem não é escrito como uma formalidade a ser esquecida. Em vez disso, é visto pelos engenheiros como uma oportunidade não apenas de consertar uma fraqueza, mas de tornar o Google mais resiliente como um todo. Embora um postmortem não tenha como intenção apontar dedos, deve indicar onde e como os serviços podem ser melhorados. Aqui estão dois exemplos:

Apontando dedos

“Precisamos reescrever todo o complicado sistema de back-end! Ele está quebrando semanalmente nos últimos três trimestres e tenho certeza de que estamos todos cansados de consertar as coisas a cada uma ou duas semanas. Sério, se eu for avisado mais uma vez, vou reescrevê-lo eu mesmo…”

Sem culpa

“Um item de ação para reescrever todo o sistema de backend pode realmente evitar que essas páginas irritantes continuem a ocorrer, e o manual de manutenção para esta versão é bastante longo e realmente difícil de ser totalmente treinado. Tenho certeza de que nossos futuros plantonistas vão nos agradecer!”

Prática recomendada: evite culpar e mantenha-se construtivo(a)

Postmortem sem culpa pode ser difícil de escrever, porque o formato postmortem identifica claramente as ações que levaram ao incidente. Remover a culpa de um postmortem dá às pessoas a confiança para escalar os problemas sem medo. Também é importante não estigmatizar a produção frequente de postmortems por uma pessoa ou equipe. Uma atmosfera de culpa incorre no risco de criar uma cultura na qual incidentes e problemas são varridos para debaixo do tapete, levando a um maior risco para a organização. (Consulte “Just Culture: A Foundation for Balanced Accountability and Patient Safety” para mais informações.

Colabore e compartilhe conhecimento

Valorizamos a colaboração, e o processo postmortem não é exceção. O fluxo de trabalho postmortem inclui colaboração e compartilhamento de conhecimento em todos os estágios.

Nossos documentos postmortem são Google Docs, com um modelo interno. Independentemente da ferramenta específica que você usa, procure os seguintes recursos principais:

Colaboração em tempo real
Permite a coleta rápida de dados e ideias. Algo essencial durante o estágio inicial de criação de um postmortem.

Um sistema aberto de comentários/anotações
Facilita as soluções de crowdsourcing e melhora a cobertura.

Notificações de e-mail
Pode ser direcionado a colaboradores dentro do documento ou usado para inserir novos colaboradores para fornecer informações.

Escrever um postmortem também envolve revisão formal e publicação. Na prática, as equipes compartilham o primeiro rascunho postmortem internamente e solicitam que um grupo de engenheiros seniores avalie o rascunho para ver se está completo. Os critérios de revisão podem incluir:

• Os principais dados do incidente foram coletados para a posteridade?
• As avaliações de impacto estão completas?
• A causa raiz era suficientemente profunda?
• O plano de ação e correções de bugs resultantes têm prioridade apropriada?
• O resultado foi compartilhado com as partes interessadas relevantes?

Depois que a revisão inicial é concluída, o postmortem é compartilhado de forma mais ampla, normalmente com a maior equipe de engenharia envolvida ou em uma lista de e-mails interna. Nosso objetivo é compartilhar postmortems para o maior público possível que se beneficiaria com o conhecimento ou as lições transmitidas. O Google possui regras rígidas sobre o acesso a qualquer informação que possa identificar um usuário final, e até mesmo documentos internos como postmortems nunca incluem tais informações.

Prática recomendada: não deixar nenhum postmortem sem revisão

Um postmortem não revisado poderia muito bem nunca ter existido. Para garantir que cada rascunho concluído seja revisado, encorajamos sessões regulares de revisão para postmortem. Nessas reuniões, é importante encerrar quaisquer discussões e comentários em andamento, para capturar ideias e finalizar o estado.

Quando os envolvidos estiverem satisfeitos com o documento e seus itens de ação, o postmortem é adicionado a um repositório de equipe ou organização de incidentes anteriores. (Se quiser iniciar seu próprio repositório, o Etsy lançou o Morgue, uma ferramenta para gerenciar postmortems). O compartilhamento transparente torna mais fácil para outras pessoas encontrar e aprender com a postmortem.

Apresentando uma cultura postmortem

Introduzir uma cultura postmortem na organização é mais fácil de falar do que fazer; tal esforço requer cultivo e reforço contínuos. Reforçamos uma cultura postmortem colaborativa por meio da participação ativa da alta administração no processo de revisão e colaboração. A administração pode encorajar essa cultura, mas postmortem sem culpa são idealmente o produto da automotivação do engenheiro. No espírito de nutrir a cultura postmortem, os SREs criam atividades de forma proativa que disseminam o que aprendemos sobre a infraestrutura do sistema. Alguns exemplos de atividades incluem:

Postmortem do mês

Em um boletim informativo mensal, um postmortem interessante e bem escrito é compartilhado com toda a organização.

Grupo postmortem do Google+

Este grupo compartilha e discute postmortems internos e externos, práticas recomendadas e comentários sobre postmortems.

Clubes de leitura postmortem

As equipes organizam clubes de leitura postmortem regulares, nos quais um postmortem interessante ou impactante é trazido à mesa (junto com alguns refrescos saborosos) para um diálogo aberto com os participantes, não participantes e novos Googlers sobre o que aconteceu, quais lições o incidente transmitiu e o rescaldo do incidente. Frequentemente, o postmortem que está sendo revisado tem meses ou anos!

Roda do infortúnio

Os novos SREs costumam ser tratados com o exercício Roda do infortúnio (consulte “Disaster Role Playing” no Capítulo 28), no qual um postmortem anterior é reencenado com um elenco de engenheiros desempenhando os papéis definidos no postmortem. O comandante do incidente original ajuda a tornar a experiência o mais “real” possível.

Um dos maiores desafios da introdução de postmortems em uma organização é que alguns podem questionar seu valor devido ao custo de sua preparação. As seguintes estratégias podem ajudar a enfrentar este desafio:

• Facilite o postmortem no fluxo de trabalho. Um período de teste com vários postmortems completos e bem-sucedidos podem ajudar a provar seu valor, além de ajudar a identificar quais critérios devem iniciar um postmortem.
• Certifique-se de que escrever postmortems eficazes seja uma prática recompensada e celebrada, tanto publicamente por meio dos métodos sociais mencionados anteriormente, quanto por meio do gerenciamento de desempenho individual e de equipe.
• Incentive o reconhecimento e a participação da liderança sênior. Até mesmo Larry Page fala sobre o alto valor dos postmortems!

Melhor prática: recompensar visivelmente as pessoas por fazerem a coisa certa

Os fundadores do Google, Larry Page e Sergey Brin, são os anfitriões do TGIF, um evento geral semanal realizado ao vivo em nossa sede em Mountain View, Califórnia, e transmitido para os escritórios do Google em todo o mundo. Um TGIF de 2014 teve como foco “A arte do postmortem”, que apresentou a discussão sobre incidentes de alto impacto sob o ponto de vista da SRE. Um SRE apresentou um lançamento que ele havia promovido recentemente; apesar dos testes completos, uma interação inesperada inadvertidamente desligou um serviço crítico por quatro minutos. O incidente durou apenas quatro minutos porque o SRE teve a presença de espírito de reverter a mudança imediatamente, evitando uma interrupção muito mais longa e em maior escala.

Esse engenheiro não apenas recebeu dois bônus de colegas imediatamente depois em reconhecimento por sua maneira rápida e equilibrada como lidou com o incidente – O programa Peer Bonus do Google é uma maneira de outros Googlers reconhecerem colegas por esforços excepcionais e envolve uma recompensa simbólica em dinheiro – como também recebeu uma enorme salva de palmas do público da TGIF, que incluía os fundadores da empresa e uma audiência de numerosos Googlers na casa dos milhares. Além de um fórum tão visível, o Google tem uma série de redes sociais internas que geram elogios de colegas para postmortems bem escritos e tratamento excepcional de incidentes. Este é um exemplo de muitos em que o reconhecimento dessas contribuições vem de colegas, CEOs e todos os demais.

Melhor prática: peça feedback sobre a eficácia do postmortem

No Google, nos esforçamos para resolver os problemas à medida que surgem e compartilhamos inovações internamente. Nós regularmente pesquisamos nossas equipes sobre como o processo postmortem está apoiando seus objetivos e como o processo pode ser melhorado. Fazemos perguntas como: A cultura está apoiando seu trabalho? Escrever um postmortem envolve muito trabalho? (leia o Capítulo 5: Eliminando o trabalho pesado). Quais as melhores práticas que sua equipe recomenda para outras equipes? Que tipo de ferramentas você gostaria de ver desenvolvidas? Os resultados da pesquisa dão aos SREs nas trincheiras a oportunidade de pedir por melhorias que irão aumentar a eficácia da cultura postmortem.

Além dos aspectos operacionais de gerenciamento e acompanhamento de incidentes, a prática postmortem foi inserida na cultura do Google: agora é uma norma cultural que qualquer incidente significativo seja seguido por um postmortem abrangente.

Conclusão e melhorias contínuas

Podemos dizer com segurança que, graças ao nosso investimento contínuo no cultivo de uma cultura postmortem, o Google resiste a menos interrupções e promove uma melhor experiência do usuário. Nosso grupo de trabalho “Postmortems no Google” é um exemplo de nosso compromisso com a cultura de postmortems sem culpa. Este grupo coordena os esforços postmortem em toda a empresa: reunindo modelos postmortem, automatizando a criação postmortem com dados de ferramentas usadas durante um incidente e ajudando a automatizar a extração de dados de postmortem para que possamos realizar análises de tendências. Conseguimos colaborar com as práticas recomendadas de produtos tão díspares como YouTube, Google Fiber, Gmail, Google Cloud, AdWords e Google Maps. Embora esses produtos sejam bastante diversos, todos eles conduzem postmortems com o objetivo universal de aprender nas horas mais sombrias.

Com um grande número de postmortems produzidos a cada mês no Google, as ferramentas para agregá-los estão se tornando cada vez mais úteis. Essas ferramentas nos ajudam a identificar temas e áreas comuns para melhorias além dos limites do produto. Para facilitar a compreensão e a análise automatizada, recentemente aprimoramos nosso modelo postmortem (consulte “Exemplo Postmortem” no Apêndice D) com campos de metadados adicionais. O trabalho futuro neste domínio inclui aprendizado de máquina para ajudar a prever nossas fraquezas, facilitar a investigação de incidentes em tempo real e a reduzir os incidentes duplicados.

Fonte: Livro Google SRE