6 minutos de leitura
Autor(a)
Oi eu sou o Goku :) apaixonada por café, graphic novels e tecnologia.
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
No ambiente complexo de TI é irrealista dizer que incidentes nunca vão acontecer,e quando eles ocorrem, a forma com que o time lida é crucial. Um processo já conhecido é a criação do postmortem (em português, “depois da morte”), que geralmente é um documento, e tem como objetivo ajudar os times a estruturar um processo para a discussão e análise desses incidentes.
Este documento, geralmente, contém: 1) a descrição do ocorrido e a causa raiz; 2) em qual período a indisponibilidade ocorreu; 3) quais os impactos (perda de dados, por exemplo); 3) a linha do tempo dos fatos ocorridos (hora e descrição); 4) quais medidas foram tomadas para a solução; 5) e quais foram adotadas depois do problema, para evitar que ele ocorra novamente e evidenciar os aprendizados da equipe com a ocorrência.
Esse postmortem também pode tomar a forma de uma reunião interna, com as pessoas no papel de SRE (Site Reliability Engineering, ou "Engenharia de Confiabilidade de Sites"). O mais importante aqui é que exista um momento em que o time consiga levantar todos os itens listados acima, para compartilhar o conhecimento e que durante a indisponibilidade, as ações tomadas sejam documentadas para a posteridade, de forma que seja possível analisar não somente o problema, mas também quais foram as ações do time durante o incidente.
Quando um time decide adotar essa prática, é importante que sejam discutidos quais são os critérios para a criação do documento. Alguns exemplos podem ser:
Sim, não é necessário que a sua empresa tenha SREs - por exemplo - para usar postmortem. O mais importante é que seu time converse e saiba os motivos de adotar esse conceito, e que além disso, exista um processo já desenhado e pronto para quando incidentes acontecerem. O uso do postmortem não deve ser iniciado de forma reativa, mas seu time deve estar preparado para usá-lo em qualquer momento. Também deve-se garantir um tempo do time para discutir os postmortems juntos.
Para garantir que tudo será discutido e as ações mapeadas depois do incidente serão resolvidas, é possível adotar um status para os postmortem, como:
“em aberto” quando ainda não foram discutidos;
e dar como “fechados” somente os que já foram avaliados pelo grupo ou que já tiveram todas as ações resolvidas.
Agora que já entendemos o que é postmortem e a sua funcionalidade para o time, vamos entender o que é o Blameless postmortem?
Para garantir que o processo do postmortem seja maduro, não cause danos ao time e não crie um ambiente com uma cultura ruim, existe o conceito Blameless postmortem (ou em tradução livre, livre de culpa). Nesse formato, tudo é feito sem apontar nomes ou culpados, afinal o que queremos de resultado aqui não é gerar atritos, é avaliar o que causou o problema e garantir que não se repita, ou seja, o foco aqui é o incidente ou falha e não as pessoas.
Para isso, é importante que todos saibam qual o resultado esperado do postmortem, isto é, que todo o time saiba que não deve comunicar o incidente citando nomes, que haja a definição de quem trabalhará nas ações do postmortem colaborativamente, se desvencilhando daquele velho formato conhecido: “quem derrubou o sistema é quem deve corrigi-lo.”
Listamos abaixo algumas ações que você pode incluir no postmortem para garantir a diminuição de riscos nos seus sistemas:
Vamos ver um exemplo de como essas dicas podem ser aplicadas? Para isso, segue um modelo de postmortem para analisarmos juntos:
Como pudemos perceber no exemplo supracitado, o time descreve em forma de linha do tempo os eventos que tiveram como origem o incidente reportado às 09:15 e que teve sua correção garantida às 10:12 da manhã. Também consta ali o plano de ação para evitar que a indisponibilidade do meio de pagamento boleto volte a ocorrer, ou seja, o documento coloca em evidência o incidente e a solução e não responsabiliza nenhuma pessoa pelo problema.
É importante lembrar que deve-se ter cuidado ao citar nomes de membros do time no postmortem, para não fazer de forma que atribua culpa. Além disso, você pode registrar quem foi o responsável pelas ações de correção após o início do incidente. Se desejar, você pode registrar também o nome das empresas que são suas clientes e que foram afetadas.
Como vimos, com a adoção do postmortem a equipe consegue ter ali documentado, não somente o problema identificado, mas a sua correção e a volta à normalidade do sistema; além disso, ele também atua como uma aprendizagem para o time - que deve, no mínimo, tomar ações para evitar a repetição do problema e conhecer bem a sua causa raiz.
Portanto, a forma como os times lidam com incidentes, molda como os times trabalham e como o ambiente de trabalho é visto por todos. Usar conceitos como Blameless postmortem substituindo o velho - e nenhum pouco construtivo - “apontamento de dedos” (ou de culpados), é uma das formas de ter um ambiente mais harmonioso e colaborativo. Caso você queira conhecer mais sobre esse assunto, indico esse post no blog da Google: Postmortem Culture: Learning from Failure.
Avalie este artigo
