Capítulo 14 — Automação
Mapa da aula
Aula 14 publicada. Mapa, exemplo, EX053.
flowchart TD
N0["14.1 Automatizar"]
N1["14.2 Não automatizar"]
N2["14.3 Janelas"]
N3["14.4 Detecção de laços"]
N4["14.5 Revisão da saída"]
N5["14.6 Controle de mudanças"]
N6["14.7 Tarefas idempotentes"]
N7["14.8 Chave de desativação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX053"]
Desenho lógico
flowchart LR
N0["14.1 Automatizar"]
N1["14.2 Não automatizar"]
N2["14.3 Janelas"]
N3["14.4 Detecção de laços"]
N4["14.5 Revisão da saída"]
N5["14.6 Controle de mudanças"]
N6["14.7 Tarefas idempotentes"]
N7["14.8 Chave de desativação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX053"]
[14.1 Automatizar]
|
v
[14.2 Não automatizar]
|
v
[14.3 Janelas]
|
v
[14.4 Detecção de laços]
|
v
[14.5 Revisão da saída]
|
v
[14.6 Controle de mudanças]
|
v
[14.7 Tarefas idempotentes]
|
v
[14.8 Chave de desativação]
|
v
[Exemplo resolvido] --> [Exercício EX053]
Objetivos de aprendizagem
Você vai (1) decidir o que automatizar; (2) manter pessoas na validação; (3) agendar a automação dentro das janelas; (4) monitorar a automação para detectar laços.
14.1 Automatizar
Hashes, comparações de listas de portas, verificações de campos de chamados, esqueletos de relatório. A regra é automatizar apenas as verificações que Sam já faz do mesmo jeito toda semana, como classificar inventários e calcular hashes de evidências. As tarefas podem repetir esses caminhos comprovados, mas não podem inventar novos métodos, e uma automação que introduziria uma nova técnica de ataque é recusada para o ENG-512. A invenção de métodos fica, portanto, inteiramente fora da fila de automação; uma técnica nova precisa ser escrita como cartão de método, revisada e executada à mão primeiro.
14.2 Não automatizar
Exploração, decisões de escopo, severidade sem revisão. As decisões de parada e a ampliação do escopo também continuam humanas. Os operadores param diante de alertas de tarifa, e as tarefas nunca decidem sozinhas continuar. No código das tarefas, uma flag de alerta de tarifa é uma parada rígida que congela a execução, e não um aviso brando que um operador possa descartar. Manter essas escolhas fora da automação significa que um script não pode ampliar o ENG-512 nem continuar testando durante um alerta só porque ninguém estava olhando o console naquele momento. As classificações de severidade também esperam por um revisor humano antes de qualquer chamado ser aberto.
14.3 Janelas
A automação roda apenas dentro da janela do engajamento, com os mesmos limites de taxa. Os agendamentos das tarefas correspondem exatamente à janela de sábado das ROE. Tarefas livres de madrugada contra a homologação são violações do controle de mudanças, por mais convenientes que fossem, e os controles de acesso do agendador negam os usuários de ENG fora da janela assinada, para que a regra não dependa da memória. Isso mantém o tráfego automatizado dentro do período em que responsáveis e plantonistas o esperam e conseguem distinguir um teste de um problema real. Quando uma tarefa ainda está rodando no fechamento da janela, ela para e o restante espera pelo próximo horário combinado.
14.4 Detecção de laços
Limites de novas tentativas e de tempo máximo de execução são obrigatórios. A detecção de laços em cada tarefa encerra a execução quando respostas 401 se repetem além do orçamento de ruído. A parada das 10:12 do exercício sintético é o padrão que a automação deve copiar: a tarefa para, libera suas conexões e emite a mesma frase de interrupção que o exercício ensinou, para que o canal do engajamento receba uma mensagem que a equipe de resposta já reconhece. Uma tarefa sem limite de novas tentativas e sem limite de tempo de execução não está pronta para a janela de sábado, por melhor que tenha se saído num teste rápido.
14.5 Revisão da saída
Todo candidato a achado automatizado recebe validação humana. A revisão da saída é obrigatória antes que qualquer achado seja entregue. Linhas NOT APPROVED automatizadas ainda precisam de uma pessoa que verifique divergências de nome DNS, que a tarefa não consegue julgar, então o registro automático às cegas é recusado. As tarefas de abertura automática de chamados ficam desativadas até que essa etapa humana de divergência dê aprovação. A revisão custa alguns minutos por execução e evita que os responsáveis recebam chamados sobre hosts que apenas estavam listados com outro nome. Os revisores também confirmam que cada candidato corresponde a um host aprovado antes de virar chamado.
14.6 Controle de mudanças
Os scripts de automação são versionados como código de produção. O controle de mudanças da automação é igual ao controle de mudanças das ROE. Uma tarefa nova não pode entrar na janela de sábado até passar pela revisão por pares e até que o SOC seja avisado, com o mesmo modelo de um anúncio de mudança nas ROE. Acrescentar uma tarefa em silêncio é tratado como defeito, porque o SOC veria tráfego inesperado sem nenhum aviso que o explicasse e poderia responder como se fosse um ataque real. A versão da tarefa e o revisor que a aprovou são registrados com o aviso de mudança.
14.7 Tarefas idempotentes
Comparações automatizadas podem rodar duas vezes sem duplicar chamados. Sam usa host+porta+data como chave dos chamados para evitar duplicatas. O projeto idempotente é o que torna seguras essas novas execuções. Os geradores de relatório do ENG-512 de Sam fazem upsert pela chave do serviço em escuta, então executar uma tarefa uma segunda vez atualiza o chamado existente daquela porta, em vez de abrir uma duplicata. O upsert pela chave do serviço é coberto por um teste unitário no repositório de automação, para que uma mudança posterior no gerador de relatórios não reintroduza em silêncio chamados duplicados que os responsáveis teriam de fechar.
14.8 Chave de desativação
A automação tem uma flag global de desativação que o SOC pode solicitar. Sam testa essa flag no primeiro dia do engajamento. Com essa única flag, Sam pode desligar toda a automação de ENG se o planejador de viagens se comportar mal. O teste de desativação é um item do Laboratório II, e a chave precisa ser exercitada de ponta a ponta no ensaio; uma chave que existe só no papel mantém a tarefa fora da lista de sábado. Testá-la cedo significa que, se ela um dia for necessária durante uma janela real, ninguém estará descobrindo pela primeira vez se ela funciona de fato.
14.9 Disciplina de campo
Pull requests de automação precisam de um bloco de segurança: limites de taxa, interruptor de emergência, dry-run e a cláusula das ROE que permite a tarefa. Sem esse bloco, os revisores rejeitam o PR. Sam acrescentou o modelo depois que um script bem-intencionado rodou fora da janela porque o cron usava UTC e o autor pensava no horário local. A disciplina de campo para a automação é janela respeitada, atenção a laços, revisão e possibilidade de desativação. Esperteza sem supervisão não é um objetivo na NMT. Uma tarefa que falha em qualquer uma dessas quatro propriedades fica fora da lista de sábado até que a lacuna seja corrigida e revisada de novo por um colega.
14.10 Nota de encerramento
Sam acompanha num gráfico o tempo de execução da automação a cada noite. Uma tarefa que de repente leva dez vezes mais pode estar presa num laço ou lendo um inventário maior — os dois casos merecem um olhar humano antes da próxima janela. A automação multiplica bons cartões de método e também multiplica erros. Por isso, Sam só automatiza uma tarefa depois que uma execução manual do ENG-512 teve sucesso no mesmo caminho, com o cartão de método, a taxa e as evidências já revisados. Automatizar um caminho não comprovado apenas repete um erro não testado a cada execução agendada.
14.11 Extra
Os limites incluem tanto o número de novas tentativas quanto os minutos de relógio. A tarefa de comparação de portas de Sam morre depois de 20 minutos e o aciona; um travamento silencioso é tratado como um interruptor de parada que falhou. Como prática extra, Sam escreve um exercício de desativação no README de cada automação e o executa de fato no jump host antes de a tarefa ser agendada. Se a chave de desativação não foi testada, a tarefa fica fora da lista de sábado, porque uma chave que nunca foi acionada não dá garantia nenhuma. O README registra quando o exercício foi executado pela última vez, para que um revisor veja que a chave foi exercitada recentemente.
Exemplo resolvido (NMT sintética)
Sam automatiza a comparação de portas toda noite sobre as exportações de inventário da homologação durante a semana do engajamento; ele continua triando à mão as linhas NOT APPROVED.
Caso sintético — Northline Municipal Transit (NMT). A operadora de transporte, Sam Park e todos os números foram inventados para fins didáticos.
Erros e limites
Sistemas de transporte reais e equipamentos de tarifa nunca são testados sem uma autorização separada e especializada. Este livro usa apenas dados sintéticos e não concede autorização para testar sistemas reais.
Exercícios
- EX053 — Lista do que automatizar. Nomeie três bons candidatos à automação. Rubrica: 3 = três do capítulo; 2 = dois; 1 = um; 0 = nada.
- EX054 — Nunca automatizar. Nomeie duas coisas que Sam não deve automatizar. Rubrica: 3 = exploração e decisões de escopo; 2 = uma; 1 = hashes; 0 = nada.
- EX055 — Limite de novas tentativas. Por que as novas tentativas da automação precisam de limites? Rubrica: 3 = evitar bloqueios/tempestades de logs/laços; 2 = parcial; 1 = ilimitado é melhor; 0 = nada.
- EX056 — Etapa humana. O que sempre precisa de uma pessoa antes de um achado ser registrado? Rubrica: 3 = validação dos candidatos automatizados; 2 = parcial; 1 = nenhuma etapa; 0 = nada.
Síntese
Automatize o repetitivo; nunca automatize permissão, exploração nem severidade sem revisão.
Continue estudando — capítulo 14 de 18
← Capítulo 13 (rascunho) · Índice de capítulos do curso · Capítulo 15 (rascunho) →