Uma das grandes mudanças de mentalidade que precisamos desenvolver ao encarar incidentes de TI é que podemos (e devemos) aprender com os incidentes, encarando-os como oportunidades de crescimento e desenvolvimento.

E uma das abordagens mais assertivas para isso é o post mortem.

Como Carol Dweck citou em seu livro Mindset, todos temos o mindset de crescimento e o mindset fixo.

Por conta dos impactos financeiros que um Incidente acarreta para uma empresa, a maioria dos tomadores de decisão neste domínio possuem um mindset mais fixo. Algo como “sempre fizemos assim”.

Porém, como já comprovado por pesquisas realizadas pelo Google através do SRE e DORA Metrics, quanto mais você encara essas situações como aprendizado e dedica tempo para se debruçar sobre estes aprendizados, maior a probabilidade de evitar que tais situações ocorram novamente. 

 

O que é um Post Mortem?

Acredito que se você já pesquisou alguma coisa sobre Post Mortem, se deparou com o jargão “Blameless Post Mortem“.

Parece que estas palavrinhas estão sempre juntas. E assim devem ser, pois se completam como queijo com goiabada! (ah que polêmica).

Mais do que um documento, o Post Mortem é uma ferramenta que habilita a cultura do aprendizado com a falha e o blameless = sem culpa.

Introduzir um processo de postmortem em sua organização de TI é tanto uma mudança cultural quanto técnica. E esse é um dos pontos cruciais que você precisa entender.

Já vi empresas que implementaram a criação de um documento pós incidente, porém todas as pessoas na sessão estavam claramente amedrontadas de propor idéias e discussões saudáveis sobre o que poderia ter causado o erro, com receio de retaliações.

De nada adianta um documento que dá margem para omissão, pois a sombra do que realmente aconteceria, se a real causa do incidente fosse descoberta, ronda as mentes dos colaboradores.

Post Mortems podem ser uma ferramenta totalmente efetiva para direcionar mudanças organizacionais positivas e prevenir outages repetidos. Porém, somente se forem bem elaborados, com ações que realmente entram em backlog e são executadas. E se forem totalmente colaborativos e compartilhados.

De uma forma mais explícita: Post Mortem é um registro escrito do que ocorreu durante um incidente em produção, seu impacto, as ações tomadas para mitigação e resolução, as ações contribuintes para o incidente (causas raízes) e os Itens de ação derivados para prevenir que o Incidente ocorra novamente.

Mais detalhes sobre o que é, como implementar e realizar, você pode ver aqui:
https://sre.google/sre-book/postmortem-culture/ 

 

Como a segurança psicológica e a importância de uma cultura sem culpados é crucial para que o post mortem funcione corretamente?

“Em culturas organizacionais patológicas e burocráticas, medições são formas de controle, e as pessoas escondem informações que desafiam as regras, estratégias e estruturas de poder existentes. (…) Onde há medo, você terá números incorretos” (Humble et al. 2014, p.56).”  (tradução livre do livro Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations).

 

Acredito que Timothy Clark foi a pessoa que cunhou com mais pesquisa e aprofundamento o tema da segurança psicológica em seu livro “Os 4 estágios da segurança psicológica”. (se você conhece outros autores que falam sobre o tema de forma bacana, deixe aqui nos comentários para trocarmos sobre o assunto!)

Me remeteu um pouco ao modelo SHU-HA-RI do Lean. Mas basicamente o que Timothy nos ensina é que praticamente todo ser humano passa por 4 estágios até se sentir realmente psicologicamente seguro para se expressar de forma autêntica:

• Estágio 1. Será que eu consigo ser eu mesmo neste ambiente?
• Estágio 2. Será que eu consigo evoluir neste ambiente sem julgamentos?
• Estágio 3. Será que eu consigo trazer valor para este ambiente e será bem recebido?
• Estágio 4. Será que eu posso ser verdadeiro quanto à minha visão e me expressar respeitosamente, porém livremente sem medos de retaliações?

 

O gráfico abaixo nos demonstra o quanto são tênues os limites entre cada um destes pontos, sempre balizados pelo respeito e permissão, onde temos de ter atenção para que não seja um ambiente explorador, e nem paternalista.

Somente construindo um real ambiente seguro psicologicamente é que os times vão compartilhar suas ideias de forma genuína e sem medos de retaliações ou favoritismos.

