Close

Ready for ITSM at high velocity?

Comment exécuter le support informatique à la DevOps

Il est prouvé que l'intégration des principes DevOps au sein de vos équipes d'ingénierie et de services informatiques améliore considérablement la qualité du service, le moral des équipes, la résolution des problèmes et la productivité de l'entreprise. En fait, les entreprises qui adoptent les principes DevOps enregistrent une amélioration de 45 % de la satisfaction des clients, une hausse de 43 % de la productivité des employés, une baisse de 41 % des taux de défauts et une baisse de 38 % des coûts informatiques.

Avec des statistiques comme celles-ci, l'intégration des principes DevOps à la gestion des services informatiques constitue une grande victoire pour les entreprises. Mais ce changement peut sembler compliqué pour les équipes. La bonne nouvelle ? Ce n'est pas aussi compliqué que ça en a l'air. Les clés pour booster les performances des services sont d'une simplicité déconcertante.

Qu'est-ce que DevOps ?

Alors, qu'est-ce que DevOps exactement ? Il s'agit d'un ensemble de pratiques qui rassemble deux entités souvent cloisonnées qui s'opposent de longue date, j'ai nommé : les équipes de développement et opérationnelles. L'objectif est la collaboration, la communication ouverte et la recherche de solutions pour permettre aux deux équipes d'atteindre leurs objectifs respectifs.

Comme l'expliquent nos experts : « DevOps est un ensemble de pratiques qui automatisent les processus entre les équipes de développement et informatiques afin de leur permettre de développer, tester et livrer des logiciels plus rapidement et avec plus de fiabilité. Le concept de DevOps repose sur la mise en place d'une culture de la collaboration entre les équipes qui étaient, historiquement, cloisonnées. Parmi les avantages assurés, le gain de confiance, l'accélération des livraisons, la capacité à résoudre les tickets plus rapidement ou encore la gestion plus efficace des tâches non planifiées. »

Pourquoi DevOps pour le support informatique ?

Du point de vue de l'entreprise, les chiffres parlent d'eux-mêmes : amélioration de 45 % de la satisfaction des clients, hausse de 43 % de la productivité des employés, et baisse de 38 % des coûts informatiques. Le mouvement DevOps a contribué de manière significative aux résultats de l'entreprise, ce qui explique probablement que 4 entreprises sur 5 disent appliquer au moins certains principes DevOps.

Tout aussi convaincants pour les équipes elles-mêmes, ces principes améliorent la satisfaction, la collaboration et la reconnaissance des employés et de l'équipe (s'ils sont appliqués correctement). Ils simplifient les processus complexes, accélèrent les tâches et suppriment un niveau de bureaucratie qui a longtemps causé des tensions au sein des équipes informatiques, de développement et d'autres équipes interdépendantes.

Là où les équipes opérationnelles étaient frustrées par les nouvelles versions qu'elles ne connaissaient pas et n'étaient pas prêtes à gérer (et qui, selon Gartner, entraînaient 85 à 87 % des incidents), DevOps ouvre les canaux de communication et prépare les opérations informatiques à l'avenir. Là où les équipes de développement étaient frustrées par un retour des équipes opérationnelles qui ralentissait les lancements, elles peuvent désormais collaborer pour accélérer des lancements qui n'affectent pas les engagements SLA et les objectifs SLO.

DevOps pour le service informatique : bonnes pratiques

Priorisez un virage culturel

Le virage culturel constitue le principal défi de l'intégration DevOps.

Les organisations informatiques traditionnelles sont souvent cloisonnées, l'équipe de développement travaillant au sein de son propre écosystème et l'équipe opérationnelle prenant le relais (souvent avec peu ou pas d'avertissement des changements système avant qu'ils ne se produisent) dès qu'un changement est apporté.

