Incidente humano: como uma decisão bem-intencionada causou downtime
Tomei uma decisão que parecia certa, foi bem-intencionada, e causou downtime de 40 minutos. O que isso ensina sobre a diferença entre intenção e impacto em operações.
Tomei uma decisão bem-intencionada. Causou 40 minutos de downtime.
Estava monitorando um servidor quando percebi que o disco estava chegando em 80% de capacidade — limite que a empresa considerava alarme. A política era avisar o gestor e aguardar instrução.
Mas eu sabia o que precisava ser feito: havia logs antigos que não eram mais necessários, e remover eles liberaria espaço suficiente. A limpeza era segura. Era a solução óbvia.
Decidi fazer sem avisar. Rápido, simples, resolve o problema antes de virar alarme.
Removi os logs. Ao fazer isso, a remoção triggou um processo de rotação automática de logs que eu não sabia que existia. Esse processo travou o serviço que dependia dos logs para funcionar. O serviço ficou indisponível por 40 minutos enquanto o problema era diagnosticado por alguém que tinha mais contexto do sistema do que eu.
Bem-intencionado e correto são coisas diferentes.
Eu estava certo que remover os logs liberaria espaço. Estava errado em assumir que não havia dependências ocultas. Estava mais errado ainda em agir sem comunicar — porque mesmo se a remoção fosse tecnicamente segura, a falta de comunicação criou um incidente onde ninguém sabia o que havia mudado.
Quando o sistema parou e o time de operações começou a investigar, ninguém sabia que eu havia feito qualquer coisa. O diagnóstico levou muito mais tempo do que deveria por causa disso.
Quando assumi que havia feito a limpeza, a reação não foi raiva — foi frustração com o processo. "A gente tem o processo de aviso exatamente para evitar isso. Não porque a gente não confia em você — porque a gente não conhece todas as dependências de cabeça e documenta por isso."
Sistemas complexos têm dependências que não estão visíveis para quem os opera em partes.
O processo de aviso ao gestor antes de ação não era burocracia. Era um mecanismo para garantir que quem tinha visibilidade do sistema inteiro tivesse chance de checar antes de mudança acontecer.
Eu tinha visibilidade parcial. Operei como se tivesse visibilidade total.
Essa é a lição que mais levei de S1: a diferença entre o que você sabe e o que o sistema sabe são coisas distintas. Processo de comunicação antes de ação em produção existe para bridgear essa diferença.
Anos depois, quando implementei processo de change management em plataformas com centenas de serviços, a motivação era a mesma: ninguém tem visibilidade total de um sistema complexo. Comunicação antes de mudança não é desconfiança — é reconhecimento de complexidade.
Essa semana: quando foi a última vez que você fez uma mudança "simples" em produção sem comunicar — e tinha alguma dependência oculta que você não sabia?