Il est jeudi après-midi et le gestionnaire des changements examine un changement sur un cluster de bases de données. La date proposée semble convenable. Ce que personne ne remarque, c'est qu'une mise à jour du stockage sous-jacent au même cluster est prévue pour cette nuit-là, que l'application affectée n'a qu'une fenêtre de maintenance le dimanche matin, et que la clôture de fin de mois est en cours, une période pendant laquelle la production ne doit pas être touchée du tout. Tout cela est consigné quelque part. Pas au même endroit.
Toute personne ayant géré des opérations sait comment cela se termine : un appel téléphonique matinal, un propriétaire de service anxieux, et une équipe expliquant pourquoi deux changements se sont heurtés au lieu de faire le travail qu'ils avaient prévu. Cela ne concerne pas souvent la négligence. Il s'agit du fait que les règles pour toucher la production ne sont pas suffisamment visibles pour les personnes qui planifient les changements.
Pourquoi les tableurs et la bonne volonté ne suffisent pas
Nous voyons souvent des fenêtres de maintenance enregistrées dans les contrats ou la documentation de service, des gels annoncés par e-mail, et des collisions détectées par un collègue expérimenté qui « sait ce qui se passe où ». Cela fonctionne tant que le volume de changements est faible et que ce collègue n'est pas en vacances.
Les points faibles sont prévisibles :
- la fenêtre de maintenance appartient au service, mais le changement est planifié sur un serveur, donc quelqu'un doit tracer le lien manuellement,
- un gel est annoncé mais jamais appliqué,
- deux changements sur une infrastructure partagée se révèlent ne pas être en collision qu lorsque quelqu'un vérifie le calendrier, si cela arrive,
- de grands changements sur de nombreux éléments sont exécutés en une seule fois, parce qu'un déploiement progressif est difficile à planifier.
Comment l'aborder
L'idée principale est simple : les règles doivent être des données et non une connaissance tribale. Une fenêtre de maintenance appartient à un service et doit être traçable à partir de chaque élément dont le service dépend. Un gel est une période pendant laquelle le système n'acceptera pas de date de changement. Les collisions doivent être évaluées pendant la planification et non détectées à la vue.
Il est tout aussi important de reconnaître que toutes les situations ne conviennent pas à des règles strictes. Lorsqu'un nouveau processus est introduit ou dans une organisation qui n'a jamais défini de fenêtres de maintenance, une exception délibérée et traçable est préférable aux règles que tout le monde contourne.
Comment Eywo Stratum gère cela
Dans Eywo Stratum, un changement est lié à des éléments de la CMDB et, via la cartographie des dépendances, aux services qui s'exécutent dessus. Avant qu'un changement ne soit soumis à l'approbation, le système calcule son impact : quels services et applications seront interrompus ou dégradés.
Les règles de planification s'appuient sur ce calcul :
- fenêtres de maintenance – un changement ne peut être planifié que dans les fenêtres des services affectés,
- gels de changement – un changement ne peut être planifié pendant un gel,
- collisions – le système signale d'autres changements qui se chevauchent dans le temps et la portée,
- exécution progressive – un changement peut être effectué élément par élément, de sorte qu'un service redondant n'a pas à être interrompu dans son ensemble.
Chaque changement apparaît dans le calendrier des changements, où le gestionnaire des changements et les propriétaires de services peuvent voir ce qui arrive et quand. Le propriétaire du service affecté approuve l'interruption, et selon le modèle de changement, le gestionnaire des changements ou le CAB également. Les changements standard pré-approuvés se déroulent rapidement ; les changements normaux et urgents ont leurs propres étapes et délais.
Pour la période de déploiement, Eywo Stratum propose un modèle de « changement sans fenêtre de maintenance ». Cela permet à une organisation de commencer à enregistrer et à approuver des changements avant que chaque service n'ait une fenêtre définie. L'exception demeure visible et traçable, et une fois que les fenêtres existent, les équipes passent aux modèles standard.
Calme au lieu d'improvisation
Les fenêtres de maintenance et les gels ne sont pas de la bureaucratie. Ce sont des accords entre les opérations et les personnes qui dépendent d'un service. Lorsque le système les applique, le gestionnaire des changements peut se concentrer sur le fond d'un changement plutôt que de rechercher des calendriers, et les ingénieurs commencent leur quart de nuit en sachant que personne d'autre ne travaille sur la même infrastructure. Tout le monde peut rentrer chez soi l'esprit tranquille.
Les fenêtres de maintenance, les gels, les contrôles de collision et le calendrier des changements sont inclus dans l'édition Standard.
Eywo Stratum Standard
Pour les organisations qui souhaitent une CMDB fiable et des processus ITSM gérés.