APRENDER. PRATICAR. EVOLUIR.O procedimento aplica-se a este alvo
Um runbook precisa de corresponder ao serviço, ambiente, versão e estado observados. No modelo original, o procedimento espera positions 2.4 em prod-eu e encontra versão 2.5. A autorização está confirmada, mas o estado necessário do batch é desconhecido. O modelo devolve duas lacunas: versão e pré-condição. Não executa qualquer comando nem decide autorizações reais. Na prática, L2 deve fornecer a diferença concreta ao owner, em vez de editar o registo para aparentar compatibilidade. Experiência anterior ajuda a investigar, mas não confirma automaticamente um contexto que mudou.
Transformar o âmbito em parâmetros
Se a decisão abrange um worker, um wildcard que seleciona todos os workers é uma diferença material. Revê a lista efetiva de alvos, a origem dos parâmetros e os limites da ação antes de executar. Um modo de pré-visualização pode ajudar, mas confirma que realmente não altera estado e que usa a mesma seleção da execução. O objetivo não é criar uma aprovação adicional genérica: é fazer corresponder a operação concreta ao âmbito já autorizado. Se o procedimento não permite demonstrar essa correspondência, apresenta a lacuna e pede a correção necessária.
Calcular a janela inteira
O exercício reserva nove minutos para executar, sete para validar e seis para rollback. São 22 minutos num modelo sequencial de durações fixas; uma janela de 20 não satisfaz esse plano. O cálculo não prevê variabilidade, dependências ou o tempo de uma decisão humana. A equipa deve avaliar esses fatores no ambiente real. Comparar apenas os nove minutos de execução com a janela omite etapas que permitem aceitar ou recuperar o serviço. L2 comunica opções e limites; uma alteração de janela ou de âmbito pertence ao responsável com autoridade para a decidir.
Reverter código não reconcilia dados
Uma imagem anterior pode arrancar sem conseguir interpretar os registos produzidos pela versão nova. O plano de recuperação precisa de considerar estado persistente, compatibilidade e efeitos externos. No caso fictício, o formato mudou e existem operações já escritas. Não elimines esses registos para fazer o dashboard ficar verde. Entrega a equipa responsável a lista de estados e o problema de compatibilidade, preservando identidades. A solução pode envolver migração compatível, recuperação controlada ou outra opção acordada. O curso não executa uma migração nem presume que qualquer rollback desfaz todas as alterações.
Probes e ações que podem ampliar o incidente
Uma liveness probe deve ser interpretada segundo a sua configuração e o problema que pretende detetar. Se depender de um serviço externo lento, restarts podem aumentar a instabilidade sem corrigir a dependência. Recolhe motivo dos restarts, resultado da probe e sintomas do serviço externo antes de propor repetição. Readiness e liveness têm funções diferentes; passar readiness também não prova a entrega de um ficheiro de fecho. A fonte Kubernetes apoia a distinção dos mecanismos. O exercício usa apenas um caso fictício, sem alterar probes, reiniciar Pods ou validar um cluster real.
Expiração e continuidade de uma mitigação
Uma mitigação temporária tem um estado observado, um responsável e um limite ou critério de remoção. No modelo, às 09:00 UTC o prazo também é 09:00, não há extensão e o próximo turno não aceitou a responsabilidade. O resultado assinala expiração e falta de dono, sem remover nem prolongar nada automaticamente. Esse detalhe importa: o relógio não prova execução de uma reversão. No handover, distingue o que ainda está ativo, o que foi autorizado e a decisão urgente que falta. A passagem só está concluída quando existe aceitação adequada da responsabilidade.
O gate do modelo identifica versão 2.5 em vez de 2.4 e batch desconhecido. Noutro cálculo, 9 + 7 + 6 minutos excedem a janela de 20 em dois minutos. Nenhum modelo executa mudanças.
Armadilhas comuns
Executar com versão diferente por hábito; aceitar wildcard além do âmbito; tratar desconhecido como confirmado; esquecer rollback na janela; assumir que expiração remove ou prolonga a mitigação.
Tópicos relacionados: Mitigação e validação operacional · Passagem de turno e melhoria · Cronologia, recuperação e passagem L2
Um runbook utilizável liga condições observáveis a ações delimitadas e a critérios de recuperação. A automação deve conservar essa ligação e a evidência do que fez.
Referência: The evolution of automation at Google · Operational support; PostgreSQL 18, OpenSSL 3.5 and BIND 9.20.29 examples; reviewed 2026-09-30