Notre culture DevOps
Avec l’émergence des méthodes agiles lors des dernières décennies (Manifesto agile - février 2001), il est maintenant acquis chez les développeurs que notre métier est d’apporter de la valeur rapidement grâce à une approche itérative couplée à de l’amélioration continue.
On pourra discuter du niveau de maturité fluctuant des développeurs qui mettent sur leur CV « Agile / Scrum» (les plus matures comprendront : Scrum != Agile) mais il est indéniable qu’ils ont compris l’intérêt des itérations et de la boucle de feedback.
En effet s’il y a une chose à retenir dans ce billet c’est l’importance de cette boucle de feedback : plus tôt un problème est découvert et moins son coût de résolution est élevé.
Ainsi on évite l’effet tunnel et on permet de fournir de la valeur à notre client dès la première itération. Effet collatéral intéressant, si notre projet s’arrête (budget, politique, pandémie, …), la valeur livrée est utilisable et ainsi quoiqu’il arrive on en a pour l’argent investi.
Après un portrait si idyllique on pourrait alors penser que maintenant il ne s’agit plus que d’aider les développeurs à murir leur compréhension de la culture de l’agilité.
Mais la réalité est tout autre. La plupart d’entre vous y sont confrontés quotidiennement : on fait des itérations de 2 semaines mais on livre 4 fois par an en production. Du coup oubliez le beau discours sur la valeur ajoutée toutes les deux semaines, la boucle de feedback sur les mises en productions de code produit en moyenne il y a 2 mois, etc… 20 ans d’évangélisation pour en arriver là ? Pourquoi ?
La réponse est simple : pour optimiser, on nous a séparés ! On s’est inspiré des techniques de production de masses pour pousser le rendement au maximum comme le taylorisme.
Dans un monde où la division du travail est déjà la norme, pour obtenir des conditions propres à fournir le rendement maximum dans le cadre d'une organisation, le taylorisme préconise :
une analyse détaillée et rigoureuse — d'où l'accent mis sur le qualificatif de « scientifique » — des modes et techniques de production (gestes, rythmes, cadences, etc.) ;
l'établissement de la « meilleure façon » (the one best way) de produire (définition, délimitation et séquençage des tâches) ;
la fixation de conditions de rémunération plus objectives et motivantes. Ce qui donne ce nom le taylorisme
Cependant, ce qui est vrai pour produire des milliers de voiture à la chaine (approche déterministe), ne l’est pas pour notre métier : apporter de la valeur à mon client pour qu’il se différencie des concurrents (approche empirique). Chacun de mes clients à ses spécificités.
Avec l’industrialisation, nous mettons en place une chaine de production qui coûte très cher. Cette dernière est rentable lorsque vous produisez plusieurs milliers de voitures. Sinon il vaut mieux les faire à la main. Dans notre métier nous ne produisons pas plusieurs milliers de voitures identiques. Par contre nous sommes confrontés à l’éternel problème des coûts qui nous force à trouver des solutions. Ainsi pour cela j’automatise des tâches mais je garde la flexibilité de réorganiser tout le processus chaque jour. Cette automatisation revêt divers aspect (continuous integration, continuous deployment, patterns d’architecture, réutilisation de briques, cloud, etc… ).
On ne fait pas de l’industrialisation mais de l’automatisation !
Ainsi cette industrialisation nous a divisé ce qui a eu pour effet pervers de nous déresponsabiliser : il suffit de discuter avec les différentes équipes pour vite comprendre que le coupable, c’est toujours l’autre. Chacun a pour objectif de faire sa tâche au mieux sans se soucier de l’autre. L’objectif du développeur est de produire du code, poser une architecture, s’assurer de la maintenabilité et maintenant d’apporter du changement. Celui de l’ops, c’est la stabilité, la sécurité, s’assurer que tout tourne. Cette séparation fait qu’il y a une incompréhension latente entre les développeurs et les opérationnels. Mais surtout on a oublié notre but commun : livrer de la valeur au métier !
La culture DEVOPS c’est casser ce mur de la confusion pour imposer notre responsabilité commune. C’est retrouver une boucle de feedback rapide sur l’ensemble du cycle de vie d’une application (et pas seulement de sa construction). C’est travailler ensemble.
Comment ?
Les puristes vous diront de mettre ensemble les ops et les dév. Malheureusement, il faudra être convaincant car avoir un administrateur réseau par équipe de développement n'aidera pas à rationaliser les coûts.
D’autres créeront une troisième équipe dont l’objectif est de faire discuter les deux autres. Nous pouvons alors nous demander si la création d'une équipe supplémentaire fluidifie réellement les échanges et améliore la boucle de feedback ?
Enfin il y a ceux qui mettent un outil en place (docker au hasard) et espèrent que par magie le reste suivra. Effectivement l’axe de l’automatisation sera bien adressé mais le plus difficile reste la communication. Attention à ne pas confondre les outils DEVOPS de la culture DEVOPS même si les deux sont importants.
Il n’existe pas de réponse simple. Il vous faut créer votre culture DEVOPS en responsabilisant vos équipes et en leur donnant les moyens d’automatiser et fluidifier un maximum le cycle de vie de vos applications afin d’avoir une boucle de feedback la plus courte possible. Rien que ça…
Ceux qui ont déjà essayé mesurent la difficulté. C’est pour appréhender cela que chez CROSS nous avons découpé DEVOPS en 5 grandes pratiques. Ainsi nous pouvons auditer chaque pratique et en fonction de vos objectifs, mesurer votre maturité DEVOPS. À la suite de ces analyses nous pouvons identifier les goulots d’étranglement et vous aider à travailler sur des axes d’amélioration.
En plus de ces 5 pratiques, il est important d’adresser aussi les sujets de sécurité (DEVSECOPS).
Dans de prochains articles nous reviendrons plus en détails sur chacune de ces pratiques afin de mieux comprendre ce qu’elles regroupent et les points permettant d’améliorer votre boucle de feedback.