É esse o ambiente que você quer promover para que seu post mortem seja efetivo para sua organização!

 

 

Quando e como realizar um Post Mortem?

Dependendo da quantidade de Incidentes hoje que você lida em sua companhia, você vai perceber que fazer Post Mortem para todos eles possa ser algo impraticável.

Post Mortem é uma ferramenta que vai te ajudar a entender quais são os caminhos que seu time precisa tomar e percorrer até o fim para evitar que Incidentes similares voltem a ocorrer.

Levando isto em consideração, surge a pergunta: Faz sentido realizar post mortem para Incidentes que não tiveram impacto relevante?

Em geral, como a realização do post mortem é algo que demanda um tempo de dedicação de profissionais qualificados, a recomendação é de que seja considerado obrigatório para Incidentes mais críticos que causam alto impacto financeiro. Mas é facultativo para demais incidentes.

Veja a seguir um passo a passo de como gerar um post mortem bem documentado.

Primeiro passo: Um resumo com data e hora dos acontecimentos no calor do momento.

A recomendação do início da escrita do Post Mortem é: o quanto antes, melhor!

Considerar que existem um tempo de expurgo de logs importantes a serem analisados para identificação do que pode ter acontecido é de suma importância.

Se você possui uma política de expurgo de logs da aplicação de 5 dias, e o seu post mortem é agendado para 7 dias após a ocorrência do incidente, certamente não terá nenhuma informação para analisar e será uma sessão bastante infrutífera.

Enquanto o incidente está acontecendo, se você não possui uma ferramenta de monitoração ou de ITSM que te proporcione isso, é importante montar uma linha do tempo do que está acontecendo durante o incidente.

Segundo passo: Declarar o impacto do incidente

Nem sempre é possível identificar o impacto do incidente enquanto ele está acontecendo e, principalmente, relacionar este impacto ao negócio.

É importante ter uma seção do documento dedicada a isso e evoluir a maturidade da descrição deste impacto para cada Incidente.

Um exemplo ruim: 3 pods do cluster A da aplicação B

Um exemplo bom: XXX usuários afetados, resultando em uma estimativa financeira de R$xxx de perda.

Terceiro passo: Descrever a resolução do incidente

O terceiro item importante que todo bom post mortem deve conter, é a resolução.

As seguintes perguntas devem ser respondidas nesta seção do documento:

• A solução aplicada para resolver o incidente foi de contorno ou foi definitiva?
• Esta solução, sendo de contorno, é automatizada ou manual?

 

Quarto passo: Entender os fatores que contribuíram com o incidente

 

O próximo passo é entender quais foram os fatores contribuintes para que o Incidente ocorresse, a famosa causa raiz, que muitas vezes por ser referida no singular, limita as pessoas a pensarem que existe somente uma causa.

Prefiro chamar de fatores contribuintes, pois com o tempo percebemos que quase nunca existe uma única causa raiz. Ainda mais para ambientes cada vez mais complexos!

Este é o momento de colocar todos que trabalharam na resolução do Incidente e mais alguns especialistas (se estes não participaram) para conversar de forma aberta e segura. Trocar ideias e suposições através de análises conjuntas e sem apontar dedos, se atendo aos fatos da ocorrência.

De acordo com o Google, uma realidade frequente que encontramos nesse tipo de evento está ilustrada na imagem abaixo.

Somente com bastante aprofundamento da análise é que realmente conseguimos chegar nos reais fatores contribuintes.

É importante levar em consideração que esta sessão não deve ser feita muito tempo após a resolução do Incidente, para garantir que a maioria das pessoas ainda tenham fresco em suas memórias o que ocorreu, e que os logs ainda estejam disponíveis para análise.

Algumas recomendações variam de 48 horas a 3 dias úteis, precisando entender o que faz mais sentido para sua necessidade.

Itens de Ação

Ainda nesta sessão, são levantadas os Itens de Ações que serão tomadas para evitar que o Incidente ocorra novamente no futuro.

Os Itens de Ação devem ser listados pensando em um formato de lições aprendidas.

Peça para que o grupo reflita sobre as seguintes questões:

• O que aprendemos com este Incidente?
• Quais são as ações que podemos ter para garantir que ele não volte a acontecer?

De uma forma geral, você deverá sair com uma lista de itens que endereça os principais pontos abaixo:

