La pratique de la gestion des services

Mettre en œuvre le processus Dev-Ops à partir des processus ITIL et d’une

méthodologie projet

Création : août 2013 Mise à jour : août 2013

2

A propos

A propos du document Ce document pratique est le résultat de la mise en oeuvre du référentiel ITIL et d'autres référentiels dans des directions informatiques en France au travers des missions qui me sont confiées depuis 2004. Il est mis à la disposition de la communauté francophone ITIL pour diffuser quelques conseils et notes sur le passage souvent délicat de la théorie à la mise en pratique de ces référentiels. Ce document peut être utilisé de manière libre à condition de citer le nom du site (www.itilfrance.com) ou le nom de l’auteur (Pascal Delbrayelle).

A propos de l'auteur Pascal Delbrayelle intervient avec plus de 25 ans d'expérience comme consultant sur les projets d'une direction informatique ayant comme facteur de succès la mise en œuvre des bonnes pratiques ITIL comme, par exemple, la mise en place d'un site de secours, la mise en place d'un outil de gestion des configurations ou la définition des normes et standards techniques des environnements de production. Ces projets requièrent :

la connaissance des différents métiers du développement et de la production informatique la pratique de la conduite de projets techniques de la direction informatique la maîtrise de la définition et de la mise en place de processus pour rationaliser et adapter

les méthodes de travail au sein de la direction informatique

A propos de mission et de formation Si vous pensez que l’expérience de l’auteur sur la gestion des services informatiques (ITSM) peut vous aider dans vos projets sur l’organisation ou sur la production informatique, n’hésitez pas à le contacter pour toute question ou demande :

par mail : pascal.delbrayelle@itilfrance.com par téléphone : +33 (0)6 61 95 41 40

Quelques exemples de mission : Modélisation simple des processus de gestion des changements, des projets et des

mises en production en vue de la sélection, l'achat et l'implantation d'un outil de gestion de projets avec planification, gestion des ressources, des budgets, des livrables et des connaissances

Accompagnement avec la réorganisation d'un DSI passant d'une organisation en silos techniques vers une organisation inspirée du référentiel ITIL et la mise en oeuvre d'outils pour institutionnaliser les processus ITIL

Accompagnement d'une DSI dans la formulation de l'appel d'offres au futur centre de services en se basant sur les processus et la fonction centre de services du référentiel ITIL

3

Table des matières 1 La démarche de ce dossier ............................................................................................................... 4

2 Eviter les pièges du référentiel ITIL ................................................................................................... 5

2.1 Confondre "Conception des Services" et "conception d'un service" ............................................ 5

2.1.1 Le cycle de vie des services présenté selon ITIL ................................................................. 5

2.1.2 L'autre cycle de vie : celui d'UN service ............................................................................... 5

2.1.3 La conception des services : une phase très mal perçue par les utilisateurs ITIL ................ 5

2.1.4 Un autre facteur de confusion : les processus de la conception des services eux-mêmes .. 6

2.1.5 La conception des services : tactique de mise en œuvre de la stratégie des services ......... 7 2.1.6 Le célèbre mais encombrant SDP (package de conception de service) .............................. 8

2.2 Confondre « changement » et « mise en production »................................................................ 9

2.2.1 L’origine de la confusion : les outils logiciels ITIL................................................................. 9

2.2.2 Autre confusion : « déployment » et « release » .................................................................. 9

2.2.3 Un projet est déclenché par une demande de changement ................................................. 9

2.2.4 Les projets statégiques « affrètent » un changement .......................................................... 9

2.2.5 La gestion des changements est un processus de pilotage et non pas de réalisation ....... 10

2.2.6 Le processus de gestion des changements : un premier pas vers le Dev-Ops .................. 12

3 L’approche Dev-Ops confrontée à ITIL et à la gestion de projets..................................................... 13

3.1 Raison d’être de cette démarche .............................................................................................. 13

3.2 Etape numéro 1 : rationaliser les activités Dev-Ops ................................................................. 13

3.2.1 Concilier le « pas forcément inconciliable » : méthodologie projet et ITIL .......................... 13

3.2.2 Le fondement de la démarche : le processus ITIL de gestion des changements ............... 13

3.2.3 Deux parties distinctes : traiter la demande de changement et traiter le changement ........ 13

3.2.4 Ranger toutes les activités des processus impliqués dans des cases ............................... 14

3.2.5 Formaliser (ou reformaliser) les processus ITIL impliqués dans Dev-Ops ......................... 15

3.2.6 Introduire l’agilité dans le processus Dev-Ops ................................................................... 17

3.3 Etape numéro 2 : outiller le macro-processus Dev-Ops ............................................................ 17

3.3.1 Premier axe : accélérer l’enchaînement des activités et viser le zéro défaut ..................... 17

