Patch Management – Réflexions – n°5 : Les cycles de maintenance

C’est bien d’automatiser au maximum, encore faut-il planifier ces opérations. Doit-on planifier toutes ces opérations selon le même cycle de maintenance « long » (option big-bang au risque de se transformer en big-badaboum) ou des cycles « courts » (option « blind-test » pour la découverte des bugs / comportements non prévu)? La réponse est bien plus compliquée. Déjà, tous les types de Patching ne s’inscrivent pas dans le même cycle de maintenance. Raisonnons donc en fonction des différents domaines :

  • Mise à niveau Pilotes / Logiciels bas niveau des Hyper-V : Pour maintenir la stabilité de la plateforme et le support des éditeurs, on est obligé de suivre un rythme soutenu. Certes, on n’est pas obligé de suivre au jour le jour et de s’imposer des cycles courts mais on doit quand même suivre. On aura besoin d’un à deux cycles de maintenance par an. A mon sens, difficile de faire plus car il faudra du temps pour valider que les changements opérés produisent bien les effets escomptés et qu’on n’observe pas de régression pouvant affecter nos SLA et par extension les SLA de nos locataires.
  • Patch Management Microsoft : On est tous d’accord pour suivre le rythme mensuel imposé par Microsoft. C’est sportif mais pas impossible. En fonction de la taille de l’infrastructure, on devra découper en plusieurs phases. Par exemple, patcher un certain nombre de châssis par semaine sur un cycle d’un mois. A mon sens, c’est une approche à privilégier car avec Windows 10 et Windows Server 2016, la notion de « Ring » va changer les choses. Devra t’on passer sur le modèle Long-Term Branch? C’est une bonne question, pas encore assez de recul pour juger. Par contre le choix du mode d’installation Nano devrait nous faciliter grandement la tâche pour réduire drastiquement le nombre de correctifs à installer et le nombre de redémarrages nécessaires.
  • Patch Management « Out of band » : Là, c’est la criticité qui impose le cycle. La première option serait de travailler dans le mode urgence. Pas évident à organiser et le résultat risque d’être approximatif. On peut aussi prévoir de pré-réserver des créneaux pour réaliser ce type d’opération et les utiliser ou non. C’est l’option que je préfère. On évite l’organisation dans l’urgence et on inscrit cela dans un cycle régulier, plus facile à maîtriser. Après, on peut prévoir d’intégrer ce type de patching dans le cycle du Patch Management Microsoft. C’est envisageable si on a bien prévu un cycle de maintenance court. On profite du créneau horaire du premier pour intégrer le second.
  • Patch Management de la Fabric : Avec les solutions Cloud Privé / Hybride de Microsoft, c’est facile, les équipes System Center fournissent des Update Rollup tous les trimestres. Autant on n’a pas de problème ou presque à appliquer les correctifs Microsoft & Out of Band sur notre Fabric, autant les updates UR sont trop spécifiques et nécessitent trop de tests. Pour cette raison, choix a été fait de ne pas suivre le rythme de publication de Microsoft. Il a été décidé de sauter un UR sur deux sauf si l’UR en question nous corrige des problèmes nous impactant ou apportant des fonctionnalités requises par nos locataires. En plus chaque UR apporte son lot de nouvelles fonctionnalités à mettre en place / qualifier, …

clip_image001[4]

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.