Gestion des systèmes distribués en production

La gestion des systèmes distribués consiste à exploiter, observer, modifier, sécuriser, dimensionner et rétablir des logiciels dont les composants communiquent par un réseau. Elle porte sur le service utilisé et sur les processus, machines, bases de données et services externes qui le rendent possible.

Pour les équipes de développement et d'exploitation, la question centrale est de savoir si les utilisateurs peuvent accomplir leur tâche. Des serveurs en fonctionnement et des conteneurs en bonne santé fournissent des indications utiles, mais un paiement peut échouer alors que chaque instance se déclare disponible. Ce guide explique comment définir la santé du service, maîtriser les changements, limiter la propagation des pannes et tester la reprise.

Pourquoi la gestion des systèmes distribués est-elle différente ?

Les systèmes distribués connaissent des défaillances partielles : un composant ou un chemin réseau peut cesser de fonctionner tandis que les autres restent actifs. Une requête peut traverser plusieurs services, attendre une base de données et créer une tâche dans une file. Les équipes peuvent observer l'erreur finale loin de sa cause initiale.

L'état du système ajoute une difficulté. Des réplicas peuvent conserver différentes versions des données, dans les limites des garanties de leur protocole de réplication. Un déploiement peut faire coexister anciennes et nouvelles versions du logiciel. Remplacer un processus défaillant ne permet pas de savoir si sa dernière opération a abouti ni si les tâches en attente reprendront correctement.

La gestion nécessite donc deux vues liées. La vue du service mesure des résultats utiles, comme les commandes terminées ou l'actualité des rapports. La vue des composants examine les dépendances qui produisent ces résultats. Commencez l'analyse par le symptôme visible pour l'utilisateur, puis utilisez les observations sur les composants pour l'expliquer.

Gestion et orchestration

L'orchestration des charges de travail automatise une partie de l'exploitation. Kubernetes, par exemple, gère des charges conteneurisées à l'aide de mécanismes d'état souhaité et prend en charge le déploiement, la mise à l'échelle, la découverte de services et le remplacement de conteneurs. Ces capacités ne définissent ni les objectifs de service de l'application, ni ses procédures de récupération des données, ni les responsabilités en cas d'incident.

La gestion des systèmes distribués couvre aussi les décisions de capacité, le contrôle des accès, la revue des changements, les sauvegardes, les coûts et les personnes chargées d'intervenir. Un système peut fonctionner sur des machines virtuelles ou des serveurs physiques sans orchestrateur de conteneurs et nécessiter tout ce travail.

Une exécution distribuée n'impose pas de décentraliser toutes les décisions de gestion. Un plan de contrôle ou un service de configuration commun peut coordonner plusieurs nœuds, mais devient alors une dépendance avec ses propres besoins d'exploitation. Notre guide des systèmes distribués et décentralisés explique la différence entre la répartition du travail et celle du contrôle.

Connaître les services, les dépendances et les responsables

Tenez à jour un catalogue des services et une cartographie des dépendances utilisables pendant un incident. Incluez les services applicatifs, bases de données distribuées, files de messages, caches, systèmes de stockage, services d'identité, DNS et API externes. Un schéma qui omet l'authentification ou un service de paiement tiers peut manquer la dépendance qui empêche la reprise.

Pour chaque composant critique, documentez :

• Les responsabilités : équipe propriétaire, couverture du support et procédure d'escalade.
• Les dépendances : services appelés et services ou parcours utilisateurs qui dépendent du composant.
• L'état : données dont il est responsable, emplacement de stockage et méthode de récupération.
• Le déploiement : versions actives, emplacements, sources de configuration et limites importantes.
• Les consignes d'exploitation : tableaux de bord, symptômes connus et procédures testées.

Actualisez ces informations lorsque les dépendances ou les responsabilités changent. Le catalogue doit aider une personne qui intervient à trouver les bonnes observations et le bon interlocuteur. Il n'a pas besoin de reproduire tous les détails de l'implémentation.

Définir la santé du service avec les SLI et les SLO

Un indicateur de niveau de service, ou SLI, mesure un aspect défini du comportement d'un service. Un objectif de niveau de service, ou SLO, fixe une cible pour cet indicateur sur une période donnée. Les recommandations SRE de Google expliquent comment relier ces mesures aux décisions d'exploitation et au service reçu par les utilisateurs.

