DevOps

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.

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.

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.

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 JTBD — Job To Be Done à lui. Cela augmente aussi l'autonomie de chaque membre de l'équipe, ce qui n'est pas sans rappeler le concept MAP — Mastery, 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%%: