Mettre en œuvre DevOps

La fin du Fordisme en informatique

 Par Alain Sacquet

DevOps est un mot à la mode. Malheureusement chacun a tendance à lui donner un sens différent souvent très loin de ce que ce concept recouvre réellement. Ce terme a été inventé par Patrick Debois en 2009 à Gand. Pour populariser cette démarche il a organisé des conférences : les devopsdays. Cette nouvelle approche du développement informatique a connu rapidement un réel succès, notamment Outre-Atlantique.

Malheureusement on ne sait toujours pas très bien ce que recouvre ce terme. Ainsi Jez Humble a constaté que les promoteurs de DevOps ont « toujours - intentionnellement - manqué de définition ou de manifeste ». Ceci est peut-être dû au fait Patrick Debois n’a jamais donné une définition de ce concept, pas plus qu’il n’a écrit un Manifeste comme ce fut le cas pour les Méthodes Agiles, ni produit un référentiel de la gestion de projet comme PMBok, Prince 2 ou CMMI. Il n’y a pas non plus cherché à établir un recueil de bonnes pratiques comme COBIT qui tend à ressembler à une lettre au Père Noël. Malgré cette absence de définition le terme s’est rapidement popularisé car il correspond à une réelle demande.

Différents promoteurs de DevOps se sont exercés, avec plus ou moins de bonheur, à rechercher une définition de cette notion. Ainsi le même Jez Humble a proposé comme définition : « DevOps est un mouvement regroupant des personnes soucieuses de développer et d'exploiter à grande échelle des systèmes fiables, sécurisés et performants. » Il a précisé que c’est : « une communauté de pratiques interdisciplinaires dédiée à l'étude de la construction, de l'évolution et de l'exploitation de systèmes résilients évoluant rapidement à grande échelle ». C’est intéressant mais c’est encore un peu imprécis. Gene Kim a été plus loin en affirmant : « nous considérons que DevOps est le résultat de l'application des principes du Lean au flux de valeur informatique ».

Tentative de définition de DevOps

En fait l’idée est de s’y prendre de manière différente par rapport à l’approche traditionnelle de l’informatique. C’est une manière disruptive de travailler. Dans ces conditions on peut définir la démarche DevOps comme une manière de construire un système permettant d’avoir ensuite des évolutions rapides et d’avoir un système résilient. L’idée clé de cette approche consiste à chercher à produire des évolutions en continu.

Cette approche consiste, selon Gene Kim, à appliquer à l’informatique des principes du Lean Manufacturing en travaillant la « value stream » afin d’améliorer de manière continue les systèmes d’information. Pour cela on va s’attacher à effectuer en continu des séries de changements ponctuels.

Analyse du problème

L’informatique fonctionne de manière traditionnelle en mode silo avec un mur séparant les Etudes et l’Exploitation. C’est le mur de la confusion. Ceci est dû au fait que les objectifs de ces deux unités sont très différents. Les équipes de développement sont orientées vers le changement alors que les équipes d’exploitation sont préoccupés par la stabilité des systèmes.

Le Mur de la confusion

Apparemment cette organisation et notamment l’existence des silos est incontournable. Ceci explique les nombreux incidents apparaissant lors de la mise en production d’une nouvelle application ou d’une nouvelle version d’une application ancienne. Ils se traduisent par des tensions, voir des conflits. Mais en réalité c’est une fausse opposition car elle est due aux choix d’organisation lié à l’existence de deux équipes différentes.

Pour éviter ces difficultés il est nécessaire de supprimer le mur de la confusion. Pour cela il est nécessaire de refondre l’approche classique allant de l’expression des besoins à la mise en œuvre de l’application opérationnelle.

Pour améliorer « l’IT value stream » la réponse de DevOps est de :

-       Faire changer l’état d’esprit des équipes informatiques en changeant leur culture,

-       Développer la communication en cherchant à court-circuiter la hiérarchie, si c’est nécessaire,

