O que faz

Descreva o que você está mudando por meio de um pequeno formulário estruturado — o tipo de alvo, se ele está em hardware compartilhado, se está no caminho do tráfego, quantas coisas dependem dele, se há um par redundante e até onde vai o alcance de usuários — e um registro fixo de dezessete regras originais mapeia o raio de impacto. O mapa é um conjunto de camadas concêntricas: o próprio alvo da mudança, os vizinhos co-localizados que compartilham o dispositivo ou a plataforma dele, os serviços a jusante que dependem dele, e a superfície humana e de negócio por trás de tudo isso. Cada camada é preenchida com as categorias de coisa que poderiam ser afetadas ali. Ao lado do mapa, a ferramenta expõe fatores de risco classificados por severidade (no caminho do tráfego, tudo depende dele, sem redundância, voltado ao cliente) e medidas de contenção que encolheriam o raio (drenar antes, mudar um nó, fazer failover para o standby, reduzir o TTL, restaurar o par degradado). Uma faixa geral aproximada — contido, moderado ou amplo — resume o alcance. Um clique exporta uma avaliação de raio de impacto em Markdown para o chamado de mudança.

O que deliberadamente não é

Esta ferramenta não tem conhecimento da sua topologia real. Ela mapeia categorias a partir do que você descreve, não os seus servidores e enlaces específicos. Ela mapeia o que poderia ser afetado; nunca afirma o que vai quebrar. Não aprova uma mudança, não faz conexões de rede, não pede credenciais e não substitui nem uma análise de impacto real nem uma revisão de mudança. O mapa que ela produz é um convite a confirmar as especificidades contra o seu ambiente real, para que nada em uma camada seja esquecido. As notas em texto livre fluem apenas para a avaliação exportada; nunca influenciam quais regras disparam.

Como o mapa é montado — e como é verificado

Cada regra é um predicado puro sobre a entrada estruturada; ao disparar, ela adiciona itens de categoria afetada (cada um pertencente a uma camada fixa), opcionalmente um fator de risco e opcionalmente medidas de contenção. Um item puxado por várias regras ainda aparece uma única vez, ordenado pela primeira regra que o adicionou; as camadas são sempre emitidas na mesma ordem concêntrica, de modo que o mapa se lê do alvo para fora. A camada do alvo sempre tem o objeto que está sendo mudado e o estado que o seu backup precisa capturar; as outras camadas se preenchem a partir da co-localização, do caminho do tráfego, dos dependentes, da redundância, do alcance de usuários e do tipo de alvo. A faixa aproximada é derivada do risco de maior severidade que disparou. O painel "Por que este mapa?" lista cada regra que disparou com o seu motivo, de modo que o mapa é auditável, não oracular.

Como não existe um único mapa "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, as camadas preenchidas exatas com seus ids de item ordenados, os fatores de risco exatos, as medidas de contenção exatas, as ressalvas exatas e a faixa aproximada. Onze vetores (seis cenários, cinco rejeições) fixam o registro atual; qualquer desvio quebra o build. Uma borda deliberada é fixada abertamente: um alvo dedicado e autônomo com alcance estreito ainda cai numa faixa ampla, porque sem par qualquer interrupção é total — a leitura honesta, em vez de uma suavizada.

Entrada da API

O ponto de entrada com paridade de API recebe um objeto JSON: {"target", "colocation", "trafficPath", "dependents", "redundancy", "userReach", "preset", "notes": {"summary", "targetDetail"}}. Todos os campos exceto notes usam os vocabulários fechados mostrados no formulário; um valor fora do vocabulário é um erro de formato, nunca um palpite.