Sujet : change-management
-
Modifier un enregistrement DNS avec un plan de retour arrière : abaissement du TTL, bascule et vérification
Une modification DNS n'atteint les utilisateurs qu'à mesure que l'ancien TTL expire dans les caches : il faut donc abaisser le TTL une durée complète de l'ancien TTL avant le changement, laisser l'ancienne cible en service jusqu'à confirmation de la nouvelle partout, et tenir compte des résolveurs qui, comme le permet la RFC 8767, continuent de servir des données périmées lorsque les serveurs faisant autorité sont injoignables.
-
Liste de contrôle d'accès de secours avant toute modification à distance de la configuration de démarrage
Avant de modifier ce qui conditionne le démarrage d'un système distant (entrée par défaut du chargeur d'amorçage, paramètre du noyau, entrée fstab, unité dépendante du réseau ajoutée à une cible de démarrage), vérifiez qu'une seconde voie d'accès existe toujours, que l'accès console fonctionne réellement dès maintenant, qu'un état sain peut être restauré et qu'un retour arrière est écrit à l'avance plutôt qu'improvisé après coup.
-
Un calendrier de changements et des fenêtres de maintenance pour une petite équipe opérations
Placer chaque changement planifié susceptible d'affecter les utilisateurs sur un calendrier partagé unique avec un propriétaire, une fenêtre, une ligne de retour en arrière et des règles de blackout ; le livre SRE de Google indique que l'équipe SRE a constaté qu'environ 70 % des pannes sont dues à des changements sur un système en production, si bien que « qu'est-ce qui a changé ? » est la première question de tout incident, et le calendrier est l'endroit où elle trouve réponse.
-
Quand un service dont les utilisateurs se trouvent dans tous les fuseaux horaires doit-il planifier sa fenêtre de maintenance ?
Question ouverte : une fenêtre de maintenance à 3 h du matin localement correspond à midi pour quelqu'un d'autre ; comment les petites équipes desservant des utilisateurs mondiaux ont-elles choisi leurs fenêtres, et les fenêtres de minimum de trafic, de disponibilité de l'équipe ou tournant par région ont-elles entraîné moins de plaintes et des changements plus sûrs ?
-
Préparer la reprise avant un changement de durcissement : accès console, sauvegarde, retour arrière automatique planifié et journal des modifications
Méthode pour rendre tout changement de durcissement réversible avant de l'appliquer : vérifier l'accès hors bande, sauvegarder ce qui va changer, armer un retour arrière planifié qui se déclenche si rien ne confirme le succès, et journaliser le changement. Une erreur de réseau ou d'authentification se corrige ainsi d'elle-même, sans déplacement sur site.
Lisible par machine : JSON