-       Concevoir des systèmes facilement déployables, facile à étendre en fonction des besoins des utilisateurs et simples à exploiter,

-       Mettre à la disposition des informaticiens, les outillages puissants et efficaces.  

La démarche est ce qu’on appelle dans le domaine du mangement le « time to value ». Pour cela on doit s’attacher à mettre sous contrôle l’ensemble de bout en bout des processus.

L’approche Lean

Cette première approche intéressante mais elle ne règle pas le problème. Pour y arriver il est nécessaire d’aller plus loin dans la démarche en la combinant avec une approche de type Lean (Pour en savoir plus sur l’approche Lean sur Wikipédia cliquez ici). Pour cela on va s’attacher aux points suivants :

-       S’attacher à créer de la valeur pour le client en identifiant précisément ce qu’il attend et ce qui représente de la valeur pour lui.

-       Lutter contre les activités inutiles. Pour cela on va analyser les étapes successives du processus qui aboutissent à la création du produit ou du service puis on va s’attacher à supprimer toutes les étapes qui ne créent pas de valeur. On ne doit garder que ce que le client est prêt à acheter,

-       Supprimer les gaspillages. Pour cela on va s’assurer que les étapes restantes s’enchaiîent de façon fluide, sans gaspillage, ni stock intermédiaire, avec l’objectif d’accélérer au maximum le temps d’exécution du processus complet.

-       Éliminer les fonctionnalités qui ne serviront à rien et que personne n’utilisera en demandant au client d’intervenir tout au long du processus, plutôt que d’engager les travaux de réalisation sur la base de prévisions faites au moment de la commande. On ne réalise que ce que le métier est prêt à signer.

-       Rechercher perpétuellement la perfection qui n’est atteinte que lorsque la valeur est fournie instantanément et sans gaspillage. Il faut pour cela travailler à flux tiré.

C’est la réalisation effective de la promesse faite par le DevOps. Cela représente un changement profond des méthodes de travail traditionnelle. Pour apprécier l’importance de ces changements un exemple permettra de mieux comprendre leur importance.

Un exemple troublant

Imaginer un travail consistant à effectuer dix fois trois opérations successives simples consistant à réaliser un dessin sur une feuille de papier, puis la plier et enfin mettre sous enveloppe cette feuille. Deux solutions sont possibles :

-       Effectuer d’abord les dix dessins, puis faire les dix pliages et enfin mettre sous enveloppe les dix pages,

-       Faire un premier dessin, le plier et le mettre sous enveloppe puis ensuite faire un deuxième dessin, le plier et les mettre sous enveloppe et ainsi de suite.

Question simple : quelle est la solution la plus productive ?

La plupart des personnes pensent que la première solution est la meilleure grâce à la division du travail mais l’expérience montre qu’en fait la seconde est plus productive que la première. La raison est que la solution de type Lean est plus efficace car on supprime les stocks intermédiaires. De plus cette démarche facilite les changements en cours de production.

Cet exemple d’une très grande simplicité est troublant car toute la théorie managériale repose sur des concepts comme la division du travail, le taylorisme, … et cela nous induit en erreur

« La théorie c’est quand on a tout compris mais que rien ne marche. La pratique c’est quand tout marche mais on ne sait pas pourquoi »

                                                                                              Albert Einstein

Or justement l’expérience montre qu’en traitant une à une les trois opérations on obtient très vite des résultats. C’est un premier type de gain. Mais le véritable avantage tient à la gestion des incidents. Lorsque l’opérateur rencontre des problèmes dans le processus il lui est possible de les corriger rapidement. Il est ainsi possible d’éviter de devoir refaire une partie du travail déjà réalisé (le « reworking »).

Concrètement, en informatique, cela se traduit par un changement dans la démarche de travail usuelle. Traditionnellement on a une approche monolithique. La gestion de projet se fait étape par étape : on commence par effectuer l’expression des besoins, puis on effectue l’analyse fonctionnelle puis, quand elle est validée, on passe à la programmation, puis quand elle est terminée on effectue des tests. C’est une approche en mode palier. On effectue une chose après l’autre. Malheureusement cette démarche est lourde et lente. Pour éviter ces inconvénients il est nécessaire d’avoir une autre approche plus modulaire.

