L'échec du DevOps est un sujet délicat pour certains, car le DevOps est généralement perçu comme un moyen de éviter échec. Par conséquent, lorsqu'on échoue dans une pratique DevOps, la situation peut sembler presque désespérée. Cependant, tout comme un approche commerciale de l'échec rapide Comme le prouve souvent la méthodologie Agile « échouer et s'adapter rapidement », les échecs DevOps constituent en réalité un pas dans la bonne direction. Ils représentent la première étape vers l'apprentissage de ces échecs et la transformation de vos pratiques DevOps en une approche qui vous mènera vers un succès encore plus grand, et ce, plus rapidement.

Le DevOps trouve ses racines dans l'Agile, où des cycles de développement plus courts, ponctués de retours d'information fréquents, permettent d'obtenir rapidement, au fil du temps, des produits mieux adaptés aux besoins des clients. L'objectif de ces retours est de tirer des enseignements de ses actions grâce aux retours clients, puis d'analyser les points forts et les axes d'amélioration.

Les boucles de rétroaction sont efficaces car les changements fréquents et les échecs offrent des occasions d'apprendre, ce qui réduit concrètement les risques. De nombreux types de défaillances peuvent affecter une pratique DevOps, et votre réaction est cruciale. Examinons-en quelques-unes.

Échec de la réaction à l'incident

Lorsqu'un problème logiciel survient (qu'il soit lié au déploiement ou qu'il s'agisse d'un bug), votre réaction est souvent plus importante que le problème lui-même. Ce type de défaillance peut prendre plusieurs formes, notamment :

• Réaction exagérée: Consacrer trop de temps ou trop de ressources à corriger ou à tenter d'éviter une nouvelle défaillance
• Réaction incorrecte : Un mauvais diagnostic ou une hypothèse erronée concernant un problème, potentiellement due à un manque d'informations, peuvent entraîner des complications.
• Absence de réaction : Le problème n'est pas résolu assez rapidement ou de manière suffisamment efficace, et il réapparaît peu après.

Gestion des incidents L'évaluation de son succès à l'aide d'indicateurs clés de performance (KPI) est un élément essentiel de la mesure et un ingrédient indispensable à la réussite du DevOps. Il est important d'évaluer et de résoudre rapidement les incidents en mettant en évidence les informations pertinentes, en sollicitant l'aide d'autres membres de l'équipe et en considérant le système dans son ensemble plutôt que de désigner des composants individuels (et les personnes qui les gèrent) comme étant la cause du problème.

Les principaux enseignements à retenir sont une approche holistique de réponse aux incidents , diffuser les connaissances, tirer des leçons 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 considèrent le DevOps comme un simple processus ou outil et s'attachent à mettre en place des procédures rigides et formelles. Or, imposer trop de formalisme, être trop strict sur les processus et imposer certains outils peut limiter la flexibilité de votre organisation face au changement. Le DevOps devrait plutôt inclure… outils et des procédures qui renforcent l'agilité de votre organisation.

Par exemple, les outils qui mesurent l'efficacité globale de votre développement et de votre déploiement logiciel vous aideront à obtenir des retours d'information pour améliorer cette efficacité. Comment ? En indiquant les points à améliorer et… goulots d'étranglement à éliminer Une trop grande rigidité peut empêcher votre organisation d'évoluer suffisamment vite pour s'améliorer ou répondre aux besoins d'une base d'utilisateurs ou d'un marché en constante évolution.

Limiter la portée du DevOps

Le travail lié aux pratiques DevOps ne repose pas sur une seule personne, ni même sur une seule équipe au sein de votre organisation. J'ai vu des situations où des individus étaient embauchés spécifiquement comme « experts DevOps », censés résoudre comme par magie tous les problèmes de déploiement et de maintenance des logiciels existants. En résumé : cette approche volonté échouer.

De même, j'ai également vu des situations où service client et assistance Le personnel a reçu des appels de clients concernant une nouvelle fonctionnalité installée pendant le week-end, dont ils n'avaient pas été informés au préalable. Lorsque les principaux responsables du support apprennent l'existence de modifications logicielles par vos clients, il s'agit d'un échec DevOps.

DevOps est une pratique organisationnelle qui transforme ce qui était appris de Le développement agile est appliqué de bout en bout tout au long du cycle de vie du logiciel. Cette pratique devrait être étendue à d'autres fonctions de l'entreprise. Ainsi, le développement est aligné sur la valeur client, et non sur les projets. Les équipes produit collaborent non seulement avec le personnel informatique, mais aussi avec les équipes en charge du support client, de la documentation technique, de la promotion et du marketing de l'application, ainsi qu'avec les responsables métiers, y compris les dirigeants en charge de la planification stratégique. L'élargissement des boucles de rétroaction à l'ensemble de l'organisation est source d'apprentissage pour tous.

