Création : août 2013 - La boutique ITSM · Or, ceci est faux en partie car ce n’est pas comme cela que cela se passe pour un service. ... Ce n’est pas une erreur du référentiel

Création : août 2013

www.laboutiqueitsm.com - www.itsm.boutique

1

Dev-Ops confrontée à ITIL et à la gestion de projetsLa pratique - Concevoir

A propos du documentCe document pratique est le résultat de la mise en oeuvre du référentiel ITIL® et d'autresréférentiels dans des directions informatiques en France au travers des missions qui me sontconfiées depuis 2004 ainsi que des formations que j’anime avec création de supportsoriginaux.

Il est mis à la disposition de la communauté francophone pour diffuser quelques conseils etnotes 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.laboutiqueitsm.com) ou le nom de l’auteur (Pascal Delbrayelle).

A propos de l'auteurLa transformation d'une organisation informatique en fournisseur de services informatiquesnécessite une réflexion lucide et permanente sur les tactiques à mettre en place pour quel'opérationnel s'aligne naturellement avec les objectifs stratégiques.

Souvent, l'application brutale sans réflexion d'un référentiel de bonnes pratiques comme ITIL®ou d'un logiciel ITSM améliore peu la performance de l'organisation. Les tactiques mises enplace (organisation, processus, etc.) ne sont pas les plus pertinentes à appliquer sur uncontexte spécifique et manquent de relief (prise en compte faible de facteurs telsqu'importance, priorités, gains rapides, etc.).

De plus, face à l'évolution rapide des situations et des contraintes, le format de ces référentiels(mastodontes avec une nouvelle version tous les 3 ans ou plus) est devenu trop statique etn'est plus adapté.

Il est temps de mettre de l'agilité au sein même des référentiels de bonnes pratiques.

L'amélioration continue et le Lean jouent un rôle prépondérant dans cette nouvelle manièrede faire.

Pour partager avec l’auteur : [email protected]@laboutiqueitsm.com

Pour recommander ses compétences sur les réseaux sociaux : http://fr.linkedin.com/pub/pascal-delbrayelle/27/270/634 http://www.viadeo.com/fr/profile/pascal.delbrayelle

2


Sommaire1. La démarche de ce dossier

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

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

3


1 La démarche de ce dossierCe dossier présente les deux aspects de l’approche Dev-Ops : structurer d’une manière particulière les activités aussibien de l’équipe projet que des équipes d’exploitation dans un projet puis automatiser au maximum ce processus afin degagner du temps.

Mais préalablement à cela, j’ai voulu présenter comment déjouer deux pièges classiques du référentiel ITIL sur desprocessus de conception et de transition des services que j’utiliserai ensuite pour alimenter la réflexion du processusglobal de Dev-Ops.

Les deux pièges que je dévoile sont la confusion possible entre « Conception des services » et « conception d’unservice » et la confusion fréquente entre « changement » et « mise en production ».

4


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’uncycle de vie :

Malheureusement, il peut porter à confusion avec un autre cycle de vie plus opérationnel et il faudrait plutôt dire « Cyclede 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 laconception des services, la transition des services puis l’exploitation des services, pour revenir en conception desservices 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 leportefeuille de services s’il s’agit de quelque chose de stratégique, la mise en place d’un service commence par unedemande de changement (lancement d’un projet). Nous sommes alors directement projetés dans … la transition desservices 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 dansITIL®), développé, testé puis mis en production dans cette même phase de transition. C’est d’ailleurs pour cela quecelle-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 puisrebouclera 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 d'ITIL®

Alors nous pouvons nous demander légitimement à quoi sert finalement la phase de conception des services ? D’autantplus qu’au vu des processus de cette phase, on retrouve aussi des activités que nous ne pouvons réaliser que dans laphase 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 quelquesinterrogations.

5


Simplifions le discours ITIL® et voyons les deux ambitions de la phase de conception des services :

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

concevoir un cadre de fonctionnement pour les équipes de transition et les équipes d'exploitation, tant aussi biendans la manière de travailler (processus, méthodologies, normes, etc.) qu’au niveau technique avec la conceptionde solutions d’infrastructures aptes à supporter les futurs services d’affaires et surtout les niveaux de serviceassocié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èbremais 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’estqu’un processus est associé à un ensemble impressionnant d’objectifs, certains liés à la conception, d’autres à latransition 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 duprocessus, ce dernier se décompose en plusieurs sous-processus, chacun des sous-processus se voyant attribué l’undes 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’onpeut avoir du processus résultant.

Par exemple pour les processus de la conception des services, nous allons trouver des activités de conception, detransition, 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 unseul livre (donc une seule phase). Le choix délibéré qui a été fait a été de ranger un processus dans la phase pourlesquelles 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 cettecompréhension globale de ce que sont les processus ITIL®.

