# Construtor de Runbook de Janela de Mudança > Descreva uma mudança planejada em seis campos estruturados; um conjunto fixo de regras monta um runbook ordenado em seis fases — com os riscos que o plano carrega e ressalvas de prontidão sobre a entrada. Estrutura consultiva para revisar e adaptar, nunca uma aprovação. - Tool: https://ronutz.com/pt-BR/tools/change-window-runbook-builder - Family: Operações e fieldcraft --- ## O que faz Descreva uma mudança planejada por meio de seis campos estruturados — tipo de mudança, ambiente, raio de impacto, reversibilidade, a janela e as salvaguardas já em vigor — e um registro fixo de 22 regras originais dispara de forma determinística sobre essa descrição. O resultado é um RUNBOOK ORDENADO montado em seis fases fixas: pré-voo, aprovações e comunicação, execução, verificação, gatilhos de rollback e retorno, e encerramento. Ao lado dele, a ferramenta expõe os riscos que o plano carrega (classificados por severidade: uma mudança sem volta, um raio de impacto amplo, uma janela em horário comercial num sistema crítico) e ressalvas de prontidão sobre a própria entrada — nenhum backup marcado como feito, um rollback não marcado como testado, o monitoramento não pronto. Cinco presets de domínio (genérico, load-balancer, dns, tls-pki, firewall) dão sabor às sugestões de comando onde algum se aplica. Um clique exporta um runbook em Markdown pronto para o chamado de mudança ou para a ponte, com os passos que você marcou já assinalados. ## O que deliberadamente não é Esta ferramenta estrutura e sequencia; ela nunca aprova uma mudança e nunca executa nada. Não faz conexões de rede, não pede credenciais nem segredos, e não substitui o processo de aprovação de mudança nem a revisão de produção. O runbook que ela monta é uma proposta para revisar e adaptar ao seu próprio ambiente e aos seus padrões — quem executa e assina é uma pessoa. As notas em texto livre (resumo, detalhe da mudança, responsável pelo retorno) fluem apenas para o runbook exportado; nunca influenciam quais regras disparam, de modo que o comportamento do motor permanece totalmente determinístico. ## Como o runbook é montado — e como é verificado Cada regra é um predicado puro sobre a entrada estruturada; ao disparar, ela puxa um conjunto de passos (cada um pertencente a uma fase fixa) e, opcionalmente, um fator de risco. Um passo referenciado por várias regras ainda aparece uma única vez, ordenado pela primeira regra que o puxou; as fases em si são sempre emitidas na mesma ordem operacional, então o runbook se lê de cima a baixo como um de verdade. Toda mudança recebe uma espinha de base (delimite o escopo, faça o baseline, confirme a aprovação, aplique, verifique contra o baseline, observe, defina um gatilho de rollback, encerre), e as especificidades se somam a partir do tipo de mudança, da reversibilidade, do ambiente, do raio de impacto, da janela e do preset. O painel "Por que estes passos?" lista cada regra que disparou com o seu motivo, de modo que o plano é auditável, não oracular. Como não existe um único runbook "correto" para uma ferramenta consultiva, os vetores de ouro clássicos não se aplicam. O modelo de verificação — a decisão firmada pelo piloto do Construtor de Hipóteses de Falha para toda a família de Operações e Trabalho de Campo — é o de VETORES-INSTANTÂNEO DE DISPARO DE REGRAS: para cada entrada de teste, o build afirma exatamente quais regras disparam, na ordem do registro, os ids de passo exatos e ordenados em cada fase, o conjunto exato de fatores de risco e o conjunto exato de avisos de prontidão. Treze vetores (oito cenários, cinco rejeições) fixam o registro atual; qualquer desvio em regras, passos, atribuição de fase, riscos ou avisos quebra o build. ## Entrada da API O ponto de entrada com paridade de API recebe um objeto JSON: `{"changeType", "environment", "blastRadius", "reversibility", "window", "safeguards": [], "preset", "notes": {"summary", "changeDetail", "backoutOwner"}}`. Todos os campos exceto `notes` usam os vocabulários fechados mostrados no formulário; um valor fora do vocabulário (incluindo uma salvaguarda desconhecida) é um erro de formato, nunca um palpite. `safeguards` pode ser um array vazio. ## Standards and references - Original change-runbook ruleset (D-18: original by construction) - the 22-rule registry, 30 runbook steps across six fixed phases, 11 risk factors, and six readiness warnings are original editorial work encoding standard change-management practice (pre-flight, approvals and comms, phased execution, verification, back-out triggers, close-out); no external specification is claimed or reproduced ## Related reading - [Janelas de Mudança Que Não Viram Incidentes](https://ronutz.com/pt-BR/learn/change-windows-that-do-not-become-incidents.md): A maior parte das quedas autoinfligidas são mudanças que deram errado sem um caminho limpo de volta. A diferença entre uma mudança e um incidente raramente está na mudança em si; está no runbook em torno dela — o que você verificou antes, como sequenciou, o que o faria parar e se o caminho de volta estava escrito e testado antes de você precisar dele.