Les principaux enseignements à retenir sont l'importance d'étendre les boucles de rétroaction, la communication et les activités de mesure clés à tous les niveaux de votre organisation. Par ailleurs, n'oubliez pas les fournisseurs, prestataires et composants externes. Pensez également à inclure la validation, l'audit et le suivi de ces composants.

Le jeu des reproches et la compétition

Étant donné que la méthode Agile révèle souvent des goulots d'étranglement dans le processus de livraison de logiciels d'une organisation, il est facile de pointer du doigt les personnes ou les activités perçues comme des freins. Dans ce cas, le DevOps peut creuser un fossé encore plus grand entre les équipes, ce qui est à l'opposé de l'objectif recherché.

Plutôt, supprimer les silos (Les équipes ou les personnes qui ont tendance à travailler de manière isolée) et décloisonner les équipes avant d'identifier les points de blocage et les axes d'amélioration. En travaillant ensemble dès le départ, avec des responsabilités partagées, les progrès se feront de manière unifiée, et non par le biais de la compétition.

Garder un silo ou deux

Il n'est pas rare que les organisations, même celles qui ont obtenu de réels succès avec les méthodes Agile et DevOps, créent des exceptions en interne concernant ces pratiques. Il peut s'agir d'une application existante, d'une équipe performante, voire d'un employé expérimenté. Cependant, exclure une personne ou une équipe des pratiques DevOps peut s'avérer problématique.

Les silos ont tendance à se multiplier et à nuire aux pratiques de développement logiciel d'une organisation. Même si un cofondateur de l'entreprise fait partie du silo, personne ne devrait être exempté des processus et de la collaboration encouragés par la démarche DevOps de votre organisation. En résumé : DevOps signifie supprimer les silos et les goulots d'étranglement. Sans exception.

Ignorer l'environnement de développement

Le DevOps s'applique à bien plus que les environnement de production et les déploiements. Même lorsque les sprints de développement Agile sont couronnés de succès, que les déploiements en production sont automatisés et que les tests sont continus, ne pas étendre ces pratiques à l'environnement de développement engendre ses propres problèmes. Par exemple, si les environnements de développement et de test ne sont pas gérés avec les mêmes outils, approches et personnes que votre environnement de production, vous risquez de rencontrer des problèmes en production dès que votre logiciel est confronté à des configurations potentiellement uniques, ce qui conduit souvent à des défaillances inattendues.

Il est essentiel de comprendre comment le développement est réalisé, où il est effectué et où il sera déployé en production. Si l'un de ces trois éléments est inconnu lors du développement, le risque d'échec deviendra quasi certain au moment de la mise en production. Il est donc 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 seront probablement utilisés en production.

Accès excessif à l'équipe

Le renforcement du travail d'équipe induit par le DevOps est un atout, tout comme l'acquisition de compétences accrues par les membres de l'équipe grâce à la découverte de nouvelles procédures ou de nouveaux composants logiciels. Cependant, négliger la responsabilité supplémentaire qui en découle peut mener à des défaillances critiques. Par exemple, si le DevOps permet généralement à un développeur d'interface utilisateur de se familiariser avec la base de données d'une application et même de déployer lui-même les modifications de cette base, il devient problématique d'apporter des modifications accidentelles à une base de données de production. Bien que les goulots d'étranglement soient éliminés, des contrôles doivent également être mis en place pour éviter toute catastrophe.

Les points à retenir sont les suivants : surveiller et signaler tout accès inattendu aux systèmes de production critiques, et mettre en place des procédures pour annuler (voire même appliquer) les modifications dommageables effectuées, intentionnelles ou non.

Conclusion : Tout est une question de personnes

L'objectif n'est pas la réussite en soi dans le domaine du DevOps ; il ne s'agit ni d'un processus ni d'une activité. Il s'agit plutôt d'utiliser les principes du DevOps pour améliorer vos logiciels, l'expérience client et votre organisation. En effet, si l'un de ces éléments fait défaut, la tâche risque d'être ardue, même si vous pensez maîtriser le DevOps.

Il est important de se rappeler que tous ces ingrédients impliquent des personnes réelles. Quelle que soit la manière dont le DevOps vous aide à y parvenir, en tirant des leçons de vos échecs et en instaurant une culture d'amélioration continue, rendre les clients heureux Et surtout, prenez du plaisir à le faire : voilà ce qui compte vraiment. Chaque jour, tandis que vous travaillez à atteindre vos objectifs, gardez à l’esprit ce qui est essentiel.