La réunion hebdomadaire des opérations discute du remplacement planifié d'un tableau de stockage. Quelqu'un pose la question : « Quels services seront réellement affectés ? » Silence. L'administrateur de stockage sait quels serveurs sont connectés. L'équipe de virtualisation a une bonne idée des machines virtuelles qui s'exécutent dessus. Mais qui sait exactement quelles applications et services métier s'exécutent dessus, et qui doit être informé ? La réponse est reconstituée à partir de plusieurs personnes et de plusieurs feuilles de calcul, et elle est souvent incomplète.
La même question se pose à un moment pire. La supervision signale un hyperviseur défaillant, et le service d'assistance ne peut pas dire s'il s'agit d'un système de test oublié ou d'un service sur lequel des milliers de personnes comptent chaque matin. La priorisation est bloquée, et les personnes qui pourraient résoudre le problème passent leur temps à déterminer ce qui est réellement cassé.
Pourquoi l'impact est rarement connu à temps
Les organisations ont des connaissances en matière de dépendances. Il suffit qu'elles soient dispersées. Chaque équipe voit sa propre couche et la comprend bien. Ce qui manque, c'est une vue qui relie les couches.
- La documentation d'architecture devient obsolète avec chaque changement, et peu de personnes la maintiennent à jour.
- Une CMDB sans relations n'est qu'une liste d'éléments. Sans liens, elle ne peut pas dire ce qui dépend de quoi.
- La supervision voit les composants techniques mais pas les services métier qui en dépendent.
- L'analyse de l'impact des changements est effectuée manuellement et dépend de l'expérience de celui qui l'écrit.
Le résultat est que l'impact est découvert au moment de la défaillance, lorsqu'il est trop tard pour planifier ou communiquer.
Une meilleure façon de penser à l'impact
La clé est de modéliser les dépendances une fois et de les utiliser partout. Si la CMDB sait comment les couches sont liées, du service métier à travers l'application, la base de données et le serveur jusqu'à l'hyperviseur, le stockage et le réseau, la même question peut être posée dans différentes situations :
- Avant un changement : qu'est-ce qui sera indisponible ou dégradé pendant les travaux ?
- Lors d'un incident : quel service est affecté, et qui est responsable ?
- Lors du traitement d'événements de supervision : quels alertes sont liés, et quelle est la cause probable ?
- Lors de la planification : qu'est-ce qui se passe si un composant donné échoue, et le service survivra-t-il ?
Une seule cartographie des dépendances sert alors la gestion des changements, les répondants aux incidents et l'équipe de supervision.
Comment Eywo Stratum gère cela
Eywo Stratum affiche une cartographie des dépendances en couches : services métier, applications, bases de données, serveurs, hyperviseurs, stockage et réseau. Pour chaque élément, vous pouvez voir ce qui s'exécute dessus et ce sur quoi il s'exécute.
En haut de la carte, vous pouvez exécuter une simulation de panne. Sélectionnez un composant, et Stratum montre quels services et applications seraient affectés et si certains d'entre eux sont protégés par redondance. D'autres parties du produit s'appuient sur les mêmes fondations :
- Incidents : lorsqu'un incident est signalé à partir d'un élément de la CMDB, Stratum suggère le service affecté, l'impact et l'équipe de résolution. La priorité est alors dérivée de l'impact et de l'urgence.
- Changements : avant qu'un changement ne soit soumis, son impact est calculé, montrant quels services et applications seront indisponibles ou dégradés. Le propriétaire du service affecté approuve alors une panne qu'il comprend réellement.
- Supervision : dans la gestion des événements, les alertes sont regroupées en situations en fonction de la topologie de la CMDB, de sorte que vous voyez une cause probable au lieu de dizaines de notifications distinctes.
La question « Qu'est-ce qui casse si cela tombe en panne ? » est alors répondue à partir de données que l'équipe comprend, et non à partir de suppositions lors d'une réunion.
Conclusion
Vous pouvez connaître l'impact d'une panne avant qu'elle ne se produise. Cela nécessite une CMDB qui connaît les relations, et non seulement les éléments, et un outil qui met cette connaissance à profit dans les changements, les incidents et la gestion des événements. Pour les équipes opérationnelles, cela signifie moins de suppositions dans les moments critiques et plus de confiance lors de la planification.
La cartographie des dépendances, la simulation de panne et le calcul de l'impact pour les incidents et les changements font partie de l'édition Standard ; le regroupement d'alertes basé sur la topologie est inclus dans l'édition Business.
Eywo Stratum Standard
Pour les organisations qui souhaitent une CMDB fiable et des processus ITSM gérés.