3.3.2 Second axe : permettre les digressions et les boucles contrôlées dans le processus Dev-Ops 18

3.3.3 Un outil de gestion et de pilotage qui va faire office de chef d’orchestre ............................ 18

3.4 Définition des pratiques d’intégration continue, de livraison continue et de déploiement continu (traduction d’un article de Martin Fowler) ............................................................................................ 18

4

1 La démarche de ce dossier Ce dossier présente les deux aspects de l’approche Dev-Ops : structurer d’une manière particulière les activités aussi bien de l’équipe projet que des équipes d’exploitation dans un projet puis automatiser au maximum ce processus afin de gagner du temps. Mais préalablement à cela, j’ai voulu présenter comment déjouer deux pièges classiques du référentiel ITIL sur des processus de conception et de transition des services que j’utiliserai ensuite pour alimenter la réflexion du processus global de Dev-Ops. Les deux pièges que je dévoile sont la confusion possible entre « Conception des services » et « conception d’un service » et la confusion fréquente entre « changement » et « mise en production ».

5

2 Eviter les pièges du référentiel ITIL

2.1 Confondre "Conception des Services" et "conception d'un service" 2.1.1 Le cycle de vie des services présenté selon ITIL Le cycle de vie des services tel qu’il est présenté dans ITIL est un schéma très conceptuel pour faire passer l’idée d’un cycle de vie :

Malheureusement, il peut porter à confusion avec un autre cycle de vie plus opérationnel et il faudrait plutôt dire « Cycle de vie de la gestion des services », ce qui est plus long à dire et difficile à retenir, surtout dans les formations ITIL Fondamentaux effectuées au pas de charge.

2.1.2 L'autre cycle de vie : celui d'UN service Ce modèle global de cycle de vie des services peut donner l’impression qu’un service passe successivement de la conception des services, la transition des services puis l’exploitation des services, pour revenir en conception des services pour élaborer une nouvelle version par exemple. Je l’ai souvent vu comme, par exemple, dans certains supports de formation ITIL Fondamentaux. Or, ceci est faux en partie car ce n’est pas comme cela que cela se passe pour un service. En laissant tomber la partie stratégie des services où le service peut être inscrit très longtemps à l’avance dans le portefeuille de services s’il s’agit de quelque chose de stratégique, la mise en place d’un service commence par une demande de changement (lancement d’un projet). Nous sommes alors directement projetés dans … la transition des services sans passer par la case conception des services ! Le service est alors conçu (dans les processus de transition des services et des processus projets non décrits dans ITIL), développé, testé puis mis en production dans cette même phase de transition. C’est d’ailleurs pour cela que celle-ci s’appelle comme cela : le service va ainsi passer de l’état d’idée à quelque chose d’opérationnel en production. Le cycle de vie d’un service se résume donc à deux phases du Cycle de vie des Services : transition et exploitation puis rebouclera sur transition s’il faut le faire évoluer. Cela se fera au travers d’une demande de changement. De même, en fin de vie, le retrait du service sera effectué par le biais d’une ultime demande de changement.

2.1.3 La conception des services : une phase très mal perçue par les utilisateurs ITIL Alors nous pouvons nous demander légitimement à quoi sert finalement la phase de conception des services ? D’autant plus qu’au vu des processus de cette phase, on retrouve aussi des activités que nous ne pouvons réaliser que dans la phase de transition (élaborer un SLA se fait en même temps que la conception du service par exemple) ou qui sont à première vue rattachés à la phase d’exploitation (des activités opérationnelles comme la surveillance de la disponibilité ou de la capacité suffisante des composants techniques qui sont en exploitation), de quoi alimenter quelques interrogations. Simplifions le discours ITIL et voyons les deux ambitions de la phase de conception des services :

6

relayer ce qui a été élaboré au niveau stratégique (phase de stratégie des services) vers les activités quotidiennes des équipes où deux groupes de personnes sont clairement identifiés : les équipes de développement et les équipes d’exploitation

concevoir un cadre de fonctionnement pour les équipes de transition et les équipes d'exploitation, tant aussi bien dans la manière de travailler (processus, méthodologies, normes, etc.) qu’au niveau technique avec la conception de solutions d’infrastructures aptes à supporter les futurs services d’affaires et surtout les niveaux de service associés.

Le résultat de tout cela (l’ensemble des livrables de l’ensemble des processus de la phase) est contenu dans le célèbre mais encombrant SDP (Service Design Package ou package de conception de service).

