Un calendrier de changements et des fenêtres de maintenance pour une petite équipe opérations

Objectif

Rendre « qu'est-ce qui a changé ? » vérifiable d'un seul coup d'œil pendant un incident, écarter les changements risqués des heures où personne ne peut réagir, et prévenir les personnes qui utilisent le service d'une perturbation planifiée avant qu'elle ne commence.

Prérequis

Un calendrier partagé ou un simple tableau que peut lire et modifier quiconque déploie ; un accord sur ce qui constitue un changement (déploiements, migrations de schéma, changements DNS et de certificats, maintenance chez le fournisseur, mises à niveau d'infrastructure, bascules de feature flags ayant un impact utilisateur) ; un canal d'incident où le calendrier est relié par un lien.

Étapes

1. Définir le format des entrées : quoi, propriétaire, début et fin attendue, systèmes concernés, impact utilisateur attendu (aucun, dégradé, panne), plan de retour en arrière, étape de vérification. Une ligne pour chacun. Un changement sans ligne de retour en arrière n'est pas planifié.
2. Définir des fenêtres permanentes : une fenêtre courante pour les changements à faible risque pendant les heures ouvrées, quand le propriétaire et une seconde personne sont joignables, et une fenêtre de maintenance pour les travaux perturbateurs, annoncée à l'avance sur la page de statut. Énoncer les fenêtres dans un seul fuseau horaire nommé.
3. Définir des règles de blackout : aucun changement perturbateur la veille d'un jour férié, pendant un lancement, pendant un incident ouvert, ou lorsque le propriétaire du changement est aussi l'astreinte principale sans doublure. Les blackouts sont eux aussi des entrées de calendrier, donc visibles.
4. Ajouter les événements des fournisseurs. Les fournisseurs d'hébergement et de cloud annoncent des maintenances ; les copier dans le même calendrier afin qu'elles ne soient pas prises pour des changements internes pendant un incident.
5. Avant de commencer, le propriétaire publie « démarrage de <entrée> » sur le canal des opérations, puis « terminé, vérifié » ou « annulé » ensuite. Les déploiements automatisés publient les mêmes messages depuis le pipeline.
6. Pendant un incident, la première question est le calendrier : qu'est-ce qui a démarré ou s'est terminé dans les dernières heures ? Les entrées sans heure de fin sont les premières suspectes.
7. Faire une revue mensuelle : changements effectués hors fenêtres, changements sans ligne de retour en arrière, incidents dont la cause était un changement planifié. Ajuster les règles plutôt que d'ajouter des étapes d'approbation.

Résultat attendu

Les personnes qui répondent aux incidents corrèlent les symptômes avec les changements en quelques minutes ; les travaux perturbateurs cessent d'atterrir accidentellement un vendredi tard ; les personnes qui utilisent le service voient la maintenance planifiée avant qu'elle ne commence.

Limites et base de vérification

Le chiffre de 70 % est le constat rapporté par le livre SRE pour l'équipe SRE de Google, pas une constante universelle. Un calendrier qui exige une approbation pour chaque déploiement ralentit la livraison et se voit contourné ; garder le coût d'une entrée faible et réserver l'approbation à la catégorie fenêtre de maintenance. Aucun taux d'adoption ni aucune réduction de pannes n'est revendiqué.