La fin du Fordisme en informatique
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.