EasyTech #14 - Pas d'agile sans DevOps

Une théorie trop sous-estimée mais essentielle 🙌

Salut à toi,

J’espère que tu vas bien 😃

De mon côté tout va bien, j’ai dû déménager de chez mes parents mon uniforme de l’X. En vélo bien sûr… c’était pas très pratique 😂

Aujourd’hui on va parler DevOps, théorie trop souvent négligée mais hyper importante pour développer des applications efficacement.

Histoire du DevOps

On commence par un petit retour en arrière.

Ancêtre n°1 : le lean

Les excès du Taylorisme

Avant de parler lean, il qu’on parle du Fordisme / Taylorisme.

Au début du XXème siècle, on commence à construire des voitures au sein de l’industrie à grande échelle. Ford va notamment démocratiser la voiture avec sa célèbre Ford T, à prix abordable pour tous les ménages.

Pour produire avec beaucoup d’efficacité toutes ces voitures. On crée une méthode qu’on appelle “l’organisation scientifique du travail” (OST), qu’on assimile souvent au Fordisme et au Taylorisme.

C’est ce qu’on appellerait aujourd’hui le travail à la chaîne.

L’idée : on spécialise à fond les travailleurs, chacun réalise une tâche, mais la réalise à la perfection. On observe, on forme et on mesure, pour être le plus efficace sur chaque micro-tâche.

Le résultat : c’est puissant parce que les choses sont bien huilées. En revanche : (1) pour les travailleurs c’est très abrutissant ; (2) quand il y a un problème sur la chaîne, un truc qui sort de la normale, les travailleurs ne sont pas compétents pour le traiter (parce que ça sort de la tâche de laquelle ils sont experts).

L’émergence du lean post 2ème Guerre Mondiale

En réaction notamment à ça, le lean va émerger à partir de la fin de la seconde guerre mondiale.

Un des piliers structurants du lean va être : Respect the People = respecter les travailleurs.

Dans les modèles type OST comme on l’a vu, on respecte peu les gens au sens où on les assimile à des machines qui réalisent tout le temps la même tâche. Et non à des hommes capables de réfléchir et de trouver des solutions innovantes à des problèmes.

Ensuite avec ce genre de fonctionnement à la chaîne, on a tendance à créer pas mal de stocks. Je produis je produis je produis, et ensuite je mets de côté en attendant que ça vende. Si le client n’aime pas ? C’est son problème.

Ford disait qu’on pouvait avoir sa voiture de n’importe quelle couleur tant que la couleur était noire !

Bref pas hyper user-centric comme approche.

Le lean se construit donc en opposition à ça, dans les usines Toyota, au Japon.

Extension du lean

Et ça marche ! Extrêmement bien même ! Très vite Toyota s’impose comme un des principaux constructeurs automobiles mondiaux.

À tel point que le lean / aussi appelé Toyotisme va dépasser les frontières du Japon et s’appliquer à l’industrie automobile dans d’autres pays.

Ensuite, la théorie est trouvée tellement puissante qu’on va l’étendre à d’autres champs d’application :

→ Aux organisations avec des théories comme le Six Sigma où on va considérer les entreprises / organisations comme si elles étaient des usines qui produisent quelque chose (mais pas des voitures)

→ Au développement de logiciel ! C’est le Lean Software Development avec deux grands théoriciens du sujet, Mary Poppendieck et Don Reinertsen. Deux ouvrages références : Implementing Lean Software Development et Principles of Product Development Flow.

L’agile

Le développement de l’informatique “grand public”

En parallèle, à partir de années 1980 - 1990, l’informatique commence à se développer de plus en plus. On n’est pas encore à l’ordinateur individuel (~ années 2000), voire au smartphone (~ années 2010) mais tranquillement les logiciels et applications informatiques commencent à voir le jour.

Pour autant, les méthodes de développement sont toujours très “cycle V” / Waterfall (cascade) dans l’esprit avec un vision pas mal inspirée du BTP.

Ce sont d’ailleurs des approches assez logiques, naturelles :

→ Je commence par définir ce que je veux, c’est mon expression de besoin, mon cahier des charges. Et j’essaye de le faire de manière exhaustive pour ne pas revenir dessus derrière.

→ Ensuite j’envoie en développement, pour écrire le code qui permet de construire l’application. Je développe tout le cahier des charges ! Normal c’est ce que je veux et j’ai passé beaucoup de temps à l’écrire.

→ Ensuite je teste les développements réalisés, tests techniques dits unitaires, tests orientés “fonctionnels” avec les profils plus maîtrise d’ouvrage. Je confronte la réalité de ce qui a été construit, par rapport au cahier des charges.

→ Enfin je peux déployer mon application, et donner accès aux utilisateurs finaux aux fonctionnalités qu’ils attendent depuis qu’on a écrit le cahier des charges.

Cette approche présente deux principaux problèmes :

→ 1 d’un point de vue technique, c’est beaucoup plus efficace de développer un petit peu, de tester un petit peu puis de déployer un petit peu. La complexité croît exponentiellement avec le volume développé / testé / déployé d’un coup

→ 2 d’un point de vue utilisateur, entre le moment où on a consulté l’utilisateur (si on l’a fait) rédiger le cahier des charges… et le moment où on a construit l’application. Il peut se passer plusieurs années et le besoin a change ou n’existe plus.

2001, le manifeste agile est publié.

En 2001 c’est le pavé dans la mare. 17 ingénieurs / développeurs se regroupent et écrivent le manifeste agile en réaction à ces méthodes de développement qu’ils estiment inefficaces et très désagréables pour les équipes.

Ce texte va donner un énorme coup de boost à ces approches incrémentales et itératives. Notamment parce que le terme “agile” est très très bien trouvé d’un point de vue marketing. C’est notamment très international, très catchy court et très parlant.

Le coeur du manifeste agile c’est :

→ les individus et leurs interactions plutôt que les processus et aux outils ;

→ un logiciel fonctionnel plutôt qu’à une documentation exhaustive ;

