L'échec de DevOps est un sujet délicat pour certains, car DevOps est généralement perçu comme un moyen de éviter échec. Par conséquent, lorsque vous échouez dans une pratique DevOps, la situation peut sembler presque désespérée. Cependant, tout comme approche commerciale fail-fast , ou la méthodologie « échouer et s'adapter plus tôt » d'Agile le prouve souvent, les échecs DevOps sont en fait un pas dans la bonne direction. Ils constituent la première étape vers l'apprentissage des échecs et la transformation de votre pratique DevOps en une pratique qui vous mènera vers un succès encore plus grand, le plus tôt possible.

Le DevOps trouve ses racines dans la méthode Agile, où des cycles de développement plus courts avec des boucles de rétroaction fréquentes vous guident rapidement, sur une période donnée, vers une livraison de produit plus adaptée aux besoins des clients. L'objectif de la boucle de rétroaction est d'apprendre de vos actions grâce aux commentaires des clients, puis de mesurer ce qui s'est bien passé et ce qui peut être amélioré.

Les boucles de rétroaction sont efficaces car les changements et les échecs fréquents offrent des opportunités d'apprentissage qui réduisent réellement les risques. Il existe de nombreux types d'échecs qui peuvent survenir dans une pratique DevOps, et votre réaction compte. Examinons-en quelques-uns maintenant.

Échec de la réaction à un incident

Lorsque des problèmes logiciels surviennent, qu'ils soient liés au déploiement ou à des bugs, votre réaction est souvent plus importante que le fait qu'ils se soient produits. Les échecs peuvent alors prendre plusieurs formes, notamment :

• Réaction exagérée: Passer trop de temps ou trop de ressources à réparer ou à essayer d'éviter un échec répété
• Réaction incorrecte : Diagnostiquer un problème de manière erronée ou supposer le mauvais problème, potentiellement en raison d'un manque d'informations
• Manque de réaction : Ne pas résoudre le problème assez tôt ou assez efficacement et le problème réapparaît peu de temps après

La gestion des incidents et évaluer son succès grâce à des indicateurs clés de performance sont des éléments de mesure importants qui sont des ingrédients essentiels au succès de DevOps. Évaluez et résolvez rapidement les incidents en faisant apparaître des informations pertinentes et en recrutant d'autres membres de l'équipe pour vous aider, et en considérant le système dans son ensemble au lieu de pointer du doigt des composants individuels (et les personnes qui se trouvent derrière eux) comme étant la cause.

Les points à retenir ici incluent une approche holistique de Réponse aux incidents , diffuser les connaissances, apprendre des échecs et des incidents passés pour prévenir les problèmes futurs et automatiser les réponses pour résoudre les problèmes plus rapidement.

Créer trop de processus

Certains pensent que DevOps est simplement un processus ou un outil et se contentent de mettre en place des ensembles de procédures rigides et formelles à suivre. Mais imposer trop de formalités, être trop strict sur les processus et imposer certains ensembles d'outils peut limiter la flexibilité de votre organisation en matière de changement. Au lieu de cela, DevOps devrait inclure outils et des procédures qui améliorent l'agilité de votre organisation.

Par exemple, les outils qui mesurent l'efficacité globale de votre développement et de votre déploiement de logiciels vous aideront à fournir des commentaires pour améliorer cette efficacité. Comment ? En indiquant les changements à apporter et les goulots d'étranglement qui doivent être supprimés Avec trop de rigidité, votre organisation risque de ne pas être en mesure de changer suffisamment rapidement pour s’améliorer ou répondre aux besoins d’une base d’utilisateurs ou d’un marché en évolution.

Limiter la portée de DevOps

Le travail d'une pratique DevOps ne repose pas sur une seule personne ni même sur une équipe au sein de votre organisation. J'ai été témoin de situations où des individus ont été spécifiquement embauchés comme « la personne DevOps » qui ferait comme par magie des « trucs DevOps » pour résoudre tous les problèmes de déploiement et de maintenance de logiciels existants. Mais voici en résumé : cette approche volonté échouer.

De même, j’ai également vu des situations où service et assistance à la clientèle Le personnel a reçu des appels de clients concernant une nouvelle fonctionnalité installée au cours du week-end dont ils n'avaient aucune connaissance préalable. Lorsque les personnes clés du support apprennent les modifications apportées à votre logiciel par vos clients, vous êtes confronté à un échec DevOps.

DevOps est une pratique organisationnelle qui reprend ce qui était appris de Le développement agile est appliqué de bout en bout à la livraison du logiciel. Cette pratique doit être étendue à d'autres fonctions de l'entreprise. Cela signifie que le travail de développement est aligné sur la valeur client, et non sur les projets, et que les équipes produit travaillent non seulement avec le personnel informatique, mais aussi avec les personnes qui répondent au téléphone, rédigent la documentation technique, font la promotion et commercialisent l'application et servent de sponsors commerciaux, y compris les dirigeants qui planifient l'avenir. Tout le monde a quelque chose à apprendre lorsque les boucles de rétroaction sont étendues à tous les membres de l'organisation.