2.1.4 Un autre facteur de confusion : les processus de la conception des services eux-mêmes D’une manière générale, un processus est destiné à atteindre un objectif simple. Or, ce que j’ai constaté dans la documentation ITIL et les différents supports de formation ITIL Fondamentaux, c’est qu’un processus est associé à un ensemble impressionnant d’objectifs, certains liés à la conception, d’autres à la transition et enfin d’autres à l’exploitation. Ce n’est pas une erreur du référentiel ITIL car il faut comprendre en réalité que pour couvrir les ambitions du processus, ce dernier se décompose en plusieurs sous-processus, chacun des sous-processus se voyant attribué l’un des objectifs du processus. Le processus étant la « somme » de ces différents sous-processus, il cumule donc tous les objectifs de ses sous-processus. Enfin, lorsqu’on examine les activités des sous-processus, nous constatons que certaines sont de nature de conception, d’autres de nature de transition et d’autres encore de nature d’exploitation. Certains sous-processus peuvent même mélanger des activités de phases différentes. Alors, imaginez la vision que l’on peut avoir du processus résultant. Par exemple pour les processus de la conception des services, nous allons trouver des activités de conception, de transition, d’exploitation sans oublier le souci permanent d’amélioration continue. Pour des raisons concrètes de compréhension des livres ITIL, toutes les activités d’un processus sont rangées dans un seul livre (donc une seule phase). Le choix délibéré qui a été fait a été de ranger un processus dans la phase pour lesquelles les activités prépondérantes du processus s’y trouvent. Les processus de conception des services sont donc difficilement appréhendables si nous n’avons pas cette compréhension globale de ce que sont les processus ITIL. Prenons un exemple : celui de la gestion des niveaux de services. Nature Objectif Stratégie Assurer et améliorer les relations et la communication avec les organisations

d'affaires Conception S’assurer que des cibles spécifiques et mesurables sont développées Conception et Exploitation

Surveiller 1 et améliorer 2 la satisfaction du client par le biais de la qualité de service

1. Exploitation 2. Conception

Conception S’assurer que l’informatique et les clients ont des attentes claires et non ambigües du niveau de service

Transition et Exploitation

Définir 1, documenter 1, valider 1, surveiller 2, mesurer 2, rapporter 2 et revoir 1 le niveau des services informatiques

1. Transition 2. Exploitation

Amélioration continue

S’assurer que des mesures pro-actives sont mises en place partout il est possible d’en justifier les coûts

7

Chaque objectif est lié à un sous-processus élémentaire et peut être modélisé sous la forme d’un traitement de flux (workflow). Le processus d’ensemble de gestion des niveaux de service a été catégorisé dans la conception des services car les activités les plus importantes sont situées dans cette phase.

Les autres processus de cette phase sont aussi découpables de la même manière. Leur objectif commun est de mettre en place et de maintenir les règles de fonctionnement, les infrastructures mutualisées (SAN, réseaux, etc.), les processus et les procédures, les méthodologies projets, etc. que les chefs de projet et les exploitants devront appliquer dans la transition des services et dans l’exploitation des services. Il est à noter que le sous-processus le plus connu de la gestion des niveaux de service est « définir, documenter, valider, surveiller, mesurer, rapporter et revoir le niveau des services informatiques » et que cet objectif est de nature de transition et d’exploitation. Il va donc couvrir la phase de réalisation du changement (ou la phase de projet) pour un nouveau service (élaboration et accord sur les niveaux de service) et la phase d’exploitation (surveillance et production de rapport sur les accords de niveau de service). Ceci ajoute à la confusion possible sur l’intérêt de la phase de conception des services. Habituellement, lors de missions en clientèle, j’intègre ce sous-processus dans la méthodologie projet (ainsi que les autres sous-processus de nature de transition).

2.1.5 La conception des services : tactique de mise en œuvre de la stratégie des services Quand on regarde bien les activités quotidiennes réalisées dans une organisation informatique, on y retrouve deux grandes catégories réalisées par des équipes au fonctionnement bien différent :

les activités de développement où on fait passer un service (que se soit une application ou une infrastructure technique) de l’état d’idée à un ensemble opérationnel de composants

les activités d’exploitation où on gère au quotidien les services fournis et les infrastructures techniques

8

Afin de structurer ces activités et de les aligner pour qu’elles servent au mieux les objectifs stratégiques, il est nécessaire de définir une tactique de mise en œuvre de la stratégie des services. Lorsque l’on examine les processus de conception des services, on s’aperçoit qu’ils remplissent ce rôle.

2.1.6 Le célèbre mais encombrant SDP (package de conception de service) Ce livrable est en sortie de la conception des services et c’est aussi un livrable d’entrée de la phase de transition de service. C’est comme cela qu’il est présenté dans les principes de la phase de conception des services. Il contient donc le résultat des cogitations de l’ensemble des processus de conception des services, entre autres les livrables classiques :

le catalogue des services les accords de niveaux de service, les accords de niveau d’opérations et les contrats de sous-

