Postmortem: Como lidamos com falhas no LuizaLabs
No LuizaLabs, trabalhamos em larga escala, com centenas de sistemas distribuídos, e melhorias tanto técnicas, quanto que envolvem demandas da área de negócio, são entregues de forma frequente.
Dado esse contexto, as squads tentam seguir boas práticas de engenharia de software, a fim de impactar o mínimo possível o ambiente de produção e, consequentemente, nossos clientes.
Porém, mesmo procurando seguir boas práticas, é inevitável que num ambiente com tantas aplicações distribuídas incidentes não ocorram eventualmente.
Dada a premissa de que essas situações hora ou outra irão ocorrer e impactar clientes e vendas, uma empresa pode seguir duas abordagens que veremos a seguir.
- Punição
A primeira e, infelizmente, bastante comum em empresas tradicionais, é a da punição dos responsáveis pelo problema, a fim de mostrar que esse tipo erro não é tolerado na empresa.
O problema de seguir por esse caminho é o sentimento de medo que isso gera, minando iniciativas de quem está tentando inovar. Mais pessoas podem começar a pensar que faz mais sentido deixar as coisas como estão e manter o emprego.
Além disso, quando um erro ocorrer, é bem provável que as equipes não sejam transparentes com relação ao que ocorreu e procurem apenas achar culpados pelo problema.
A médio e longo prazo, o resultado desse tipo de cultura é péssimo, porque:
- Débitos técnicos serão criados até que a manutenção dos sistemas se torne insustentável;
- Inovações serão inexistentes ou muito pensadas e burocratizadas até chegarem no ambiente de produção;
- A área de negócio é impactada, dada tamanha burocracia criada por esse tipo de cultura.
2. Aprender com os erros
E se, por outro lado, ao invés de apontarmos dedos procurando culpados pelo problema, focarmos energias em tirar lições de aprendizado e sermos mais resilientes quando incidentes acontecerem?
Esse tipo de cultura disseminada faz as pessoas minimizarem os efeitos do medo em errar, além de engajar os times a serem transparentes e compartilhar detalhadamente o que ocorreu.
E por que isso é importante? Existem inúmeras vantagem em adotar essa abordagem:
- Trabalhar com tecnologia requer entregar inovações de forma constante: novas tecnologias e práticas surgem todo o tempo e isso requer uma curva de aprendizado e inevitavelmente, cometeremos ao nos aventurar em coisas novas;
- Demandas de negócio são incessantes, principalmente no contexto de e-commerce. Se a equipe estiver segura sabendo que estará tudo bem se algum erro acontecer durante a jornada e tirarmos aprendizado disso, a velocidade de entrega dessas features tende a ser muito maiores. É aquela velha premissa: “só erra quem faz”.
Postmortem
Conforme vimos na segunda abordagem, podemos não nos preocupar em apontar dedos e achar culpados. Isso não significa que simplesmente esqueceremos o que ocorreu e a vida seguirá. Caso isso caia no esquecimento, o mesmo incidente pode ocorrer inúmeras vezes e a ideia é aprender com os erros, a fim de evitar ao máximo que ocorra novamente.
Precisamos, então, encontrar uma forma pública de documentar o erro e as ações tomadas de forma detalhada, para que esse aprendizado consiga chegar a outros times também.
Aqui no Luizalabs, a forma que lidamos com erros, buscando maximizar aprendizados e transparência é escrevendo Postmortems.
Originado da expressão “após a morte”, esse termo em latim é utilizado em diversos contextos, sempre que se quer indicar que um exame minucioso será feito para descobrir ou compreender melhor o que levou à morte — ou ao erro, como no contexto em que estamos falando.
E é isso que exatamente constitui um Postmortem em nosso contexto: após a "morte" (incidente), tentamos identificar o que ocorreu minuciosamente.
Alguns pontos que consideramos importantes a serem incluídos em um Postmortem são:
- Timeline dos eventos: todos os horários de cada ação tomada, contemplando desde o início até o seu término;
- Impacto: as consequências do incidente ocorrido. O nível de detalhamento depende muito da maturidade das métricas de negócio que estão disponíveis. O ideal é ser o mais transparente possível;
- Causa Raiz: o que realmente casou o incidente;
- Solução: como o problema foi resolvido.
Existem diversas formas e até modelos prontos para serem utilizados como padrão de documentação de um Postmortem.
Quando o time responsável tiver documentado e revisado o documento, deve ser compartilhado com todas as outras pessoas da empresa, ou com os times de tecnologia que podem se beneficiar das lições aprendidas.
No site da Atlassian, existe um modelo que contempla todos os itens mencionados acima.
O essencial, nesse caso, é ser o mais transparente possível e detalhar tudo o que o time conseguiu identificar até chegar a causa raiz e solução para o problema.
Conclusão
Trabalhar em uma empresa em que seja incentivado a não ter medo de errar e ao mesmo tempo aprender com falhas é essencial para mantermos um ambiente saudável e transparente.
Apesar de existirem diversas formas de documentar um Postmortem, é um aspecto muito mais cultural do ambiente em que se trabalha, do que uma documentação formal.
Apesar de existirem diversas formas de documentar um Postmortem, é um aspecto muito mais cultural do ambiente em que se trabalha do que uma documentação formal.
A cultura no LuizaLabs nos permite maximizar aprendizados e, por isso, utilizamos postmortems como ferramenta há um bom tempo.
Isso incentiva nosso comprometimento com inovação, pois sabemos que podemos testar tecnologias novas constantemente, de forma responsável, mas sem medo de errar.
A cultura no LuizaLabs é a de maximizar aprendizados e, por isso, utilizamos postmortems como ferramenta há várias anos. Isso incentiva nosso comprometimento com inovação, pois sabemos que podemos testar tecnologias novas, sempre com responsabilidade, mas sem medo de errar.
