APRENDER. PRATICAR. EVOLUIR.Definir a decisão que o documento suporta
Um runbook deve permitir que alguém decida e execute uma ação nas condições previstas. Começa pelo serviço, versão, público e operação: reiniciar uma instância não é recuperar uma aplicação nem reconciliar os ficheiros de um batch. Para um serviço fictício de reporting de fundos, identifica a janela de fecho, os dados de entrada e quem confirma a recuperação funcional. Regista pré-condições, resultado esperado, limites e contactos. O gestor de projeto pode exigir estes elementos na passagem para RUN, enquanto o especialista valida comandos e dependências. Uma página extensa sem critérios de sucesso continua a deixar decisões por resolver. Usa um ensaio para descobrir passos que o autor conhece de memória, mas que a equipa de prevenção não consegue inferir do texto.
Escolher a origem e controlar a revisão
Quando a documentação acompanha alterações de software, uma code wiki permite manter ficheiros Markdown no repositório e usar a revisão da branch publicada. O mapeamento identifica repositório, branch e pasta. Uma alteração em main:/docs não atualiza uma wiki que lê release/4:/ops. Antes de diagnosticar cache, compara esses três elementos e procura o commit no caminho efetivamente publicado. Para exigir revisão prévia, configura políticas na branch e verifica o seu cumprimento; a presença de um link para uma pull request não prova aprovação. No exercício, a correção tem de ser adaptada à versão 4 antes de ser integrada. Copiar cegamente as instruções da versão 5 pode introduzir opções de configuração que o binário anterior não reconhece.
Garantir acesso ao público certo
Testa leitura com uma identidade autorizada que represente RUN. O autor pode ter Basic e permissões de contribuição enquanto a prevenção tem outro nível de acesso. Em projetos privados, Stakeholder não dá acesso a uma code wiki publicada; permissões de repositório não substituem esse limite. Também não existe uma fronteira de permissões por página dentro da mesma wiki. Se determinadas instruções têm público restrito, separa-as num repositório ou sistema com controlo de acesso adequado. Remover uma entrada do índice não protege o conteúdo. No handover, regista quem consegue abrir a revisão necessária e como obter acesso de contingência autorizado. A alternativa deve respeitar a classificação do documento, sem distribuir credenciais ou aumentar permissões de escrita só para resolver leitura.
Navegação e diagramas que ajudam a agir
A navegação deve aproximar o operador do procedimento aplicável. Verifica nomes, capitalização, links e sequência de páginas; um índice desatualizado pode enviar o leitor para uma recuperação antiga. No ficheiro .order, a entrada usa o nome da página sem .md e com a capitalização correta. Para diagramas, distingue validade sintática de validade operacional. Um diagrama pode desenhar perfeitamente um processo errado. O exemplo apresenta restart seguido de Process running e fecho do incidente, mas a regra interna exige uma confirmação funcional. Acrescenta a verificação e os caminhos de sucesso e falha. A wiki tem limites próprios de Mermaid: usa a sintaxe documentada para o destino e verifica a apresentação, sem assumir que outro editor utiliza a mesma versão ou capacidades.
Fixar a versão aplicável à entrega
Uma branch é uma referência que pode avançar. O URL de main pode ser útil para a documentação atual, mas não identifica por si só o procedimento aprovado de uma release anterior. No pacote de passagem, liga a versão entregue à revisão exata do runbook e à evidência de revisão. Preserva também o âmbito: um documento correto para a aplicação errada não satisfaz a necessidade. O exemplo fictício usa release 4, uma revisão doc-r4 e um ensaio de recuperação com RUN. Se uma alteração de emergência modifica a configuração, reavalia as instruções afetadas antes de reutilizar a aprovação anterior. Esta ligação é uma convenção de governação do exercício; não é uma função automática que a plataforma garanta apenas porque o ficheiro está em Git.
Diagnosticar a cadeia de notificação
Uma notificação depende de um evento, uma subscrição que o selecione e uma forma de entrega ao público escolhido. Se Ana recebe avisos de main mas não de release/4, começa por comparar o filtro e o âmbito pessoal com o requisito da equipa. Não há motivo para alterar primeiro o transporte quando a condição de seleção já exclui o evento. Para service hooks, verifica ainda acesso aos recursos de origem: gerir subscrições não concede leitura de uma área restrita. Distingue esta situação de uma tentativa HTTP que falhou no destino. Regista o identificador do evento, a subscrição relevante e a etapa em que se perdeu a evidência. Isso permite escalar para a equipa certa sem inventar que toda a cadeia funcionou porque uma subscrição existe.
Confirmar destinatários e responsabilidades
O nome de uma subscrição de equipa não significa que todos recebem todos os eventos. A entrega por função pode selecionar apenas o responsável atual, enquanto outra opção envia individualmente aos membros. Confirma o público desejado antes de alargar a distribuição e avalia se os detalhes do evento podem ser partilhados com esse público. Uma mensagem técnica também precisa de contexto suficiente para a próxima ação: serviço, impacto observado, referência da alteração e ligação ao procedimento aplicável. A equipa deve saber quem assume a análise e quando escalar. Num contexto internacional, usa instantes explícitos e evita expressões como amanhã à noite sem fuso horário. O exercício não impõe um SLA universal; o prazo de reconhecimento e a escalada dependem do acordo interno e da criticidade do serviço.
Aceitar a passagem com evidência
Conclui a passagem através de um pequeno conjunto de demonstrações, não de uma contagem de páginas. No caso de reporting de fundos, RUN abre a revisão aprovada para release 4, interpreta o procedimento e executa um ensaio representativo num ambiente autorizado. A equipa regista resultado, restrições conhecidas e ações em falta. O gestor decide readiness a partir do critério acordado: neste caso, sem exceção aprovada, as lacunas de versão, acesso ou ensaio mantêm a passagem pendente. Um pacote alternativo pode ser válido se satisfizer as mesmas condições de conteúdo, controlo e utilização. Não basta exportar a página errada. O ensaio demonstra o que foi efetivamente testado; não garante sucesso em todos os incidentes nem substitui a revisão especializada dos comandos de produção.
sequenceDiagram
participant APS
participant App
APS->>App: Restart
App-->>APS: Process running
APS->>App: Functional check
alt Expected result observed
APS->>APS: Record evidence and close
else Failed or inconclusive
APS->>APS: Keep incident open and investigate
endA release 4 entra no sábado, mas a wiki em main descreve release 5. RUN não tem acesso à code wiki privada. A decisão permanece pendente até existir uma revisão aplicável aprovada, acesso autorizado e ensaio registado.
Armadilhas comuns
Confundir branch atual com revisão aprovada; usar a identidade do autor para aceitar acesso de RUN; tratar um diagrama bem desenhado como processo correto; confundir filtros com falhas de transporte.
Tópicos relacionados: Políticas de branch e revisão · Critérios de aceitação operacional · Diagnóstico de subscrições
Documentação operacional útil combina conteúdo aplicável, público autorizado, verificação prática e uma cadeia de comunicação que chega aos responsáveis certos.
Referência: Publish a Git repo to a wiki · AZ-400 objectives 2026-07-27