Une approche pièce à pièce

Pour éviter les gros projets monolithes il faut aller vers une démarche pièce à pièce. Cela consiste de traiter complètement une fonctionnalité, aussi complexe soit elle, de l’expression du besoin par l’utilisateur, à sa réalisation, à ses tests et à sa mise en production avant de passer à la fonctionnalité suivante. C’est le meilleur moyen d’optimiser le fonctionnement de l’usine informatique (IT Factory). Pour comprendre cela un exemple simple permet d’apprécier le phénomène

Lorsqu’on observe une autoroute on constate que les voitures circulent sans peine malgré un forte circulation puis soudain on constate que sans raisons les voitures s’arrêtent. Pour comprendre les bouchons il est nécessaire de prendre en compte trois facteurs :

-       Le débit. Il est mesuré par le nombre de voitures passant devant un compteur rapporté à l’unité de temps, par exemple 100 véhicules par minute.

-       La densité du trafic. Elle est appréciée par le nombre de véhicules se trouvant sur une distance donnée. Lorsque la distance moyenne entre chaque véhicule diminue la densité du trafic augmente et le risque d’embouteillage s’accroît.

-       La vitesse moyenne des voitures. Elle est stable pendant un certain temps puis soudain elle diminue et fini par s’effondrer. Lorsque la densité du trafic augmente la vitesse du flux de voitures diminue.

L’embouteillage survient lorsque le trafic est près de la saturation et que soudain un conducteur change de comportement : il freine car son téléphone sonne ou qu’un enfant pleur à l’arrière de sa voiture. Les conducteurs qui suivent freinent à leur tour et très vite le trafic se bloque.

On observe le même phénomène dans une usine fonctionnant à la chaîne : plus le débit augmente plus le risque de saturation est élevé. Lorsque un incident survient tout se bloque. Il en est de même dans le cas d’une équipe informatique. Normalement tout se passe bien mais lorsque cette dernière s’approche de la saturation et si un problème apparaît on assiste alors à un blocage et cela se traduit par une forte dégradation de la productivité. Une méthode de développement agile comme Scrum cherche à limiter les causes de ce type d’embouteillage (Pour en savoir plus sur Scrum sur Wikipédia cliquez ici). Dans cette approche on mesure la vélocité de l’équipe. Elle est mesurée à chaque Sprint. Plus on fait des Sprints courts meilleure est la fluidité de l’activité.  

La démarche pièce à pièce doit suivre les mêmes principes. Ses résultats sont simples :

-       La qualité des applications ainsi développées doit être meilleure,

-       La productivité des équipes informatiques doit s’améliorer,

-       La réactivité lors de l’apparition de nouveaux besoins doit s’améliorer.

Instrumenter la démarche

Pour y arriver il est nécessaire d’industrialiser la démarche DevOps en se dotant d’outils puissants et efficaces comme, par exemple, l’automatisation des tests. Dans une démarche classique la phase de tests est toujours trop lourde et comme en général le projet est en retard on la réduit au strict minimum. Ceci fait que les applications sont mises en production alors qu’elles sont imparfaitement testées.

Dans le cadre de la démarche DevOps on fait exactement le contraire. On teste le code tout au long du processus. Dès que le développeur a rédigé un ensemble cohérent de lignes de code on le test. Et pour améliorer la situation, dans la mesure du possible on cherche à automatiser les tests.

Il est pour cela nécessaire de concevoir l’application de façon à ce qu’elle soit facilement testable. La solution consiste à prévoir la testabilité dès la conception de l’application. De même il est nécessaire d’avoir un système de production fiable et notamment qu’il soit, en cas d’incident, facilement réparable comme ça été le cas de l’observatoire satellitaire Hubble. Un point clé de sa conception a été sa grande sûreté de fonctionnement. La Nasa a conçu le satellite pour être réparable. Lorsque elle s’est aperçue après son lancement que Hubble était myope il a suffi de concevoir sur terre les pièces nécessaires (les fameuses lunettes correctrices) et en quelques heures les astronautes ont réalisé la réparation dans l’espace.

