LOW, MEDIUM, HIGH e DANGER: classificando risco antes de liberar playbooks Ansible

Uma das maneiras mais fáceis de criar um incidente com automação é tratar todos os playbooks como se tivessem o mesmo risco.

Tecnicamente, todos podem ser executados com:

1
ansible-playbook alguma-coisa.yml

Mas operacionalmente existe uma diferença enorme entre:

1
2
3
4
coletar uptime
reiniciar um serviço
alterar uma instância cloud
apagar um recurso

Na organização de uma plataforma Ansible + Semaphore, usamos uma taxonomia simples:

1
2
3
4
5
LOW
MEDIUM
HIGH
DANGER
UNKNOWN

Ela não tenta substituir change management ou análise de risco formal.

Serve para impedir que uma automação desconhecida ganhe interface de execução antes de alguém entender seu blast radius.

LOW — leitura, diagnóstico e inventário #

Exemplos típicos:

ping;
facts;
health check;
leitura de logs;
inventário;
consulta a API;
listagem de eventos;
coleta pré-migração.

A característica principal é não ter intenção de alterar estado do alvo.

Isso não significa risco zero.

Um playbook read-only ainda pode:

consultar centenas de hosts de uma vez;
gerar carga;
ler dados sensíveis;
produzir um arquivo com informação que não deveria sair do ambiente.

Mas é uma classe adequada para começar a validar inventories, credenciais e operação do Semaphore.

MEDIUM — configuração simples e reversível #

Exemplos possíveis:

instalar pacote;
alterar configuração controlada;
aplicar ajuste padronizado;
atualizar agente;
implantar configuração de logs.

Aqui já existe mudança.

Eu espero pelo menos:

1
2
3
4
5
escopo explícito
idempotência
backup quando necessário
validação pós-mudança
rollback conhecido ou mudança facilmente reversível

Quando existir check_mode útil, ele deve ser aproveitado.

HIGH — mudança que pode interromper serviço ou alterar produção #

A documentação do projeto coloca nessa classe ações como:

restart;
deploy;
alteração cloud;
mudança de produção.

É onde aparecem playbooks de:

1
2
3
4
5
reiniciar container
fazer deploy de API
resize de instância
migrar domínio
atualizar Nginx em produção

Para essa categoria, uma interface com um botão “Run” não é suficiente.

Quero guardrails adicionais.

DANGER — destruição ou perda potencial de recurso/dado #

A categoria DANGER é reservada para verbos como:

1
2
3
4
5
6
delete
destroy
expurgo
terminate
drop
truncate

Essas operações merecem tratamento separado porque a consequência não é apenas indisponibilidade temporária.

Pode existir perda permanente ou recuperação complexa.

Em muitos casos eu nem liberaria esse tipo de template para operadores gerais.

UNKNOWN é uma categoria útil #

Um erro comum é forçar classificação quando ainda não se leu o arquivo.

UNKNOWN é melhor que falsa segurança.

Se o nome é:

1
Ajuste_Redis.yaml

não dá para saber pelo nome se ele:

só lê configuração;
altera parâmetro;
reinicia Redis;
apaga cache;
mexe em persistência.

Até abrir o conteúdo, o estado correto é desconhecido.

Risco não deve ser deduzido apenas pelo módulo Ansible #

Um shell: pode executar algo inofensivo.

Um módulo declarativo pode aplicar uma mudança muito ampla.

O risco depende da combinação:

1
2
3
4
5
6
7
intenção
alvo
escopo
mudança
reversibilidade
impacto
proteções

Por isso a classificação é do procedimento, não apenas do módulo usado.

O mesmo playbook pode mudar de risco conforme o alvo #

Considere um restart:

1
2
um container de HMG → HIGH controlável
500 servidores de produção → HIGH com blast radius extremo

A categoria não precisa virar uma fórmula matemática, mas o template precisa levar o escopo em conta.

O Survey e o inventory são parte do risco.

Survey por categoria #

Um padrão documentado para a plataforma foi reduzir perguntas em LOW e exigir mais contexto conforme o risco cresce.

LOW #

1
2
3
target
motivo
ticket

MEDIUM #

1
2
3
4
5
target
ambiente
motivo
ticket
dry_run

HIGH #

1
2
3
4
5
6
target
ambiente
motivo
ticket
dry_run
confirmacao

DANGER #

1
2
3
4
5
target
ambiente
motivo
ticket
confirmacao

Isso não é uma especificação universal de Semaphore.

É um contrato operacional simples que deixa o risco visível na interface.

Confirmação textual ainda é melhor que nada #

Para HIGH/DANGER, a documentação sugere uma proteção do tipo:

1
2
3
4
if [ "${confirmacao:-}" != "SIM" ]; then
  echo "Execução bloqueada."
  exit 1
fi

Isso não é autenticação extra.

Também não evita alguém de digitar SIM sem pensar.

Mas elimina a execução crítica que acontece apenas porque todos os defaults já estavam preenchidos.

Em um desenho mais maduro, confirmação pode ser combinada com RBAC, aprovação externa, janela de mudança ou pipeline.

Nome do template deve denunciar a natureza da mudança #

Outra convenção útil:

1
2
3
4
5
Diagnóstico - Health Check
Diagnóstico - Logs Container
CHANGE - Reiniciar Container
CHANGE - Resize Cloud
DANGER - Remover Recurso

O operador não deveria descobrir que a receita reinicia produção depois de abrir os logs.

O nome faz parte do guardrail.

Um risco baixo pode ter blast radius alto #

Pense num inventário read-only executado contra 500 hosts simultaneamente.

A intenção é LOW.

Mas a concorrência pode gerar:

centenas de SSHs;
consultas a APIs;
carga em bastion;
excesso de logs;
tempo de task alto.

Por isso a plataforma também usa limites de paralelismo e duração máxima no control plane.

A classificação de mudança e o controle de execução são camadas diferentes.

Como eu revisaria um playbook #

Para classificar, responderia:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Ele altera estado?
Pode parar serviço?
Pode alterar cloud/DNS/rede?
Pode remover recurso/dado?
Existe rollback?
Existe check/dry-run?
Qual é o alvo máximo possível?
Que secrets usa?
A operação é idempotente?
Como o sucesso é validado?

Depois atribuiria a classe e registraria o motivo.

O que a fonte sustenta #

A documentação privada do projeto define explicitamente:

1
2
3
4
5
LOW     = leitura, diagnóstico, inventário, ping, listagem
MEDIUM  = instalação/configuração simples
HIGH    = restart, deploy, alteração cloud, alteração produção
DANGER  = delete, destroy, expurgo, terminate, drop, truncate
UNKNOWN = precisa leitura

Também documenta padrões de Survey por risco e a exigência de confirmação em operações críticas.

O artigo expande os princípios operacionais, mas não afirma que todo playbook do inventário já recebeu classificação final.

O principal aprendizado #

Automação remove passos manuais.

Ela não remove consequência.

Uma taxonomia simples de risco ajuda a responder antes da execução:

isso é só coleta, é mudança, pode interromper produção ou pode destruir alguma coisa?

Essa resposta deveria existir antes de oferecer o botão para outra pessoa clicar.