No setor de enterprise IT, muitas organizações discutem a adoção da transformação digital. No entanto, parece que elas se concentram maioritariamente no lado mais agradável, os “momentos de paz”, deixando de lado os períodos de crise, ou seja, os incidentes. Sim, incidentes, comportamentos inesperados ocorrerão com seu serviço ou plataforma. Você possui um processo de resposta a incidentes ou um runbook? O foco deste post é no ritual pós-incidente, e não exclusivamente na resposta a incidentes (incident response), tema que abordaremos em um futuro post.
Aqui, mais uma vez, vou ressaltar a importância da cultura SRE e como é comum que organizações que não adotaram essa cultura enfrentem incidentes similares ou idênticos repetidamente. Mesmo assim, eventos como esses não conduzem a uma investigação aprofundada, abrindo espaço para mais perdas de receita e danos à reputação da organização em uma era digital na qual a experiência do cliente (CX) e qualidades como disponibilidade se tornam diferenciais cruciais na escolha de um serviço pelos clientes.
Hello Postmortem
“Postmortem (análise de pós-incidente) é um relatório/registro escrito de um incidente, desde a detecção, seu impacto, as ações tomadas para mitigar ou resolver o problema, as root causes(s) e as ações de acompanhamento para evitar a recorrência do incidente”. – Google
SRE no seu melhor #interrupções #análisedepósincidente
Uma das diferenças entre a mentalidade/filosofia SRE em comparação com outras mentalidades operacionais começa aqui. 😉
Preencher um documento com Análise de Causa Raiz root cause analise (RCA) não pode ser o único foco pós-incidente. “O custo do fracasso é a educação.”
Em outra linguagem, no mundo SRE, nenhum incidente é realmente dado como resolvido/encerrado sem um postmortem. POR QUÊ? Porque os incidentes são oportunidades inestimáveis de aprendizado, e postmortem garantem essa aprendizagem com falhas e ajudam a identificar e corrigir fraquezas…
Elaborar uma análise pós-incidente pode parecer uma tarefa exaustiva, intimidadora e até mesmo assustadora. No entanto, você se surpreenderá com os insights que ganhará sobre seus processos e as vulnerabilidades do sistema que serão reveladas durante este exercício. É importante salientar que realizar um postmortem só vale a pena se ele trouxer valor agregado; caso contrário, será tempo desperdiçado.
Cultura
Adotar mindset Confiabilidade/Postmortem vai além de apenas focar nos sintomas e restabelecer a operacionalidade do serviço; é essencial tratar as causas subjacentes do problema. Tomemos um exemplo simples, algo aparentemente trivial como uma paralisação causada por falta de espaço em uma partição ou mount point específico. Após resolver o incidente, não basta apenas registrar num documento RCA que a partição estava cheia e que foi realizado um processo de limpeza, e o service restabelicido. Como medida preventiva, vamos implementar uma rotina de limpeza…
Nestes moldes, é difícil perceber exatamente o que deu errado ou falhou para provocar um incidente, incluindo o tempo necessário para a implementação da rotina de limpeza e a identificação da pessoa responsável por essa tarefa. Relativamente ao incidente em si, podemos supor que um aumento repentino no volume de logs pode ter sido causado por um acréscimo no número de erros registrados, um aumento no nível de detalhe dos logs debug (verbosity) ou no número de transações. Estas são hipóteses que deveriam ser facilmente esclarecidas se houvesse um monitoramento/observabilidade básico e eficaz do número de transações e erros por exemplo. Antes mesmo de avançarmos para observability ou RED monitoring, surge a questão: o que aconteceu com o monitoramento do espaço disponível nos discos? 😲
Antes de apresentar um modelo de questões para postmortem, é importante lembrar que para este processo ser verdadeiramente valioso (promovendo aprendizado contínuo) e não se basear em opiniões, distorções ou ocultação de dados e fatos, é essencial que a organização já tenha cultura de psychological safety (um ambiente de segurança psicológica). Isto implica adotar uma cultura generativa, onde o foco não esteja em atribuir culpas. Os técnicos devem sentir-se seguros para compartilhar todos os detalhes necessários sem o receio de punição, garantindo assim a transparência e a eficácia do processo.
Template/Questões
Detecção
Como o incidente foi detectado? Desafio você a responder: 🙂 reportado pelo end user, pois não conseguiam realizar pesquisas, etc… Devemos evitar ao máximo os cenários em que é o usuário quem nos informa sobre outages ou instabilidades no nosso serviço.
Se mais de três interrupções não foram inicialmente detectadas nem por nossas ferramentas nem pelos engenheiros, 😦 é evidente um erro 404: Práticas de SRE Não Encontradas aqui.
Tempo e esforço devem ser aplicados para melhorar e obter uma visão clara da experiência do usuário em nosso serviço.
Recorrência
Esse incidente (com mesmo RCA) ocorreu antes? Se sim, por que aconteceu novamente?
Desafio você a responder SIM, o mesmo aconteceu, incidentes INC-757 & INC-828. Correção ainda a ser implementada…
É cenário indesejável; a mentalidade SRE visa evitar que um erro ocorra mais de uma vez, o que também justifica nossa ênfase em aprender com as falhas.
Backlog
Alguma tarefa em nosso backlog poderia ter prevenido o incidente ou reduzido significativamente blast radius impacto? Se sim, por que não foi feito?
É comum que, após um postmortem, sejam gerados itens de ação para corrigir e aprimorar os pontos fracos identificados. É essencial que esses itens de ação estejam devidamente registrados, atribuídos e com alta prioridade, além de possuírem prazos claros de conclusão. Trata-se de um trabalho que agrega valor ao serviço e contribui para melhorar sua confiabilidade.
RCA (irei colar o examplo do postmortem do gitlab)
Resumindo, simples postmortem deve conter pelo menos:
- Detalhes sobre a descoberta do incidente
- Linha do tempo (a cronologia é importante)
- Respostas aos 5 porquês(5 whys), uma técnica de questionamento iterativo
- Maneiras de prevenir o incidente
- Registro de Incidentes relacionados
- Lição aprendida e itens de ação claros com timelines
- Qualquer informação de apoio
Nota: É recomendável que o postmortem seja realizado dentro de um período de 24 a 72 horas após o incidente, enquanto as informações ainda estão frescas na memória de todos.
Exemplos de postmortem:
https://www.elastic.co/blog/elastic-cloud-incident-report-feburary-4-2019
https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/
https://github.com/dastergon/post-mortems
https://www.atlassian.com/incident-management/postmortem/templates#incident-summary
Templates
https://github.com/dastergon/postmortem-templates/blob/master/templates/postmortem-template-srebook.md
https://github.com/dastergon/postmortem-templates
Wrap up
Mais perguntas como essas podem definitivamente auxiliar na sua jornada rumo à maior confiabilidade. Não faz sentido identificar dados e padrões que comprometem a confiabilidade e simplesmente ignorá-los, “dormindo tranquilamente”. Especialmente quando enfrentamos problemas recorrentes e incidentes frequentemente detectados ou relatados pelos clientes, sem a existência de medidas preventivas no nosso backlog ou ações planejadas para reduzir o alcance do impacto. E fica evidente a necessidade de garantir o pilar base SRE, monitoramento/observabilidade para poder ter dados claros “data-driven” e deixar de ser uma team reativa.
Virtual Cluster IT 