→ la collaboration avec les clients plutôt qu'à la négociation contractuelle ;

→ l’adaptation au changement plutôt qu'à l'exécution d’un plan.

Sachant que le Manifeste précise que “s’il y a de la valeur dans les éléments sur la droite, notre préférence porte sur les éléments à gauche de la phrase.”

Pour être très précis, on parlait déjà dans la littérature des années 1990 des approches incrémentales comme étant une alternative intelligente au cycle en V. Pour autant le manifeste va vraiment les aider à exploser.

Si vous êtes curieux sur l’agile ou souhaitez en savoir plus, j’ai commencé à traiter le sujet dans l’édition Easy Tech #8 sur les bases de l’agile.

L’agile fait naître des conflits entre Dev et Ops

À partir des années 2000, l’agile va donc grandement améliorer la partie “développement” des applications informatiques.

C’est le moment d’introduire une mini précision. Quand tu gères des logiciels / produits, il y a deux grands types d’activité :

• Développement = je fais changer mon logiciel sans forcément avoir direct une visibilité sur l’impact utilisateur

• Opération = je m’assure que mon logiciel tourne bien et que les utilisateurs soient contents

Donc les développeurs travaillent en petits cycles incrémentaux, et montrent de manière très régulière le fruit de leur travail aux utilisateurs finaux. Pour autant, les développeurs ne font pas directement évoluer l’application auquel accède l’utilisateur final. Ils la font évoluer sur un environnement de test.

Ce sont les départements Opération / Exploitation / Production qui se chargent de faire évoluer cette application auquel accède l’utilisateur final. On parle d’ailleurs d’environnement de production pour décrire le serveur sur lequel est installé la version de l’application qui est accessible pour les utilisateurs finaux.

Donc vous me voyez venir.

L’agile va énormément accélérer la partie développement… sans s’occuper de la partie déploiement / mise en production. Résultat, on va super vite pour faire évoluer l’application sur les environnements de test. Mais on est toujours aussi lents pour déployer des évolutions pour l’utilisateur final, sur les environnements de production.

💡 Qu’est-ce qu’un “déploiement” ?

C’est comme ça qu’on appelle l’action d’installer une nouvelle version d’un logiciel sur un serveur / environnement.

Il pouvait n’y avoir aucune version auparavant sur le serveur / environnement, quand on lance le logiciel pour la première fois.

Il pouvait y avoir une version antérieure, auquel cas, la nouvelle version va en général écraser l’ancienne. On passe par exemple de la v1.1 à la v1.2

Ce qui génère deux problèmes :

→ D’abord, évidemment, l’utilisateur est frustré ! Les développeurs lui montrent de nouvelles versions de l’application sur les environnements de test. Mais celui-ci va toujours devoir attendre longtemps pour voir arriver ces fonctionnalités en production.

→ Ensuite, cela génère une grosse frustration pour les fonctions de Production. Qui se retrouvent un peu montrés du doigt comme “les rabats-joie”, les goulets d’étranglement du processus. Là où ça n’est évidemment pas de leur faute… ils n’ont pas encore eu l’équivalent de leur révolution agile

Le besoin d’agiliser jusqu’à la production

De là vient ce besoin de transporter l’agile jusqu’à la partie mise en production ! Pour faire que ça n’aille pas juste vite pour développer sur des environnements de test auxquels n’a pas accès l’utilisateur. Car dans ce cas, ça ne lui apporte pas de valeur.

Pour être un poil plus précis, voici les trois gros problèmes auxquels répond le DevOps.

Le conflit chronique entre les Dev et les Ops

Je pense que vous commencez à avoir une intuition du potentiel un peu explosif de la situation.

→ D’un côté, j’ai les développeurs. Ils veulent de la vitesse. Délivrer le plus vite possible du code pour donner des nouvelles fonctionnalités aux utilisateurs. Plus l’application évolue, plus ils sont contents. Car ça veut dire qu’ils apportent de la valeur.

→ De l’autre, j’ai la production. Ils veulent de la stabilité. Les utilisateurs n’aiment pas les applications qui buggent. Les utilisateurs n’aiment pas faire des mises à jour de leurs applications. Alors devoir faire des déploiements qui déstabilisent tout ça, la production n’aime pas.

On a donc un vrai antagonisme entre ces deux acteurs.

Un antagonisme d’ailleurs renforcé par des frontières organisationnelles. C’est à dire des situations où la production appartient à un premier département. Et où les développeurs appartiennent à un second département.

DevOps va répondre à ce problème. Comment ? On va le voir par la suite. En tout cas le nom même vise à traduire cette idée de créer du lien entre ces deux fonctions (DevOps = Développeur + Opération).

Le besoin d’accélérer les déploiements

On a vu que l’agile se développe à partir des années 2000. Globalement le DevOps va grossir beaucoup à partir des années 2005-2010. Or comme je l’ai dit rapidement tout à l’heure, ce sont des années où l’informatique va véritablement exploser. Le digital, la tech, vont commencer à faire partie de nos vies de manière de plus en plus poussée.

Ça veut dire que le besoin de développer des fonctionnalités très rapidement devient une condition de survie. La tech devient un asset stratégique. Les concurrents se démarquent par de nouvelles fonctionnalités. Pour ne pas se faire doubler, il faut réussir à tenir le rythme.

Par ailleurs, en parallèle, les utilisateurs commencent également à avoir “des goûts de luxe”. Ils s’habituent à de belles applications efficaces. Et demandent des évolutions et des nouvelles fonctionnalités. Avec une patience de plus en plus réduite.

Bref tout pousse à accélérer le plus possible le développement informatique et à réduire le “time-to-market”. C’est à dire le temps entre l’émergence d’une idée et son lancement sur le marché.

Éviter la spirale négative de la dette technique

Enfin réussir à livrer rapidement des fonctionnalités est une garantie de résilience de l’application informatique. C’est une manière d’éviter une dette technique qui grossit de manière incontrôlée.

