Résilience18 juin 20264 minutes de lecture

Les points de défaillance uniques que vous ne connaissez pas

Un service est redondant sur le papier. Dans la réalité, il peut dépendre d'un seul commutateur, d'un seul tableau de stockage ou d'un seul hyperviseur. Voici comment identifier ces points faibles avant qu'ils ne vous causent des problèmes.

Le service dispose de deux serveurs d'applications et d'une base de données en cluster, et sur le diagramme d'architecture, tout semble sûr. Mais un jour, un seul appareil réseau tombe en panne et tout le service est hors service. La revue post-incident révèle que les deux serveurs d'applications fonctionnaient sur le même hyperviseur, ou que les deux instances de base de données étaient attachées au même tableau de stockage. La redondance n'existait que dans une seule couche.

Des découvertes comme celle-ci sont inconfortables pour tout le monde. Le propriétaire du service pensait être protégé. L'équipe d'exploitation peut avoir suspecté le point faible, mais n'avait aucun moyen de le prouver. Et les personnes qui ont lutté contre l'incident la nuit se demandent pourquoi personne ne l'a vu venir.

Pourquoi les points de défaillance uniques restent cachés

Un point de défaillance unique (SPOF) est rarement une erreur de conception. Il est généralement le résultat d'une dérive progressive. Les changements d'infrastructure, les machines virtuelles bougent, la capacité est réallouée. Ce qui était séparé lors du lancement peut finir sur le même matériel des mois plus tard.

  • La redondance est évaluée une couche à la fois. L'équipe d'applications voit deux serveurs, l'équipe de virtualisation voit une capacité de réserve, et personne ne voit l'ensemble de la chaîne.
  • Les diagrammes capturent l'intention, pas la réalité. Ils montrent comment les choses étaient censées être, pas où les systèmes ont bougé depuis.
  • Les examens de résilience sont des exercices ponctuels. Ils ont lieu lors de la conception ou lors d'un audit, pas de manière continue.
  • La maintenance expose les faiblesses trop tard. Si les deux nœuds d'un couple redondant sont corrigés en même temps, le service est interrompu même s'il est formellement redondant.

Une meilleure façon de penser à la résilience

La résilience du service est une propriété de l'ensemble de la chaîne de dépendance, et non de composants individuels. Elle doit donc être évaluée au niveau du service, à travers toutes les couches à la fois. Nous recommandons :

  1. Enregistrer explicitement la redondance. Quels éléments se substituent les uns aux autres et forment un groupe redondant.
  2. Rechercher des SPOF de manière continue, et non une fois par an. Chaque changement d'infrastructure peut modifier la réponse.
  3. Tester la résilience avec simulation. Demandez ce qui se passe lorsqu'un composant spécifique tombe en panne.
  4. Intégrer la redondance dans la maintenance. Corrigez les nœuds redondants l'un après l'autre pour que le service reste opérationnel.

Comment Eywo Stratum gère cela

Eywo Stratum fonctionne avec une cartographie des dépendances en couches, des services métier aux applications, bases de données et serveurs, jusqu'aux hyperviseurs, stockage et réseau. Sur cette base, il peut :

  • enregistrer des groupes redondants, c'est-à-dire des éléments qui se substituent les uns aux autres,
  • identifier des points de défaillance uniques, les composants dont la défaillance affecte un service quelle que soit la redondance ailleurs dans la chaîne,
  • évaluer la résilience du service et montrer où un service est protégé et où il ne l'est pas,
  • simuler la défaillance d'un composant sélectionné et montrer les services et applications affectés.

La connaissance de la redondance façonne également la maintenance. Les changements peuvent être effectués élément par élément de manière progressive, de sorte que les nœuds d'un groupe redondant ne soient jamais désactivés ensemble. Dans l'édition Business, l'accord de correction avec le propriétaire du service prend en charge la correction progressive des nœuds redondants : un nœud est mis à jour et vérifié avant que le suivant ne suive. Le service reste disponible même pendant la maintenance de routine.

Le propriétaire du service n'a plus à se fier à un diagramme. Il voit l'état actuel, dérivé de la CMDB, et sait sur quoi son service dépend réellement.

Conclusion

Les points de défaillance uniques n'apparaissent pas du jour au lendemain, et une revue ponctuelle ne les fera pas disparaître. Vous ne pouvez les trouver qu'en examinant un service dans son ensemble, à travers toutes les couches, avec une vue qui reste actuelle. Les découvertes inconfortables de nuit deviennent alors des éléments ordinaires du plan de travail, résolus de manière calme et pendant les heures de travail.

Les groupes redondants, l'analyse des points de défaillance uniques et la simulation de panne sont partie de l'édition Standard ; la correction progressive des nœuds redondants dans le cadre de la gestion des correctifs fait partie de l'édition Business.

Eywo Stratum Standard
Pour les organisations qui souhaitent une CMDB fiable et des processus ITSM gérés.

Comparer les éditions →