O que devo fazer ao encontrar uma falha no sistema: o passo a passo

Responder a uma falha no sistema segue seis passos em ordem fixa: confirmar e delimitar o impacto, comunicar antes de resolver, estabilizar o serviço, identificar a causa raiz, corrigir com validação e conduzir post-mortem sem culpa. Restaurar vem antes de entender, e cada passo tem um critério de saída que precisa estar verdadeiro para avançar ao seguinte.

Encontrar uma falha no sistema exige um procedimento escrito, executado na mesma ordem por qualquer pessoa de plantão. A sequência começa em confirmar e delimitar o impacto, comunicar quem precisa saber e estabilizar o serviço. Depois vêm identificar a causa raiz, corrigir com validação e registrar o aprendizado. A ordem pesa tanto quanto os passos.

Restaurar o serviço vem antes de entender por que ele quebrou. A precedência tem motivo operacional: um sistema crítico fora do ar acumula prejuízo a cada minuto que passa, enquanto a investigação prossegue depois, sobre a telemetria que ficou retida. Inverter os dois costuma terminar em indisponibilidade prolongada e diagnóstico incompleto.

Cada um dos seis passos tem um critério de saída, isto é, o que precisa estar verdadeiro para que o plantão avance ao próximo. Sem esse critério, a equipe pula etapas sob pressão e descobre a lacuna depois.

A Rike IS conduz consultoria, implantação, treinamento e governança contínua em observabilidade sobre a plataforma Dynatrace, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte.

Passo 1: confirmar e delimitar o impacto

O primeiro passo confirma que existe falha real e delimita o que ela atinge, antes de qualquer ação corretiva em produção.

Alerta e incidente são coisas distintas. Um disparo isolado pode vir de coleta interrompida, de janela de manutenção esquecida ou de um limiar mal calibrado, e agir sobre falso positivo consome o plantão e ainda produz mudança desnecessária no ambiente. A confirmação leva segundos quando existe telemetria de transação real: o plantão verifica se as operações de negócio continuam concluindo.

A delimitação responde a três perguntas, nesta ordem. Qual serviço está afetado. Quantas transações caem dentro do recorte. E qual operação de negócio deixou de concluir para o usuário.

A terceira pergunta é a que muda a condução do incidente. Uma degradação no cadastro de senha tem prioridade diferente de uma degradação na autorização de pagamento, mesmo com indicadores de infraestrutura idênticos nos dois casos. O recorte também precisa de dimensão de população: falha que aparece só em uma região, em uma versão de aplicativo ou em um provedor de conectividade indica causa distinta de falha generalizada, e essa distinção elimina boa parte das hipóteses antes de qualquer mergulho técnico.

O instrumento que dá referência ao plantão é o Service Level Objective, ou SLO, o objetivo interno de disponibilidade acordado para o serviço. Dele deriva o orçamento de erro, a margem de indisponibilidade que a equipe pode consumir no período sem romper o compromisso.

Para o Site Reliability Engineer, ou SRE, a delimitação diz quanto desse orçamento o incidente queima naquele instante. Para o CIO, a mesma delimitação é o que permite informar ao negócio o que está indisponível, sem exagero e sem minimização.

Critério de saída do passo 1: o incidente tem serviço, escopo e operação de negócio nomeados por escrito.

Passo 2: comunicar antes de resolver

O segundo passo abre a comunicação, e ele acontece antes de a causa ser conhecida.

Equipes técnicas tendem a adiar o aviso até ter uma explicação pronta. O adiamento custa caro: enquanto o time cala, o atendimento recebe chamados sem contexto, gestores descobrem o problema por terceiros e a confiança no relato posterior fica comprometida. Comunicar cedo não significa comunicar hipótese, significa comunicar fato confirmado e escopo delimitado.

O procedimento precisa nomear quatro destinatários e o que cada um recebe. A equipe técnica recebe o canal único de coordenação. O atendimento recebe o texto que pode repassar ao usuário. A gestão recebe impacto de negócio e previsão de próxima atualização. E, quando existe compromisso contratual, o cliente recebe o comunicado no formato previsto no Service Level Agreement, ou SLA, o acordo formal de nível de serviço.

Cadência vale mais que conteúdo nesse momento. Uma atualização a cada intervalo fixo, mesmo sem novidade, sustenta a confiança melhor que uma explicação completa entregue tarde. O texto da primeira mensagem cabe em três linhas: o que está afetado, o que já foi confirmado e quando sai a próxima atualização.

