DevOps

Une équipe de développement typique dans le monde de %LVD% : 7
        personnes + experts pour des besoins ad hoc (DBAs, Sécurité,
        Architectes, %...%)
Une équipe de développement typique dans le monde de %LVD% : 7 personnes + experts pour des besoins ad hoc (DBAs, Sécurité, Architectes, %...%)

La notion de %DevOps% dans le contexte Agile est encore nouvelle et peu d'entreprises ont encore adopté ce paradigme. Ce n'est qu'à partir de 2008 que cette notion a commencé à se frayer un chemin dans les services IT. En 2011, ceux qui étaient investis dans l'Agilité ont contribué à répandre le concept. Depuis 2012-2013, il s'est propagé linéairement pour percoler dans toutes les entreprises qui ont entamé des transitions agiles et donc souvent aussi digitales. Pourtant, nous manquons encore de matériel objectif et concret pour théoriser le concept, même si, au demeurant, la théorie est beaucoup plus mature que la pratique. Les succès techniques et commerciaux de géants du secteur technologique apportent néanmoins la démonstration de la validité des idées défendues par %DevOps% dont plus personne ne peut ignorer qu'il est à l'œuvre dans la réussite de Netflix, dans le triomphe d'Amazon, dans la fortune de Google, dans les outils notamment enfichés dans la suite Azure de Microsoft. C'est un raz-de-marée qui rend enthousiastes tous les thuriféraires de l'intelligence %DevOps%.

%DevOps% est une notion importante dans %LVD%, aussi cardinale que les 5 piliers, que la colonne vertébrale digitale, que le mode %KAN%.

Cette notion %DevOps% est à l'œuvre dans toutes les Transformations Digitales car, comme j'aime le rappeler, toutes s'arcboutent sur la %...% digitalisation [1] . Parler des aspects théoriques et d'organisation est certes utile, fondamental même, mais si l'on ne met pas en place les actions concrètes de terrain rien ne se cristallise ce qui réduit les %tds% à un ensemble de schémas et de PowerPoint qui n'atteignent ainsi aucun objectif tangible. J'aime renvoyer les organisations au tableau de %AUTHOR.Magritte%, Ceci n'est pas une pipe dont le sens général est de distinguer un objet de sa représentation. Ainsi donc, pour %LVD%, les schémas, les textes et les slides PowerPoint illustrent les %tds% mais ne peuvent être pris pour elles. Toute représentation trahit l'objet représenté et aucune ne peut en donner le goût véritable.

Les méthodes Agiles habituelles ont pris le contrepied des méthodes traditionnelles en rassemblant les métiers appelés à collaborer en vue de la réalisation d'un objectif final. Là où la division scientifique du travail a séparé les métiers, les méthodes Agiles les réassemble. En cela, elles sont le résultat d'un papier parfaitement fondateur signé par %AUTHOR.Takeuchi% et %AUTHOR.Nonaka% : %BOOK.The New New Product Development Game%, article qui est le tout premier à présenter le rugby comme une analogie intéressante s'appliquant aux projets qu'ils ont étudiés. C'est aussi dans cet article qu'apparaît pour la première fois le terme Scrum dans l'acception qu'il revêt dans l'arsenal Agile.

Les méthodes Agiles rassemblent les programmeurs, les testeurs (AQ globale) et les utilisateurs. C'est déjà une grande amélioration par rapport aux méthodes plus traditionnelles, mais cela n'englobe pas encore l'ensemble du système. Le problème à résoudre — et il est tellement répandu qu'on peut presque affirmer qu'il est totalement généralisé — c'est le fossé qui est apparu entre ceux qui créent les solutions et ceux qui les font vivre, qui les maintiennent et les réparent, le fossé entre Construction / Développement [2] et Maintenance%/%Opérations.

Il y a 30 ans, beaucoup des métiers de l'informatique n'existaient pas de manière différenciée%%: on était programmeur, analyste et %...% opérateur tout à la fois. C'est avec la multiplication des machines qu'il n'a plus été possible pour les informaticiens de tout faire avec des casquettes différentes. La tendance n'a fait que se renforcer avec le temps donnant ainsi lieu au métier d'opérateur. Ce fut le moment de la grande césure entre Développement d'un côté et Opérations de l'autre. La césure a sécrété un problème majeur%%: la ségrégation des préoccupations des uns et des autres. Désormais, les informaticiens s'occupaient de créer et les opérateurs de maintenir sans se préoccuper des soucis de l'autre groupe.

