Dans le cours : Les fondements du DevOps

Changer les mentalités

(musique techno) - Vous ne serez pas surpris d’apprendre que le service IT n’est pas le département préféré des employés de l’entreprise. Les entreprises s’appuient sur la technologie pour proposer leurs services depuis des décennies, mais la satisfaction vis-à-vis de l’IT reste faible. [Homme à droite] Chez les spécialistes de la technologie, on a des rivalités entre les développeurs, les administrateurs système, les spécialistes de la sécurité, etc. [Formateur] Et les administrateurs de bases de données ! Oui, ne les oublions pas. La plupart du temps, ces différents groupes sont en conflit, et pas en harmonie. On se moque souvent de ces petites guéguerres dans des BD comme Dilbert, User Friendly et XKCD ou des séries comme The IT Crowd. Malheureusement, c’est moins drôle dans la vraie vie, quand vous avez l’impression que l’on vous met des bâtons dans les roues. En DevOps, on appelle cela « le mur de la confusion ». Imaginez un développeur qui programme quelque chose et qui balance son code au-dessus du mur pour le faire passer à l’ingénieur opérations chargé du déploiement et du support. Cette approche crée une séparation, alors qu’il faudrait avoir un objectif commun. [Homme à droite] On pense souvent que ces divisions proviennent du manque de compétences relationnelles chez les professionnels de la technologie, mais c’est faux. Le problème vient en fait de la culture de l’entreprise. Cette culture a en effet tendance à récompenser des comportements contradictoires. Dans une société lambda, les développeurs doivent créer des fonctionnalités et mettre en place des changements le plus rapidement possible. En parallèle, l’équipe opérations doit assurer la stabilité et contrôler le changement, ce qui crée tout de suite un conflit. Cette séparation des responsabilités génère des intérêts contradictoires et nuit aux boucles de rétroaction. Et en récompensant uniquement les activités qui concernent strictement ces groupes et pas les autres, on obtient de moins bons résultats globaux. Et c’est encore pire dans les équipes opérations. Les développeurs sont généralement organisés par secteur métier ou applications, mais les équipes infrastructure sont souvent organisées par pile technologique. [Homme à droite] Oui, et cela crée également des divisions à l’intérieur de l’équipe infrastructure. Au lieu d’avoir deux ou trois équipes avec des priorités différentes, vous avez besoin de six équipes rien que pour mettre en place un changement : réseau, Unix, web, data center et base de données. [Formateur] Merci d’avoir inclus les administrateurs de bases de données ! Vous savez, l’alignement métier et IT a toujours été un sujet épineux dans les organisations IT, et certaines organisations technologiques ont beaucoup souffert de ces contradictions internes. Souvent, ce sont nos processus et organisations IT internes qui sont à la traîne. En 2004, j’étais responsable d’une équipe opérations Web, et nous avons dû collaborer avec une autre équipe pour déployer des serveurs. Cela nous a pris six semaines en tout. On a travaillé ensemble sur les spécifications, puis on a lancé le processus d’achat, on a commandé le produit au fournisseur, on l’a réceptionné, on l’a installé, on a déployé l’OS et on a enfin pu commencer à l’utiliser. Un jour, un commercial spécialiste de la virtualisation est venu. Il nous a montré comment déployer un serveur virtuel en 15 minutes. On l’a acheté tout de suite. Et à votre avis, combien de temps l’équipe a-t-elle mis pour l’installer ? 15 minutes, comme promis ? - Malheureusement, ça a été plus long. 4 semaines. On a juste gagné les deux semaines que le fournisseur met généralement pour exécuter la commande. La création du serveur a bien pris 15 minutes, mais nos processus ont mis 4 semaines. Il fallait bien prendre en compte les normes, les tickets, la documentation, etc., mais nous étions bien conscients que notre approche transformait un processus très simple et réalisable par une seule personne en une séquence d’étapes interminable et multiéquipe. Et ça, c’est inacceptable aujourd’hui. Dans les BD et les séries que nous avons citées plus tôt, les employés de l’IT jettent de la poudre aux yeux des utilisateurs et des managers, car ils ne s’y connaissent pas du tout en technologie. Mais l’IT existe depuis suffisamment longtemps, et la plupart des dirigeants sont plus technophiles qu’avant, donc quand ils voient un processus de 15 minutes qui s’étale sur 4 semaines, ils demandent des explications. Ils veulent savoir pourquoi ils investissent du temps et de l’argent dans des choses qui ne font rien pour leur compétitivité. Et c’est une très bonne question. Pour contourner ces difficultés, beaucoup optent pour l’externalisation et l’informatique de l’ombre, mais ces approches sont tout aussi problématiques. Les organisations et les processus IT développés au fil des années freinent aujourd’hui la réussite des entreprises. Face à ces mentalités et à ces comportements bien établis, que pouvons-nous faire pour changer de culture ? Nous allons voir ça en détail dans le reste du chapitre.

Table des matières