Quem coordena a comunicação não deve ser quem está com as mãos no teclado, porque acumular os dois papéis atrasa os dois.

Para o gerente de infraestrutura, a comunicação estruturada evita que metade da equipe pare para responder perguntas em paralelo. Para o CTO, é o que separa um incidente conduzido de um incidente que vira crise de reputação interna.

Critério de saída do passo 2: os quatro destinatários receberam a primeira mensagem, com coordenador nomeado e horário da próxima atualização definido.

Passo 3: estabilizar o serviço

O terceiro passo devolve o serviço ao usuário pelo caminho mais curto disponível, mesmo sem causa raiz identificada.

Mitigação e correção são etapas diferentes. Mitigação restaura a operação com o recurso que já existe: desviar tráfego para a instância sadia, desligar uma funcionalidade recém-liberada, reverter a última mudança, ampliar capacidade ou acionar o failover, o mecanismo que desloca a carga para a instância sadia. Correção vem depois, quando o mecanismo da falha já está entendido.

Três opções de mitigação precisam estar à mão de uma equipe de plantão. A reversão da última alteração publicada, quando a linha do tempo aponta correlação. O desligamento seletivo de funcionalidade por chave de configuração, que preserva o restante da aplicação. E o isolamento da dependência degradada, com resposta alternativa no lugar da chamada que trava.

A reversão merece um critério explícito, porque é a mitigação mais usada e a mais mal usada. Ela resolve quando a falha começou junto com uma publicação e o estado dos dados permite voltar. Não resolve, e às vezes piora, quando houve migração de esquema de banco sem caminho de volta, ou quando a degradação vem de dependência externa alheia à publicação.

Há um custo escondido na estabilização que times aprendem depois de alguns incidentes. Reiniciar um componente resolve o sintoma e apaga o estado que explicaria a origem, o que torna a retenção de telemetria parte do procedimento e não detalhe de arquitetura. Antes de reiniciar, o plantão captura o que precisa ser preservado.

Para o profissional de DevOps, este passo é o que justifica manter a reversão automatizada, testada e acessível sem aprovação demorada. Para o CEO, é o passo que encurta o tempo de indisponibilidade percebido pelo cliente final, que é a única medida que chega ao negócio.

Critério de saída do passo 3: a operação de negócio voltou a concluir, ainda que em modo degradado.

Passo 4: identificar a causa raiz

O quarto passo busca o evento que originou a cadeia de falhas, e não o componente que gritou mais alto.

Em arquitetura distribuída, sintoma e origem raramente moram no mesmo lugar. Uma lentidão de banco de dados aparece como erro de tempo limite na aplicação, que aparece como erro de aplicativo no usuário, e o alerta chega pelas três camadas ao mesmo tempo. Correlacionar isso à mão, sob pressão, é o que faz o tempo de resolução variar de minutos a horas entre um plantão e outro.

A investigação manual segue quatro fontes, em ordem de rendimento. A linha do tempo de mudanças, porque publicação, alteração de configuração e ajuste de infraestrutura explicam a maioria dos incidentes. O rastreamento distribuído, ou trace, que mostra cada parada do percurso da requisição. Os logs da janela exata do início. E as métricas de saturação de recurso nos componentes envolvidos.

O trace é o GPS da viagem da requisição, mostrando cada parada do trajeto.

A plataforma Dynatrace encurta esse percurso por três componentes. O OneAgent descobre a stack em execução sem configuração manual por componente. O Smartscape mantém o mapa de dependências do ambiente em tempo real, com quem chama quem e sobre que infraestrutura. E o Davis, que dentro do Dynatrace Intelligence é responsável pela análise causal, percorre esse mapa e aponta o evento gerador, apresentando um problema priorizado em vez de dezenas de alertas que descrevem o mesmo incidente por ângulos diferentes.

Dashboards organizam e tornam exploráveis os sinais operacionais, enquanto a Dynatrace Intelligence complementa essa análise com detecção de anomalias, correlação e investigação causal para reduzir a triagem e orientar a resposta.

Essa automação de correlação é o que se chama de Artificial Intelligence for IT Operations, ou AIOps, a aplicação de inteligência artificial à operação de tecnologia. A profundidade de dados que ela consome vem da instrumentação de aplicação, e o Application Performance Monitoring, ou APM, é o que registra cada transação ponta a ponta.

