Un commutateur en panne n’est pas un service en panne

À deux heures du matin, l’un des deux commutateurs d’une baie tombe en panne. Les serveurs sont raccordés aux deux, les services continuent donc de fonctionner. La supervision remonte pourtant des dizaines d’alertes, la carte des dépendances vire au rouge et, à la réunion du matin, les responsables de service lisent que leur service a été « dégradé ». Il ne l’a pas été. Il a seulement fonctionné quelques heures sans secours.

Le cas inverse est pire. Cinq serveurs virtuels lèvent des alertes alors que l’hôte sur lequel ils tournent reste muet, parce que la supervision ne le voit pas. Cinq signalements distincts apparaissent, cinq personnes examinent chacune leur serveur et la vraie cause passe inaperçue.

Les deux problèmes ont la même origine : l’outil sait ce qui est relié à quoi, mais pas ce que la panne d’un élément provoquerait réellement.

La portée n’est pas l’impact

La plupart des CMDB savent dire ce qui dépend d’un élément. Une réponse honnête demande pourtant plus qu’une liste de relations :

• La redondance. Un serveur raccordé à deux commutateurs survit à la perte de l’un d’eux. Mais un pare-feu ne remplace pas un commutateur, et une interface réseau d’administration ne remplace pas une interface de données.
• L’état des éléments. Un second commutateur prévu mais pas encore en service ne secourt rien. Un composant en maintenance est de fait hors service pendant le changement.
• La nature de la relation. L’administration (la console qui pilote un serveur), la réplication et la sauvegarde ne propagent pas une panne. Un serveur ne s’arrête pas parce que sa réplique est tombée.

Si l’outil ne fait pas ces distinctions, chaque analyse d’impact est exagérée. Les équipes cessent de lui faire confiance et reviennent aux estimations en réunion.

Trois états au lieu de deux

Stilla distingue désormais trois situations :

• Panne – l’élément ne fonctionne pas, car tous ses supports sont tombés.
• Dégradé – l’élément fonctionne sans une partie de ses fonctions ou avec des performances réduites.
• À risque – un seul des composants redondants est tombé. L’élément continue de fonctionner, mais sans secours.

« À risque » s’affiche sur l’élément dépendant le plus proche et sur les services au-dessus de lui, marqués « sans redondance ». Cela ne se propage pas plus loin. La perte d’un commutateur d’une paire ne marque donc plus des centaines d’éléments, mais uniquement ce qui a réellement perdu son secours. La perte des deux commutateurs est alors, à juste titre, une panne.

D’autres parties du produit reposent sur le même calcul. Lorsqu’un changement est planifié sur un composant redondant, le responsable du service est informé que le service fonctionnera sans secours, mais n’a rien à approuver, et le changement peut avoir lieu hors fenêtre de maintenance. Le contrôle des points uniques de défaillance considère les éléments prévus comme absents, si bien que les faiblesses cachées apparaissent avant de poser problème.

Une carte qui montre ce qui se passerait

La carte des dépendances évolue sur trois points :

• Les relations d’administration forment une couche séparée, masquée par défaut. La vue de ce dont dépend un service ne montre ainsi que les vraies dépendances, et non tout ce qui l’administre.
• La vue de ce qui dépend d’un élément simule immédiatement sa panne. Les éléments en couleur seraient touchés ; les éléments en gris n’en dépendent que de manière redondante ou via l’administration.
• Le chemin d’impact met en évidence la chaîne qui va de la cause à chaque service touché, y compris les ports, interfaces et zones traversés. On voit comment une panne atteint un service et on peut l’expliquer à la direction ou à un client.

Une corrélation des événements selon la même logique

La gestion des événements regroupe les alertes liées en une seule situation et indique la cause probable. Elle le fait désormais par simulation de panne :

• Seul un élément dont la panne explique réellement les alertes peut en être la cause. Une alerte sur l’un des deux commutateurs d’une paire n’est donc pas la cause de la panne du serveur situé en dessous, et l’opérateur ne s’attaque pas au mauvais élément.
• Parmi plusieurs candidats, celui qui explique le plus d’alertes l’emporte. Lorsqu’un serveur virtuel, son hôte et son datastore lèvent tous des alertes, la situation reçoit la cause la plus profonde, et non la première dans le temps.
• Les alertes expliquées par la cause sont des symptômes. Elles restent visibles dans la situation, mais n’envoient pas de notifications, sont exclues des indicateurs de bruit et se résolvent avec la cause.
• Cause déduite. Lorsque plusieurs éléments lèvent des alertes et que leur support commun reste muet, Stilla le déduit de la CMDB et crée une situation marquée « déduite de la topologie ». L’opérateur sait par où commencer, même si la supervision ne voit pas cet élément.

La priorité d’une alerte et d’un incident prérempli suit l’impact réel sur le service. Une alerte sur un composant redondant ne reçoit donc plus la priorité d’un service critique qu’elle ne menace pas, et la file de l’opérateur reste plus claire.

Des processus qui s’enchaînent

La correction passe généralement par un changement. Un même changement peut résoudre plusieurs incidents et un problème, et son résultat est reporté dans tous les enregistrements liés. Un problème dont la cause est documentée passe à l’état Résolu après un changement réussi, un changement échoué le renvoie en analyse et les auteurs des incidents sont informés. Si des alertes apparaissent sur les éléments du changement après sa clôture, la revue post-changement devient obligatoire et un incident se crée en un clic.

Conclusion

Une analyse d’impact n’a de valeur que si l’on peut s’y fier. Elle doit donc distinguer une panne de la perte d’un secours, et les mêmes chiffres doivent valoir lors de la planification d’un changement, pendant un incident et au moment où la supervision remonte des dizaines d’alertes. Pour l’exploitation, cela signifie moins d’appels nocturnes pour des symptômes, un chemin plus court vers la vraie cause et des réunions où l’on ne débat plus de l’impact.

La carte des dépendances, les trois états d’impact, le chemin d’impact et le lien entre changements, incidents et problèmes font partie de l’édition Standard. La corrélation des événements par simulation de panne, les symptômes et les causes déduites relèvent de l’édition Business.