traitance le plan de disponibilité, le plan de capacité, les plans de continuité de service, la politique de sécurité, la politique vis-à-vis des fournisseurs externes (procédure d’achat, fournisseurs référencés,

configurations avec des tarifs négociés, etc.) Il va aussi contenir toutes les règles et préconisations à appliquer dans les phases de transition et d’exploitation des services :

méthodologie projet et l’ensemble des processus de transition et d’exploitation, ainsi que les modèles de processus (procédures) associés

choix d’infrastructures lourdes comme la virtualisation, le SAN, etc. préconisations et briques standard d’infrastructure à même de répondre à la plupart des exigences

de niveau de service (au vu du contenu du pipeline des services qui a déjà été élaboré) Enfin, il contiendra aussi tous les modèles de document et les documentations des outils logiciels à utiliser dans les phases de transition et d’exploitation. Malheureusement, à d’autres endroits de la documentation ITIL, le SDP est présenté comme étant l’ensemble des documents accompagnant la mise en œuvre d’UN service. Par exemple, si ce dernier est traité en mode projet, le SDP est présenté comme étant l’ensemble des livrables du projet. Il y aurait donc autant de SDP que de mise en œuvre de nouveaux services ou d’evolutions de service.

9

Ceci est contradictoire avec la définition clairement énoncée du livrable en entrée de la transition des services. Les deux points de vue sont conciliables en les présentant de la manière suivante : il contient initialement l’ensemble des livrables de la conception des services (y compris les modèles de document) puis va s’enrichir des documents liés à chaque changement (mise en œuvre d’un nouveau service ou évolution de service existant). Il s’agit donc d’un ensemble documentaire très volumineux puisqu’il contient toutes les documents opérationnels utilisés en conception, en transition et en exploitation des services. Il sera donc géré naturellement sous une forme de gestion documentaire et c’est une partie importante de la base de connaissances.

2.2 Confondre « changement » et « mise en production » 2.2.1 L’origine de la confusion : les outils logiciels ITIL Lors de mon utilisation de plusieurs logiciels certifiés ITIL, quelle ne fut pas ma surprise de constater qu’une équipe projet fait des demandes de changement à chaque fois qu’il faut demander aux équipes d’exploitation de mettre en production un serveur, une base de données ou un package d’installation applicatif. Historiquement et avant la popularisation du référentiel ITIL, le terme change était utilisé dans ce sens dans ces logiciels. Beaucoup de présentations ITIL font aussi cet amalgame. 2.2.2 Autre confusion : « déployment » et « release » Le nom du processus « Gestion des déploiements et des mises en production » est aussi très ambigü en français car il est difficile de traduire correctement « Release and Deployment Management ». En effet, le terme release est traduisible à la fois par package d’installation (le binaire) et par l’action de mettre en production le package d’installation. Le terme mise en production doit être pris dans le seul sens de package d’installation. Le nom du processus aurait pu être « Gestion des packages d’installation et des déploiements », la première partie étant matérialisée par la bibliothèque des media définitifs (DML ou Definitive Media Library).

2.2.3 Un projet est déclenché par une demande de changement La séquence prévue dans ITIL est la suivante :

demande de changement pour toute modification de l’environnement de production (au sens large, comprenant tous les actifs de service : organisation, processus, personnes, connaissances, etc.) : certains changements (les plus importants) seront traités en mode projet

les processus de gestion des changements, de méthodologie projet et d’autres processus de la transition des services sont déclenchés

lorsqu’arrive le moment de livrer un « media définitif » et de le déployer dans l’environnement de production, le processus de gestion des changements ou la méthodologie projet, va faire des demandes de mise en production déclenchant ainsi la partie la plus importante du processus de gestion des déploiements et des mises en production

Ainsi, un changement ou un projet, peut déclencher un ou plusieurs déploiements. Le processus de gestion des déploiements et des mises en production peut, de son côté, décider de regrouper plusieurs mises en production dans une seule (déploiement d’un ensemble de correctifs par ex.) pour des questions pratiques. 2.2.4 Les projets statégiques « affrètent » un changement Les projets stratégiques seront aussi traités de manière classique dans le processus de gestion des changements. Les projets stratégiques sont initiés par le processus de gestion du portefeuille de services, lui-même initié par d’autres processus stratégiques (gestion de la stratégie ou gestion financière des services par ex.) ou l’amélioration continue des services.

10

Le schéma suivant résume les activités macros du processus de gestion du portefeuille de services :