C'est cet exact problème qu'il est nécessaire d'adresser avec le JTBD (Job To Be Done) en tête, avec le ravissement des clients en bille, avec le souci de cohésion et l'esprit d'équipe nécessaire à l'épanouissement de la force de travail. C'est la raison pour laquelle %LVD% fait belle place à la notion de %DevOps% considéré comme un moyen de pousser le concept d'Agilité à inclure les Opérations dans la vue d'ensemble, ce qui permet de combler le fossé avec la Production (au sens informatique) et de mettre fin aux équipes isolées.

%DevOps% étend l'horizon de l'Agilité
%DevOps% extends the horizon of Agility

%DevOps% est un moyen de créer la boucle de rétroaction nécessaire entre la production et la conception / construction. Il s'agit de l'unification du développement, de la livraison et de la maintenance / support, mettant fin à ce mur qui sépare les deux mondes%%: les logiciels ne doivent plus être jetés par-dessus le mur et laissés à d'autres personnes pour qu'elles les fassent fonctionner. %DevOps% est l'incarnation de la loi du karma%%: tout ce que vous avez fait de mal ou de bien vous reviendra à un moment donné. Pour les développeurs, c'est l'occasion de s'approprier réellement leur code et de faire avancer le point final (jusqu'aux opérations).

En ayant une équipe agile qui prend soin de ce qu'elle a produit, non seulement en le construisant, mais aussi en le livrant et, plus tard, en le rendant plus mature (maintenance perfective) et plus robuste (opérationnalité accrue), nous jetons les bases du principe de responsabilité de bout en bout.

Pour paraphraser %AUTHOR.Melinda Ballou%, il ne suffit pas de faire des bébés et de les mettre au monde, il faut aussi les élever, les éduquer. C'est le sens de la parenté. C'est ce que je mets en avant avec les équipes de développement de type %DevOps% avec %LVD%.

La théorie du jeu postule que 2 joueurs ont intérêt à collaborer lorsque la probabilité qu'ils se rencontrent à nouveau est élevée, ce qui s'exprime par le facteur %OMEGA% (ou défini plus poétiquement comme l'ombre du futur %--% shadow of the future).

Lorsque tous les membres de l'équipe se trouvent dans une seule grande pièce, les informations de quelqu'un deviennent les vôtres, sans même essayer. Vous commencez alors à réfléchir en termes de ce qui est le meilleur pour le groupe dans son ensemble, ou en termes d'alternatives, et pas seulement pour vous-même. Si chacun comprend la position de l'autre, alors chacun d'entre nous est plus disposé à céder, ou du moins à essayer de se parler. Des initiatives peuvent alors émerger. %--% When all the team members are located in one large room, someone's information becomes yours, without even trying. You then start thinking in terms of what's best or second best for the group at large and not only about where you stand. If everyone understands the other person's position, then each of us is more willing to give in, or at least to try to talk to each other. Initiatives emerge as a result.

%--% %AUTHOR.Hirotaka Takeuchi% and %AUTHOR.Ikujiro Nonaka% in %BOOK.The New New Product Development Game%

Il me vient plusieurs exemples personnels très réels dans lesquels il eut mieux valu être organisés en mode %DevOps%. Je vous en livre deux issus du même contexte.

Cas 1

Développant la plateforme Internet & Mobile Banking d'un groupe bancaire français, l'équipe était particulièrement satisfaite de ce grand moment qui visait la mise en production généralisée de la solution, un grand moment préparé avec soin pour que la nouvelle solution soit disponible sans aucune interruption de service. Les meilleurs spécialistes de Paris avaient convié les meilleurs spécialistes de Bruxelles et tout ce beau monde était prêt à poser les actes qui avaient été souvent répétés avant le moment fatidique. La seconde du grand basculement arrive et %...% tout se passe comme espéré%%! C'est formidable. Le champagne coule et l'anxiété fait place au soulagement. Gavés de petits fours, la bouche pleine de sourires, l'équipe de Bruxelles se met tout doucement en ordre de retourner vers la Belgique quand une alerte se fait entendre après 1h ou 2h de fonctionnement fluide. C'est un opérateur de Paris qui s'étonne d'une forme de ralentissement d'une des fermes de serveurs. Tout le monde fait mine de s'y intéresser de manière affairée mais au fond parfaitement distraite. Quel est ce grain de sable qui grippe la machine%%? Le phénomène échappe à la reconnaissance d'un problème classique; il est inexplicable et %...% il commence maintenant à se répercuter sur la deuxième ferme de serveurs ce qui commence à sérieusement inquiéter ceux qui étaient restés fêter le digne événement. Il ne faut qu'une partie du temps pour que le problème infecte maintenant la troisième ferme (il y en avait 4 pour un total de 84 serveurs) et avant qu'on ne connaisse la nature du problème la 4ème ferme est à son tour touchée, tombe et fait s'effondrer tout l'édifice. Nous sommes à ce moment-là sans plateforme bancaire pour le grand public, une situation parfaitement gênante. Les plans de rollback sont déroulés ce qui permet de rétablir le service, l'ancien banking. La perturbation aura été réelle, certes, mais temporaire. La cause%%? Des traces%/%logs qui ont complètement rempli l'espace disque%%! Ni plus, ni moins%%! L'espace disque devenu rare, les activités de garbage collection étaient devenues singulièrement plus lentes jusqu'à rendre indisponible la première ferme. La charge étant alors repartie sur 3 fermes au lieu de 4, chacune était maintenant sollicitée davantage générant le même comportement que celui observé pour la ferme #1 mais plus vite. Le reste de l'histoire se devine aisément%%: une deuxième ferme tombe et le problème se reporte sur celles qui restent, accélérant de plus belle.

Quel est le lien avec %DevOps% ? C'est très simple%%: si nous avions embarqué les opérateurs dans le processus de développement, le problème se serait présenté bien avant, et sur des environnements de test au lieu de la production. À l'heure H, nous n'aurions pas connu cette déconvenue assez frustrante.

[%...%] si nous avions embarqué les opérateurs dans le processus de développement, le problème se serait présenté bien avant, et sur des environnements de test au lieu de la production.

Cas 2

Le cas 2 est finalement la suite du cas 1. Les traces étaient générées par des appels à une fonction unique%%: le code en était truffé. Il y avait bien une paramétrisation possible, on ou off, mais sans aucune autre granularité que celle d'un système binaire. L'équipe de développement s'est alors saisie du sujet et a fait œuvre de finesse dans la manière de générer des traces en utilisant une sorte d'Error Level. Plus le niveau était élevé, plus les traces étaient abondantes. Parfait.

Un nouveau jour J a alors été décidé entre Paris et Bruxelles, un nouveau déploiement, bien moins festif que le premier, question de mauvaise expérience passée j'imagine. Ce nouveau déploiement a été un succès. Aucun doute là-dessus. Cependant%...%

La nouvelle plateforme est donc disponible et est maintenant active depuis 1 ou 2 mois quand nous recevons un message inquiétant ramené au support technique parisien par un client qui a vu des mouvements affichés dans son relevé d'opérations n'appartenant pas à son compte (juste l'affichage, heureusement). Que s'était-il passé%%? C'est justement dans cette enquête que je puise mon deuxième exemple DevOps%%[3] : les opérateurs parisiens voulant retracer les opérations effectuées par le client pour déterminer la cause du problème en étaient réduits à consulter 84 fichiers de logs différents, 1 par serveur, si bien que suivre la totalité d'une opération de A à Z impliquait des recherches archéologiques synchronisées sur 84 sites différents, avec le début de l'opération sur la machine X, la suite en ordre dispersé sur d'autres machines et la fin sur la machine Z. L'enfer%%! Là encore, aurions-nous été structurés en mode DevOps que nos opérateurs nous auraient tout de suite informés de la complexité du suivi des logs. Nous aurions évité une nouvelle frustration et une frayeur peu commune qui a d'ailleurs nécessité un retour temporaire à l'ancienne plateforme et à une forme de compromission de la confiance de Paris à l'égard de Bruxelles%%!

Conclusion

En incorporant les opérateurs dès le développement de la solution, %cad% dès la collecte des exigences, vous vous épargnez bien des frustrations et désillusions ultérieures parce que vous aurez pu anticiper les problèmes qui ne seraient finalement jamais apparus, du moins pas en production, là où ils coûtent jusqu'à 500 fois plus chers à résoudre.

C'est ce qu'%AUTHOR.Yves Morieux% et %AUTHOR.Peter Tollman% ont exprimé dans leur excellent livre %BOOK.Six Simple Rules, How to Manage Complexity without Getting Complicated%. La règle numéro cinq%%: Extend the Shadow of the Futrure. Cette règle crée des boucles de rétroaction en exploitant l'effet du temps. C'est une observation sacrément simple pour comprendre l'importance de ce qui se passera demain suite à ce que nous faisons aujourd'hui. Par conséquent, nous devons créer les boucles qui font que les gens ressentent les conséquences de la façon dont ils gèrent les choses aujourd'hui. J'aime cette façon de le représenter%%: faire en sorte que les gens marchent dans les chaussures qu'ils fabriquent pour les autres.

En incorporant les opérateurs dès le développement de la solution, %cad% dès la collecte des exigences, vous vous épargnez bien des frustrations et désillusions ultérieures parce que vous aurez pu anticiper les problèmes qui ne seraient finalement jamais apparus, du moins pas en production, là où ils coûtent jusqu'à 500 fois plus chers à résoudre.

Selon %AUTHOR.Morieux% et %AUTHOR.Tollman%, ces boucles de rétroaction sont bien plus préférables et efficaces que l'utilisation de la supervision, des métriques et des incitants. C'est ce que %DevOps% apporte à l'organisation et le sentiment d'accomplissement dans L(i)VID.

Tout cela est ce qu'on appelle Shift Left, comme décrit ci-dessous%%:

%DevOps% étend l'horizon de l'Agilité en rapatriant des préoccupations
des opérateurs dès les premières étapes du développement
Le paradigme %l"%Shift Left%r"% : les préoccupations des opérations migrent vers la gauche pour désormais s'intégrer à la conception%/%construction

You Build It; You Run It!

%AUTHOR.Werner Vogels%, Amazon, l'a dit en des mots simples et parfaitement efficaces%%:You build it, you run it (Enterprise DevOps: Why You Should Run What You Build | AWS Cloud Enterprise Strategy Blog).

Il s'agit là pourtant d'une véritable difficulté de mise en oeuvre pour nombre de grosses entreprises organisées sur une informatique plus traditionnelle.

Vertues attendues

Production-ready

Lorsque les équipes doivent opérer elles-mêmes les solutions qu'elles développent et lorsqu'elles sont secondées par des ingénieurs de l'exploitation le code informatique produit contient d'emblée les éléments qui vont faciliter les opérations de maintenance et de contrôle. Ce sont les cas #1 et cas #2 dont je parlais ci-avant. Les considérations principales des Ops sont prises en compte dès la collecte des besoins, et elles font l'objet de tests. Elles sont donc éprouvées d'abord dans des environnements où les dégâts occasionnés sont mineurs. Le temps agit également comme révélateur et lisseur%%: plus le cérémonial se répète, plus de problèmes sont révélés, souvent d'ailleurs de manière notablement fortuite, sont adressés et résolus et ensuite contribuent à immuniser les développements futurs.

Résolution AVANT problème

Quand les problèmes de production deviennent aussi les problèmes de l'équipe qui a développé les solutions, on assiste à une forme de créativité préventive%%: on crée des procédures qui vérifient l'espace disque, la mémoire disponible, la charge sur l'application, on invente des messages de service, %...% Les programmeurs ADORENT ça%%! Ils ont l'impression de créer des objets vivants. À l'utilité ils joignent l'agréable.

Transparence

Personne ne veut que son temps personnel soit interrompu. Celui qui prend les appels fera tout son possible pour éviter de les recevoir en premier lieu. Vos équipes souhaiteront naturellement une plus grande transparence dans l'environnement et mettront en place un suivi proactif afin de pouvoir identifier les problèmes ou les tendances inquiétantes avant qu'ils ne se généralisent. En plus de permettre de détecter les problèmes avant qu'ils ne se produisent, ce type de transparence devrait permettre de trouver beaucoup plus facilement les causes profondes des problèmes qui persistent.

Autonomie et sens

Être au contact direct du client est une expérience dont bien des informaticiens n'ont jamais fait l'apprentissage. C'est très enrichissant et très responsabilisant. Cela donne du sens au travail réalisé et fait prendre conscience que le code informatique produit est un objet vivant dont le client se saisit pour effectuer un travail qui, pour lui, est important. C'est son JTBDJob To Be Done à lui. Cela augmente aussi l'autonomie de chaque membre de l'équipe, ce qui n'est pas sans rappeler le concept MAPMastery, Autonomy, Purpose.

Dev et Ops%%: le mur tombe

La compréhension des problèmes des autres (utiliser soi-même les chaussures qu'on fabrique pour les autres) c'est faire tomber le mur entre les Ops et les Devs. La compréhension va dans les deux sens et ne se limite pas à l'entendement des objectifs des autres mais aussi de leurs contraintes. Les gens se parlent et continuent à se parler par la suite, pour d'autres activités. La communication quitte de plus en plus le formel et migrent vers l'informel.

Qualité opérationnelle; problèmes en baisse, satisfaction et confiance en hausse

Comme le disait Adrian Cockcroft, les développeurs détestent être dérangés à 3 heures du matin. Les problèmes sont anticipés avant leur apparition (alertes générées en console avec interventions préventives) ce qui diminue sensiblement le nombre d'incidents.

La satisfaction de l'utilisateur final s'en trouve améliorée et avec elle sa confiance dans l'entreprise. Une autre confiance est en hausse%%: celle du Business vis-à-vis de l'IT.

Automatisation

Les développeurs détestent les tâches manuelles répétitives, donc s'ils découvrent qu'ils doivent faire quelque chose encore et encore en production pour résoudre un problème, ils ont l'envie d'en trouver la cause et d'automatiser la solution. J'ai même vécu l'expérience d'un groupe qui, au contact d'un API de virtualisation, s'est trouvé à engager des appels pour %...% augmenter la mémoire dévolue à la machine virtuelle sur laquelle leur appli tournait, à augmenter la puissance des processeurs, leur nombre, l'espace disque, etc. puis à relâcher les ressources quand elles n'étaient plus nécessaires. Les développeurs ADORENT automatiser et, soyons de bon compte, les ordinateurs sont des machines à automatiser%%!

Qui est de garde%%?

Le succès de Netflix est planétaire. Ce succès, la société le doit à sa grande maîtrise technologique qui lui a permis de migrer d'une entreprise de location de vidéos pour être aujourd'hui l'une des plateformes leader de services de streaming. En matière de %TD%, je pense que nous avons là l'exemple archétypal%%!

Un des architectes, sinon THE Architect, qui a été mis à contribution pour entamer la grande migration d'une infrastructure dédiée, avec ses propres centres de données, vers une architecture Cloud est %AUTHOR.Adrian Cockcoft%. Il s'exprime ici sur le mouvement %DevOps% et ce qui a été le positionnement de Netflix sur le sujet%%:


( ! ) Fatal error: Uncaught Error: Class 'trql\tag\Tag' not found in D:\websites\lvid.org\www\httpdocs\content\devops.html on line 509
( ! ) Error: Class 'trql\tag\Tag' not found in D:\websites\lvid.org\www\httpdocs\content\devops.html on line 509
Call Stack
#TimeMemoryFunctionLocation
10.0007358592{main}( )...\index.html:0
20.0013359152include_once( 'D:\websites\lvid.org\www\httpdocs\index.html' )...\index.html:2
30.0026455416include_once( 'D:\websites\lvid.org\www\httpdocs\template\lvid.html' )...\index.html:2
40.11362742840getFileContent( )...\lvid.html:251
50.11562898136include_once( 'D:\websites\lvid.org\www\httpdocs\content\devops.html' )...\lvid.html:353