Choisissez des indicateurs adaptés à la charge de travail. Une API interactive peut nécessiter des objectifs de réussite des requêtes et de latence. Un pipeline de données peut nécessiter un objectif de fraîcheur des résultats. Un service de stockage doit fournir des observations sur la conservation et la récupération des données. L'utilisation du processeur aide à expliquer le comportement, mais représente rarement le résultat attendu par l'utilisateur.

Définissez les règles avant de calculer un pourcentage : requêtes prises en compte, résultats considérés comme réussis, point de mesure, exclusions et période. Une réponse HTTP 200 peut contenir un résultat incorrect. Une mesure effectuée côté serveur peut manquer un délai subi par le client.

Prenons un SLO illustratif fondé sur les requêtes, avec un objectif de 99,9 % de réussite. Sur un million de requêtes prises en compte, 1 000 peuvent échouer pendant la période. Ce budget porte sur des requêtes, pas sur un nombre fixe de minutes d'indisponibilité. Le convertir en temps nécessite des hypothèses sur le trafic et la répartition des échecs. Un objectif de disponibilité mesuré en temps utilise un autre calcul.

Convenez de la réponse à une consommation trop rapide du budget d'erreur, par exemple limiter les mises en production risquées pour donner la priorité à la fiabilité. Une longue période de mesure ne permet pas non plus de confirmer la fin d'un incident en cours : vérifiez séparément les résultats récents et les tâches en attente.

Relier les métriques, les journaux et les traces distribuées

La supervision suit certaines conditions définies ; l'observabilité aide à comprendre pourquoi le système se comporte ainsi. Le guide d'observabilité d'OpenTelemetry décrit comment l'instrumentation produit des métriques, des journaux et des traces permettant d'expliquer l'activité entre les services.

Les métriques montrent des mesures dans le temps, comme le débit des requêtes ou l'ancienneté des tâches en attente. Les journaux enregistrent des événements et leur contexte. Le traçage distribué relie des segments de travail instrumentés le long d'une requête. Propagez le contexte de trace entre les services et les systèmes de messagerie concernés, et ajoutez des identifiants de corrélation utiles aux journaux.

La trace d'une commande lente peut montrer une attente liée au service de stock. Une instrumentation absente ou l'échantillonnage peuvent laisser des lacunes : une trace documente le travail capturé, sans prouver tout ce qui s'est passé. De même, un journal reste utile sans identifiant de trace, mais relier les événements devient plus difficile.

Gardez une télémétrie exploitable. Choisissez délibérément les durées de conservation et l'échantillonnage, limitez la cardinalité incontrôlée des étiquettes de métriques et restreignez l'accès aux données d'exploitation. Les identifiants secrets et les données personnelles inutiles ne doivent pas entrer dans les journaux. Enregistrez les déploiements et les modifications de configuration pour pouvoir les rapprocher des symptômes.

Surveiller les signaux du service et rendre les alertes utiles

Les quatre signaux de référence présentés par Google SRE constituent un point de départ pour la supervision des systèmes distribués :

• Latence : durée des opérations, y compris les plus lentes et celles qui échouent.
• Trafic : demande entrante, par exemple requêtes ou tâches par seconde.
• Erreurs : opérations échouées, résultats incorrects ou hors des exigences de service convenues.
• Saturation : pression sur une ressource limitée, comme les connexions, la mémoire, le stockage ou la capacité des workers.

Adaptez les mesures à la charge. L'ancienneté d'une tâche en attente peut compter davantage que la longueur de la file lorsqu'un résultat est attendu rapidement. Examinez la distribution des latences lorsque c'est utile : une moyenne seule peut masquer un petit groupe de requêtes beaucoup plus lentes.

Déclenchez une alerte d'astreinte lorsqu'une intervention rapide est nécessaire. Transformez les investigations moins urgentes en tickets et conservez les informations de diagnostic dans les tableaux de bord ou les journaux. Chaque alerte doit avoir un responsable, expliquer l'impact et proposer une première action utile. Supprimez les alertes redondantes ou régulièrement sans suite exploitable.

Maîtriser la configuration et les changements logiciels

