Yphise optimise en Coût Valeur Risque l informatique d entreprise

Transcription

1 Maîtriser le Change et le Release Management Juin 2007 Xavier Flez Propriété Yphise 1

2 Enjeux La maîtrise du changement est un sujet essentiel et complexe pour toutes les DSI complexité des SI fil de l eau sur technologies hétérogènes avec des liens externes conséquences de changements «mineurs» enjeu de réactivité exigence des SLAs Une DSI est une «usine à changements» ceci n a jamais été aussi vrai ; le challenge de la maîtrise va continuer à être difficile pour beaucoup de DSI 2

3 La «méthode» La «méthode» pour avancer sur un enjeu de Production est maintenant établie regarder la spécification ISO ensuite les pratiques ITIIL réfléchir et compléter pour être simple et efficace Application... Release Release Management Service Delivery Capacity Mngt Service Level Mngt Information Security Mngt Service Continuity & Availability Mngt Control Configuration Mngt Change Mngt Resolution Incident Management Problem Management Budgeting & Accounting for IT services Relationship Business Relationship Mnanagement Problem Management 3

4 L apport ITIL : le Change management (1/2) Un changement est initié par un RFC (Request For Change) Le CAB (Change Advisory Board) a pour mission d assister le CM (Change Manager) dans l évaluation et la priorisation du changement Le CAB et son intervention varient selon l importance du changement le CM autorise et informe le CAB la RFC circule entre membres du CAB le CAB se réunit... 4

5 L apport ITIL : le Change management (2/2) Il est recommandé de définir des Change Models pour standardiser les changements La publication des changements approuvés avec date de mise en œuvre se fait par un FSC (Forward Shedule of Changes) Un PSA (Projected Service Availability) fait le lien avec les SLA Le FSC et le PSA sont validés avec le client, le SLM, le Service Desk et l Availability Mngt 5

6 L apport ITIL : le Release management (1/2) Une release est un ensemble de modifications correspondant à une liste de RFCs Elle peut concerner du hard et du soft L assemblage du soft s appelle le build management. Il est de la responsabilité du RM (Release Manager) L assemblage du hard doit être contrôle et documenté On nous dit qu il est pertinent de distinguer des releases majeures, mineures, emergency fix 6

7 L apport ITIL : le Release management (2/2) Une Release Policy doit établir les règles relatives aux releases La CMDB et la DSL (Definitive Software Library) doivent être mises à jour tout au long du process La release doit être testée. Le CM doit s assurer de la réalisation de User Acceptance tests et d un sign-off Un back-out plan doit être défini. Etablir le retour arrière de chaque change est de la responsabilité du CM, la cohérence d ensemble du RM 7

8 Qu est-ce qui manque ou ne va pas bien? Une «vue court terme», faite pour de la réactivité «on reçoit des RFCs, on les évalue et les valide avec l aide de CABs, on les planifie dans un FSC, on build et on déploie dans une release» Ce processus est très séduisant parce que réactif Mais, en pratique, on bloque tout de suite sur une difficulté fondamentale : un changement mineur, et même très mineur (ex paramètre de configuration ou droit) peut créer des régression graves ; c est très difficile à apprécier dans un processus de changement qui demande leur avis à n personnes On a tendance à faire croître et embellir le nombre d interventions «sans risque mais urgentes» et qui finalement font baisser la QoS alors qu il faudrait les freiner 8

9 Qu est-ce qu il faut faire? Comme bien souvent avec ITIL on peut bien ou mal faire ; la différence se joue sur «peu de choses» Il faut prendre les concepts utiles et les implémenter avec intelligence, au delà de ce qu en dit ITIL Certains concepts sont à développer ; il y a enfin des concepts manquants Nous allons voir tout cela... 9

10 1. Distinguer changement standard et non standard (1/2) Nous préconisons tout d abord d abandonner le concept de changement mineur et majeur pour le remplacer par celui beaucoup plus puissant et pertinent de standard et non standard, distinction peu mise en avant par ITIL L enjeu n est pas la taille du changement mais le risque de régression et la difficulté de vérification a priori d une non régression Nous définissons un changement standard ainsi le mode opératoire de déploiement est défini ET il n y a pas d analyse d impact à mener ou le mode opératoire d analyse d impact n est pas ambigu 10

11 1. Distinguer changement standard et non standard (2/2) Fondamental : les changements standard et non standard ne se traitent pas du tout de la même manière 1. On peut traiter des changements standard par un processus qui part d une RFC au déploiement en appliquant un Change Model 2. Les changements non standard doivent passer dans du release management que nous allons ensuite caractériser (et qui n est que partiellement dans ITIL) L erreur la plus fréquente et la plus grave que nous rencontrons est de vouloir faire du non standard avec les méthodes qui conviennent au standard 11

12 2. Standardiser progressivement les changements (1/3) Au départ des changements standards il y en a très peu installer ou déménager un poste installer un serveur avec un socle technique Est a priori non standard tout ce qui est upgrade système, middleware, progiciel modification de paramétrage (droits ou configuration) applications internes L enjeu est de standardiser progressivement les changements en définissant leur Change Model Avec de la volonté, on arrive à standardiser des déploiements middleware, progiciels ou applicatifs ou des changements de paramétrage 12

13 2. Standardiser progressivement les changements (2/3) Nous préconisons 3 parties dans chaque Change Model l amont = la qualification l aval = le déploiement le backout Nous insistons aussi sur le fait que cette réflexion soit l occasion d un effort d industrialisation création de builds poussables en production sans rebuild scripting de déploiement documentation évolutions applicatives qui suppriment certains changements (ex màj de paramètres) 13