Lorsqu’est arrivé le moment pour un nouveau service de passer dans la partie « catalogue de services » du portefeuille de services (encore une autre ambiguïté du référentiel ITIL), le processus de gestion du portefeuille de services va faire une « demande de changement améliorée » appelée « proposition de changement » (Change Proposal) pour déclencher le processus de gestion des changements. La proposition de changement est une demande de changement enrichie de tous les documents stratégiques qui ont déjà été réalisés sur le futur service avant même que le changement ait été initié (et le projet lancé), notamment le dossier business (qui est l’équivalent d’un document d’avant-projet). Une fois le changement lancé, le changement se déroule de manière classique bien qu’il soit suivi (de loin) par le processus stratégique de gestion du portefeuille de services. Dans la vraie vie, c’est exactement ce qui se passe sur un projet stratégique en cours de réalisation : même si le directeur informatique n’est pas le chef de projet, il suit quand même d’assez près l’évolution du projet stratégique.

2.2.5 La gestion des changements est un processus de pilotage et non pas de réalisation Bien que j’utilise rarement le schéma ITIL du processus de gestion des changements en raison de sa trop grande simplification, il permet néammoins de voir qu’une fois la demande de changement autorisée, les activités du processus parlent de planifier et de coordonner les activités de réalisation et de faire un bilan sur la réalisation :

11

Ce qui n’est pas présenté dans ce schéma, ce sont les interactions avec les autres processus, qu’ils soient ITIL ou appartenant à la méthodologie projet. D’autre part, l’activité « Coordonner l’implantation » couvre toutes les étapes de conception, de développement/paramétrage, de test et de mise en production du produit. Lorsqu’on aligne les activités de ce processus avec une méthodologie projet, il est possible de détailler les activités de changement qui sont à rapprocher avec les activités jalons d’un projet.

12

Evidemment, ceci n’est valable que pour les changements traités en mode projet :

Nous sommes là très loin d’un processus opérationnel où l’équipe projet fait des « demandes de changement » aux équipes d’exploitation à chaque fois qu’une intervention de production est nécessaire. Ces demandes faites par l’équipe projet sont en fait des demandes de mises en production qui vont déclencher le processus de gestion des déploiements et des mises en production.

2.2.6 Le processus de gestion des changements : un premier pas vers le Dev-Ops Dev-Ops est une approche permettant d’accélérer très fortement les projets en structurant d’une manière complètement intégrée les processus de développement et les processus d’exploitation et en mettant un œuvre un outillage logiciel automatisant un maximum d’activités de ce macro-processus. Ceci découle directement de la mise en œuvre des principes Lean sur ce domaine d’activités. Le processus de gestion des changements est celui qui va permettre de structurer toutes ces activités (méthodologie projet et processus ITIL concernés) et de les positionner autour des activités jalons de la gestion des changements. Ensuite, avec une vue globale de toutes ces activités, il sera moins difficile de sélectionner un outil ou un ensemble d’outils pour automatiser et accélérer le traitement de ces activités.

13

3 L’approche Dev-Ops confrontée à ITIL et à la gestion de projets

3.1 Raison d’être de cette démarche Cette démarche est focalisée sur l’idée que le temps de mise sur le marché (« Time-to-market ») d’une nouvelle offre pour une entreprise doit être réduit de manière drastique. Lorsque nous étudions la chaîne de valeur de cette mise sur le marché (selon les principes Lean), nous constatons que beaucoup de soucis et de délais trop longs sont liés au fonctionnement de la gestion de projet informatiques et aux différences de culture entre équipes de développement et équipes d’exploitation au sein du fournisseur de services informatiques.

3.2 Etape numéro 1 : rationaliser les activités Dev-Ops 3.2.1 Concilier le « pas forcément inconciliable » : méthodologie projet et ITIL Traditionnellement, les activités projets sont régentées par une méthodologie projet qui prend mal en compte les activités plus liées à l’exploitation (déploiement d’une version définitive dans l’environnement de production par ex.). D’autre part, en examinant de près le référentiel ITIL, on s’aperçoit que les termes « développement » ou « projet » sont très peu cités dans la documentation. ITIL présente très bien les activités d’exploitation (historiquement, ITIL vient du monde de l’exploitation) mais est peu loquace dès lors qu’il s’agit d’évoquer des activités de projet. En réalité, toutes les méthodologies projets et le référentiel ITIL parlent de bonnes pratiques mais selon des points de vue différents. Sur le fond donc, tous les référentiels parlent de la même chose et ne sont pas contradictoires. Si on veut avoir un processus global incluant à la fois le développement et l’exploitation, il faut travailler sur la forme et être créatif pour surmonter les différences de vocabulaire et de terminologie. Mais cela se fait très bien car tous les référentiels parlent de la même chose. 3.2.2 Le fondement de la démarche : le processus ITIL de gestion des changements Tout va partir du processus ITIL de gestion des changements tel qu’il a été présenté précédemment. C’est sur cette structure en activités jalons que vont venir se greffer toutes les activités de la méthodologie projet, des processus ITIL de transition des services (notamment la gestion des mises en production et des déploiements) mais aussi les processus ITIL de conception des services (en fait, les parties de processus qui sont de nature de transition). Dans une première approche, on peut citer :