Avec une application fragile, le cercle vicieux suivant s’enclenche :

→ L’application présente des bugs, des fragilités techniques qui nuisent à l’expérience utilisateur

→ Pour satisfaire l’utilisateur, il est nécessaire de construire de nouvelles fonctionnalités

→ Mais construire de nouvelles fonctionnalités sur des bases friables ne fait qu’aggraver la situation

→ Ce qui fait que les fragilités techniques sont renforcées, nuisant encore plus à l’expérience utilisateur.

Dès lors, il est nécessaire de mettre en place des bases techniques solides et fiables, pour pouvoir répondre aux besoins d’évolutions de l’utilisateur à moyen long terme. Sans risquer de tomber dans ce genre de situations dangereuses et sans issue.

---

Pourquoi est-ce important, comment cela se matérialise ?

Les trois voies du DevOps

Le DevOps peut se décomposer en trois niveaux ou voies :

→ 1 focus sur le “flow” / flux, le but est d’accélérer la livraison de valeur, de la gauche = idée business, à la droite = son déploiement en production pour l’utilisateur

→ 2 focus sur le “feedback” / les retours utilisateurs, le but est d’assurer un flux constant et rapide de feedbacks de la droite = la production, vers la gauche = en amont sur la chaîne de valeur

→ 3 focus sur l’apprentissage, à ce stade, l’idée est de s’appuyer sur le flux et le feedback pour générer des expérimentations et des apprentissages tout le long de la chaîne de valeur ; l’organisation devient résiliente et apprenante.

La première voie - le flux

6 grands principes sont utilisés pour assurer qu’on minimise le temps pour passer d’une idée, d’un concept business… à son déploiement en production, sous forme de fonctionnalités pour l’utilisateur.

Principe 1 - rendre le travail visible

Une des grandes difficultés de la tech par rapport à l’industrie est que “l’inventaire” est invisible.

Qu’appelle-t-on l’inventaire ? Quand on parle d’une usine, l’inventaire ça va être le stock de produits finis mais pas encore vendus, les pièces qu’on garde avant de les utiliser pour les assembler, etc.

Quand l’inventaire est physique, on visualise très bien que c’est coûteux. Ne serait-ce que parce que stocker des choses ça prend de la place, donc derrière c’est :

→ soit un coût supplémentaire en termes de loyer

→ soit un manque à gagner car on aurait pu mettre une machine pour produire à la place

En informatique, le stock et l’inventaire, ça va être les fonctionnalités pas encore finalisées. Elles n’apportent pas encore de valeur. Elles prennent de la place, en termes de code. Elles nous génèrent de la charge mentale. Mais elles sont invisibles, parce que tout est immatériel.

Donc une des premières choses qu’on va faire c’est rendre cet inventaire visible avec des outils de management visuel comme le tableau Kanban. Ça permet de rendre visible ces items non finalisés et donc de réduire leur quantité.

Principe 2 - Réduire le travail en cours

On parle de WIP - Work in Progress pour désigner le travail en cours. Ça va également renvoyer aux choses qu’on est en train de faire en parallèle. Tant que quelque chose est “en cours”, cela veut dire qu’il a été démarré sans avoir été fini.

Moins le WIP est élevé, plus on est efficace. Pour deux raisons :

→ Premièrement, on est plus à même de réagir face à des sollicitations urgentes. Quand on est sur l’autoroute et que l’autoroute est bondée, c’est très dur de s’écarter pour laisser passer une ambulance. C’est pareil en développement, quand tu as déjà 15 choses démarrées en parallèle, c’est difficile de le prendre en compte rapidement. Inversement, si tu as “de la place”, tu peux être plus agile et avoir des plannings bien plus dynamiques.

→ Deuxièmement, réduire le WIP nous pousse à réduire également le multitasking. On est plus focalisé sur une tâche. Qu’on va essayer de finaliser. Plutôt que de passer son temps à changer de sujet. Ce qui fait qu’on passe son temps à se déconcentrer puis à se reconcentrer. Et ce focus plus important fait que le time-to-market pour passer de l’idée business à son déploiement réduit également.

Principe 3 - Réduire la taille des “batchs“

Ce qu’on appelle “batch” (ou lot en français) ce sont les unités de travail sur lesquels on bosse.

Par exemple, si j’écris un livre, je peux avoir différentes “unités de travail”. Je peux écrire ligne par ligne, le batch = la ligne. Je peux écrire page après page, le batch = la page. Je peux écrire chapitre après chapitre, le batch = le chapitre. On voit bien que la taille du batch est importante. Si j’écris chapitre par chapitre, ça va être plus dur d’ajuster, d’itérer. J’ai intérêt à être sûr de moi. Inversement, en écrivant ligne par ligne, je suis très agile… mais peut-être un peu trop.

En informatique, on a à peu près le même genre d’arbitrage, avec l’idée qu’il vaut mieux avoir des batchs très petits (jusqu’à une certaine limite).

On identifie 3 justifications :

→ Premièrement, plus le batch est petit, plus je peux apporter de la valeur rapidement. Quand j’ai écrit une page, à la fin, cette page est finie et on peut la lire. Elle apporte de la valeur. Quand j’écris un chapitre qui contient par exemple 30 pages, c’est 30 fois plus long d’avoir quelque chose qui apporte de la valeur et qui peut être lue. Or on a vu que la première voie avait pour objectif d’apporter de la valeur vite.

→ Deuxièmement, plus le batch est petit, mieux ça se passe. Inversement, plus le batch est gros, plus c’est compliqué techniquement. En matière de déploiements en production, il vaut mieux faire plein de petits déploiements plutôt qu’un gros déploiement. La complexité additionnée de chaque petit déploiement est bien moins grande que la complexité globale d’un gros déploiement. Notamment parce que ça déstabilise beaucoup plus l’application de beaucoup la faire bouger d’un coup, ce qui entraîne des effets non linéaires.

