DevOps, a culture above all

Dans le monde d’aujourd’hui, la pression sur les entreprises de services du numérique est plus forte que jamais pour aller plus vite et être plus agile sans sacrifier la sécurité ou la performance. Cette pression se manifeste souvent par un projet annulé ou mis en attente. DevOps cherche à résoudre ce problème : comment amener les Devs, les Ops et d’autres groupes au sein d’une même organisation à collaborer autour d’un ensemble d’objectifs partagés, afin de fournir des logiciels plus rapidement et de manière plus fiable aux clients et aux utilisateurs finaux ?

DevOps inclut souvent :

• La gestion automatisée de la configuration, tests et déploiement d’applications

• Le contrôle de version du code de l'application et de l'infrastructure pour permettre la collaboration et les restaurations

• La CI (intégration continue) pour automatiser la génération de code et permettre un retour et une itération plus rapides grâce à des versions plus fréquentes et moins risquées.

Avant toute chose, DevOps est une optique culturelle sur la manière dont tout le monde devrait s’engager pour bien travailler. Dans un monde régi par le logiciel, plusieurs questions se posent.

Comment pouvons-nous mettre quelque chose en production rapidement, et que faire une fois mis en production ? Comment saurons-nous que nous avons fait le meilleur choix ? Comment pourrions-nous appliquer le plus vite possible les améliorations et les mises à jour ?

DevOps vise à inclure toutes les personnes ayant un intérêt dans le projet en les impliquant dès le début du processus de collaboration. Pour réussir, DevOps commence par comprendre les principaux avantages commerciaux. Les entreprises sont en mesure de fonctionner plus rapidement avec moins de temps d'arrêt et moins de problèmes de sécurité.

Avant toute chose, DevOps est une culture ! Toute la société devra être impliquée pour que cela fonctionne.

Il faut que les hauts responsables apportent leur soutien, mais également que toutes les personnes impliquées dans le produit final aient un intérêt, pas seulement les départements de développement et des opérations.

Il est à noter que les IT-managers qui réussissent les transformations DevOps au sein de leurs organisations ont tous un point en commun : ils se concentrent sur l'apprentissage et l'amélioration continue plutôt que sur un objectif final.

Construire le business case

Comme de nombreux IT-managers, il vous est demandé de fournir de plus en plus de produits et de services, avec beaucoup plus de contraintes de rapidité et la meilleure qualité possible, sans que la performance ou la sécurité ne soit affectées. Il semble que DevOps réponde à toutes ces contraintes ! Mais… Vous allez sûrement rencontrer le scepticisme de votre équipe avant même d’avoir vraiment commencé.

Comment allez-vous donc convaincre votre équipe et plaider pour DevOps, pour réduire la peur et ainsi transformer les sceptiques en champions ?

Commencer par la question ci-dessus est en fait un bon départ. Construire sa Business Case est un élément crucial pour la réussite de sa transformation DevOps.

Les gens n'achètent pas ce que font les leaders mais pourquoi ils le font.

La même idée se vérifie lors de la construction d'un engagement organisationnel pour une transformation DevOps. Déclarer simplement « Nous faisons DevOps » ne va pas amener les gens à s’engager. Au lieu de cela, vous allez avoir besoin d’avoir une réponse convaincante aux questions ‘’Pourquoi ? Et pourquoi maintenant ?’’ Tous nos clients veulent aller plus vite sans compromettre la fiabilité et la stabilité de leurs systèmes, des objectifs qui entrent directement en conflit dans les organisations traditionnelles.

Les développeurs sont chargés de mettre en production les nouvelles fonctionnalités le plus rapidement possible. Les opérateurs, quant à eux, mesurent le temps de disponibilité et les performances des systèmes. Ces équipes deviennent des adversaires au lieu d'être des alliés. En conséquence, les déploiements en production sont en proie à des retards et des erreurs, et se produisent beaucoup moins souvent que nécessaire.

Alignement de l’Ops à DevOps

Les Ops gagneront beaucoup plus à travailler en étroite collaboration avec les développeurs. Il peut être utile de commencer par fusionner les environnements de travail pour faire en sorte que les deux groupes travaillent ensemble, afin d’adopter les mêmes outils utilisés en développement, intégration, test et déploiement du code d’infrastructure. Cela poussera les développeurs à s’intégrer plus activement dans les déploiements et le dépannage, éliminant ainsi les anciennes barrières tout en améliorant la vitesse et la fiabilité. Le suivi de plusieurs métriques qui intéressent généralement les Ops confirmera le succès de cette collaboration, y compris celles des Devs et des QA :

• Disponibilité / indisponibilité : Êtes-vous mieux en mesure de répondre à vos exigences de niveau de service ? Les temps d'arrêt ont-ils diminué ?
• Changer le taux d’échec : Les échecs ont-ils diminué ?
• Temps moyen de récupération : Avez-vous réduit le temps nécessaire pour revenir au dernier bon état connu en cas de défaillance ?

Commencez petit et grandissez dès les premiers succès.

Alors, comment commencerez-vous à mesurer ces impacts DevOps et à renforcer votre business case ? Commencez petit avec des tâches et des projets spécifiques.

Vous ne pouvez pas modifier l’ensemble de l’organisation, mais vous pouvez commencer par amener quelques-unes de vos sous-équipes dans la bonne direction. Il peut être utile de faire appel à une personne de l’extérieur pour automatiser quelques tests ou versions et donner à l’équipe quelques exemples sur lesquels elle pourra s'appuyer.

Commencez petit avec le changement de culture, ne vous attendez pas à vendre DevOps à tout le monde à la fois. En gagnant des petits groupes avec des projets spécifiques, vous créerez des ambassadeurs pouvant contribuer à promouvoir DevOps ailleurs dans l’organisation, créant ainsi un effet multiplicateur. Pendant que vous construisez votre business case, vous devez également garder à l’esprit les obstacles potentiels au succès à long terme de DevOps.