Para o SRE, o ganho está em receber um problema com origem apontada, em vez de uma fila de alertas para triar. Para o gerente de infraestrutura, o mapa de dependências responde à pergunta que nenhum painel isolado responde: o que mais depende do componente que está degradado.

Poucos ambientes chegam ao incidente com a correlação causal já confiável, e a diferença raramente está na plataforma. Está na instrumentação que alguém desenhou antes, com convenção de atributos que sobrevive a várias equipes, e esse desenho é parte do trabalho que a Rike IS conduz junto às equipes de operações.

Critério de saída do passo 4: existe uma hipótese de causa raiz sustentada por evidência na telemetria, e não por eliminação de suspeitos.

Passo 5: corrigir e validar a correção

O quinto passo aplica a correção definitiva e prova que ela funcionou, com dado e não com percepção.

A validação é a parte mais pulada do procedimento. Encerrar o incidente porque o alerta parou de disparar é armadilha conhecida: alerta silencia também quando a coleta quebra, quando o tráfego cai por horário ou quando o usuário desistiu de tentar. Confirmação real exige olhar o indicador que representa a experiência, não o que representa a infraestrutura.

O instrumento dessa confirmação é o Service Level Indicator, ou SLI, o indicador efetivamente medido para representar o serviço. Medir disponibilidade pela resposta do servidor produz número diferente de medir pela conclusão da transação de negócio, e apenas o segundo corresponde ao que o usuário obteve.

A validação percorre três verificações. A taxa de erro voltou ao padrão do mesmo dia da semana, no mesmo horário. O tempo de resposta das transações principais voltou à faixa habitual. E a fila de trabalho acumulada durante a indisponibilidade foi drenada, porque incidente resolvido com pendência represada volta em segunda onda.

A ordem importa quando a correção definitiva depende de publicação. A equipe publica em janela controlada, com observação ativa da telemetria durante a liberação, e não no fim do plantão com a equipe exausta. Correção aplicada às pressas costuma gerar o incidente seguinte.

Para o DevOps, este passo é a evidência de que a esteira de entrega devolve retorno rápido o bastante para publicar com segurança durante um incidente. Para o CIO, é o registro que sustenta a conversa sobre o Mean Time To Repair, ou MTTR, o tempo médio que a organização leva para restaurar um serviço.

Critério de saída do passo 5: as três verificações passaram sobre o SLI do serviço, e não sobre o alerta que disparou.

Passo 6: post-mortem sem culpa

O sexto passo transforma o incidente em correção estrutural, e ele só funciona sem atribuição de culpa. Post-mortem é o registro estruturado feito depois do incidente encerrado, com o propósito de evitar a repetição.

Post-mortem sem culpa é prática operacional com regra explícita, não declaração de boas intenções. A regra é simples de enunciar e difícil de sustentar: o relato descreve decisões tomadas com a informação disponível naquele momento, e nunca a pessoa que as tomou. Quando o processo busca responsável, o relato seguinte vem incompleto, e a organização perde justamente o dado que evitaria a repetição.

O documento cobre cinco blocos, e o formato importa menos que a presença dos cinco. A linha do tempo, com horários e ações reais. O impacto medido, em transações e em usuários. A cadeia causal, do evento gerador ao sintoma percebido. O que atrasou a resolução, incluindo lacunas de acesso, de contato ou de dado. E as ações corretivas, cada uma com responsável e prazo.

O quarto bloco é o que gera mais aprendizado e o que mais some dos relatórios. Registrar que o diagnóstico ficou parado boa parte do incidente porque ninguém tinha permissão no console do banco de dados é mais útil que qualquer descrição da falha em si. A anotação de atraso operacional é o que reduz o tempo médio de resolução do próximo incidente, e é também o que sustenta a discussão de investimento em observabilidade com a evidência da própria operação.

Ação corretiva sem responsável e sem prazo é intenção registrada.

Para o CEO e o CTO, o post-mortem é o mecanismo que converte incidente em previsibilidade, porque cada repetição evitada é risco removido do balanço. Para o SRE, é o insumo que alimenta a revisão do objetivo de disponibilidade e a decisão sobre onde o orçamento de erro deve ser gasto no período seguinte.

Critério de saída do passo 6: os cinco blocos estão preenchidos e cada ação corretiva tem responsável e prazo registrados.

Onde o procedimento costuma quebrar

Procedimentos bem escritos falham em campo por motivos recorrentes, e quatro deles aparecem com frequência suficiente para merecer verificação antes do próximo plantão.

