Comment la responsabilité partagée affecte la livraison de logiciels fiables dans un environnement DevOps ?
Comment la responsabilité partagée affecte la livraison de logiciels fiables dans un environnement DevOps ?
Une analyse de OverOps
La transition vers DevOps promet une flexibilité accrue, une santé opérationnelle améliorée et une collaboration plus étroite tout au long du cycle de vie de la fourniture de logiciels, mais elle présente également de nouveaux défis. L'un d'eux est étudié par l'enquête « Dev vs. Ops: State of Accountability » d'OverOps : la responsabilité en cas de problème.
Les auteurs dressent d'abord un portrait de l'état du DevOps en entreprise, avant de s'attaquer à la responsabilité en cas de problème mais aussi d'expliquer la raison pour laquelle elle est un défi pour ces équipes.
La transformation DevOps est en cours mais lente
Malgré le buzz autour du DevOps ces dernières années, très peu d'organisations l'ont totalement adopté. Moins de 18% des personnes interrogées ont déclaré être totalement devOps, contrairement aux 82,2% d’entre elles qui n’ont adopté que partiellement, voire pas du tout, les pratiques et outils DevOps. Les répondants ont indiqué que la grande majorité des organisations allaient dans cette direction, mais que le chemin à parcourir était encore long.
L'enquête a également révélé que plus l'entreprise est grande, plus elle a de chances d'adopter au moins partiellement les workflows DevOps - 78,5% des entreprises de 1 000 employés ou plus contre 48,2% des entreprises de 50 personnes ou moins. Inversement, le pourcentage de répondants qui n’ont pas prévu d’adopter ou qui envisagent encore de l’adopter diminue au fur et à mesure que la taille de l’entreprise augmente.
Une évolution rapide dans la fréquence des publications
L'adoption agile est bien vivante dans tous les secteurs et toutes les tailles d'entreprise. Selon l'enquête, la majorité des personnes interrogées (quelle que soit leur taille, leur adoption, leur secteur d'activité ou leur infrastructure) appliquent des calendriers de publication plus fréquents. Plus de 90% déploient du code au moins une fois par mois et plus de 60% le font au moins une fois toutes les deux semaines. 43,8% de tous les répondants ont également indiqué qu'ils alignaient leur code ou leurs versions avec les sprints.
Si la rapidité est clairement une priorité pour les communautés de développement et d’exploitation, elle introduit des risques. La pression pour déployer rapidement de nouvelles fonctionnalités et respecter les délais de sprint peut avoir un impact significatif sur la qualité et la fiabilité du code. 38,2% de tous les répondants ont indiqué que le fait de passer trop rapidement est en fait la principale raison pour laquelle des erreurs entrent en production. Parmi les répondants ayant déclaré avoir adopté pleinement DevOps, le pourcentage était légèrement plus élevé, à 44,6%.
1,4% ont répondu avec d'autres périodes
L’automatisation n’est pas une solution miracle
Pour suivre les calendriers de publication accélérés, les entreprises exploitent un large éventail d'outils d'automatisation pour prendre en charge le cycle de vie du développement logiciel. Les équipes de développement et d’exploitation font largement appel à l’automatisation pour détecter les problèmes de production: 62,7% des personnes interrogées ont déclaré utiliser un outil automatisé pour la notification des erreurs. De plus, 63,2% ont déclaré utiliser des tests automatisés pour garantir la qualité des applications.
Malgré l’adoption de l’automatisation, l’enquête a également révélé qu’un nombre alarmant de personnes utilisaient encore des méthodes manuelles. 76,6% de tous les participants au sondage ont déclaré utiliser au moins un processus manuel pour détecter les erreurs, et 35,6% ont utilisé exclusivement des processus manuels. Pire encore, plus de la moitié (52,2%) des répondants ont déclaré qu'ils comptaient sur les clients pour les informer de leurs erreurs.
Comment découvrez-vous les erreurs en production ?
L'enquête a aussi fourni une liste d'outils populaires pour les équipes de développement et les équipes d'exploitation.
Pour les équipes de développement, ce sont les outils de tests automatisés qui remportent la mise avec une adoption à 68,6%. Ils sont suivis par les Analyseurs / Gestionnaires de journaux et d'événements (61,6 %). Pour les équipes d'exploitation, la palme d'or revient aux outils de Surveillance d'infrastructure / réseau, utilisés par 69,6% des équipes. Les Analyseurs / Gestionnaires de journaux et d'événements se retrouvent également ici en seconde place cette fois-ci avec une adoption à 68,8 %.
Outils les plus populaires
Mesure de l'efficacité d'une équipe DevOps : tous les regards sont tournés vers la qualité et la productivité du code
Tout le monde semble convenir que la qualité du code et la productivité sont importantes. Plus de la moitié des répondants ont indiqué que la productivité (55,8%) et la qualité du code (56,9%) constituaient le principal moyen de mesurer l’efficacité de leur équipe.
Selon 55,8% des répondants Ops, le temps de disponibilité des services est la première chose à évaluer pour mesurer le succès d'équipes individuelles. En revanche, les développeurs mettent encore plus l'accent sur la productivité et la qualité de leur code.
Comment mesurez-vous l'efficacité de votre équipe ?
Le dépannage prend du temps
Malgré l'automatisation poussée et l'accent mis sur la productivité et la qualité du code, plus d'un répondant sur quatre (25,8%) consacrent encore plus de 20% de leur temps à résoudre les problèmes de code, ce qui équivaut à environ un jour complet de travail par semaine (ou plus). passé sur le dépannage. 42% des répondants consacrent 10 à 20% de leur temps à la résolution des problèmes (entre la moitié et une journée complète de la semaine de travail). Les éditeurs du rapport estime que cela signifie que le temps précieux qui pourrait être consacré au développement de nouvelles fonctionnalités pour surpasser les concurrents finit par être gaspillé à la correction de code de mauvaise qualité.
Qui est responsable de la fiabilité globale des applications ?
Pour mieux comprendre l'impact de la transformation DevOps sur la fiabilité des applications, le sondage a examiné la manière dont les équipes de développement et d'exploitation considèrent la responsabilité. Conformément à la mentalité de DevOps, la majorité des personnes interrogées pensent que les deux équipes jouent un rôle dans le bon fonctionnement du logiciel. De plus, plus les organisations évoluent dans la transformation DevOps, plus elles ont de chances de rendre l'ensemble de l'équipe responsable. Mais comme les équipes évoluent à un rythme effréné pour publier du code, qu'il manque des outils essentiels et que les processus et les rôles changent, cette approche collaborative peut entraîner une grande confusion.
Quand tout le monde est responsable, personne n'est responsable
La responsabilité partagée, bien qu’une partie essentielle d’une approche DevOps réussie, peut souvent créer de la confusion et des problèmes de communication. Plus des deux tiers des personnes interrogées (66,9%) pensent que toute l’équipe, c'est à dire les Devs et les Ops, est à blâmer lorsqu’une application plante ou contient une erreur. En outre, près des trois quarts des répondants (73%) estiment que les Devs et les Ops partagent la responsabilité de la qualité globale d'une application.
Dans le même temps, un quart des participants (23,2%) estiment que le manque de clarté quant à l'identité de la personne responsable de la qualité du code est une cause majeure d'erreurs lors de la production.
Les Devs et les Ops ne s'accusent plus mutuellement
Historiquement, les Devs et les Ops développement s'accusaient souvent mutuellement lorsque les choses n'allaient pas bien, mais il semble que cela commence à changer. En effet, les personnes interrogées dans les enquêtes sur le développement et les opérations ont indiqué qu’elles étaient chacune plus susceptibles de se tenir responsables de la qualité des applications par rapport à leurs homologues des opérations de développement ou des opérations.
Bien que les deux équipes prétendent partager la responsabilité des erreurs de production, les développeurs passent le plus de temps à résoudre les problèmes (sans surprise), 72,6% d'entre eux ont déclaré qu'au moins 10% de leur temps est consacré à la résolution des problèmes, contre seulement 56,7% chez les Ops. Malgré le sentiment de partager la responsabilité des erreurs et de la qualité du code, plus du quart des personnes interrogées chez les Ops (26,9%) ont répondu que le dépannage n’était pas de leur ressort.
Comment DevOps crée-t-il un chaos de fiabilité ?
La grande majorité des répondants au sondage, indépendamment de la taille des entreprises dans lesquelles ils travaillent, de leur rôle ou de leur secteur d’activité, estiment que la fiabilité est une priorité. De nombreuses entreprises adoptent les pratiques de DevOps dans l'espoir d'améliorer la fiabilité des logiciels, mais la pression exercée pour agir rapidement et la confusion qui règne autour de la responsabilité peuvent créer de nouveaux obstacles tout au long du cycle de vie de la fourniture de logiciels. Lorsque du code avec des erreurs est rapidement mis en production et commence à poser des problèmes, une responsabilité commune entre les équipes peut compliquer la tâche de déterminer la source du problème et de déterminer qui est chargé de le résoudre.
Alors que la majorité des entreprises en sont à mi-parcours, voire au début, de leur aventure dans DevOps, beaucoup n’ont pas de processus formel en matière de fiabilité, ce qui entraîne une confusion quant au rôle que chaque membre de l’équipe joue. Cette tendance à la désorganisation était encore plus marquée dans les grandes entreprises que dans les petites. Seulement 27,9% des entreprises de moins de 50 employés ont signalé un problème lié à des propriétaires multiples / peu clairs, contre 36,5% des entreprises de plus de 1 000 employés, soulignant les défis supplémentaires liés à la mise à l'échelle.
Conclusion
Source : rapport (au format PDF)Envoyé par OverOps
Et vous ?
Que pensez-vous de la philosophie DevOps ?
Voir aussi :
Répondre avec citation
Partager