Prenons un exemple : ceci 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 Surveiller (1) et améliorer (2) la satisfaction du client par le biais de la qualité de serviceet 1. ExploitationExploitation

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 Définir (1), documenter (1), valider (1), surveiller (2), mesurer (2), rapporter (2) et revoir (1) le niveExploitation informatiques

1. Transition

2. Exploitation

6


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

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 lesactivité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 lesexploitants 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 detransition et d’exploitation. Il va donc couvrir la phase de réalisation du changement (ou la phase de projet) pour unnouveau service (élaboration et accord sur les niveaux de service) et la phase d’exploitation (surveillance et productionde 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 lesautres 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 deuxgrandes 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 infrastructuretechnique) 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

Afin de structurer ces activités et de les aligner pour qu’elles servent au mieux les objectifs stratégiques, il est nécessairede définir une tactique de mise en œuvre de la stratégie des services.

7


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 deservice. 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 leslivrables 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 avecdes 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 desservices :

méthodologie projet et l’ensemble des processus de transition et d’exploitation, ainsi que les modèles deprocessus (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 deservice (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 lesphases de transition et d’exploitation.

Malheureusement, à d’autres endroits de la documentation ITIL®, le SDP est présenté comme étant l’ensemble desdocuments accompagnant la mise en œuvre d’UN service. Par exemple, si ce dernier est traité en mode projet, le SDPest 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.

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’ensembledes 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ésen 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

8


2.2 Confondre « changement » et « mise en production »2.2.1 L’origine de la confusion : les outils logicielsITIL®

Lors de mon utilisation de plusieurs logiciels certifiés ITIL®, quelle ne fut pas ma surprise de constater qu’une équipeprojet doit faire des demandes de changement à chaque fois qu’elle demande aux équipes d’exploitation de mettre enproduction 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 ceslogiciels.

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 ilest 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 étantmaté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, comprenanttous les actifs de service : organisation, processus, personnes, connaissances, etc.) : certains changements (lesplus importants) seront traités en mode projet

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

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

Ainsi, un changement ou un projet, peut déclencher un ou plusieurs déploiements. Le processus de gestion desdéploiements et des mises en production peut, de son côté, décider de regrouper plusieurs mises en production dansune 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’autresprocessus stratégiques (gestion de la stratégie ou gestion financière des services par ex.) ou l’amélioration continue desservices.

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

9


Lorsqu’est arrivé le moment pour un nouveau service de passer dans la partie « catalogue de services » du portefeuillede services (encore une autre ambiguïté du référentiel ITIL®), le processus de gestion du portefeuille de services va faireune « demande de changement améliorée » appelée « proposition de changement » ( Change Proposal) pourdéclencher le processus de gestion des changements.

La proposition de changement est une demande de changement enrichie de tous les documents stratégiques qui ontdéjà été réalisés sur le futur service avant même que le changement ait été initié (et le projet lancé), notamment ledossier 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 leprocessus 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 ledirecteur 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 grandesimplification, il permet néammoins de voir qu’une fois la demande de changement autorisée, les activités du processusparlent de planifier et de coordonner les activités de réalisation et de faire un bilan sur la réalisation :

10


Ce qui n’est pas présenté dans ce schéma, ce sont les interactions avec les autres processus, qu’ils soient ITIL® ouappartenant à la méthodologie projet.

D’autre part, l’activité « Coordonner l’implantation » couvre toutes les étapes de conception, dedé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 dechangement qui sont à rapprocher avec les activités jalons d’un projet.

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

11


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 leprocessus 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ètementintégrée les processus de développement et les processus d’exploitation et en mettant un œuvre un outillage logicielautomatisant 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éthodologieprojet 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 ensembled’outils pour automatiser et accélérer le traitement de ces activités.

12


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

3.1 Raison d’être de cette démarcheCette démarche est focalisée sur l’idée que le temps de mise sur le marché (« Time-to-market ») d’une nouvelle offrepour 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 quebeaucoup de soucis et de délais trop longs sont liés au fonctionnement de la gestion de projet informatiques et auxdifférences de culture entre équipes de développement et équipes d’exploitation au sein du fournisseur de servicesinformatiques.

13


3.2 Etape numéro 1 : rationaliser les activités Dev-Ops3.2.1 Concilier le « pas forcément inconciliable » : méthodologie projet etITIL®

Traditionnellement, les activités projets sont régentées par une méthodologie projet qui prend mal en compte lesactivité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 » sonttrès peu cités dans la documentation. ITIL® présente très bien les activités d’exploitation (historiquement, ITIL® vient dumonde 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 devue 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, desprocessus ITIL® de transition des services (notamment la gestion des mises en production et des déploiements) maisaussi 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

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 puisseprendre 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 demandepertinente 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éthodologieprojet, la partie « avant-projet » ou « pré-étude » (ou autre « étude d’opportunité ») selon le vocabulaire méthodologiqueemployé.

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 serviceconvenus avec les ressources présentes dans la partie exploitation (ressources techniques et humaines et contrats desous-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/ouparamétrage), tests, mise en production et pilote.

14


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 chaquephase du changement (ou du projet).

Une fois réalisé, il est donc possible de dessiner un macro-processus dont une structure simplifiée est la suivante (tousles 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 enest pour l’instant très éloigné).

Ce cadencement est piloté par le processus de gestion des changements au travers des activités de pilotage quiconsiste essentiellement à valider le déroulement de la phase précédente (tous processus confondus) et à autoriser laré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êmemanière ainsi que les activités de conception des services (catalogue de services, niveaux de services, fournisseurspour 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 caseprocessus 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 fluxde 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-Opsest la partie la plus connue de négociation et de mise en place des SLAs, OLAs et contrats de sous-traitance lié à la miseen place d’un nouveau service :

15


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 duprocessus Dev-Ops :

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

16


Le schéma positionne les différentes activités du flux de travail classique de la gestion des niveaux de service dans lesdiffé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®, pouvantdonner l’impression d’un référentiel en silos de processus, chacun des processus vivant sa vie indépendamment decelle des autres processus.

L’intégration du processus de gestion des niveaux de service dans le processus Dev-Ops permet aussi de préciser troisgrands déclencheurs de ce flux de travail de gestion opérationnelle des niveaux de service (les trois cercles rouges avecun 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é avecdes 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 changementsafin 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 deservice, 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 desniveaux 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 deboucle 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 deniveau d’opérations et les contrats de sous-traitance, il y aura plusieurs ajustements successifs afin de contentertoutes 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éajustementsdans les processus ITIL® impliqués.

Mais cela ne change pas l’approche globale.

17


3.3 Etape numéro 2 : outiller le macro-processus Dev-OpsLe processus Dev-Ops ainsi structuré doit être examiné afin de voir comment l’accélérer.

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

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 faitperdre 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 sontdes candidats idéaux pour cela, à condition qu’ils puissent s’interfacer et piloter les autres outils impliqués dans ladémarche.

La conception des environnements de développement, d’intégration et d’exploitation devront avoir inclus dans leurré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 cequi 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 ; iln’est plus utile de dérouler tout le processus et de le redéclencher pour rejouer la partie qui nous intéresse ; celaest 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 miseen place d’un processus séquentiel. Beaucoup de ces logiciels proposent ce type de fonctionnalités (sous-processus parexemple) 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’arsenalclassique 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 processusprê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) parla 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 pouvoirdéclencher automatiquement ceux-ci et pouvoir recevoir un message lui signalant la fin de la réalisation del’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éstechniques d’interface du logiciel qui doit réaliser l’activité (email, webservices, etc.).C’est ce que Serena Software appelle l’orchestration des services.

18


3.4 Définition des pratiques d’intégration continue, de livraison continue et de déploiementcontinu (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 sontpré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 vousconstruisez 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 nouvellesfonctionnalités

n’importe qui peut obtenir le transfert rapide et automatisé sur la production chaque fois qu’un développeur fait unchangement

vous pouvez effectuer des déploiements presse-boutons de n’importe quelle version du logiciel sur n’importe quelenvironnement à la demande

Vous parvenez à la livraison continue en intégrant continuellement le logiciel réalisé par l’équipe de développement, enproduisant les exécutables et en exécutant des tests automatisés sur ces exécutables pour détecter les problèmes. Deplus, vous installez les exécutables sur de plus en plus d’environnements proches de celui de production pour s’assurerque 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 endé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 (souventconnues comme la « culture DevOps »)

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

La livraison continue est souvent confondue avec le déploiement continu (« Continuous Deployment »). Le déploiementcontinu veut dire que tout changement traverse tout le pipeline et soit automatiquement passé en production, entraînantquotidiennement de nombreux déploiements. La livraison continue veut simplement dire que vous êtes capable deréaliser ces déploiements fréquents mais vous avez la possibilité de ne pas le faire, habituellement en raison depréférences des organisations d’affaires requérant un rythme de déploiement plus lent. Pour faire du déploiementcontinu, 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 surl’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.

19

Documents

Création : août 2013 - La boutique ITSM · Or, ceci est faux en partie car ce n’est pas comme cela que cela se passe pour un service. ... Ce n’est pas une erreur du référentiel