O primeiro é o procedimento que existe apenas no documento. Runbook nunca exercitado revela lacuna de acesso, de contato e de permissão no pior momento possível, e o exercício periódico com a equipe de plantão é o que expõe essas lacunas em janela controlada. Simular um incidente conhecido custa uma tarde e economiza a primeira hora do incidente real.

O segundo é a ausência de critério de escalonamento. Sem regra escrita, escalonar vira decisão social: aciona-se quem tem confiança para acordar às três da manhã. O critério objetivo tem três gatilhos, definidos antes do incidente: tempo decorrido sem hipótese confirmada, impacto que ultrapassa um limite acordado e necessidade de acesso que o plantonista não possui.

O terceiro é a instrumentação que só cobre parte do percurso. Quando o rastreamento distribuído termina no limite do serviço próprio e a dependência interna aparece como caixa fechada, o diagnóstico para exatamente onde precisava avançar. A cobertura de instrumentação é decisão tomada em tempo de projeto, e cobra o preço em tempo de incidente.

O quarto é a inconsistência de nomes e atributos entre equipes. Quando o mesmo serviço aparece com identificações diferentes em contextos diferentes, os painéis fragmentam, a correlação automática perde precisão e o plantão volta a costurar dado à mão. Corrigir isso depois que o dado está em produção custa reprocessamento, e é por isso que a governança de atributos entra no início.

Há um traço comum aos quatro pontos de quebra. A organização decide todos eles fora do incidente, em tempo de projeto e de governança, e paga a conta dentro dele, quando já não há margem para decidir. Um procedimento de resposta é tão bom quanto a telemetria que o alimenta e quanto o exercício que o mantém vivo, e os dois dependem de trabalho contínuo, não de esforço concentrado depois da primeira indisponibilidade grave.

Perguntas frequentes

E se o serviço voltar sozinho, antes de qualquer ação do plantão?

Falha que se resolve sem intervenção continua sendo incidente e exige o mesmo registro. A investigação precisa acontecer enquanto a telemetria daquela janela ainda está retida, porque o comportamento intermitente costuma reaparecer sob condição de carga parecida. Sem esse registro, o próximo plantão recebe o mesmo sintoma sem contexto e recomeça o diagnóstico do zero.

Quem encerra formalmente o incidente, e o que acontece entre a mitigação e a correção definitiva?

O encerramento cabe a quem coordenou a comunicação, não a quem aplicou a mitigação, porque a mesma pessoa não consegue avaliar impacto e executar comando ao mesmo tempo. Enquanto o serviço opera pelo caminho alternativo, o incidente permanece aberto em severidade reduzida. A correção definitiva herda um responsável e um prazo, e o encerramento só ocorre quando ela entra em produção com validação.

Qual a diferença entre tempo médio de resolução e MTBF?

O MTTR mede quanto a organização leva para restaurar o serviço depois que a falha aparece. O Mean Time Between Failures, ou MTBF, mede o intervalo médio entre uma falha e a seguinte. Um procedimento de resposta bem executado melhora o MTTR. Melhorar o MTBF depende de correção estrutural, e é por isso que o post-mortem alimenta o segundo indicador, não o primeiro.

Indisponibilidade dentro de janela de manutenção planejada consome orçamento de erro?

Depende do que a equipe de operações e o negócio acordaram por escrito antes da janela. Manutenção anunciada, com horário e duração combinados, costuma ficar fora da contagem. O tempo que ultrapassa a janela combinada entra como indisponibilidade comum. Definir essa regra durante o incidente transforma medição em negociação, e o indicador perde valor para as duas partes.

O procedimento muda quando a degradação é lenta, sem indisponibilidade total?

A ordem dos seis passos permanece, mas o passo de confirmação fica mais custoso, porque a infraestrutura responde dentro do esperado enquanto o usuário já sente diferença. A medida que decide é o Digital Experience Monitoring, ou DEM, que observa o que o usuário efetivamente obteve na ponta. Sem essa leitura, a degradação lenta só é confirmada quando já virou indisponibilidade.

Estruturar resposta a incidente em ambiente crítico exige instrumentação adequada, correlação causal confiável e governança de performance sustentada ao longo do tempo. A Rike IS conduz esse trabalho sobre a plataforma Dynatrace, do diagnóstico do ambiente à rotina de revisão com a equipe de operações, em órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte. Leve o runbook do seu ambiente para uma conversa técnica com os especialistas da Rike IS.