APRENDER. PRATICAR. EVOLUIR.Aceitar a operação, não apenas os documentos
Uma equipa pode ter recebido o manual e continuar incapaz de operar o serviço. Define tarefas representativas para demonstrar acesso, diagnóstico, ação e escalada. Num exercício fictício, o turno noturno deve identificar o batch afetado, consultar logs autorizados e localizar o responsável pela reconciliação sem depender da conta pessoal do projeto. Regista quem executou, em que ambiente e com que resultado. Um ensaio bem-sucedido de uma pessoa não comprova cobertura de todos os turnos. Falhas encontradas geram correção, responsável e nova verificação; a transferência de responsabilidade só usa a evidência que realmente existe.
Medir o resultado que interessa
Define o indicador com população, resultado considerado bom, janela temporal e origem dos dados. Um serviço que devolve HTTP 200 mas entrega um ficheiro incompleto pode falhar o objetivo de negócio. Se 98 de 100 ficheiros elegíveis foram completos e recebidos antes do corte, a taxa desse exercício é 98%. Excluir os dois atrasados do denominador muda a pergunta medida. Distingue indicador, objetivo e acordo de serviço; não inventes penalizações contratuais. Se a medição só observa pedidos que chegaram ao backend, identifica o que pode faltar antes desse ponto e acorda cobertura suficiente com os responsáveis.
Testar alerta, encaminhamento e resposta
Ter uma regra no sistema de monitorização não prova que alguém recebe e trata o alerta. Num ensaio autorizado, verifica condição de disparo, destinatário, horário, confirmação e escalada. Um dashboard verde pode coexistir com um canal de paging desligado. Confirma também que o runbook liga o sintoma ao serviço e inclui limites do que o operador pode fazer. Um alerta sem responsável definido cria uma dependência oculta do projeto. Se o suporte externo só funciona em horário comercial, representa esse limite na cobertura prometida e decide como responder fora desse período antes de aceitar disponibilidade permanente.
Ensaiar recuperação até ao serviço utilizável
Um backup concluído não demonstra restauração utilizável. Num ensaio, confirma acesso ao destino, dados, chaves necessárias, aplicação, dependências e validação funcional. Mede desde o ponto de início acordado até ao resultado aceite; não pares o relógio quando a máquina arranca se o objetivo inclui reconciliação. Um tabletop exercita discussão e coordenação, mas não comprova sozinho o tempo de cópia dos dados. Identifica componentes comuns que podem falhar nos dois locais, como identidade ou gestão de chaves. Regista o âmbito realmente testado, os resultados e as exclusões para não transformar uma demonstração parcial numa garantia de resiliência.
Gerir exceções e terminar apoio temporário
Uma exceção aceite precisa de âmbito, risco, controlo temporário, responsável, prazo e evidência de fecho. Não uses uma lista de problemas como substituto da aceitação de quem vai operar. Se o projeto permanece em apoio temporário, define que tarefas continua a executar e os critérios para sair. No exercício, a saída pode exigir dois ciclos completos sem intervenção do projeto e sucesso num ensaio de escalada; esses critérios são definidos pelo caso, não uma norma universal. Se não forem cumpridos, propõe extensão ou correção autorizada. A chegada da data prevista não torna a equipa automaticamente autónoma.
Manter o serviço depois do fecho
A entrega continua a mudar após o fecho do projeto. Deixa responsáveis por rever contactos, acessos, monitorização, procedimentos de recuperação e dependências quando ocorrer uma alteração relevante. Num serviço fictício, substituir o middleware pode invalidar passos do runbook e tempos do ensaio anterior; o registo deve desencadear uma revisão proporcional ao impacto. Liga pendências de obsolescência e desativação a equipas que aceitaram o trabalho e o financiamento. Mantém evidência de encerramento, benefícios e limitações. Um fecho administrativo é uma decisão de governação; não apaga tarefas que continuam necessárias para manter o serviço.
O teste de backup está verde, mas RUN não consegue obter a chave necessária no local de recuperação. O projeto ainda não demonstrou restauração utilizável. A pendência precisa de acesso autorizado, ensaio e aceitação; enviar o manual não a resolve.
Armadilhas comuns
Aceitar presença numa formação como competência demonstrada; medir só componentes; excluir falhas do denominador; confundir tabletop com restauro; encerrar apoio temporário apenas pela data.
Tópicos relacionados: Conduzir decisões e comunicar o essencial · Tratar risco, obsolescência e recuperação · Preparar a mudança e entregar autonomia
A autonomia de RUN é demonstrada por pessoas, acessos, procedimentos e resultados; precisa de manutenção depois do projeto.
Referência: Contingency Planning Guide for Federal Information Systems · DR Technical Project Manager 2026.4; independent professional curriculum