le processus de gestion des changements la partie transition de la méthodogie projet le processus de validation et des tests de service

le processus de gestion des déploiements et des mises en production

la partie transition du processus de gestion du catalogue de services

la partie transition du processus de gestion des niveaux de service

la partie transition du processus de gestion des fournisseurs (sous-traitants impliqués dans le projet)

Il serait aussi possible d’impliquer certaines parties des processus de conception des services suivants : gestion de la disponibilité

gestion de la capacité

gestion de la sécurité

gestion de la continuité des services informatiques

Ceci demande un niveau de maturité plus important et n’est pas nécessaire dans un premier temps.

3.2.3 Deux parties distinctes : traiter la demande de changement et traiter le changement

14

Traiter la demande de changement consiste à évaluer la demande et à produire un dossier suffisamment complet pour être présenté à une autorité (très souvent, le fameux CAB ou comité consultatif sur les changements) afin qu’il puisse prendre une décision sur la suite à donner à la demande :

rejeter la demande

autoriser la demande mais la mettre en attente pour réalisation ultérieure (par ex. : il s’agit d’une demande pertinente mais il faudra attendre l’année prochaine faute de budget dans l’immédiat)

autoriser la demande et lancer la réalisation dans la foulée

Ceci amènera à intégrer dans la démarche le processus ITIL d’évaluation des changements et dans une méthodologie projet, la partie « avant-projet » ou « pré-étude » (ou autre « étude d’opportunité ») selon le vocabulaire méthodologique employé. Traiter le changement consiste à transformer l’idée de service ou d’évolution de service en un produit fonctionnel, installé, opérationnel et exploitable. L’exploitabilité est la possibilité de fournir le service selon les niveaux de service convenus avec les ressources présentes dans la partie exploitation (ressources techniques et humaines et contrats de sous-traitance notamment) et dans le respect des contraintes budgétaires. Dans cette partie, nous allons retrouver les phases classiques d’un projet : conception, réalisation (développement et/ou paramétrage), tests, mise en production et pilote.

3.2.4 Ranger toutes les activités des processus impliqués dans des cases Pour l’ensemble des parties de processus impliqués, il est impératif de ranger les activités en séquence dans chaque phase du changement (ou du projet).

15

Une fois réalisé, il est donc possible de dessiner un macro-processus dont une structure simplifiée est la suivante (tous les processus n’ont pas été représentés) :

Il est possible de voir dans ce schéma un début de cadencement tel qu’il est décrit dans les principes Lean (mais on en est pour l’instant très éloigné). Ce cadencement est piloté par le processus de gestion des changements au travers des activités de pilotage qui consiste essentiellement à valider le déroulement de la phase précédente (tous processus confondus) et à autoriser la réalisation de la phase suivante. Nous voyons aussi que les activités de développement (Dev) et les activités d’exploitation (Ops) sont gérées de la même manière ainsi que les activités de conception des services (catalogue de services, niveaux de services, fournisseurs pour ne citer que ceux-là). Nous sommes donc la en présence du macro-processus Dev-Ops (enfin, une fois que le détail de chaque case processus x phase aura été détaillé avec l’exhaustivité des processus impliqués).

3.2.5 Formaliser (ou reformaliser) les processus ITIL impliqués dans Dev-Ops Pour la partie des processus ITIL impliqués dans un cycle Dev-Ops, il faut revoir leur conception et restructurer ces flux de traitement en les inscrivant dans chaque des phases Dev-Ops. J’ai réalisé ce travail chez des clients en partant des processus théoriques ITIL de gestion du catalogue de services, des niveaux de services et des fournisseurs et il n’y a pas de contradiction entre ITIL et Dev-Ops. Prenons, par exemple, le processus de gestion des niveaux de service. La partie du processus impliquée dans Dev-Ops est la partie la plus connue de négociation et de mise en place des SLAs, OLAs et contrats de sous-traitance lié à la mise en place d’un nouveau service :

16

Voici, de manière plus détaillée (attention : toutes les activités ne sont pas représentées) ce que cela donne au niveau du processus Dev-Ops :

Les flèches reliant les activités jalons du processus de gestion des changements et les activités dans les autres processus n’ont pas été représentées.

17