→ Troisièmement, il y a un effet isolation des problèmes avec des petits batchs. Et inversement un effet contamination des problèmes avec de gros batchs. Typiquement si mon clavier a un problème et qu’une lettre n’est pas tapée correctement. Comme je fais lire (je récupère un feedback) après avoir écrit. Je me rendrai compte bien plus vite du problème du clavier lorsque mon batch = la ligne ou la page. Si mon batch est un chapitre voire le livre, je ne me rendrai compte du problème qu’une fois le chapitre / livre fini. Il faudra tout recommencer du début, ça fera beaucoup de travail.

Principe 4 - réduire le nombre d’intermédiaires

C’est une bonne pratique générale qui dépasse le DevOps.

Les silos, les différents niveaux de validation et les intermédiaires ont un impact négatif sur la productivité. C’est en particulier vrai pour les sujets tech.

→ D’une part, ça fait que les différents intermédiaires travaillent uniquement pour livrer quelque chose à l’intermédiaire suivant, pas pour délivrer de la valeur à l’utilisateur

→ D’autre part, ça crée un effet “file d’attente”, avec une pile de choses qui s’accumule petit à petit. Au lieu d’avoir un batch petit qui passe vite de l’idée au déploiement ; on va avoir un plus gros batch qui avance lentement entre les différents services pour aboutir au final au déploiement.

En général pour régler ce problème il faut :

→ 1 réorganiser les équipes pour leur permettre de délivrer directement de la valeur par des déploiements, ce qui veut dire leur donner les moyens de le faire de manière sécurisée

→ 2 automatiser le plus possible les différentes étapes pour passer du développement à la mise en production afin que le process soit industriel, rigoureux et fiable.

Principe 5 - identifier et supprimer les contraintes en continu

Lorsqu’on observe le processus par lequel on délivre des fonctionnalités, on va naturellement voir apparaître des endroits où les choses ne vont pas aussi vite que prévu. C’est ce qu’on appelle les “contraintes” dans le monde lean.

Par exemple, s’il faut passer devant un comité qui se réunit une fois par mois pour déployer une feature en production, ce comité va être une “contrainte”, au sens où c’est un goulet d’étranglement qui réduit la vitesse pour passer de l’idée à la mise en production.

On va essayer de détecter le plus rapidement possible ces contraintes et de les supprimer / transformer pour en faire des atouts plutôt que des freins.

Quelques exemples de contraintes classiques :

→ Un temps trop élevé pour créer de nouveaux environnements sur lesquels effectuer des tests

→ Des procédures trop complexes et longues pour déployer du code, notamment si ces étapes sont manuelles

→ Les tests manuels qui ralentissent la vérification du bon fonctionnement des fonctionnalités

→ Une architecture avec des composants trop imbriqués les uns avec les autres, ce qui entraîne des effets de bord lorsqu’on fait bouger un endroit de l’application, on risque de créer des bugs à un autre endroit (= des régressions).

Principe 6 - éliminer les déchets dans le flux de valeur / value stream

Petite précision, quand on parle de value stream / flux de valeur, on parle du processus, des différentes étapes par lesquelles passe une idée avant d’être déployée en production. Classiquement on va retrouver :

→ La rédaction d’une forme de spécification / expression de besoin

→ Le développement de la fonctionnalité

→ Le test de la fonctionnalité

→ Le déploiement de la fonctionnalité

→ L’utilisateur accède à la fonctionnalité

Toutes ces actions sont réalisées par des acteurs pour apporter de la valeur à l’utilisateur final, on peut donc le voir comme un flux :

💡 Le flux de valeur

idée → spécification → développement → test → déploiement → accès à l’utilisateur

Le lean parle de déchet pour désigner tout ce qui retarde l’arrivée de la valeur pour l’utilisateur sur cette chaîne.

Par exemple

→ Une fonctionnalité qu’on a commencé à développer mais qui n’est pas finalisée ⇒ n’apporte pas de valeur = déchet

→ Les processus supplémentaires, juste là “pour faire joli” ⇒ n’apporte pas de valeur = déchet

→ Les fonctionnalités qu’on rajoute en plus, parce qu’on pense que ça va faire plaisir à l’utilisateur sans que ça soit le cas ⇒ n’apporte pas de valeur = déchet

→ Les bugs / anomalies qui nuisent à l’expérience utilisateur, et l’empêchent de profiter du produit ⇒ n’apporte pas de valeur = déchet

On va essayer de repérer toutes ces choses et de les minimiser au maximum.

→ Pour ne pas avoir de fonctionnalités non finalisées ⇒ on ne démarre que ce qu’on est sûrs de finir rapidement

→ Pour ne pas avoir de processus inutiles ⇒ on essaye d’être très exigeant sur les comités, réunions, meetings…

La deuxième voie - le feedback

Maintenant qu’on sait aller très vite d’une idée, d’un concept à son déploiement en production, on peut se focaliser sur le chemin retour ! Récupérer du feedback, de la visibilité sur comment ça s’est passé dans l’autre sens.

Pourquoi est-ce important ?

Premièrement, la réponse logique est que le feedback utilisateur est toujours crucial quand on développe des applications informatiques. Le risque principal auquel on fait face, c’est de créer une solution à un problème qui n’existe pas.

Donc avoir un feedback le plus rapide possible va permettre d’éviter de tomber dans ce travers.

J’ai une idée → je l’envoie vite en production (1ère voie).

L’utilisateur y accède → je prends son feedback (2ème voie).

Deuxièmement, les systèmes informatiques sont des systèmes dits “complexes”. C’est à dire que c’est pas facile à gérer. Par exemple, je ne peux pas toujours anticiper leur comportement, comme quand je fais deux fois de suite la même action, mais qu’elle n’a pas le même résultat.

Comme on ne peut pas tout anticiper, tout comprendre, tout prédire, dans ces systèmes, on va devoir développer une connaissance “empirique” de ceux-ci. C’est à dire qu’au lieu de raisonner de manière théorique, en amont. On va essayer d’observer de plein de manières différentes le système, pour être plus efficaces lorsqu’on interagit avec.