Une modification de configuration peut toucher les adresses des services, les indicateurs de fonctionnalités, les délais, les politiques de nouvelle tentative, les règles d'accès et les limites de ressources. Suivez la configuration souhaitée et comparez-la à l'état effectif. Certaines différences sont volontaires pendant un déploiement : recherchez les écarts inexpliqués plutôt que d'exiger des instances identiques à tout instant.

La configuration ordinaire doit être versionnée, révisable, reproductible et traçable. Conservez les secrets dans un système adapté et référencez-les depuis la configuration. Prévoyez une procédure contrôlée pour les changements d'urgence, avec enregistrement des modifications et réconciliation ultérieure avec la source habituelle.

Un déploiement pose un problème de compatibilité autant que de planification. Anciennes et nouvelles versions peuvent échanger des messages. Les événements stockés peuvent survivre à la version qui les a produits. Après un retour arrière, un ancien binaire peut rencontrer des enregistrements écrits par la nouvelle version.

Les mises à jour progressives remplacent les instances par étapes. Un déploiement canari expose une population limitée avant d'étendre la nouvelle version. Un déploiement bleu-vert bascule le trafic entre deux environnements. Le guide de Google sur les déploiements canaris explique l'importance d'un trafic représentatif et de mesures pertinentes. Chaque méthode exige de vérifier les dépendances partagées et la compatibilité des données.

Avant la mise en production, définissez les critères d'arrêt et la stratégie de rétablissement : retour arrière, version corrective, désactivation d'une fonctionnalité ou modification du routage. Traitez les migrations de schéma séparément. Restaurer une ancienne version de l'application n'annule pas une transformation irréversible des données.

Planifier la capacité et agir sur le goulot d'étranglement

Les performances dépendent des ressources et de la coordination sur le chemin de la charge de travail. Ajouter des réplicas applicatifs ne corrige pas une base saturée, une opération sérialisée, une partition surchargée ou une API externe limitée. Ces réplicas peuvent même augmenter la pression en ouvrant davantage de connexions ou en multipliant les nouvelles tentatives.

Mesurez une demande représentative et les ressources qu'elle consomme. Tenez compte des pics, de la croissance, du surcoût des déploiements, de la maintenance et de la perte d'un composant. La capacité totale du système devient moins utile si la perte d'un nœud surcharge tous les autres.

La mise à l'échelle horizontale ajoute des instances ; la mise à l'échelle verticale modifie la capacité d'une instance. Les deux peuvent aider si elles répondent à la contrainte réelle. La mise à l'échelle automatique prend aussi du temps pour observer la demande et démarrer une capacité utilisable. Testez son délai, ses limites, le démarrage des instances et ses effets sur les dépendances.

Pour les files, suivez le débit d'arrivée, le débit de traitement, l'ancienneté des tâches et les limites de stockage. Si le travail arrive durablement plus vite qu'il n'est traité, l'accumulation continue. Une file laisse du temps pour réagir ; elle ne fournit pas la capacité de traitement manquante.

Limiter les surcharges et les défaillances distantes

Définissez les tâches qui peuvent attendre, celles qui peuvent être refusées et celles qui nécessitent une capacité réservée. Limites de débit, limites de concurrence, files bornées et contrôles d'admission peuvent empêcher une demande excessive de consommer toutes les ressources. Séparez les réserves de ressources lorsqu'une charge ne doit pas épuiser celles d'une autre.

Fixez des échéances explicites aux opérations distantes. L'expiration d'un délai signifie que l'appelant a cessé d'attendre, pas que l'opération distante n'a eu aucun effet. Réessayer un paiement ou une commande nécessite donc une gestion des doublons liée à un état applicatif durable. Une annulation n'efface pas une modification déjà validée.

Les recommandations AWS sur les nouvelles tentatives préconisent de borner leur nombre, d'espacer progressivement les essais et d'ajouter une variation aléatoire. Déterminez les échecs qui autorisent une nouvelle tentative et respectez le temps restant. Coordonnez ces politiques entre clients, passerelles et services pour éviter de multiplier le même travail. Un refus pour manque de capacité peut autoriser un nouvel essai différé selon le contrat du service ; une requête invalide inchangée ne le permet généralement pas.

