Em ambientes de TI complexos, não é realista dizer que os eventos nunca acontecem e, quando acontecem, a maneira como a equipe lida com isso é importante. Um processo bastante conhecido é a criação de um postmortem (português, “após a morte”), que geralmente é um documento destinado a ajudar a equipe a estruturar um processo de discussão e análise desses eventos.
Este documento geralmente contém: 1) uma descrição do que aconteceu e a causa raiz; 2) quando a indisponibilidade ocorreu; 3) qual o impacto que teve (por exemplo, perda de dados); 3) uma linha do tempo da ocorrência (tempo e descrição); 4 ) Quais ações foram tomadas para a solução; 5) e o que foi realizado após a ocorrência do problema para evitar que ele se repetisse e destacar as lições que a equipe aprendeu com a ocorrência.
Essa análise post-mortem também pode assumir a forma de uma reunião interna envolvendo aqueles em uma função de Engenharia de Confiabilidade do Site (SRE). O mais importante aqui é que houve um tempo em que a equipe conseguiu levantar todos os itens listados acima, compartilhar conhecimento e, nos períodos de indisponibilidade, documentar as ações tomadas para a posteridade, para que não só o problema possa ser analisado , mas o papel da equipe no comportamento do evento.
Para que tipos de eventos criamos postmortems?
Quando uma equipe decide adotar essa prática, é importante discutir os critérios para a criação da documentação. Alguns exemplos podem ser:
Quando seu sistema estiver indisponível por mais de um determinado período de tempo;
Quando ocorre perda de dados;
Quando a experiência do usuário é afetada;
Mesmo quando for necessário restaurar o sistema para uma versão anterior.
Qualquer empresa pode adotar?
Sim, não é necessário que sua empresa tenha um SRE – por exemplo – para usar a análise postmortem. Mais importante ainda, sua equipe falará e conhecerá os motivos da adoção do conceito, além de haver um processo a ser preparado quando ocorrer um evento. O uso após o fato não deve ser ativado passivamente, mas sua equipe deve estar sempre pronta para usá-lo. Dê tempo para a equipe discutir a autópsia em conjunto.
Para garantir que tudo seja discutido e as ações mapeadas após o evento sejam resolvidas, os estados de análise pós-evento podem ser empregados, como:
1) “aberto” quando não foi discutido;
2) E apenas aqueles que foram avaliados pela equipe ou que resolveram todas as ações como “fechadas”.
Agora que entendemos o que é a análise postmortem e o que ela faz para uma equipe, vamos entender o que é a não responsabilidade postmortem?
O que é Blameless postmortem?
Para garantir que o processo post-mortem seja maduro, não prejudique a equipe e não crie um ambiente cultural ruim, existe um conceito de análise post-mortem sem responsabilidade. Nesse formato tudo é feito sem nomear ou culpados, afinal o resultado que queremos aqui não é criar atritos, mas sim avaliar o que causou o problema e garantir que não volte a acontecer, ou seja, aqui O foco é nos eventos ou falhas , não pessoas.
Para isso, é importante que todos saibam o resultado esperado da autópsia, ou seja, toda a equipe saiba que não deve se referir a nomes para comunicar o evento, que haja uma definição de quem estará cooperando na autópsia -mortem, rompendo com o conhecido formato antigo: “Quem travar o sistema deve consertá-lo.”
Aqui estão algumas ações que você pode incluir em sua autópsia para garantir que seu sistema seja menos arriscado:
registrar e ajustar processos;
escrever testes;
monitorar seus sistemas e sistemas que são críticos para o seu negócio;
Se possível, financeiramente, tenha um “plano b” para sistemas como: servidores e provedores de nuvem que, ao cair, deixam todos os sistemas offline;
Certifique-se de que sua equipe saiba como escrever software com segurança.
Vamos ver um exemplo de como aplicar essas técnicas? Para isso, aqui está um modelo post-hoc para analisarmos juntos:
Descrição do evento: Ocorreu um problema com o pagamento via boleto na finalização da compra. Detecção: Rodrigo da equipe de CS informa que o cliente não consegue emitir um ticket (09:15).
Causa raiz: o banco emissor não está disponível.
Linha de atividade:
09:15 A equipe do CS nos informou que o cliente não conseguiu emitir um ticket.
09:20 Conseguimos reproduzir o problema no ambiente de desenvolvimento, o gateway de pagamento confirmou que a forma de pagamento não está disponível.
09:32 Informamos a empresa que não está disponível.
09:40 Mariana e Leonardo iniciam um patch (ajuste do sistema de emergência) para processar os pagamentos do Boleto através de outro gateway e, portanto, de outro banco.
10:10 Correção aérea.
10:12 Lançamos um ticket de teste em produção para garantir que funcionou.
Impacto: os ingressos não podem ser emitidos no site por 57 minutos.
Aprendizados e ações:
Certifique-se de que temos uma opção b quando o método de pagamento do checkout não estiver disponível. Para isso, desenvolveremos uma função para processar pagamentos através dos meios de pagamento (jobs) disponíveis no checkout (responsável: Jacque). Link do cartão no Trello.
Implementar monitoramento de checkout para sabermos antecipadamente quando o sistema estiver indisponível (lead: André). Link do cartão no Trello.
Como podemos ver no exemplo acima, a equipe descreve o evento iniciador de um incidente relatado às 09h15 na forma de uma linha do tempo e garante uma correção às 10h12. Ele também contém um plano de ação para evitar a reincidência da indisponibilidade da forma de pagamento via boleto, ou seja, o documento destaca o incidente e a solução e não responsabiliza ninguém pelo problema.
É importante lembrar que você deve ter cuidado ao citar os nomes dos membros da equipe após o fato e não o faça de forma acusatória. Além disso, você pode documentar quem é responsável pela ação corretiva após o início de um incidente. Se desejar, você também pode registrar o nome da empresa afetada como seu cliente.
Para concluir
Como podemos ver, ao empregar a análise post-mortem, a equipe consegue estar presente para documentar não apenas os problemas encontrados, mas também a correção do problema e o retorno do sistema à normalidade; além disso, funciona como uma curva de aprendizado para o equipe – pelo menos deve ser tomada Tome medidas para evitar que o problema se repita e compreenda completamente sua causa raiz.
Assim, a maneira como uma equipe lida com um incidente determina como a equipe trabalha e como todos veem o ambiente de trabalho. Usar conceitos como Blameless postmortem para substituir o antigo – e nada construtivo – “apontar e apontar” (ou apontar o dedo), é uma forma de ter um ambiente mais harmonioso e colaborativo. Se você quiser saber mais sobre o assunto, recomendo este artigo no Google Blog: Culture After the Thing: Learning From Failure.
