Procédures opérationnelles¶

Formaliser les processus recurrents pour les rendre prévisibles, reproductibles et transmissibles.

Différence entre runbook et procédure¶

Un runbook guide une action reactive (incident, alerte). Une procédure formalise une action planifiee, recurrente ou structurante. La procédure est exécutée en conditions normales, avec du temps pour vérifier chaque étape.

Procédure de déploiement¶

Une bonne procédure de déploiement est reproductible par n'importe quel membre de l'équipe, même sans connaissance approfondie de l'application.

flowchart TD
    A["Pre-requis verifies"] --> B["Notification parties prenantes"]
    B --> C["Sauvegarde / snapshot"]
    C --> D["Deploiement"]
    D --> E{"Tests de fumee"}
    E -->|OK| F["Validation fonctionnelle"]
    E -->|KO| G["Rollback"]
    F --> H["Notification cloture"]
    G --> H

Structure type d'une procédure de déploiement¶

Pre-requis

• Environnement cible identifié et accessible
• Version a déployer validee en preprod
• Fenêtre de maintenance confirmee avec les parties prenantes
• Contacts d'escalade disponibles

Étapes

1. Notifier l'équipe et les utilisateurs impactes (modèle de message en annexe)
2. Prendre un snapshot ou une sauvegarde de l'état courant
3. Exécuter le déploiement selon le pipeline CI/CD ou le playbook prévu
4. Lancer les tests de fumee définis (liste en annexe)
5. Valider les métriques clés (latence, taux d'erreur, sante des instances)
6. Confirmer la clôture aupres des parties prenantes

Rollback

En cas d'échec des tests de fumee ou d'anomalie critique après déploiement, revenir à la version précédente en utilisant le snapshot ou la procédure de rollback spécifique au composant (voir procédure rollback — lien).

Maintenance planifiee¶

La maintenance planifiee suit un schéma avant/pendant/après pour éviter les oublis.

Checklist de maintenance¶

Avant la maintenance

• Fenêtre de maintenance approuvee et communiquee
• Sauvegardes récentes verifiees
• Procédure de rollback préparée
• Monitoring d'après-maintenance préparé
• Contacts d'escalade identifiés

Pendant la maintenance

• Actions tracees dans le ticket de changement
• Communications aux équipes impactees si dépassement prévu
• Vérification intermédiaire des indicateurs de sante

Après la maintenance

• Tests fonctionnels valides
• Métriques revenues à la normale
• Documentation mise à jour si applicable
• Ticket de changement clos avec compte-rendu

Bascule DR (Disaster Recovery)¶

La bascule DR est la procédure la plus critique et la moins souvent exécutée. Elle doit être documentee de façon exhaustive et testée périodiquement.

Phases d'une bascule¶

Onboarding ops¶

L'onboarding d'un nouvel opérateur ou ingénieur ops est lui-même un processus documentable. Un onboarding bien structure réduit le temps avant autonomie et la charge pour l'équipe existante.

Parcours progressif¶

Checklist accès jour 1¶

• Accès VPN et bastion
• Accès aux outils de monitoring (Grafana, Datadog, etc.)
• Accès à la base documentaire (wiki, runbooks)
• Accès aux systèmes de ticketing
• Contact de l'astreinte en cours présenté