14 2. Standardiser progressivement les changements (3/3) Nous insistons sur le rôle de CM en tant que promoteur et contrôleur de cette standardisation Nous voyons souvent des CM dont le rôle est très fortement centré sur un suivi journalier des demandes. Cette partie doit être minimisée Nous décalons nettement le CM vers l effort de standardisation 14

15 3. Renforcer considérablement le concept de release (1/2) Fondamental : un changement qui reste non standard, petit ou grand, doit passer dans un processus de release management Un processus de release management définit différents niveaux de validation du bac à sable (sandbox) au SI certifié Il permet de gérer et contrôler comment on passe de l un à l autre où on teste quoi où et comment on debuggue comment on propage les modifications à quelles conditions on peut sortir un change pour mep (le release management n est pas synonyme de «gros» déploiements peu fréquents) 15

16 3. Renforcer considérablement le concept de release (2/2) Il amène une discipline toujours délicate qui est la gestion des environnements de test. Sujet non traité par ITIL (nous n avons jamais compris pourquoi) Il est très important de comprendre que le release management ici présenté est d une autre envergure, sans être contradictoire, que le discours ITIL centré sur «un build et une mep simples» Plusieurs conséquences importantes... 16

17 4. Voir nettement en avant L avancement de la validation d une release se fait sur plusieurs semaines ou mois (on peut régler les choses de différentes manières, mais il faut quand même de la durée) Le FSC et le CAB doivent donc voir devant Nous avons souvent constaté que ces outils ITIL d évaluation et de planification sont ramenés à la semaine ou sur les WE qui viennent, pas à 3 mois. Ce qui ne va pas Notons que cette erreur n est pas dans ITIL (le CAB peut par ex être un comité release hebdo sur 3 mois) Mais sa conception d ensemble du change management y conduit aisément 17

18 5. Développer correctement la CMDB (1/2) De même la CMDB, outil d analyse des impacts, doit être suffisamment prospective Une CMDB sur la production n est pas suffisante Il faut y mettre la vue de la ou des releases à venir, à partir des environnements «mutualisés» (par opposition aux environnements «bac à sable») Une vue signifie, ITIL dit cela très bien les CI de la release les relations de dépendances entre CI et, «cerise sur le gâteau», le lien DSL 18

19 5. Développer correctement la CMDB (2/2) ITIL dit bien que la CMDB se met à jour «dès le début» du process Une erreur fréquente des projets CMDB est de centrer l effort sur l automatisation de sa population à partir de la production et pas assez pour une mise à jour préventive forcément plus manuelle ITIL dit bien que la CMDB doit permettre une vue release Une erreur dans les projets CMDB est de rester sur une vue CI (souvent pour des raisons d outils) Nous voyons un rôle CM et/ou RM fort dans la tenue de cette CMDB 19

20 6. Développer les process de déploiement Le release management tel qu introduit par ITIL peut donner l impression que la mep est quelque chose de simple : on planifie dans un FSC, on build et on pousse Ce cas simple n est pas une généralité hétérogénéité des technologies leur distribution enjeux de synchronisation applicative backout En particulier n apparaît pas explicitement la notion de plan de mise en production qui peut être quelque chose de complexe En d autres termes une partie importante du release management est de construire et outiller le ou les process de déploiement, ce qu on peut sous estimer complètement à la lecture d ITIL 20

21 7. Surveiller les changements en nombre et nature (1/2) Les «bons changements» sur une production, en dehors de la mep de releases validées sont ceux qu on n a pas à appliquer Cette boutade est importante. L esprit d ITIL est, avec raison, la réactivité à la demande Mais à force de vouloir améliorer son change management, on en oublie l essentiel qui est que la QoS monte avec la stabilité Les évolutions de nos SI par rapport à l époque de construction d ITIL renforcent considérablement la prudence a priori sur l application de changements «mineurs» 21

22 7. Surveiller les changements en nombre et nature (2/2) Un volet important du change management doit être la mise en place de mesures et d une analyse périodiques de la raison d être des changements Cette prise de recul périodique est selon nous un rôle essentiel du CM Elle peut aussi amener des CABs, sous un angle non décrit par ITIL, qui est la réflexion et la décision préventives sur les changements licites ou non 22

23 En résumé : les bonnes pratiques 1. Distinguer clairement standard et non standard 2. Standardiser progressivement les changements 3. Renforcer considérablement le concept de release 4. Voir nettement en avant 5. Développer correctement la CMDB 6. Développer les process de déploiement 7. Surveiller les changements en nombre et nature 23

24 Pour conclure Leading the IS changes Projects Plus notre expertise avance, et plus l articulation entre Change et Release management nous paraît être forte business... Managing the relationship with the businesses Business partnership management Demands and project portfolio management... to business business... Conducting projects Developing projects Support Environment delivery Change & Release mngt IS-related missions Testing... to business Industrializing Et plus la distinction a priori en deux processus distincts nous semble source d erreurs IT Management and Governance IT financial and asset management IT risk control Architecture Security Service continuity Service level management Maintenance Outsourcing strategies Improvement strategies Operating the IS Operations IS = Information System business... YBRM Yphise Business Risk Management Yphise map of the IT operational processes Yphise - v2.5 Help desk, incidents, problems Product & infrastructure management Data publishing... to business 24

25 Merci 25