Il est nécessaire d’arriver à la même situation en informatique. L’objectif est d’arriver à une production qui s’exécute sans anicroche. Si un incident survient il doit être rapidement résolu. C’est particulièrement le cas des sites de commerce électronique qui fonctionnent 24 heures sur 24, 365 jours par an.

Pour s’assurer de la fiabilité des applications et de l’installation il est nécessaire de mettre en place une procédure de « Chaos Monkey ». Celle-ci permet de provoquer des pannes aléatoires et de voir ce qui se passe. L’objectif est de rendre les systèmes d’information résilients. Le Chaos Monkey permet de s’assurer qu’en cas d’incident il ne se passe rien de grave et que la production continue sans observer de dégradation significative de la qualité de service.

Pour piloter le bon fonctionnement des systèmes d’information il est nécessaire de disposer de quelques mesures suffisantes permettant de constater que le service fourni est satisfaisant. On va pour cela suivre les temps de réponse, la charge transactionnelle, la taille des files d’attente, le nombre d’incidents, le nombre de processeurs actifs, …. Ces indicateurs doivent être pertinents et une personne, ou mieux un automate intelligent, doit en permanence les suivre pour, le cas échéant, intervenir.

Pour mettre en place la procédure de développement DevOps il est nécessaire de dégager dans l’ensemble des demandes des utilisateurs de petits incréments et de travailler séparément sur chacun d’entre eux. Dans le cadre de la méthode Scrum on cherche à avoir des Sprint de 15 jours. L’expérience montre que ce cadencement n’est pas un optimum et il faut chercher à réduire ce délai. L’idéal est d’emmener le code en production tous les jours quitte à masquer les développements inachevés. Le code rédigé dans la journée est immédiatement testé et, dans la foulée, mis en production. Les GAFA procèdent de cette manière et ceci explique, en grande partie, leur réactivité.

La principale contrainte freinant cette démarche est due aux bases de données. Chacun sait qu’il est toujours difficile de modifier la structure d’une base de données. Pour éviter ces difficultés on ne supprime pas et on ne modifie pas une colonne mais on ajoute de nouvelles colonnes à la base. Cela permet d’éviter la plupart des incidents et de faire des changements au fil de l’eau. Si on souhaite modifier une colonne on garde l’ancienne et on ajoute une nouvelle colonne. Ensuite, quand les modifications ont été faites et qu’elles marchent convenablement et qu’on n’a plus besoin de l’ancienne colonne il est alors possible de la supprimer.

Comme on le voit DevOps, c’est, en fait, une autre manière de travailler.

Le temple de Toyota

La démarche que nous venons de décrire est l’application fidèle à l’informatique de la démarche d’amélioration de Toyota appelée le modèle TPS qui décrit le système de production de Toyota (Toyota Production System). Le Lean Manufacturing s’appuie sur deux piliers :

-       Le juste à temps en charge de la productivité,

-       Le « Jidoka », ou autonomation, en charge de la qualité.

C’est ce que montre le schéma ci-dessous qui décrit ce qui est souvent appelé le Temple de Toyota.

Le temple de Toyota

Le « juste à temps » de la démarche de Lean Manufacturing, voir la colonne de gauche du temple ci-dessus, s’intéresse à la performance du processus par la maîtrise du flux de transformation. Il ne s’agit pas d’expliquer la nature des activités successives qu’il convient d’effectuer, mais de réfléchir à l’organisation de ces tâches pour traiter le plus grand nombre de besoins et créer ainsi le maximum de valeur pour le client avec un effort minimal.