Un disjoncteur logiciel peut interrompre les appels répétés à une dépendance défaillante. Ses seuils, ses sondes de rétablissement et son comportement de repli doivent être testés. Le repli doit préserver le sens métier : afficher une commande acceptée alors que le statut du paiement est inconnu crée un autre problème.

Gérer séparément l'état, les sauvegardes et la reprise

Remplacer un processus et récupérer ses données sont deux opérations différentes. Pour les bases de données distribuées, stockages objet, courtiers de messages et systèmes de fichiers distribués, comprenez les garanties relatives aux écritures confirmées, au retard des réplicas, aux tâches en attente et au comportement des clients pendant une bascule.

La réplication peut fournir une autre copie utilisable, mais aussi propager une suppression accidentelle ou une mise à jour corrompue. La haute disponibilité ne supprime pas le besoin de conserver des points de récupération. Une bascule ne garantit pas non plus une absence d'interruption ou de perte de données pour toute défaillance.

Définissez un objectif de délai de reprise (RTO), le délai acceptable avant le rétablissement du service, et un objectif de point de reprise (RPO), l'intervalle acceptable de perte de données. Les recommandations AWS sur les objectifs de reprise relient ces choix à l'impact sur l'activité. Retenez des exigences nécessaires à l'entreprise et compatibles avec la solution de reprise.

Un exercice de restauration doit récupérer les données, reconstruire l'environnement nécessaire, rétablir les accès, reconnecter les dépendances et valider le fonctionnement utile de l'application. Mesurez toute la séquence et vérifiez les enregistrements manquants ou dupliqués, les autorisations et les messages en attente. Récupérer un fichier de sauvegarde ne démontre pas à lui seul la reprise du service.

La récupération dépend aussi des responsabilités et du sens des données. Les équipes doivent savoir quels enregistrements font autorité et comment réconcilier les systèmes après une interruption. Notre guide du système d'information distribué traite cette dimension de la gestion de l'information.

Maintenir la sécurité et les accès entre les services

Suivez les identités humaines et applicatives, les autorisations, les secrets, les certificats, les accès administratifs et les dépendances logicielles. Les recommandations zero trust du NIST rejettent la confiance implicite fondée uniquement sur l'emplacement réseau. La présence sur un réseau interne ne suffit pas à justifier une autorisation.

Accordez à chaque service les droits nécessaires, utilisez des connexions chiffrées adaptées et auditez les actions sensibles. Le contrôle d'accès fondé sur les rôles aide à organiser les permissions, mais ces rôles doivent être réexaminés lorsque les responsabilités changent. Évitez les identifiants partagés qui compliquent l'attribution des actions et la révocation.

Testez la rotation et l'expiration des identifiants et certificats, ainsi que les accès nécessaires à la reprise. Les identifiants de courte durée réduisent leur période d'utilisation après une exposition, tout en faisant du service émetteur une dépendance supplémentaire. Les accès d'urgence doivent être contrôlés, journalisés et utilisables pendant les défaillances auxquelles ils doivent répondre.

Répondre aux incidents de manière coordonnée

Définissez les niveaux de gravité, l'escalade et les attentes de communication avant un incident sérieux. Les recommandations de Google sur la gestion des incidents distinguent coordination, opérations et communication. Une petite équipe peut cumuler ces rôles si chacun sait qui prend les décisions et qui modifie le système.

Une séquence de réponse pratique consiste à :

1. Établir l'impact : utilisateurs, fonctions, emplacements et données touchés, avec la durée.
2. Coordonner : nommer un responsable, impliquer les propriétaires des dépendances et consigner les actions.
3. Stabiliser : choisir une mesure prévue, comme arrêter un déploiement ou réduire le travail entrant.
4. Enquêter : rapprocher traces, métriques, journaux et changements récents, tout en communiquant les faits connus.
5. Vérifier la reprise : contrôler les résultats actuels, les tâches accumulées et l'exactitude des données avant de clore l'intervention.

Prenons l'exemple fictif d'un incident de commande après une mise en production. L'utilisation du processeur reste faible, mais la latence augmente et les connexions à la base se remplissent. Ajouter des réplicas pourrait accentuer cette pression. L'équipe devrait comparer les versions, examiner les requêtes lentes et les nouvelles tentatives, puis appliquer une mesure testée adaptée aux observations. Elle devrait ensuite vérifier les commandes terminées et les éventuels doublons, sans déduire la reprise d'un indicateur CPU au vert.