• Garantir que a mitigação não gere mais impactos, no caso de o Incidente ter sido resolvido de forma mitigatória, e não definitiva, e se a mitigação ainda estiver gerando impactos (débito técnico urgente);
• Endereçar possíveis ajustes de protocolos e processos;
• Endereçar possíveis ajustes de monitoramento;
• Endereçar minimização e, se possível, resolução definitiva dos fatores contribuintes com maior risco levantados (débito técnico médio / longo prazo);
• Mapeamento de riscos. Nem sempre um Post Mortem irá tratar todas as causas raízes de forma definitiva, porém o fato de listarmos, e todos estarem cientes dos riscos da não resolução, pode ser o suficiente para o momento que seu produto estiver passando. 

 

Clareza da documentação

Garantir que a forma da escrita do Post Mortem seja clara e de fácil entendimento de todos é um ponto muitas vezes não é levado em consideração, mas que faz muita diferença para o aprendizado de todos. Principalmente para os que não participaram do Incidente e estão aprendendo com o seu incidente!

Os Itens devem ser específicos, ter uma ação real e ter uma clara definição de entrega.

Um exemplo de um item mal escrito seria: “Investigar a monitoração deste cenário”.

Um bom exemplo seria: “Adicionar alertas para todos os casos em que o serviço retornar >1% de erros”. 

Você pode encontrar modelos de post mortem em diversos lugares. Particularmente sou muito fã deste modelo da PagerDuty.

 

Como garantir que as ações levantadas estejam sendo endereçadas?

Para mim, esse é um dos pontos mais importantes de todo este fluxo de valor.

De que adianta realizar os demais 3 itens deste checklist, se no fim, as ações de fato não forem endereçadas de forma efetiva?

É este passo que muitas empresas não implementam e gerenciam de forma contínua, e passam a não confiar que o fluxo de valor de Post Mortem seja tão efetivo assim.

Minha sugestão aqui é pegar emprestado um pouco de conhecimento da Gestão de Problemas do ITIL, que possui uma sugestão bem estruturada e organizada para lidar com estas ações.

Algumas principais sugestões seriam:

Um lugar centralizado de registro dos Post Mortem e suas ações levantadas.

Pode ser uma seção no Confluence, uma ferramenta de ITSM e até mesmo uma sala no Slack. O que importa, é que seja de fácil acesso para todos, e simples de verificar o progresso dos itens

Classificação de ações

Classifique as ações criadas pelo post mortem em até 4 baldes: Ações imediatas, ações de médio prazo (até 4 semanas), ações de longo prazo (+ de 4 semanas), e ações de riscos levantados sem mitigação (accepted risks).

Colaboração e cultura blameless

Garanta que todos do grupo multidisciplinar da construção do post mortem, esteja confortável e de acordo com os baldes de cada ação, e que cada uma delas tenha uma data limite e uma pessoa responsável

 

Comitês

Realizar um comitê regular, a cada 15 dias ou semanal.

Você pode testar e ver o que funciona melhor para seu contexto, para entender se alguém do fórum está precisando de algum tipo de ajudar e fazer um recap dos Post Mortems com itens em aberto.

Há algo que o grupo pode fazer para ajudar o encerramento das ações ainda em aberto?

Temos evoluído bem na tendencia de diminuição dos incidentes?

Mais do que uma sessão de cobrança de ações, é importante manter nesta agenda também o mindset de crescimento, aprendizado e lições aprendidas.

Se não estipulamos prazos reais em algum post mortem e temos ações se arrastando por muitas semanas, qual o motivo disso?

Estamos com algum impedimento não mapeado que deveria se tornar uma nova ação do Post Mortem?

Testar

O mais importante de tudo isso, é testar. Essas sugestões são apenas baseadas na experiência e nos testes que eu vivi, nos ambientes que eu passei, mas cada contexto é um, e tentar realizar estes fóruns em cada contexto vai ser diferente!

 

Espero que este texto tenha te dado alguma dica ou ideia de que você ainda não tinha pensado, e te inspirado a cultivar e expandir a cultura de aprendizados na sua área de tecnologia!

 

Referências:

https://research.google/pubs/pub45906/

https://www.leaderfactor.com/4-stages-of-psychological-safety#:~:text=Psychological%20safety%20is%20a%20condition,or%20punished%20in%20some%20way.

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
https://sre.google/resources/practices-and-processes/anatomy-of-an-incident/

https://sre.google/sre-book/postmortem-culture/

https://www.atlassian.com/incident-management/get-the-handbook#