La solution consiste à évaluer la séquence d’activité du point de vue de la création de valeur pour le client, supprimer les gaspillages (surproduction, attentes, rebuts-corrections, gammes opératoires mal adaptées, les transports/ruptures de flux, les mouvements inutiles et les stocks), supprimer des goulets d’étranglements, diminuer la taille des lots jusque au pièce à pièce et constituer des unités autonomes de production (ou équipes intégrées).

Le deuxième pilier du Lean Manufacturing poursuit la qualité et veille à ce qu’aucune cause de défaut ne perdure dans le processus de fabrication, c’est la colonne de droite du temple.

L’évolution des équipes

Pour mettre en place le DevOps il est nécessaire de changer la mentalité des personnels de l’informatique, que ce soit les développeurs ou les exploitants. C’est probablement un des points les plus délicat car il y a de mauvaises habitudes et il est nécessaire de les changer. Ainsi on a poussé les personnes à se spécialiser à outrance. Il faut au contraire développer la poly-compétence afin que chacun soit capable de faire de la conception, de la réalisation, des tests, la mise en production et de l’exploitation. Idéalement, toutes ces compétences sont réunies au sein de chaque équipe devenue autonome dans la satisfaction des besoins de leur métier utilisateur. Reste encore à ce que les différentes équipes fonctionnent sans qu’elles s’attendent les unes les autres et finissent par ralentir l’allure globale du projet.

Ces ralentissements peuvent venir de ce que certaines fonctions sont communes à toutes les équipes. Il est nécessaire alors de les codévelopper et de fusionner les modifications de chacun tous les soirs. Cette discipline connue sous le nom d’intégration continue permet la mise en production quotidienne de ce qui a été programmé et testé au cours de la journée. C’est du développement à haute fréquence.

On va ainsi aller progressivement vers un mode de développement intégré. Il concerne un grand nombre d’applications dont les sites Web et notamment l’amélioration des pages Web, les prototypes, le Big Data, …

Pour que chaque application puisse aller en production à son initiative, il faut que le respect des interfaces des autres applications suffise à garantir que l’on ne prend pas de risque sur le comportement business des processus transversaux aux dites applications. Ce n’est pas le cas lorsque l’architecture ancienne réalise un couplage trop fort et trop fragile entre les différentes applications ou leur différents modules applicatifs. Dans ce cas, on est obligé d’organiser ou de maintenir des rendez-vous d’intégration pour s’assurer que les nouvelles applications, chacune dans leur nouvelle version, fonctionnent correctement avec leurs sœurs siamoises. Cette caractéristique définit les monolithes applicatifs pour lesquels le fonctionnement en palier doit être maintenu : une mise en production globale en « big bang » suit le rendez-vous d’intégration.

Les applications métiers anciennes peuvent être des monolithes mais ce n’est pas toujours le cas. De même les ERP peuvent poser des problèmes d’intégration mais ce n’est pas une fatalité. Dans SAP, par exemple, la notion de « transport » peut permettre le fonctionnement en mode pièce à pièce jusqu’à la mise en production. On doit dans tous les cas essayer de multiplier les mises en production pour diminuer la taille des lots d’évolution, quitte à s’écarter d’un fonctionnement à haute fréquence.

Comme le montre le schéma ci-dessous de la pyramide digitale de la DSI Inclusive il est nécessaire de faire coexister dans les équipes informatiques trois modes de développement.

D’un côté il y a le mode prototype et le mode DevOps qui sont très voisins et s’adressent à des applications digitales mais aussi des applications traditionnelles qui ont été rendues modulaires et peuvent être modifiées et améliorées par incrément de code.

De l’autre il y a les applications traditionnelles que les anglo-saxons appellent les « légacy », souvent écrites en Cobol, et qui doivent être gérées selon le mode classique. Cependant, au fur et à mesure des travaux de réécriture, il est souhaitable de les faire migrer vers une architecture modulaire de façon à évoluer ensuite en mode DevOps.

Pour en savoir plus : http://www.timspirit.com/conseil/conseil-devops/ ou la home www.timspirit.com