Automatisation et scripts ops
1) Pourquoi automatiser les opérations
Réduit MTTR/erreurs humaines, accélère les releases et les réactions.
Rend les actions répétables et auditables (conformité).
Libère le temps des ingénieurs pour les améliorations, pas la routine.
2) Principes de base
1. Idempotence : redémarrage → même résultat.
2. Garde-corps sécurisés : dry-run, confirmations, limites, auto-reculs.
3. Observabilité : les logs/métriques/trajets sont intégrés dans chaque script/pipline.
4. Configuration> constantes dans le code : tout à travers les paramètres/manifestes.
5. GitOps/Docs-as-Code : le code d'opération est versionné, revu, testé.
6. Petites étapes : parts canaries, batchs, retraits avec budgets.
7. Pas de secrets dans le repaire : seulement à travers les coffres secrets.
3) Classes de tâches d'automatisation
Remediation et incidents : reculs, changements de fournisseurs, drapeaux de dégradation de ficha.
Travaux planifiés : rotation des certificats/clés, migration des bases de données (expand→migrate→contract).
Gestion de l'infrastructure : IaC (Terraform), configurations (Ansible), manifestes K8s.
Données et DataOps : backfill, ETL, validation de qualité.
Exercice Xaoc/DR : simulation de défaillance avec des jeux de sécurité.
4) Comment choisir un outil
Bash est un court script glue, une orchestration CLI.
Python - Logique/SDK, Retrai, API, travailler avec JSON/YAML.
Ansible est une configuration idempotent, aucun agent nécessaire.
Terraform est une infrastructure déclarative.
Kubernetes Jobs/CronJobs - tâches/planification par lots.
Argo/Airflow - DAG et orchestration dépendantes.
ChatOps est un démarrage sécurisé à partir d'un chat avec un audit.
5) Architecture de l'automatisation (référence)
CLI/ChatOps → Contrôleur (GitOps/orchestrateur) → Interprètes (Ansible/Terraform/K8s Job) → Surveillance (logs/métriques/trajets) → Audit/Ticketing → Doc-artefacts (evidence).
6) Idempotence et gestion de l'état
« Vérifie, change ensuite » : detect-then-act (si déjà OK - ne fais rien).
Stockez les « notes d'exécution » (state/lock) pour les procédures longues.
Divisez les procédures en étapes atomiques avec possibilité de run répété.
7) Erreurs, retraits et retours
Retrai avec retard exponentiel et jitter.
Budget de temps d'opération (SLA total par tâche).
Les retours et le « bouton stop » (circuit breaker) sont toujours fournis.
Codes de retour explicites et erreurs structurées.
8) Sécurité et secrets
RBAC/ABAC, privilèges minimums, jetons temporaires (JIT/JEA).
Secrets de Vault/KMS/Cloud Secret Manager ; les clés tournent.
« Partage des responsabilités » : qui écrit n'est pas celui qui approuve et lance dans la vente.
Audit-journal : qui/quand/quoi/avec quel résultat.
9) GitOps и ChatOps
PR → tests → rhubarbe → merge → auto-promotion dans le milieu.
Les commandes de chat (par exemple, '/ops deploy checkout --canary 5 % ') appellent les piplines ; les bots appliquent l'evidence et les références aux dashboards.
10) Planification et orchestration
CronJobs/DAG avec dépendances et deblines.
Compétitivité : 'Forbid', 'Replace', 'Allow' (K8s) en fonction de la tâche.
Politiques de ressources/quotas pour ne pas « manger » la prod.
11) Observabilité de l'automatisation
Métriques : succès/erreur, durée, retraits, objets affectés.
Logs : structuré, correlation-ID, ligne rouge sur l'erreur.
Tracés : les étapes de longues opérations sont visibles dans les tracés distribués.
Alert : par symptômes (SLO) et par métriques techniques (deadline, % d'erreurs).
12) Tests et simulations
Les tests unitaires de logique et de parser les artefacts.
Tests d'intégration dans le bac à sable et sur le canari.
« Gym » (dry-run + fournisseurs fictifs), replay de scénarios réels.
Exercices : objectifs clairs, gates de sécurité, AAR→RCA→CAPA.
13) Modèles de code
Bash (squelette avec rampe)
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 + idempotence)
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 (tâche 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: restartedKubernetes CronJob (rotation planifiée)
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 (déclencheur 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) Chèque de mise en œuvre
- Pour chaque opération, un outil est sélectionné et décrit dans le runbook.
- Il y a dry-run, confirmations et limites (rampes).
- Les logs sont structurés, les métriques et les alertes sont connectées.
- Secrets du dépôt, accès minimum et temporaire.
- Des tests (unit/integration/canari) et des simulations ont été effectués.
- Les GitOps/PR sont obligatoires, il y a un audit.
- Le plan de reprise et les critères de réussite sont documentés.
- L'automatisation est liée aux budgets SLO/Error.
15) Anti-modèles
Scripts sans idempotence ni reculs.
« Les secrets dans le code », les comptes super-admin pour tout.
Modifications manuelles dans la vente sans audit.
Un zoo Bash au lieu d'un IaC déclaratif.
Les paramètres « cousus » dans le code ne sont pas réutilisés.
Pas de dry-run/canaries → grandes explosions.
Logs « pour les gens » sans structure et corulation.
16) Mesures de maturité de l'automatisation Ops
Coverage :% des opérations d'automatisation et de runbook.
Taux de réussite/Taux de retraite des tâches automatiques.
Mean time to execute (durée moyenne) et on-time (en deadline).
Taux d'échec de changement avant/après l'automatisation.
Audit-exhaustivité :% des opérations avec evidence complète.
Titrisations : temps de rotation des clés/certificats, part des accès JIT.
17) Résultat
L'automatisation ops n'est pas un ensemble de scripts disparates, mais un système : actions idempotentes, balustrades sécurisées, observabilité, secrets et accès sous contrôle, GitOps/ChatOps, tests et exercices. Dans un tel système, les opérations deviennent rapides, prévisibles et vérifiables - et l'entreprise reçoit des versions stables et un faible risque d'incident.