APRENDER. PRATICAR. EVOLUIR.Separar proposta, decisão, execução e resultado
O modelo documental exige owner, decision=approved e critério de paragem para marcar uma ação pronta. Uma proposta não passa, e retirar qualquer campo obrigatório faz a verificação falhar. Estes resultados validam uma regra estrutural definida para o exercício. Não autenticam a autoridade, não avaliam a qualidade da decisão e não executam uma mitigação. No registo operacional, mantém separadas a opção proposta, a decisão tomada, quem executou, quando executou e o efeito observado. Uma aprovação pode anteceder uma tentativa sem efeito ou com efeito parcial. Esta distinção evita comunicar recuperação a partir de um ticket aprovado e permite que outra equipa reconstrua o que realmente aconteceu.
Confirmar o estado que foi aceite
O fixture tem estado na revisão três e um acknowledgement da revisão dois. A regra local rejeita essa passagem porque a aceitação não cobre o contexto atual. Uma confirmação da revisão três passa; se a mitigação muda e produz revisão quatro antes da passagem efetiva, a confirmação anterior volta a ser insuficiente para o novo contexto. Não se trata de exigir números de revisão em todas as ferramentas, mas de tornar visível o que a equipa seguinte reconheceu. Numa passagem real, confirma impacto, ações ativas, hipóteses abandonadas, limites, próximo checkpoint e responsabilidade. Um campo preenchido não demonstra que a pessoa compreendeu, tem acesso e consegue atuar.
Distinguir prazo decorrido de hora civil
O exercício define escalamento após noventa segundos sem a resposta exigida. As leituras monotónicas sintéticas passam de 1000 para 1120, logo decorreram 120 segundos e o prazo foi atingido. O relógio civil recuou e indicaria menos trinta segundos se fosse usado nessa subtração. Relógios monotónicos servem para medir diferenças de duração no âmbito adequado; a sua referência não é uma hora UTC para publicar na cronologia. Mantém timestamps civis com referência temporal para comunicar entre equipas e escolhe um mecanismo de duração apropriado aos requisitos do timer. O script não altera o relógio do computador e não testa suspensão do sistema nem sincronização entre hosts.
Verificar dependências das ferramentas de resposta
No grafo fictício, consola e chat dependem de identity-a e network-a. A alternativa telefónica depende de carrier-b. Quando identity-a falha e os restantes nós estão disponíveis, o modelo deixa apenas o telefone acessível. Aplicações diferentes não implicam independência de identidade, rede ou energia. O grafo ajuda a escolher uma verificação, mas não prova que o número está atualizado, que alguém atende ou que não faltam dependências. Atribui um responsável por confirmar a via alternativa e mantém o estado do incidente num meio acessível aos participantes. Ensaiar contactos e continuidade antes de uma falha reduz a necessidade de descobrir toda a cadeia durante a resposta.
Conduzir um tabletop com informação por fases
Para uma sessão acompanhada, distribui funções de coordenação, operações, comunicação e observação. Usa apenas dados fictícios e não contactes serviços reais. Na primeira fase, entrega backlog 600, entradas quarenta, conclusões cem e cut-off em oito minutos. Pede uma atualização com hipóteses e decisão. Na segunda, revela que ao minuto quatro as conclusões caíram para setenta. Na terceira, propõe admissão limitada e pede que a equipa identifique procura deslocada. Depois anuncia indisponibilidade do chat e, por fim, uma alteração da mitigação entre acknowledgement e passagem de turno. O facilitador deve guardar decisões e dúvidas, sem fornecer imediatamente as respostas. Estas fases são um guião criado para treino; não foram executadas por um grupo humano.
Avaliar decisões e fechar ações de aprendizagem
Na revisão do tabletop, verifica se a equipa atualizou a previsão quando as premissas mudaram, distinguiu mitigação de recuperação, comunicou impacto deslocado, confirmou uma via alternativa e transmitiu a alteração mais recente no handover. O objetivo não é premiar quem falou mais depressa. Liga cada lacuna a uma melhoria com responsável, prazo e condição observável: por exemplo, repetir uma passagem com atualização intercalar e demonstrar que o destinatário identifica a ação alterada e o novo critério de paragem. Os nove grupos automáticos verificam cálculos e regras locais; não medem compreensão, cooperação sob pressão ou competência operacional. Mantém revisão humana e aplicação acompanhada como trabalho por realizar.
python3 content/labs/incident-evidence/run.py
# approved record != executed action != observed recovery
# acknowledgement revision 2 does not cover current revision 3
# monotonic elapsed: 1120 - 1000 = 120 seconds
# Dependency graph availability is not a real fallback test.O turno seguinte aceitou a revisão três, mas uma alteração posterior introduziu outra mitigação. A equipa comunica o delta e confirma o estado atualizado antes de transferir responsabilidade.
Armadilhas comuns
Marcar recuperação pela aprovação, aceitar revisão antiga, usar hora civil para um timer sem considerar ajustes e assumir que outro produto tem dependências independentes.
Tópicos relacionados: Incident Manager · Change Management · Technical Project Manager
Continuidade exige estado atual, responsabilidades reconhecidas e meios de atuação. Os modelos tornam erros visíveis; a competência de coordenação precisa de prática e avaliação humana.
Referência: Managing incidents · Incident management practices 2026-09; scoped Google SRE, PagerDuty and Atlassian examples