Automatización y scripts de ops

1) Por qué automatizar las operaciones

Reduce los errores de MTTR/humanos, acelera las liberaciones y las reacciones.
Hace que las acciones sean repetibles y auditables (cumplimiento).
Libera el tiempo de los ingenieros para mejoras, no para rutinas.

2) Principios básicos

1. Idempotencia: reiniciar → el mismo resultado.
2. Barandillas seguras: dry-run, confirmaciones, límites, giros automáticos.
3. Observabilidad: los logs/métricas/tracks están integrados en cada script/paipline.
4. Configuración> constantes en el código: todo a través de parámetros/manifiestos.
5. GitOps/Docs-as-Code: código de operación versionada, rugida, probada.
6. Pequeños pasos: participaciones canarias, batches, retiros con presupuestos.
7. Sin secretos en los repos: sólo a través de los repositorios secretos.

3) Clases de tareas de automatización

Remediación e incidencias: retrocesos, conmutaciones de proveedores, banderas de ficha de degradación.
Trabajo programado: rotación de certificados/claves, migración de la DB (expand→migrate→contract).
Gestión de la infraestructura: IaC (Terraform), Configuraciones (Ansible), K8s manifiestos.
Datos y datosOps: backfills, ETL, validación de calidad.
Ejercicios de Xaoc/DR: simulaciones de fallos con gates de seguridad.

4) Cómo seleccionar una herramienta

Bash son scripts cortos de glue, orquestación CLI.
Python - lógica/SDK, retraídas, API, trabajar con JSON/YAML.
Ansible es una configuración idempotente, los agentes no son necesarios.
Terraform es una infraestructura declarativa.
Kubernetes Jobs/CronJobs - Tareas por lotes/Planificación.
Argo/Airflow son dependientes de DAG-y y orquestación.
ChatOps es un inicio seguro desde el chat con auditoría.

5) Arquitectura automática (referencia)

CLI/ChatOps → Controlador (GitOps/orquestador) → Intérpretes (Ansible/Terraform/K8s Job) → Monitoreo (logs/métricas/tracks) → Auditoría/ticketing → Artefactos Dock (evidence).

6) Idempotencia y gestión de la condición

«Comprueba, luego cambia»: detect-then-act (si ya OK - no hagas nada).
Almacena las «marcas de ejecución» (state/lock) para procedimientos largos.
Los procedimientos se dividen en pasos atómicos con posibilidad de volver a correr.

7) Errores, retraídas y retrocesos

Retraídas con retraso exponencial y jitter.
Presupuesto de tiempo de operación (SLA total por tarea).
Los giros y el «stop-boton» (circuit breaker) siempre están disponibles.
Códigos de retorno explícitos y errores estructurados.

8) Seguridad y secretos

RBAC/ABAC, privilegios mínimos, tokens temporales (JIT/JEA).
Secretos de Vault/KMS/Cloud Secret Manager; las llaves se rotan.
«Reparto de responsabilidades»: quien escribe no es quien aprueba y lanza en venta.
Auditoría-registro: quién/cuándo/qué/con qué resultado.

9) GitOps и ChatOps

PR → pruebas → rugido → merge → auto-promoción en el miércoles.
Los comandos en el chat (por ejemplo, '/ops deploy checkout --canary 5% ') invocan pipelines; los bots aplican la evidence y las referencias a los dashboards.

10) Planificación y orquestación

CronJobs/DAG con dependencias y deduplines.
Competitividad: 'Forbid', 'Replace', 'Allow' (K8s) dependiendo de la tarea.
Políticas de recursos/cuotas para no «comerse» el mero.

11) Observabilidad de la automatización

Métricas: éxito/error, duración, retraídas, objetos afectados.
Registros: estructurado, correlación-ID, línea roja en el error.
Tracks: los pasos de operaciones largas son visibles en los trazados distribuidos.
Alertas: por síntomas (SLO) y por métricas técnicas (deadline,% de errores).

12) Pruebas y simulaciones

Pruebas unitarias de lógica y parsers de artefactos.
Pruebas de integración en el sandbox y en el canario.
«Simuladores» (dry-run + proveedores ficticios), replay escenarios reales.
Enseñanzas: objetivos claros, puertas de seguridad, AAR→RCA→CAPA.

13) Plantillas de código

Bash (esqueleto con barandilla)

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 (retraídas + idempotencia)

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())

Ansible (tarea idempotente)

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: restarted

Kubernetes CronJob (rotación 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 Actions (gatillo de ChatOps)

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) Lista de verificación de implementación

• Se selecciona una herramienta para cada operación y se describe el runbook.
• Hay dry-run, confirmaciones y límites (barandilla).
• Los registros están estructurados, las métricas y las alertas están conectadas.
• Los secretos de la bóveda, los accesos son mínimos y temporales.
• Se han realizado pruebas (unit/integración/canario) y simulaciones.
• GitOps/PR-rugir son obligatorios, hay una auditoría.
• El plan de reversión y los criterios de éxito están documentados.
• La automatización está vinculada a SLO/presupuestos de errores.

15) Anti-patrones

Scripts sin idempotencia ni retroceso.
«Secretos en el código», cuentas superadmine para todo.
Correcciones manuales en venta sin auditoría.
Zoológico de Bash en lugar de un IaC declarativo.
Configuración «cosida» en código - No se puede volver a usar.
No hay dry-run/canarios → grandes explosiones.
Logs «para personas» sin estructura ni coralización.

16) Métricas de madurez Ops-automatización

Cobertura:% de las operaciones de automatización y runbook.
Tasa de éxito/Tasa de retroceso de las tareas automáticas.
Mean time to execute (duración media) y on-time (en tiempo de espera).
Change failure rate antes/después de la automatización.
Auditoría-exhaustividad:% de las operaciones con evidencia completa.
Titulies: tiempo de rotación de claves/certificados, cuota de accesos JIT.

17) Resultado

La automatización de ops no es un conjunto de scripts dispares, sino un sistema: acciones idempotentes, barandillas seguras, observabilidad, secretos y accesos bajo control, GitOps/ChatOps, pruebas y ejercicios. En este sistema, las operaciones se vuelven rápidas, predecibles y auditables, y el negocio recibe lanzamientos estables y un bajo riesgo de incidentes.