Donc, on ne sait jamais comment le produit va se comporter (c’est un système complexe). Mais on a déjà vu plein de cas de figure différents, donc on se dit qu’on sera capable de réagir rapidement.

Comment on accélère le feedback ?

En un mot : la supervision (ou monitoring en anglais).

C’est un concept qui est trop méconnu dans la tech mais qui est pourtant très puissant. La supervision renvoie à l’ensemble des dispositifs qu’on met en place pour surveiller l’état d’un système informatique à un instant donné.

Prenons l’exemple du corps humain. C’est un système complexe ! On ne peut pas toujours bien anticiper comment il va réagir à une stimulation donnée. La supervision dans ce contexte ça serait l’ensemble des capteurs qui me permettent d’observer comment ce corps réagit. La montre connectée qui mesure mon pouls. Le thermomètre que j’utilise pour prendre ma température. L’IRM que je fais pour vérifier si tout va bien etc…

Pour un système informatique, c’est le même genre de choses.

On va avoir de la supervision technique. Elle va nous permettre de surveiller que les composants techniques réagissent bien. Est-ce que mes serveurs sont surchargés ? Est-ce que ma base de données est saturée ? Est-ce que les requêtes sont échangées correctement entre les différents composants de mon système ? Ça va aussi plus loin que ça. Typiquement si j’ai eu un bug par le passé, à cause de quelque chose qui ne s’est pas bien passé. Je vais pouvoir créer un point de supervision pour checker spécifiquement que ce bug ne se reproduit pas.

On va ensuite avoir de la supervision métier. Elle va être orientée davantage sur l’utilisation de l’application, du produit. Par exemple si mon produit est un site web comme Amazon. Je vais regarder combien de personnes sont connectées à un instant donné. Je vais regarder le montant moyen des transactions sur une période de temps donné. C’est intéressant parce que ça me renseigne à la fois sur le fait que les utilisateurs aiment mon application. Et aussi sur le fait que mon système fonctionne correctement. Typiquement si le volume de transactions est à 0$ pendant 6 heures sur Amazon. Ça veut sûrement dire qu’il y a un bug quelque part.

On parle souvent de Product Analytics pour renvoyer à la supervision métier, dans un contexte Product Management. Mais dans le monde DevOps, on préfère Supervision.

Ce que ça nous permet de faire

Avoir un feedback rapide est très puissant. On parle souvent des bénéfices que ça a au niveau “métier” / product. Pour itérer et améliorer le produit. Mais ça va plus loin que ça et ça présente des bénéfices nombreux au niveau technique également.

→ Bénéfice 1 : identifier les problèmes tout de suite

Notamment au niveau technique. C’est important car on bosse sur des systèmes complexes. Pour ces systèmes complexes, comme évoqué, on ne peut pas tout anticiper.

Donc voir les problèmes tout de suite est crucial.

→ Bénéfice 2 : capitaliser sur les problèmes rencontrés et générer de la connaissance

En plus, à force d’avoir rencontré plein de problèmes différents, on devient plus armé pour faire face à des situations difficiles. Attention, pour avoir cet effet positif à long terme, il faut documenter et tracer ces épisodes. Sinon on oublie tout.

→ Bénéfice 3 : pousser la qualité à la source

Le fait d’avoir un feedback très rapide entraîne une amélioration mécanique de la qualité, au niveau technique, du code et des fonctionnalités développées. En gros, c’est comme si dès que tu faisais quelque chose, un système te disait direct : c’est bien ✅ ou c’est pas bien ❌

Forcément ça te pousse à orienter ton travail pour avoir plus de ✅ que de ❌

→ Bénéfice 4 : optimiser le travail pour la partie aval du flux

Plus le feedback est rapide, plus ça nous sensibilise également au fait que le travail qu’on produit a des impacts ensuite sur d’autres départements, systèmes, collègues.

Si on repart sur les Dév et Ops. Si on envoie un feedback très rapide aux Dévs, par exemple ta fonctionnalité a créé plein de problèmes quand on l’a déployée. Alors les Dévs vont se rendre compte que :

• Potentiellement leurs erreurs impactent directement les Ops ;

• Symétriquement, qu’en faisant plus attention, ils facilitent le travail des Ops.

La troisième voie - l’apprentissage

Favoriser l’apprentissage à travers une culture saine

💡 D’abord, c’est quoi la “culture” ?

C’est un mot compliqué et qui fait peur ! Ici, on va entendre culture comme l’ensemble des règles implicites ou explicites qui régissent le comportement des personnes dans l’entreprise.

Par exemple :

• Une charte éthique, c’est de la culture

• Le déjeuner d’équipe qu’on fait tous les mercredi à 12h, c’est de la culture

C’est un sujet important car ça va influencer des comportements et donc évidemment, la manière dont on effectue certaines actions. À ce titre, Westrum un scientifique a défini 3 types de cultures :

• (1) Culture pathologique

Bon pas dingue de bosser dans une telle boîte. En gros les comportements sont beaucoup régis par la peur et la menace “je fais ça car j’ai peur de / car on m’a menacé…”

En général, on a tendance à masquer les informations et à les garder pour soi. Soit parce que les mauvaises nouvelles font peur. Soit parce qu’on veut garder dans sa manche une bonne nouvelle pour se sauver.

• (2) Culture bureaucratique

Dans ce cas, les choses sont plus formalisées. Là où en culture pathologique, tout était plutôt implicite, ici on fonctionne avec des règles, des process. Bref des lignes clairement définies à ne pas dépasser.

L’avantage c’est que c’est souvent plus juste. Comme la règle est explicite, si elle est bête, je peux la critiquer et donc pousser pour la supprimer.

En revanche, dans ces organisations, tu ne peux pas dépasser les lignes ce qui va nuire à la prise d’initiative ou à l’innovation. De même tout échec sera mal vu.

• (3) Culture generative

