La date de fin de support d'un système d'exploitation est connue des années à l'avance. Les fournisseurs de matériel annoncent la fin du support longtemps à l'avance. Et pourtant, la même scène se répète dans de nombreuses organisations : quelques mois avant la date limite, quelqu'un découvre des dizaines de serveurs exécutant une version non supportée, et personne ne sait exactement quels services en dépendent.
Il s'ensuit une course contre la montre. Qui est le propriétaire de cette application ? Le serveur peut-il être mis à niveau ou nécessite-t-il une migration ? Qui paie pour cela s'il n'a jamais été budgétisé ? L'équipe d'exploitation passe des semaines à construire une vue d'ensemble qui aurait dû exister dès le départ. Pendant ce temps, le responsable de la sécurité doit expliquer pourquoi des systèmes sans mises à jour de sécurité sont encore en production.
Pourquoi une feuille de calcul ne suffit pas
L'outil habituel pour suivre le cycle de vie est une feuille de calcul. Quelqu'un l'a créée une fois, a rempli les versions du système d'exploitation et les dates de fin de support, et l'a transmise. Le problème est qu'une feuille de calcul commence à devenir obsolète dès sa création.
- Elle n'est pas liée à la réalité. Un serveur est mis à niveau ou décommissionné, et la feuille de calcul n'en est pas informée.
- Elle n'est pas liée aux services. Elle liste les serveurs, pas ce qu'ils servent. Sans cela, vous ne pouvez pas décider quoi faire en premier.
- Elle n'a pas de propriétaire. Lorsque personne n'est responsable des données, personne ne les maintient à jour.
Le résultat est une liste qui répond à la question « qu'est-ce qui est ancien ? » mais pas « qu'est-ce qui est à risque et pour qui ? »
Comment aborder le cycle de vie
Le cycle de vie n'est pas un registre séparé. C'est un attribut d'éléments que vous suivez déjà. Si votre CMDB sait quel système d'exploitation est exécuté sur un serveur et quel matériel est utilisé, tout ce que vous avez à ajouter sont les dates de fin de support, et vous avez une vue d'ensemble qui se met à jour avec chaque changement.
La deuxième étape consiste à connecter le cycle de vie aux services. Un serveur non supporté portant un service métier critique est une priorité très différente d'une machine de test sans dépendances. Les décisions de renouvellement doivent suivre l'impact sur le service et non une liste alphabétique de noms d'hôte.
La troisième étape consiste à regarder vers l'avenir. Si vous pouvez voir ce qui atteint la fin du support dans un ou deux ans, vous pouvez mettre le renouvellement dans le budget, convenir avec le propriétaire du service et l'exécuter dans une fenêtre de maintenance régulière au lieu d'un projet d'urgence.
Comment Eywo Stratum gère cela
Eywo Stratum suit le cycle de vie des systèmes d'exploitation, des logiciels et du matériel directement sur les éléments de la CMDB. Pour chaque serveur, vous pouvez voir quelle version il exécute et quand le support pour cette version se termine. La vue d'ensemble montre les serveurs déjà sur des versions non supportées ainsi que ceux qui approchent de la date limite.
Parce que le cycle de vie fait partie de la CMDB, les données restent à jour. Les éléments sont peuplés via l'API de découverte, l'importation de fichiers CSV ou Excel, ou la synchronisation avec une CMDB principale. Chaque changement apporté à un élément est versionné avec son historique, afin que vous puissiez voir quand et à partir de où une version de système d'exploitation a changé. Les contrôles de qualité des données signalent les incohérences, telles qu'un serveur sans système d'exploitation enregistré.
Le lien vers les services est ce qui compte le plus. La cartographie des dépendances en couches montre quelles applications et services métier dépendent d'un serveur donné. À partir de la vue d'ensemble de la fin du support, vous pouvez passer directement aux questions qui comptent : quels services sont à risque et qui en est le propriétaire ? La planification du renouvellement commence alors par une conversation avec une personne spécifique à propos d'un service spécifique.
Le renouvellement lui-même se déroule comme un changement normal : un modèle de changement, un calcul d'impact avant la soumission, une place dans une fenêtre de maintenance en dehors des gels de changement, et l'approbation de la coupure du service par le propriétaire du service affecté. Une mise à niveau du système d'exploitation ne contourne pas le processus simplement parce qu'elle est urgente.
Conclusion
La fin du support n'a pas à être un combat annuel. Lorsque le cycle de vie vit dans la CMDB et est connecté aux services, vous le voyez venir, vous savez qui est affecté et le renouvellement peut être planifié calmement. L'exploitation n'a pas à assembler une vue d'ensemble sous pression, et les propriétaires de services apprennent à connaître le risque à temps.
Le suivi du cycle de vie des systèmes d'exploitation, des logiciels et du matériel est inclus dans l'édition Standard.
Eywo Stratum Standard
Pour les organisations qui souhaitent une CMDB fiable et des processus ITSM gérés.