Les organisations DevOps quant à elles accordent la priorité à la collaboration et à la communication entre les équipes (par le biais de pratiques et d'outils, tels que les hackathons, les stand-ups et les groupes de discussion).

Adopter ce changement implique d'adopter de nouveaux outils, de nouveaux processus et une nouvelle perspective culturelle qui privilégie la communication entre les équipes et la réussite partagée.

Automatisez ce qui peut l'être

Les gains de productivité obtenus grâce à DevOps sont, du moins en partie, imputables à une philosophie qui privilégie l'automatisation. Adopter DevOps revient à encourager les équipes à se demander constamment à quel niveau elles pourraient automatiser leurs processus.

Pouvons-nous automatiser la revue de code pour les erreurs courantes ? Pouvons-nous automatiser les systèmes pour associer les problèmes, les incidents et les demandes aux changements ou versions qui peuvent les avoir déclenchés ? Pouvons-nous automatiser les contrôles qui nous empêchent de publier du code qui ne répond pas aux exigences légales ou de sécurité ? Pouvons-nous automatiser les systèmes pour geler les nouvelles versions lorsque nous approchons de nos objectifs SLO ?

Il existe des dizaines de façons d'automatiser et d'améliorer les métriques DevOps. Voici trois des plus courantes :

  • Workflow (par exemple : déplacer plus rapidement les tickets de support via le centre de services)
  • Connaissances (lorsqu'un incident survient, votre outil de gestion des services doit automatiquement fournir les connaissances et la documentation pertinentes)
  • Remontée (s'il n'y a que deux personnes dans votre organisation à même de résoudre un problème, un système intelligent devrait le leur faire remonter directement au lieu de suivre des parcours de remontée rigides et linéaires)

Suivez les métriques importantes

Au fur et à mesure que les équipes de développement et informatiques opérationnelles travaillent ensemble, les bonnes pratiques leur dictent également de s'assurer que tout se passe bien.

Les indicateurs de performance clés (KPI) DevOps communs comprennent le temps moyen entre pannes (MTBF), le temps moyen jusqu’à la remise en route (MTTR), le temps moyen de bon fonctionnement (MTTF) et le temps moyen d'accusé de réception (MTTA). De nombreuses entreprises s'appuient également sur des chiffres, tels que le nombre d'alertes ou de demandes générées dans un certain laps de temps, le coût des temps d'arrêt par minute, ou le coût du support par appel/demande.

Les métriques que vos équipes devront suivre dépendent des équipes elles-mêmes, des promesses faites aux clients dans vos accords SLA, des objectifs SLO que vous avez convenus avec l'organisation et des points sensibles spécifiques que vous ciblez. Il est également important de comprendre que les métriques constituent une cible mobile. Au fur et à mesure des évolutions au sein de l'entreprise (produits pris en charge par le service informatique, besoins des parties prenantes, ou encore obligations légales ou de sécurité externes), les métriques que vous suivez et la façon dont vous les suivez peuvent également devoir changer.

Priorisez le partage

DevOps consiste à combler le fossé entre la création et la maintenance, les créateurs et les soutiens. Il s'agit de créer des points de vue, des objectifs, des processus et du vocabulaire communs. De partager les connaissances et la communication. Les boîtes à outils, les ressources et les bases de codes. Plus important encore, il s'agit d'une propriété commune, c'est-à-dire d'une responsabilité et d'une réussite partagées.

Pour de nombreuses organisations traditionnelles, passer à DevOps implique de repenser la définition, la reconnaissance et le suivi de ces responsabilités et réussites partagées. Les objectifs des équipes de développement et opérationnelles sont-ils aux antipodes ? La réussite d'une équipe complique-t-il celle d'une autre équipe ?

Par exemple : si l'équipe de développement est chargée de lancer de nouvelles fonctionnalités le plus rapidement possible et que l'équipe informatique opérationnelle est chargée de maintenir la disponibilité, ces deux objectifs peuvent avoir un impact négatif réciproque. Les équipes opérationnelles peuvent souhaiter ralentir les développeurs afin de dépasser les objectifs de disponibilité, et les développeurs peuvent en vouloir aux équipes opérationnelles qui les empêchent d'atteindre les objectifs de leur lancement.

Pour de nombreuses équipes DevOps, la solution est une approche SRE, selon laquelle les équipes de développement peuvent effectuer autant de lancements qu'elles le souhaitent tant que la disponibilité est comprise dans les objectifs SLO. Lorsque la disponibilité atteint des niveaux inacceptables, tous les lancements sont gelés jusqu'à ce que les équipes collaborent pour rétablir la disponibilité à son niveau normal.

ITIL et DevOps

Si vous adoptez les pratiques ITIL, vous vous demandez peut-être où DevOps s'intègre. Pour de nombreuses entreprises, les pratiques ITIL et DevOps peuvent fonctionner ensemble. En fait, chez Atlassian, nous voyons beaucoup d'entreprises bénéficier des avantages et des forces des deux solutions.

Comme cet article relatif à DevOps et ITIL l'explique : « Nous avons besoin des deux. Nous parlons de solutions complémentaires, et non concurrentielles. Nous devons pouvoir travailler plus intelligemment et plus rapidement, mais nous avons également besoin de processus et de contrôles. Les équipes et les organisations modernes et performantes commencent à le comprendre et à utiliser des éléments des deux solutions (elles ne se demandent plus laquelle des deux utiliser). »

Les pratiques ITIL ont tendance à prendre en compte les bonnes pratiques en matière d'opérations, de support, de gouvernance et d'autres fonctions métier de base. DevOps apporte des éléments, tels que la livraison continue, la culture sans reproches, les outils de collaboration et les pratiques Agile qui reposent sur les pratiques intégrées depuis longtemps dans les lignes directrices ITIL et les améliorent.

Outils pour les organisations orientées DevOps

Adopter une approche DevOps peut également signifier adopter de nouveaux outils pour la communication, l'automatisation et la collaboration entre les équipes.

Lors de l'évaluation de nouveaux outils, il est important de poser des questions telles que :

  • Cet outil fonctionne-t-il dans notre environnement et s'intègre-t-il aux outils existants ?
  • Répond-il à nos besoins ?
  • Tous les nouveaux outils fonctionnent-ils de concert dans un ensemble d'outils complet et cohérent ?

Nous sommes peut-être partiaux, mais chez Atlassian, nous utilisons Jira Service Management pour la gestion des changements et la gestion des incidents, Confluence pour la gestion des connaissances, Jira Software pour le développement logiciel et Bitbucket pour notre dépôt de code.

Si ces outils fonctionnent si bien, c'est en partie parce qu'ils fonctionnent bien ensemble. Et lorsque vous décloisonnez vos structures d'équipe, vous voudrez également décloisonner les outils que vous choisissez.