Accueil Technologie Devops : on ne recrute pas une philosophie

Devops : on ne recrute pas une philosophie

0
18
Devops : on ne recrute pas une philosophie

Revenons aux bases du devops. Ce mot-valise est la contraction de dev, les équipes de développeurs qui éditent nos applicatifs, et de ops, c’est à dire ceux qui les exploitent en production – les exploitants ou administrateurs systèmes en français. Ces deux types d’équipes ont fondamentalement des motivations orthogonales : les premiers visent à faire de nombreux changements pour faire évoluer leurs applicatifs alors que les seconds recherchent la stabilité, donc le moins de changements possible. Ce rapprochement a pour but d’encourager et de permettre à ces équipes de mieux collaborer et de casser les silos historiques qui les séparent, afin d’optimiser la création de valeur pour leur organisation – difficile à faire quand on est une seule personne, donc…

devops, c’est quoi alors ?

devops, ce n’est donc ni une technologie, ni une personne. C’est une culture, une méthodologie. Et elle fait beaucoup parler d’elle : les éditeurs n’ont que ce mot là à la bouche, les conférences devops se multiplient – pas moins de 71 conférences devopsdays ont lieu à travers le monde en 2017, en France devops REX rassemble 800 participants, et le Paris Open Source Summit de décembre réoriente toute sa partie « Tech » autour de devops – et les entreprises se transforment et le disent haut et fort – des startups en hyper-croissance jusqu’aux plus grands groupes, y compris ceux qu’on croyait les plus ancrés dans la tradition.

Où sont les supposés gains de cette méthodologie ? En un mot, partout. Selon les retours d’expériences et les études, on déploie de nouvelles versions applicatives plus rapidement, avec moins d’incidents, on gère plus de machines avec moins de personnes, ces personnes sont simultanément plus heureuses, plus efficaces et moins stressées, et en plus les divisions informatiques réagissent plus vite et réalisent des économies !

En chiffres, on parle de déploiements complètement automatiques jusqu’à 46 fois plus fréquents, de temps de changement jusqu’à 440 fois plus rapides, de temps de résolution d’incidents jusqu’à 96 fois plus courts. Rien que cela ! Cela met l’eau à la bouche, n’est-ce pas ? Alors pourquoi toutes les entreprises n’ont-elles pas embauché des dizaines de devops ou acheté la technologie magique qui va 440 fois plus vite ?

L’ingrédient secret

Quand on écoute les témoignages de ceux qui y sont arrivés, les histoires se ressemblent : on réunit tous les ingrédients (des outils, de l’automatisation, des métriques, du continuous quelque chose voire des devops) mais cela ne suffit pas. Les outils changent, mais les habitudes restent, les gains sont certes là mais restent minimes. Tout bascule quand on trouve la clé magique, ce liant tant recherché, qui d’un coup nous apparaît telle une évidence. Cette clé, c’est toujours la culture. Culture du changement, volonté de coopération, motivation intrinsèque de chacun, support du management, … peu importe comment ça démarre, tant qu’il y a une étincelle, le reste suivra.

On pourrait débattre des heures de comment promouvoir au mieux cette culture dans chaque entreprise. Les idées ne manquent pas – envoyez vos dév et vos ops manger une pizza deux par deux aléatoirement, organisez une journée de serious gaming pour les faire prendre conscience des métiers les uns des autres, ou encore créez une équipe de volontaires qui a carte blanche pour faire différemment et qui doit partager ses apprentissages – le mode d’emploi générique n’existe pas, et vraisemblablement n’existera jamais. Chaque organisation est unique, c’est ce qui fait sa force, mais c’est aussi pour ca que chaque transformation devops doit être une réflexion nouvelle.

Comment appeler les personnes qui y travaillent alors, sinon des devops ?

Vu que tout le monde doit y collaborer, on n’a qu’à dire collègue – cela n’a plus aucun sens, on est bien d’accord. Regardons plutôt le vrai rôle de chacun et parlons de coachs devops, d’experts en automatisation, d’architectes du déploiement, … Ou soyons créatifs et créons nos propres titres comme Google et ses Site Reliability Engineers ou La Poste et leur Facteur de changements – les idées ne manquent pas !

Source

LAISSER UN COMMENTAIRE

Please enter your comment!
Please enter your name here