Cette typologie d’organisation est plus positive. On se focalise sur la recherche et le partage d’information. Moins de querelles de périmètres. Tout le monde est orienté vers le même objectif ~ délivrer de la valeur. À ce titre les partages d’information se font plus naturellement dans un objectif de faire progresser l’organisation.

Mécaniquement, ça va aussi privilégier l’innovation, la prise de risque calculée. En effet, tout le monde est aligné sur le fait que ça permet d’améliorer notre efficacité. Ce sont donc des comportements favorisés.

La 3ème voie du DevOps nous pousse donc à aller vers une culture générative afin d’améliorer le potentiel d’apprentissage de notre organisation.

Institutionnaliser l’amélioration du travail au jour le jour

Pour transformer notre organisation en “organisation apprenante”, on veut que l’apprentissage soit un réflexe ! On va faire ça de deux manières :

→ D’abord, sanctuariser des temps dans les agendas pour l’amélioration continue

Toutes les semaines, chaque sprint, de manière récurrente, on prévoit un moment pour que les équipes puissent se focaliser sur des enjeux d’excellence opérationnelle et améliorent leur travail au jour le jour.

Par exemple, on peut dédire un vendredi sur deux à ce sujets. Chacun travaille sur les sujets du quotidien qui lui posent problème afin de les solutionner et de les améliorer.

C’est une manière efficace de faire car rendre ce moment obligatoire, le risque est qu’il y ait toujours quelque chose de plus prioritaire.

→ Ensuite, se focaliser sur les urgences puis sur les plus petits problèmes

De manière assez logique, c’est pertinent de bien prioriser les sujets qui font l’objet d’une amélioration continue.

⇒ Dans un premier temps, on va éteindre les gros incendies et les grands feux. Comme des pompiers. C’est nécessaire car ça ne sert à rien de faire des petites optimisations si tout le reste du produit est en flamme.

⇒ Dans un second temps, on met notre attention sur des plus petits sujets, des problèmes un peu moins sensibles mais qui peuvent dégénérer ensuite si on ne s’en occupe pas. Plus notre radar de problème est fin, plus on progresse et plus on apprend.

Transformer les découvertes “locales” en améliorations “globales”

Dans toute organisation, c’est délicat de s’assurer que l’information circule bien. Quand “un tel” est un expert d’un sujet, comment s’assurer que ses collègues bénéficient de son expertise ?

On va donc essayer le plus possible de passer :

Du tacite à l’explicite

De l’explicite à de la connaissance globale

C’est tout l’enjeu de documenter nos activités d’ailleurs. Le problème : en théorie, tout le monde est d’accord pour dire que c’est important de bien documenter. En pratique, c’est plus difficile.

Deux mécanismes qui facilitent ça :

→ Faire des analyses “post-mortems” (sans bouc émissaire)

Il y a forcément des anomalies et des choses qui ne se passent pas comme prévu. Quand c’est le cas, on réunit les personnes concernées et on fait une analyse, à froid, ce ce qu’il s’est passé.

⚠️ l’objectif n’est pas de trouver un coupable ! Il n’y a pas de coupable. Il y a juste des processus qui peuvent être améliorés. Et ces post-mortems permettent de définir les pistes d’amélioration de ces processus.

En plus, c’est par ce type de réunion qu’on rend la connaissance explicite et transcrite dans des documents.

→ Créer des procédures / check-lists pour les activités récurrentes

Dans la vie d’une organisation, on fait souvent face à des tâches récurrentes. Quand c’est le cas, il est pertinent de créer des procédures ou des check-lists pour s’assurer que la prochaine personne de la boîte qui fera face au problème… aura les idées claires sur quoi faire !

Par exemple, quand un collaborateur arrive dans l’entreprise, il y a souvent différentes choses administratives à faire. C’est un très bon prétexte pour faire une check-list afin que les actions à faire pour chaque arrivée de collaborateur soient les plus claires possibles.

Mettre en place des éléments pour renforcer notre résilience dans le travail de tous les jours

Quand on commence à progresser dans le DevOps et que notre organisation est de plus en plus mature, on risque de se détendre et de perdre l’enthousiasme / l’envie du début. Un peu comme un sportif qui finit par se lasser un tout petit peu une fois qu’il a gagné plein de titres et qu’il fait partie des meilleurs.

Afin de ne pas trop rentrer dans une zone de confort, voici 2 actions à mettre en place.

→ Continuer à définir des objectifs de + en + ambitieux

On peut toujours faire mieux ! S’agissant de la technique, on va donc identifier des indicateurs qui vont nous challenger pour être encore meilleur. Ça peut être :

• La durée de déploiement

• Le nombre d’anomalies

• La couverture du code par des tests

Ce genre d’objectifs va nous garder sous tension. Un peu comme un coureur de fond qui se fixerait toujours de nouveaux objectifs plus exigeants pour courir plus vite et plus longtemps.

→ Avoir un “growth mindset”, pour toujours progresser et être encore plus fort

Encore une fois, l’idée c’est de ne pas rester dans sa zone de confort. Et puisqu’on commence à être très à l’aise, on va s’auto-fixer des contraintes pour continuer à s’améliorer.

C’est ce qu’a fait Netflix avec le Chaos Monkey

💡 Le Chaos Monkey

Pour avoir des équipes les plus résilientes possibles, Netflix a créé un jeu / exercice appelé le “Chaos Monkey”.

Ce Chaos Monkey est un bug créé par Netflix, qui va se propager dans leurs systèmes. Pour étudier comment les équipes réagissent et les entraîner à collaborer pour trouver les bonnes solutions le plus vite possible.

Ce qui est sympa avec cette approche : il y a un côté ludique. C’est comme un jeu ! En revanche, le jour où ça arrive dans la vraie vie, on est prêt à réagir.

---

Mettre en place le DevOps

Les fondations

Un terrain favorable

Le DevOps représente une grande évolution / transformation. Pour que ça fonctionne il faut préparer le terrain en amont pour que les efforts ne soient pas faits en vain.

→ S’assurer que tous les environnements sont iso-production

Quand on développe des applications, on les installe sur des serveurs pour que celles-ci soient accessibles à tous (encore une fois “serveur de production” ou environnement de production = le serveur ou environnement auquel accède l’utilisateur final).

Pour autant, quand on développe une nouvelle fonctionnalité, on ne va pas directement l’installer en production. On va regarder si ça fonctionne sur d’autres environnements avant ! Pour éviter que l’utilisateur ait de mauvaises surprises.

C’est comme une répétition générale avant un spectacle !

Un prérequis important du DevOps est que ces environnements pour faire des répétitions ressemblent le plus possible à l’environnement de production (iso-production). Ça va nous permettre de repérer beaucoup plus vite les problèmes potentiels.

→ Sensibiliser les équipes Produit au fait de tester en environnement iso-production

Au delà d’avoir à disposition ces environnements “iso-prod”, c’est important que les équipes Produit comprennent l’importance de tester dans ces environnements.

Quand on développe des fonctionnalités, on a parfois tendance à essayer de faire marcher ça “au chausse-pied” sur un environnement de développement. En général, ces environnements sont vraiment là pour faire des tests préliminaires mais sont très différents de l’environnement de production.

Il ne faut surtout pas s’arrêter à avoir validé le développement dans ce type d’environnement ! Si ça marche sur le PC du dév, c’est cool, mais c’est pas à ce PC que va accéder l’utilisateur final.

⇒ On se fixe cette exigence : pour valider la fonctionnalité, elle doit avoir été testée dans un environnement le plus semblable possible à la production.

→ Rendre l’infrastructure plus facile à reconstruire qu’à réparer

Comme on le voit, la “représentativité” des environnements est cruciale. Il faut que le plus possible, ces environnements soient similaires à celui de production.

Pour autant, souvent la situation suivante se passe dans la vraie vie :

• D’abord on crée un environnement de qualification, de test, qui ressemble à fond à la production !

• Puis le temps passe, et on fait des modifications sur l’environnement de production, sans les répercuter sur celui de test…

• … mais aussi des modifications sur l’environnement de test qui ne correspondent pas à des évolutions de celui de production

• Bref au final, c’est plus complètement représentatif !

Ces choses là arrivent. L’enjeu dans ces cas là, c’est d’être capable très facilement de détruire l’environnement de test pour le recréer comme neuf, à l’identique de la production.

Mettre en place une stratégie fiable de test automatique

DevOps nous pousse à mettre en place des tests automatiques. Et on va voir qu’une telle stratégie est précieuse et pertinente.

Ça apporte :

→ Un produit mieux conçu

Avec des tests autos "par construction", le produit est mieux découplé. Un avantage inestimable pour créer de nouvelles fonctionnalités à long terme.

→ Des fonctionnalités faciles à déployer

Avec un truc bien conçu et des tests automatiques, c'est FACILE de passer de l'idée à se mise en production, on peut vite et facilement voir si la fonctionnalité fait ce qu’on veut et si elle pose des problèmes à d’autres endroits de l’application. C'est une agilité hyper précieuse.

→ Finis les tests manuels

L'ordi se débrouille très bien pour faire des tests simples, répétitifs. Ça dégage du temps au PM pour se focaliser sur les tests complexes, rares et bizarres (0,01% mais avec un fort pouvoir de nuisance).

→ Beaucoup moins de régressions

Et puis comme l'ordi est aussi plus rapide, plus précis et plus exhaustif, il fait moins d’erreurs. Donc on réduit le risque d’avoir une régression cachée.

Deux bonnes pratiques à avoir en tête.

Premièrement, s’assurer que les tests vont vite ! Si ça va trop lentement, on va avoir la flemme d’attendre leur résultat. Et donc on va skipper. Problème, le code devient moins fiable. On checke moins régulièrement etc…

Deuxièmement, écrire les tests automatisés avant d’écrire le code. L’avantage c’est que comme ça, les tests arrivent “gratuitement”, presque mécaniquement. En plus, ça nous permet de vérifier le code au moment où il est créé.

Automatiser les déploiements pour réduire le risque d’anomalies

De la même manière qu’on a automatisé au maximum les tests, on va automatiser au maximum les déploiements.

🤔 Pourquoi est-ce pertinent ?

Un déploiement c’est toujours une action sensible. Encore une fois, on installe une nouvelle version de l’application à un autre endroit. Et parfois tout ne se passe pas comme prévu. Juste parce qu’installer une application est un processus complexe.

Alors si en plus on rajoute un paramètre humain, on introduit un risque que la personne chargée de la mise en production fasse une erreur, ce qui renforce le risque que cette opération complexe échoue.

En automatisant, on rend l’action beaucoup plus prévisible et moins risquée.

Attention, ça ne veut pas dire pour autant qu’on va faire changer tout le temps l’application auquel accède l’utilisateur.

C’est ce qu’on appelle distinguer les déploiements des releases.

💡 C’est quoi une release ?

C’est un déploiement en production particulier.

Quand on a développé un certain nombre de fonctionnalités, ça peut faire du sens de les regrouper en tout cohérent. On parle souvent de “version” dans ce cas : et on va faire une “montée de version”.

L’avantage de faire ça, c’est que ça évite que l’utilisateur voie tout le temps les fonctionnalités changer. Imagine si tu dois télécharger une nouvelle version d’une de tes applis iPhone 3 fois par jour…

Du coup :

→ Oui on déploie très souvent en production / sur un environnement iso-prod

→ En revanche, on ne donne pas accès systématiquement à la fonctionnalité à l’utilisateur

Pour faire ça, on va introduire des “interrupteurs à fonctionnalité” (feature toggle en anglais). Je déploie en production la fonctionnalité pour autant je laisse l’interrupteur en inactif. Donc elle est là en production sans que l’utilisateur puisse la voir. Je vais pouvoir la tester mais sans prendre le risque qu’elle soit dysfonctionnelle et que l’utilisateur le voie.

Transformer l’organisation

Mettre en place de nouvelles manières de travailler n’est jamais facile. Dans toute organisation et quelle que soit l’innovation qu’on introduit.

