{"id":628,"date":"2024-09-18T14:14:06","date_gmt":"2024-09-18T14:14:06","guid":{"rendered":"https:\/\/new1tech.net\/?p=628"},"modified":"2025-08-10T19:32:09","modified_gmt":"2025-08-10T19:32:09","slug":"sre","status":"publish","type":"post","link":"https:\/\/new1tech.net\/pt\/sre\/","title":{"rendered":"SRE Postmortem: Aprendendo com o fracasso\u00a0(incidentes)"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

No setor de enterprise IT, muitas organiza\u00e7\u00f5es discutem a ado\u00e7\u00e3o da transforma\u00e7\u00e3o digital. No entanto, parece que elas se concentram maioritariamente no lado mais agrad\u00e1vel, os \u201cmomentos de paz\u201d, deixando de lado os per\u00edodos de crise, ou seja, os incidentes. Sim, incidentes, comportamentos inesperados ocorrer\u00e3o com seu servi\u00e7o ou plataforma. Voc\u00ea possui um processo de resposta a incidentes ou um runbook? O foco deste post \u00e9 no ritual p\u00f3s-incidente, e n\u00e3o exclusivamente na resposta a incidentes (incident response), tema que abordaremos em um futuro post.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Aqui, mais uma vez, vou ressaltar a import\u00e2ncia da cultura SRE e como \u00e9 comum que organiza\u00e7\u00f5es que n\u00e3o adotaram essa cultura enfrentem incidentes similares ou id\u00eanticos repetidamente. Mesmo assim, eventos como esses n\u00e3o conduzem a uma investiga\u00e7\u00e3o aprofundada, abrindo espa\u00e7o para mais perdas de receita e danos \u00e0 reputa\u00e7\u00e3o da organiza\u00e7\u00e3o em uma era digital na qual a experi\u00eancia do cliente (CX) e qualidades como disponibilidade se tornam diferenciais cruciais na escolha de um servi\u00e7o pelos clientes.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Hello Postmortem<\/h2><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

\u201cPostmortem (an\u00e1lise de p\u00f3s-incidente) \u00e9 um relat\u00f3rio\/registro escrito de um incidente, desde a detec\u00e7\u00e3o, seu impacto, as a\u00e7\u00f5es tomadas para mitigar ou resolver o problema, as root causes(s) e as a\u00e7\u00f5es de acompanhamento para evitar a recorr\u00eancia do incidente\u201d. \u2013\u00a0Google<\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

SRE no seu melhor #interrup\u00e7\u00f5es #an\u00e1lisedep\u00f3sincidente<\/h2><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Uma das diferen\u00e7as entre a mentalidade\/filosofia SRE em compara\u00e7\u00e3o com outras mentalidades operacionais come\u00e7a aqui.\u00a0\"\ud83d\ude09\"
Preencher um documento com An\u00e1lise de Causa Raiz root cause analise (RCA) n\u00e3o pode ser o \u00fanico foco p\u00f3s-incidente. \u201cO custo do fracasso \u00e9 a educa\u00e7\u00e3o.\u201d<\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Em outra linguagem, no mundo SRE, nenhum incidente \u00e9 realmente dado como resolvido\/encerrado sem um postmortem. POR QU\u00ca? Porque os incidentes s\u00e3o oportunidades inestim\u00e1veis de aprendizado, e postmortem garantem essa aprendizagem com falhas e ajudam a identificar e corrigir fraquezas\u2026<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Elaborar uma an\u00e1lise p\u00f3s-incidente pode parecer uma tarefa exaustiva, intimidadora e at\u00e9 mesmo assustadora. No entanto, voc\u00ea se surpreender\u00e1 com os insights que ganhar\u00e1 sobre seus processos e as vulnerabilidades do sistema que ser\u00e3o reveladas durante este exerc\u00edcio.\u00a0\u00c9 importante salientar que realizar um postmortem s\u00f3 vale a pena se ele trouxer valor agregado; caso contr\u00e1rio, ser\u00e1 tempo desperdi\u00e7ado.<\/em><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Cultura<\/h2><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Adotar mindset Confiabilidade\/Postmortem vai al\u00e9m de apenas focar nos sintomas e restabelecer a operacionalidade do servi\u00e7o; \u00e9 essencial tratar as causas subjacentes do problema. Tomemos um exemplo simples, algo aparentemente trivial como uma paralisa\u00e7\u00e3o causada por falta de espa\u00e7o em uma parti\u00e7\u00e3o ou mount point espec\u00edfico. Ap\u00f3s resolver o incidente, n\u00e3o basta apenas registrar num documento\u00a0RCA<\/em>\u00a0que a parti\u00e7\u00e3o estava cheia e que foi realizado um processo de limpeza, e o\u00a0service\u00a0<\/em>restabelicido. Como medida preventiva, vamos implementar uma rotina de limpeza\u2026<\/p>\n

Nestes moldes, \u00e9 dif\u00edcil perceber exatamente o que deu errado ou falhou para provocar um incidente, incluindo o tempo necess\u00e1rio para a implementa\u00e7\u00e3o da rotina de limpeza e a identifica\u00e7\u00e3o da pessoa respons\u00e1vel 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\u00e9scimo no n\u00famero de erros registrados, um aumento no n\u00edvel de detalhe dos logs\u00a0debug<\/em>\u00a0(verbosity) ou no n\u00famero de transa\u00e7\u00f5es. Estas s\u00e3o hip\u00f3teses que deveriam ser facilmente esclarecidas se houvesse um monitoramento\/observabilidade b\u00e1sico e eficaz do n\u00famero de transa\u00e7\u00f5es e erros por exemplo. Antes mesmo de avan\u00e7armos para\u00a0observability<\/em>\u00a0ou RED monitoring, surge a quest\u00e3o: o que aconteceu com o monitoramento do espa\u00e7o dispon\u00edvel nos discos?\u00a0\"\ud83d\ude32\"\u00a0<\/p>\n

Antes de apresentar um modelo de quest\u00f5es para postmortem, \u00e9 importante lembrar que para este processo ser verdadeiramente valioso (promovendo aprendizado cont\u00ednuo) e n\u00e3o se basear em opini\u00f5es, distor\u00e7\u00f5es ou oculta\u00e7\u00e3o de dados e fatos, \u00e9 essencial que a organiza\u00e7\u00e3o j\u00e1 tenha cultura de psychological safety (um ambiente de seguran\u00e7a psicol\u00f3gica). Isto implica adotar uma cultura generativa, onde o foco n\u00e3o esteja em atribuir culpas. Os t\u00e9cnicos devem sentir-se seguros para compartilhar todos os detalhes necess\u00e1rios sem o receio de puni\u00e7\u00e3o, garantindo assim a transpar\u00eancia e a efic\u00e1cia do processo.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Template\/Quest\u00f5es<\/h2><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Detec\u00e7\u00e3o<\/strong>
Como o incidente foi detectado? Desafio voc\u00ea a responder:\u00a0\"\ud83d\ude42\"\u00a0reportado pelo end user<\/strong>, pois n\u00e3o conseguiam realizar pesquisas, etc\u2026 Devemos evitar ao m\u00e1ximo os cen\u00e1rios em que \u00e9 o usu\u00e1rio quem nos informa sobre outages ou instabilidades no nosso servi\u00e7o.
Se mais de tr\u00eas interrup\u00e7\u00f5es n\u00e3o foram inicialmente detectadas nem por nossas ferramentas nem pelos engenheiros,\u00a0\"\ud83d\ude26\"\u00a0\u00e9 evidente um erro 404: Pr\u00e1ticas de SRE N\u00e3o Encontradas aqui.
Tempo e esfor\u00e7o devem ser aplicados para melhorar e obter uma vis\u00e3o clara da experi\u00eancia do usu\u00e1rio em nosso servi\u00e7o.<\/strong><\/em><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Recorr\u00eancia<\/strong>
Esse incidente (com mesmo RCA) ocorreu antes? Se sim, por que aconteceu novamente?
Desafio voc\u00ea a responder SIM, o mesmo aconteceu, incidentes INC-757 & INC-828. Corre\u00e7\u00e3o ainda a ser implementada\u2026
\u00c9 cen\u00e1rio indesej\u00e1vel; a mentalidade SRE visa evitar que um erro ocorra mais de uma vez, o que tamb\u00e9m justifica nossa \u00eanfase em aprender com as falhas.<\/em><\/strong><\/p>\n

Backlog<\/strong>
Alguma tarefa em nosso backlog poderia ter prevenido o incidente ou reduzido significativamente\u00a0blast radius<\/em>\u00a0impacto? Se sim, por que n\u00e3o foi feito?
\u00c9 comum que, ap\u00f3s um postmortem, sejam gerados itens de a\u00e7\u00e3o para corrigir e aprimorar os pontos fracos identificados. \u00c9 essencial que esses itens de a\u00e7\u00e3o estejam devidamente registrados, atribu\u00eddos e com alta prioridade, al\u00e9m de possu\u00edrem prazos claros de conclus\u00e3o. Trata-se de um trabalho que agrega valor ao servi\u00e7o e contribui para melhorar sua confiabilidade<\/em><\/strong>.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

RCA (irei colar o examplo do postmortem do gitlab)<\/h2><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Resumindo, simples postmortem deve conter pelo menos:<\/h2><\/div><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t