Transformer les retours d'incident en améliorations réalisées

Après un incident important, documentez l'impact, la chronologie, la détection, les décisions, les facteurs contributifs et les éléments observés. La pratique du retour d'incident sans recherche de culpabilité porte l'attention sur le système et sur les conditions dans lesquelles les personnes ont travaillé.

Attribuez des actions concrètes avec un responsable et une date de revue. Une action utile peut ajouter une alerte manquante, plafonner un pool de connexions, améliorer la compatibilité du retour arrière ou simplifier une dépendance. Vérifiez qu'elle réduit la défaillance concernée ou son impact. Archiver le rapport ne termine pas le travail correctif.

Automatiser les procédures comprises et tester les pannes

Le travail répétitif d'exploitation, souvent appelé toil, maintient un service sans produire d'amélioration durable. Mesurez le temps qu'il consomme, puis envisagez d'en supprimer la cause ou d'automatiser une procédure comprise. Un script qui accélère une modification dangereuse n'améliore pas l'exploitation.

Donnez à l'automatisation un périmètre borné, des autorisations adaptées, des traces de progression et un moyen d'arrêt. Vérifiez son comportement si elle s'exécute deux fois, s'interrompt à mi-parcours ou utilise des informations périmées. Conservez une procédure testée pour récupérer de ses propres défaillances.

Testez des pannes représentatives en plus du fonctionnement normal : dépendance lente, réponse perdue, file pleine, identifiant expiré, réplica indisponible ou déploiement partiel. Vérifiez les résultats pour les utilisateurs et l'intégrité des données, au-delà du redémarrage des processus.

Commencez dans un environnement isolé lorsque c'est possible. Toute injection de panne en production nécessite un périmètre convenu, des participants responsables, des effets observables, des critères d'arrêt et un plan de reprise. Adaptez sa taille à la capacité de l'équipe à en contenir les effets. Un exercice collectif peut révéler des accès manquants ou des responsabilités floues qu'un test logiciel ne détecte pas.

Choisir les outils en fonction du travail à accomplir

Choisissez des outils pour répondre à un manque opérationnel identifié. L'instrumentation et les plateformes de télémétrie aident à expliquer le comportement. L'automatisation de la configuration et de l'infrastructure rend les changements reproductibles. Les gestionnaires de charges contrôlent le placement et le cycle de vie. Les contrôles de trafic gouvernent le routage et l'admission. Les outils propres aux bases de données exposent la réplication, les requêtes et l'état de récupération.

Évaluez qui maintiendra chaque outil, comment ses accès seront contrôlés et comment l'exploitation se poursuivra s'il tombe en panne. Une pile de gestion plus importante apporte ses propres mises à jour et dépendances. Reliez chaque ajout à un besoin démontré et à une responsabilité d'exploitation explicite.

Checklist de gestion des systèmes distribués

Utilisez cette liste pour identifier les lacunes, puis classez-les selon l'impact sur les utilisateurs et les risques pour la reprise.

Avant la production

• Attribuer les responsabilités et la couverture du support.
• Cartographier les dépendances, la responsabilité des données et les exigences de reprise.
• Définir les indicateurs, les objectifs de service et les alertes exploitables.
• Instrumenter les chemins critiques et enregistrer les changements.
• Tester les limites de capacité, les délais, les nouvelles tentatives et les contrôles de surcharge.
• Tester la compatibilité des déploiements, les mesures de rétablissement et les restaurations.
• Préparer les accès, les rôles d'incident et les procédures essentielles.

Pendant l'exploitation

• Examiner les résultats du service, la consommation du budget d'erreur et la saturation.
• Inspecter l'accumulation des tâches et les dépendances lentes ou défaillantes.
• Revoir les écarts de configuration, les accès et les expirations à venir.
• Réduire les alertes inutiles et le travail manuel répétitif.

Après les changements ou les incidents

• Vérifier les résultats utilisateurs, les tâches en attente et l'exactitude des données.
• Actualiser la documentation d'exploitation et les tests de panne concernés.
• Terminer les actions correctives et évaluer leur effet.