Les points à retenir ici incluent l'élargissement des boucles de rétroaction, de la communication et des activités de mesure clés à toutes les parties de votre organisation. De plus, n'ignorez pas les fournisseurs, les prestataires ou les composants tiers. N'oubliez pas d'inclure également la validation, l'audit et la surveillance des composants externes.

Le jeu des reproches et la compétition

Étant donné que la méthode Agile permet souvent de détecter des goulots d'étranglement dans le pipeline de livraison de logiciels d'une organisation, il est facile de pointer du doigt les personnes ou les activités qui sont perçues comme ralentissant les choses. Lorsque cela se produit, DevOps peut creuser un fossé encore plus grand entre les équipes, ce qui est l'exact opposé de ce qui était prévu.

Plutôt, supprimer les silos (des équipes ou des personnes qui ont tendance à travailler en vase clos) et abattez les cloisons entre les équipes avant d'identifier les goulots d'étranglement et les améliorations. Si tout le monde travaille ensemble en premier lieu, avec un ensemble de responsabilités partagées, les améliorations se produiront en équipe unifiée plutôt qu'à la suite d'une compétition entre eux.

Garder un ou deux silos

Il n’est pas rare que les entreprises, même celles qui ont connu un réel succès avec Agile et DevOps, créent des exceptions au sein de l’entreprise en ce qui concerne cette pratique. Il peut s’agir d’une application héritée, d’une équipe éprouvée ou même d’un employé expérimenté. Cependant, exclure une seule personne ou une seule équipe de la pratique DevOps peut s’avérer problématique.

Les silos ont tendance à se multiplier et à devenir toxiques pour les pratiques de distribution de logiciels d'une organisation. Même si le silo comprend un cofondateur de l'entreprise, personne ne devrait être exempté des processus et de la collaboration que la pratique DevOps de votre organisation encourage. En un mot : DevOps signifie supprimer les silos et les goulots d'étranglement. Aucune exception.

Ignorer l’environnement de développement

DevOps s'applique à plus que le environnement de production et les déploiements. Même lorsque les sprints de développement Agile sont réussis, que les déploiements de production sont automatisés et que les tests sont continus, le fait de ne pas étendre ces pratiques à l'environnement de développement crée ses propres problèmes. Par exemple, si les environnements de développement et de test ne sont pas gérés à l'aide des mêmes outils, approches et personnes que ceux qui gèrent votre environnement de production, vous risquez de rencontrer des problèmes de production la première fois que votre logiciel rencontre des configurations potentiellement uniques, ce qui conduit souvent à une défaillance inattendue.

Sachez comment le travail de développement est effectué, où il est effectué et où il aboutira en production. Si l'un de ces trois éléments est inconnu au moment du développement, le risque d'échec deviendra presque certain au moment de la sortie. Il est absolument crucial d'orchestrer et de contrôler vos flux de travail et environnements de développement de la même manière qu'ils existeront probablement en production.

Accès à trop d'équipes

L'amélioration du travail d'équipe qui résulte de DevOps est une bonne chose, tout comme la capacité croissante des membres de l'équipe à mesure qu'ils sont exposés à de nouvelles procédures ou composants de votre logiciel. Cependant, oublier la responsabilité supplémentaire qui en découle peut conduire à un échec critique. Par exemple, s'il est généralement positif que DevOps puisse aider un développeur d'interface utilisateur à se familiariser avec la base de données d'une application (et lui permettre de déployer les modifications de la base de données en libre-service), ce n'est pas une bonne chose lorsque des modifications sont apportées accidentellement à une base de données de production. Bien que les goulots d'étranglement soient supprimés, des contrôles doivent également être mis en place pour éviter une catastrophe.

Les points à retenir ici sont de surveiller et de signaler les accès inattendus aux systèmes de production critiques, et de mettre en place des procédures pour annuler (ou même faire avancer) les modifications préjudiciables apportées, qu'elles soient involontaires ou non.

Conclusion : tout est une question de personnes

L'objectif n'est pas de réussir avec DevOps en soi, ce n'est ni un processus ni une activité. L'objectif est plutôt d'utiliser les principes de DevOps pour améliorer votre logiciel, l'expérience client et votre organisation. En fait, si l'un de ces éléments manque, la vie peut s'avérer difficile, même si vous pensez réussir avec DevOps.

Il est important de se rappeler que tous ces ingrédients impliquent des personnes réelles. Quelle que soit la manière dont DevOps vous aide à y parvenir, à tirer les leçons de vos échecs, à inculquer une culture d'amélioration constante, rendre les clients heureux , et s'amuser en le faisant sont ce qui est vraiment important. Chaque jour, alors que vous travaillez pour atteindre vos objectifs, gardez à l'esprit ce qui compte vraiment.