Le schéma positionne les différentes activités du flux de travail classique de la gestion des niveaux de service dans les différentes phases du processus de Dev-Ops. Les flèches en blanc sont ce qui est présenté de manière traditionnelle dans chacun des processus ITIL, pouvant donner l’impression d’un référentiel en silos de processus, chacun des processus vivant sa vie indépendamment de celle des autres processus. L’intégration du processus de gestion des niveaux de service dans le processus Dev-Ops permet aussi de préciser trois grands déclencheurs de ce flux de travail de gestion opérationnelle des niveaux de service (les trois cercles rouges avec un numéro) :

1. Planifier la mise en œuvre du catalogue et des niveaux de service : il s’agit de la composante d’un projet ITIL classique où il faut documenter (et éventuellement mettre en place) les niveaux de service pour des services déjà en production ; le flux de travail s’exécute en dehors de tout processus Dev-Ops ; ce flux sera aussi cadencé avec des activités des processus de gestion des fournisseurs et de gestion du catalogue de services

2. Analyser l’impact et les risques du changement : le processus est déclenché par la gestion des changements afin de travailler sur les aspects niveaux de service de ce qui sera mis en production

3. Revoir les accords de niveau de service : boucle traditionnelle interne au processus de gestion des niveaux de service, elle consiste à relancer le flux de travail sur un SLA à réviser au bout d’un certain délai si aucune évolution (demande de changement) n’a été réalisée entretemps (ce qui aurait « obligé » une révision des niveaux de service)

Il faut aussi remarquer qu’à l’intérieur d’une phase, il est possible pour un flux de travail d’avoir un système de boucle fini sans perturber la globalité du processus Dev-Ops. Ici, par exemple, lorsqu’il s’agit de négocier simultanément les accords de niveau de service, les accords de niveau d’opérations et les contrats de sous-traitance, il y aura plusieurs ajustements successifs afin de contenter toutes les parties prenantes (sans oublier l’omniprésent processus de gestion financière). 3.2.6 Introduire l’agilité dans le processus Dev-Ops Ce principe de boucle fini peut être étendu à la mise en place d’agilité dans le processus global. Ces boucles vont bousculer la structure des différentes phases Dev-Ops, ce qui nécessitera des réajustements dans les processus ITIL impliqués. Mais cela ne change pas l’approche globale.

3.3 Etape numéro 2 : outiller le macro-processus Dev-Ops 3.3.1 Premier axe : accélérer l’enchaînement des activités et viser le zéro défaut Le processus Dev-Ops ainsi structuré doit être examiné afin de voir comment l’accélérer. Le premier axe, le plus facile à traiter, est de prendre l’enchaînement d’activités tel quel et d’en accélérer le traitement. Cela sera fait obligatoirement par l’outillage du processus. Cela permettra aussi de viser le zéro défaut (un défaut fait perdre du temps à le corriger, donc autant éviter les défauts). Il y a deux familles d’outils qu’il va falloir mettre en musique pour y arriver :

une série outils spécialisés qui vont automatiser les différentes phases Dev-Ops, par exemple : - outils d’automatisation des tests - outils d’automatisation des déploiements

une série d’outils de gestion d’éléments de configuration (au sens ITIL et au sens développement), par exemple :

- gestion des configurations logicielles (développement) - gestion des versions définitives (processus ITIL de gestion des déploiements et des

mises en production) - gestion des configurations de production (processus ITIL de gestion des configurations)

Un outil fédérateur de gestion et de pilotage sera aussi nécessaire : les outils de Business Process Management sont des candidats idéaux pour cela, à condition qu’ils puissent s’interfacer et piloter les autres outils impliqués dans la démarche.

18

La conception des environnements de développement, d’intégration et d’exploitation devront avoir inclus dans leur réflexion la facilité et l’efficacité maximale d’outils automatisés concernant le processus Dev-Ops.

3.3.2 Second axe : permettre les digressions et les boucles contrôlées dans le processus Dev-Ops

Un processus, pour être pratique, doit autoriser en permanence la possibilité de faire autre chose ou autrement que ce qui est imposé dans le flux de traitement. Les utilisateurs du processus doivent pouvoir (sous condition de savoir ce qu’ils font) :

traiter certaines activités « dans le désordre » (en fait, le flux de traitement ou une partie est vu comme une check-list où chaque élément peut être traité indépendamment des autres)

reboucler sur une partie du processus afin de rejouer cette partie : cela est intéressant pour raccourcir les délais ; il n’est plus utile de dérouler tout le processus et de le redéclencher pour rejouer la partie qui nous intéresse ; cela est utile lors de la mise en place du mode Agile

Il va falloir aussi accompagner et automatiser au maximum ces digressions et ces boucles contrôlées. La programmation ou le paramétrage d’un outil de traitement de flux va donc d’avérer plus complexe que la simple mise en place d’un processus séquentiel. Beaucoup de ces logiciels proposent ce type de fonctionnalités (sous-processus par exemple) mais s'avèrent plus ou moins complexes à mettre en oeuvre selon l'ergonomie des logiciels.

