Automação ops e script
1) Por que automatizar operações
Reduz MTTR/erros humanos, acelera lançamentos e reações.
Torna as ações repetíveis e auditáveis.
Dispensa o tempo dos engenheiros para melhorar, não a rotina.
2) Princípios básicos
1. Idempotidade: reativação → o mesmo resultado.
2. Corrimãos seguros: dry-run, confirmações, limites, reversões automáticas.
3. Observabilidade: logs/métricas/trailers incorporados a cada script/pipeline.
4. Configuração> constantes no código: tudo através de parâmetros/manifestos.
5. GitOps/Docs-as-Code: O código de operações é versionalizado, revirado, testado.
6. Pequenos passos: canários, batches, retais com orçamentos.
7. Sem segredos no repo, só através do armazém secreto.
3) Classes de tarefas de automação
Remediações e incidentes: reversões, mudanças de provedores, bandeiras de descarga.
Rotações de certificados/chaves, migração de banco de dados (expand→migrate→contract).
Gerenciamento de infraestrutura: IaC (Terraform), configurações (Ansable), manifestos K8s.
Dados e DataOps: backphils, ETL, validação de qualidade.
Xaoc/DR.-exercício: simulações de falhas com gates de segurança.
4) Como selecionar ferramenta
Bash é um cenário glue curtos, uma orquestra CLI.
Python - lógica/SDK, retraí, API, trabalhar com JSON/YAML.
Ansable é uma configuração idumpotente, os agentes não precisam.
Terraform - infraestrutura declaratória.
Kubernetes Jobs/CronJobs - tarefas de pacote/planejamento.
Argo/Airflow - os dependentes DAG e orquestra.
ChatOps é um lançamento seguro a partir de um bate-papo com áudio.
5) Arquitetura automática (arbitragem)
CLI/ChatOps → Controlador (GitOps/orquestrador) → Executores (Ansable/Terraform/K8s Job) → Monitoramento (logs/métricas/trailers) → Auditoria/tiketing → Artefatos Docas (evidence).
6) Idempotidade e controle de estado
«Verifique e mude»: detect-then-act (se já for OK, não faça nada).
Guarde «marcações de execução» (state/lock) para procedimentos longos.
Divida os procedimentos em passos atômicos com possibilidade de ser novamente testado.
7) Erros, retais e reversões
Retraias com atraso exponencial e jitter.
Orçamento de tempo de operação (SLA total para a tarefa).
Os rebotes e «stop-botão» (circuito breaker) estão sempre disponíveis.
Códigos de retorno explícitos e erros estruturados.
8) Segurança e segredos
RBAC/ABAC, privilégios mínimos, tokens temporários (JIT/JEA).
Segredos de Vault/KMS/Cloud Secret Gerente; as chaves rotinam.
«Partilha de responsabilidades»: quem escreve não é quem aprova e lança em venda.
Registo de auditoria: quem/quando/com que resultado.
9) GitOps и ChatOps
PR → testes → revezamento → merj → promoção automática no ambiente.
Comandos no bate-papo (por exemplo, '/ops deploy checkout --canary 5% ') chamam pipline; os bots aplicam evidence e referências a dashboards.
10) Planejamento e orquestração
Com dependências e deadline.
Competição: «Forbid», «Replace», «Allow» (K8s), dependendo da tarefa.
Políticas de recursos/quotas para não «comer» proda.
11) Observabilidade automática
Métricas: sucesso/erro, duração, retratos, objetos afetados.
Logs: estruturados, correlation-ID, linha vermelha em erro.
Trailers: Os passos das operações longas são visíveis nos traçados distribuídos.
Alerts por sintomas (SLO) e métricas técnicas (deadline,% de erros).
12) Testes e simulações
Testes unit de lógica e parsers de artefactos.
Testes de integração na caixa de areia e no canário.
«Aparelhos» (dry-run + provedores fictícios), replay de cenários reais.
Objectivos claros, gates de segurança, AAR→RCA→CAPA.
13) Modelos de código
Bash (esqueleto com corrimão)
bash
!/usr/bin/env bash set -Eeuo pipefail trap 'echo "[ERR] line $LINENO"; exit 1' ERR
log(){ printf '%s %s\n' "$(date -Iseconds)" "$"; }
DRY=${DRY_RUN--true}
ensure_dep(){ command -v "$1" >/dev/null { echo "need $1"; exit 2; }; }
apply_change(){
local target="$1"
if [[ "$DRY" == "true" ]]; then log "[DRY] would update $target"
else kubectl apply -f "$target"
fi
}
main(){
ensure_dep kubectl for f in manifests/.yaml; do apply_change "$f"
done log "done"
}
main "$@"Python (retrai + idempotação)
python import argparse, time, json, sys from pathlib import Path import requests
def with_retries(fn, attempts=5, base=0. 2):
for i in range(attempts):
try:
return fn()
except Exception as e:
sleep = base (2i)
time. sleep(sleep)
raise
def already_done(marker):
return Path(marker). exists()
def mark_done(marker):
Path(marker). write_text("ok")
def main():
ap = argparse. ArgumentParser()
ap. add_argument("--endpoint", required=True)
ap. add_argument("--marker", default="/tmp/op. marker")
args = ap. parse_args()
if already_done(args. marker):
print("idempotent: nothing to do"); return
def call():
r = requests. post(args. endpoint, json={"action":"rotate"})
r. raise_for_status()
return r. json()
resp = with_retries(call)
print(json. dumps(resp))
mark_done(args. marker)
if __name__ == "__main__":
sys. exit(main())Ansível (tarefa Idumpotente)
yaml
- hosts: web become: true tasks:
- name: Ensure nginx present and enabled ansible. builtin. package:
name: nginx state: present
- name: Deploy config ansible. builtin. template:
src: nginx. conf. j2 dest: /etc/nginx/nginx. conf mode: '0644'
notify: restart nginx handlers:
- name: restart nginx ansible. builtin. service:
name: nginx state: restartedKubernetes CronJob (rotação programada)
yaml apiVersion: batch/v1 kind: CronJob metadata:
name: cert-rotate spec:
schedule: "0 3 "
concurrencyPolicy: Forbid jobTemplate:
spec:
template:
spec:
serviceAccountName: ops-automation restartPolicy: OnFailure containers:
- name: rotator image: registry/ops/rotator:1. 2. 3 args: ["--rotate", "--budget-ms=60000"]
envFrom:
- secretRef: { name: rotator-secrets }GitHub Action (ChatOps desencadeador)
yaml name: ops-deploy on:
workflow_dispatch:
inputs:
service: {required: true}
canary: {required: false, default: "5"}
jobs:
deploy:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run:./scripts/deploy. sh "${{ inputs. service }}" --canary "${{ inputs. canary }}"14) Folha de cheque de implementação
- Cada operação tem uma ferramenta selecionada e um runbook descrito.
- Há dry-run, confirmações e limites (corrimão).
- Os logs estão estruturados, as métricas e as alertas estão conectadas.
- Segredos do armazém, acessíveis mínimos e temporários.
- Testes (unit/integração/canário) e simulações foram realizadas.
- GitOps/PR-revezamento são obrigatórios, há uma auditoria.
- O plano de retrocesso e os critérios de sucesso foram documentados.
- A automação está ligada a SLO/orçamento de erro.
15) Anti-pattern
Não há Idempotidade ou recalls.
«Segredos no código».
Edição manual em venda sem auditoria.
Um zoológico de um pedaço em vez de uma IaC declaratória.
Parâmetros «costurados» para o código - sem reutilização.
Não há dry-run/canarinhos → grandes explosões.
Logs «para os humanos» sem estrutura ou coralização.
16) Métricas de maturidade Ops automação
Coverage:% das operações de automação e runbook.
Sucess rate/Retry rate tarefas automáticas.
Mean time to execute (duração média) e on-time (deadline).
Mudar failure rate antes/depois da automação.
Auditoria completa:% das operações de evidência completa.
Securities: tempo de rotação de chaves/certificados, proporção de JIT disponível.
17) Resultado
A automação ops não é um conjunto de script esparsos, mas sim um sistema: ações idumpotentes, corrimãos seguros, observabilidade, segredos e acessibilidade sob controle, GitOps/ChatOps, testes e ensinamentos. Nesse sistema, as operações tornam-se rápidas, previsíveis e audíveis - e os negócios recebem lançamentos estáveis e baixo risco de incidentes.