En préalable, je te conseille de lire la dernière partie de ma newsletter EasyTech #13 Devenir un PM exceptionnel. Elle explique bien comment choisir le premier projet sur lequel partir et commencer organiser la conduite du changement.

Voici maintenant quelques spécificités à avoir en tête en matière de DevOps.

L’organisation d’une entreprise a une influence importante sur son système d’information

C’est ce qu’on appelle la loi de Conway !

Quelques illustrations de conséquences de cette loi :

→ Si j’ai un département avec les développeurs front-end et un département avec les développeurs back-end. Alors, de manière naturelle et logique, le front-end sera forcément découplé du back. On développera peu d’applications en mode “full-stack”. Ça présente des avantages (moins de dépendances entre les deux parties de l’appli) et des inconvénients (besoin de se synchroniser pour faire évoluer le produit)

→ Si j’ai un département “Développement” et un département “Opérations”. Alors de manière naturelle et logique, les Ops parleront plus souvent entre eux qu’avec les Développeurs. Ce qui veut dire, plus de difficultés à se coordonner, à se comprendre etc… Autre conséquence, moins facile de mettre en place du DevOps dans ce genre d’organisation

La recommandation en général pour ne pas subir cette loi de Conway, c’est d’orienter son entreprise / organisation pour qu’elle soit orientée vers “la valeur” délivrée à l’utilisateur.

→ ❌ on évite de silotter les différents départements dev / ops / q&a-test / business / marketing etc…

→ ✅ on regroupe tout le monde dans des équipes pluridisciplinaires qui peuvent faire évoluer l’application rapidement

On peut trouver des “quick wins” pour recréer le lien rapidement entre Dev et Ops

Pour contrer la loi de Conway, on peut facilement créer plus de lien entre les Dev et les Ops. La logique sous-jacente, c’est d’intégrer les Ops dans le processus de développement des dévs. Ils seront plus impliqués et présents.

Voici trois idées pour le mettre en place.

→ 1️⃣ Faire venir les Ops aux rituels des Dev

C’est pas trop dur à faire, et ça va déjà permettre d’améliorer la communication et de fluidifier les relations. Si les développeurs bossent en agile, alors il y a beaucoup de réunions, de cérémonies et de rituels.

C’est intéressant de convier les Ops à certains.

Par exemple :

• Les points d’avancement en cours de sprint, pour que les Ops puissent être sensibilisés aux enjeux du moment

• Les démonstrations de fin de sprint, pour que les Ops puissent voir ce qui va bientôt arriver en production

→ 2️⃣ Avoir un représentant Ops dans chaque équipe de développement

C’est la solution idéale, la plus efficace.

On est en train d’utiliser la loi de Conway à notre avantage :

si organisation ⇒ technique

alors modifions l’organisation pour améliorer la technique.

Pour ça on met directement des Ops dans les équipes de développement.

Il y a plusieurs manières de faire :

• Un ingénieur spécialisé Ops / DevOps dans chaque équipe, qui a la responsabilité de s’assurer que l’équipe ait des environnements disponibles pour bosser, que les procédures de déploiement automatique fonctionnent, que tout est en place pour créer des tests automatiques… L’avantage : avec un expert en charge, on va trouver plein d’idées d’optimisation. L’inconvénient : quand l’expert est malade, en vacances ou sous l’eau, ça traîne…

• C’est pour ça que je préfère la 2ème solution : responsabiliser les développeurs sur le fait de réaliser les actions Ops. Typiquement, ce sont les développeurs qui vont faire eux mêmes les déploiements sur les différents environnements. Ce sont les développeurs qui s’assureront de bosser sur des environnements iso-prod etc. Évidemment, on garde toujours une équipe / un département avec les experts Ops. Car il y a des sujets trop complexes pour les faire gérer par les autres.

Je suis d’ailleurs fermement convaincu que l’avenir de la tech se joue avec des équipes dans ce genre : plutôt avec des profils pluridisciplinaires qui savent faire plein de choses (design, dev front, dev back, devops…) L’avantage de ces équipes, c’est qu’elles peuvent très rapidement livrer des fonctionnalités en production et apporter de la valeur. Ça n’a pas de prix.

→ 3️⃣ Mettre un responsable de la liaison avec les Ops dans chaque équipe

C’est la solution dégradée.

Parfois, les développeurs n’ont pas le temps ni l’envie de progresser sur les sujets Ops. Parfois, les Ops n’ont pas envie que les développeurs marchent sur leurs plate-bandes.

Bref, il faut trouver autre chose.

C’est là que cette solution est un bon compromis. On va nommer un des membres de l’équipe, typiquement un développeur plutôt sachant sur les sujets Ops,

Il va être responsable de :

• préparer les déploiements et mises en production

• tenir au courant les équipes Ops

Au delà de ces tâches, il initie un premier contact avec les Ops. On n’oublie pas que le DevOps est justement une manière de réconcilier les Dev et les Ops. Or, souvent ce genre de problématiques est très liée à des enjeux humains au final. Ça contribue à progresser sur ce plan directement.

D’ailleurs, c’est certes une stratégie “dégradée”. Mais, ça peut être une étape intermédiaire avant d’aller vers une solution plus ambitieuse avec des équipes “full-stack” embarquant des développeurs capables de réaliser des activités d’exploitation / opération.

---

Voilà ! C’est fini pour ce cours sur le DevOps. J’espère que ça t’a plu 😃

Conclusion

On se retrouve la semaine prochaine pour le prochain numéro !

Merci de m'avoir lu 🙏

Si tu es trop impatient pour attendre, tu peux :

• Me contacter pour échanger sur le DevOps mail ou par message LinkedIn 💪

• M'envoyer des feedbacks sur ce numéro, positifs... ou négatifs bien sûr ! C'est comme ça qu'on progresse 💪

• Partager la newsletter à des personnes susceptibles d'être intéressées 💪

Bon courage pour la semaine 😃

Victor