3.3.3 Un outil de gestion et de pilotage qui va faire office de chef d’orchestre Il existe sur le marché bon nombre de logiciels pouvant répondre à ce type de cahier des charges, en plus de l’arsenal classique de tout logiciel de gestion de flux de travail. Je citerai Serena Software qui est une plate-forme complète de gestion de flux de travail, avec des boîtes de processus prêts-à-l’emploi et la possibilité d’avoir des activités automatisées. Il existe deux types d'activités :

activités réalisées par un humain : elle est simplement signalée dans le logiciel (avec les résultats obtenus) par la personne à la fin de la réalisation de cette activité

activités automatisées : elles sont réalisées par des outils logiciels et l’outil de gestion et de pilotage doit pouvoir déclencher automatiquement ceux-ci et pouvoir recevoir un message lui signalant la fin de la réalisation de l’activité et le résultat obtenu pour le traiter et savoir quoi faire dans la suite du processus.

Serena Software permet de le faire avec pal mal de possibilités techniques afin de s’adapter aux possibilités techniques d’interface du logiciel qui doit réaliser l’activité (email, webservices, etc.). C’est ce que Serena Sofware appelle l’orchestration des services.

3.4 Définition des pratiques d’intégration continue, de livraison continue et de déploiement continu (traduction d’un article de Martin Fowler)

Pour terminer ce dossier, voici la traduction de l’article « Continuous Delivery » du site de Martin Fowler : http://martinfowler.com/bliki/ContinuousDelivery.html où les trois processus continus de la discipline Dev-Ops sont présentés, traduction réalisée le 18 août 2013. La livraison continue (« Continuous Delivery”) est une discipline de développement logiciel dans laquelle vous construisez un logiciel de telle manière qu’il puisse être déployé dans l’environnement de production à tout moment. Vous faîtes de la livraison continue lorsque :

votre logiciel est déployable au travers de son cycle de vie votre équipe se focalise d’abord sur la déployabilité immédiate du logiciel avant de travailler sur

les nouvelles fonctionnalités n’importe qui peut obtenir le transfert rapide et automatisé sur la production chaque fois qu’un

développeur fait un changement vous pouvez effectuer des déploiements presse-boutons de n’importe quelle version du logiciel

sur n’importe quel environnement à la demande

19

Vous parvenez à la livraison continue en intégrant continuellement le logiciel réalisé par l’équipe de développement, en produisant les exécutables et en exécutant des tests automatisés sur ces exécutables pour détecter les problèmes. De plus, vous installez les exécutables sur de plus en plus d’environnements proches de celui de production pour s’assurer que le logiciel fonctionnera correctement en production. Pour réaliser cela, vous utilisez un pipeline de déploiement (« Deployment Pipeline »). Le test révélateur est qu’un sponsor métier (« business sponsor ») peut demander que la version courante du logiciel en développement à un moment qu’il a choisi – et personne ne sourcille ou ne se retrouve en panique. Pour atteindre la livraison continue, vous devez avoir :

des relations de travail collaboratif très proches entre toutes les personnes impliquées dans la livraison (souvent connues comme la « culture DevOps »)

une automatisation importante de toutes les étapes du processus de livraison continue, habituellement en utilisant un pipeline de déploiement

La livraison continue est souvent confondue avec le déploiement continu (« Continuous Deployment »). Le déploiement continu veut dire que tout changement traverse tout le pipeline et soit automatiquement passé en production, entraînant quotidiennement de nombreux déploiements. La livraison continue veut simplement dire que vous êtes capable de réaliser ces déploiements fréquents mais vous avez la possibilité de ne pas le faire, habituellement en raison de préférences des organisations d’affaires requérant un rythme de déploiement plus lent. Pour faire du déploiement continu, vous devez faire de la livraison continue. L’ intégration continue (« Continuous Integration ») fait habituellement référence aux activités d’intégration, d’assemblage (« build ») et de test du code dans l’environnement de développement. La livraison continue se fonde sur l’intégration continue, ajoutant les étapes finales nécessaires pour le déploiement en production. Pour plus d’information, consultez les ressources sur ma page [celle de Martin Fowler], en particulier le livre.

20

Références : Culture DevOps : http://culturedevops.com/ http://pro.01net.com/editorial/595935/les-8-erreurs-a-eviter-pour-reussir-votre-demarche-

devops/ : Les huit erreurs à éviter pour réussir votre démarche DevOps par Frédéric Richer, directeur marketing Serena Software

DevOps mode d’emploi : http://pro.01net.com/editorial/578377/devops/ http://martinfowler.com/bliki/ContinuousDelivery.html : définition des processus de Continuous

Integration, Continuous Delivery et Continuous Deployment (en anglais)