Propriété du service Il s'agit d'une bonne pratique DevOps dans laquelle les membres de l'équipe assument la responsabilité de soutenir le logiciel qu'ils livrent à chaque étape du cycle de développement. Ce niveau de propriété rapproche beaucoup les équipes de développement de leurs clients, de l'entreprise et de la valeur fournie.

Les propriétaires de services sont les experts en la matière (SME) de leurs services. Dans un modèle de propriété de service, ils sont également responsables de la réponse à tout problème de production. Pour les équipes qui adoptent ce modèle, être de garde peut sembler intimidant. Peut-être avez-vous entendu des histoires d'horreur sur les week-ends et les soirées passés à tenir votre ordinateur portable et à répondre aux incidents ?

Il n'y a pas moyen de dissimuler la réalité : être de garde est difficile. Mais les meilleures pratiques, comme la propriété du service, peuvent apporter plus de structure et de prévisibilité aux astreintes, de sorte que, idéalement, la qualité de vie de chacun s'en trouve nettement améliorée.

Pourquoi la propriété des services est-elle importante ?

Imaginez ce scénario : vous êtes convoqué à une réunion parce que quelque chose est faux quelque part dans le système, mais comme vous n'avez pas déterminé les propriétaires de services, personne ne sait qui est la PME. Quinze minutes se transforment en 20, puis 30, et ainsi de suite. Pendant ce temps, de plus en plus de personnes répondent à l'appel, mais ne font aucun progrès.

Ce type de réponse chaotique aux incidents fait perdre un temps précieux – c'est l'incarnation même de l'inefficacité. Et le pire, c'est que cela se produit encore tout le temps.

Il n'est pas nécessaire que cela se passe ainsi. Mais examinons d'abord pourquoi tant d'équipes sont accablées par des réponses manuelles aux incidents qui traînent en longueur. Lorsque vous examinez les raisons de ce ralentissement, cela se résume au fait que les équipes ne sont pas en mesure de répondre à quelques questions très importantes :

• Quels services sont impactés ?
• À qui appartiennent ces services ?
• Quelles sont les dépendances de ces services – et à qui appartiennent-ils ? ceux prestations de service?

Les réunions comme celle-ci tentent de répondre à ces questions, mais de manière réactive. Tant que les équipes ne parviennent pas à répondre à ces questions, elles sont dans l'impasse et ne peuvent pas progresser dans la résolution de l'incident.

Ce phénomène devient de plus en plus courant à mesure que l'écosystème technologique continue d'évoluer et de devenir plus complexe dans les entreprises de toutes tailles. Des centaines de services, de microservices et une propriété distribuée rendent difficile de savoir comment agir en cas de problème.

La propriété des services peut aider les organisations à devenir plus proactives en matière de réponse aux incidents. Néanmoins, ce n’est pas une promenade de santé. Le changement culturel est difficile, et même les organisations les plus performantes qui ont réussi le passage à DevOps et à la propriété des services s’accorderont à dire que le respect des meilleures pratiques et la mise en place d’un processus d’adoption de la propriété des services peuvent contribuer à la fidélisation et à l’évolution de l’ensemble de l’organisation.

Lorsque les organisations sont en mesure d'adopter la responsabilité des services, tout le monde, des propriétaires de services aux parties prenantes exécutives en passant par les clients, en profite. Les propriétaires de services ne sont appelés à intervenir qu'en cas de nécessité. Les parties prenantes savent ce qui est affecté par un incident et peuvent collaborer avec l'équipe technique pour en atténuer l'impact. Les clients bénéficieront d'une interruption de service plus courte et d'une communication plus claire tout au long du processus.

Dans un monde où les attentes des clients n’ont jamais été aussi élevées et où l’expérience client est essentielle, cela peut placer votre organisation au-dessus de la concurrence – tout en améliorant la vie des personnes qui répondent à l’incident.

Mais qu'est-ce qu'un service en réalité ?

Définir un service peut s'avérer plus compliqué qu'il n'y paraît à première vue. Nous avons vu des organisations diviser les services de nombreuses manières, et ce n'est pas toujours aussi simple que de faire correspondre les services à ce qui est déployé dans le cloud. Pour certaines organisations, il existe également un monolithe qui doit être pris en compte. Alors, comment pouvez-vous déterminer comment diviser les choses en éléments gérables dont une équipe peut être responsable ?

Chez PagerDuty, nous définir un service comme « un élément fonctionnel distinct qui apporte de la valeur et qui appartient entièrement à une équipe ». Une autre façon de le considérer est qu'un service représente une entité que vous surveillez et sert de conteneur pour les incidents connexes qui associe les incidents aux bonnes politiques d'escalade.

En bref, cela se décompose comme ceci : si vous le surveillez et que vous souhaitez que des incidents y soient associés et que vous souhaitiez que certaines personnes soient de garde, alors c'est un service Il s’agit d’une définition plus large qui permet une plus grande flexibilité dans la manière dont les équipes peuvent définir les services non conventionnels.

Toutefois, les intervenants doivent connaître bien plus que ces limites pour être pleinement préparés à faire face aux problèmes. C'est là que la configuration des services peut faire une grande différence.

Qu’est-ce qui fait qu’un service est bien configuré ?

Chez PagerDuty, nous avons établi un ensemble de normes que nous pensons utiles aux organisations qui cherchent à approfondir leur parcours de propriété de services. Ceux-ci servent de lignes directrices sur la façon dont nous créons nos services et déterminent à quoi ressemble le « bon ».

Elles sont également flexibles. Tous les services ne sont pas conçus de la même manière et certaines de nos normes peuvent ne pas s'appliquer dans chaque situation. Considérez-les comme un point de départ que nos clients peuvent utiliser pour rendre les astreintes plus efficaces et moins pénibles pour leurs intervenants de première ligne.

Il est important de noter que chaque organisation évolue différemment et que la gestion des services est un processus, et non une simple case à cocher sur une liste de tâches. En fonction de votre maturité opérationnelle, vous devrez peut-être définir et adopter des normes à un rythme différent.

Si vous êtes une entreprise relativement petite et novice en matière de gestion de services, avec seulement quelques services principalement basés sur le cloud, vous pourrez peut-être définir des normes et configurer vos services en conséquence en quelques jours. Si vous partez de zéro, c'est encore plus simple : vous pouvez appliquer ces normes lorsque vous créez vos tout premiers services, ce qui vous permettra de réussir à long terme sans avoir à revenir en arrière et à apporter des modifications aux services précédemment configurés.

Mais si vous êtes une grande organisation avec des centaines, voire des milliers de services, ce changement peut être plus difficile. Pour ces organisations, voici quelques questions à poser qui peuvent vous aider à réfléchir à la manière d'avancer :

1. Pour quels sous-ensembles de services existants pourriez-vous établir des normes aujourd’hui, et quelles sont ces normes ? Vous constaterez peut-être que certaines normes sont faciles à appliquer à tous vos services. Par exemple, les services doivent avoir un nom qui décrit précisément ce qu'ils font. S'il existe des normes de ce type que vous savez que la majorité des services doivent suivre, c'est un bon point de départ pour les mettre en œuvre. Réfléchissez à la manière dont vous pourriez demander aux équipes pilotes d'effectuer ces changements.
2. À quoi ressemble le processus de création de nouveaux services nets ? Vous avez peut-être défini vos normes, mais modifier tous vos services actuels pour qu'ils répondent à ces normes est une tâche difficile. Si vous êtes une grande organisation, il n'est généralement pas possible de reconfigurer tous les services en même temps. Et la reconfiguration des services peut être plus frustrante que de suivre un processus pour les configurer correctement dès le départ.
3. Quel est votre objectif à long terme et à quoi ressemble un calendrier pour y parvenir ? Certains services peuvent ne pas avoir besoin de ces normes, et ce n'est pas grave. Établissez un plan pour le reste des services avec une date limite, puis commencez à intégrer des équipes supplémentaires au processus, en apportant de petits changements progressifs au fil du temps.
4. Comment connaissons-nous nos dépendances ? Au-delà de la création et de l'application de normes, il est également important de savoir comment vos services s'articulent entre eux et s'influencent mutuellement. Lors de l'élaboration de normes, réfléchissez à la manière dont vous pouvez encourager la codification de ces informations au cours du processus de configuration.

Prises individuellement, les réponses à ces questions peuvent ne pas sembler constituer un facteur de différenciation majeur, mais lorsque vous réfléchissez à leur ampleur, elles font une grande différence dans la manière dont vous réagissez aux incidents.

Comment cela aide-t-il à répondre aux incidents ?

Lors de la réponse à un incident, il est important de ne pas perdre de temps ni d'énergie sur des tâches inutiles. Tout doit être réduit à ce sur quoi l'équipe doit se concentrer pour résoudre l'incident.

La propriété du service vous aide à gagner en clarté tout au long du processus de réponse :

Par exemple, si vous avez bien configuré votre service, vous serez alerté avec le niveau d'urgence approprié et un minimum de bruit d'alerte, ce qui vous permettra de répondre uniquement aux signaux les plus importants et de hiérarchiser les priorités en conséquence. Vous pourrez également faire intervenir rapidement les bonnes personnes, car vous saurez qui sont les responsables du service. À mesure que vous gagnerez en maturité, vous pourrez également créer des séquences d'automatisation pour vos services qui vous aideront à réduire le travail nécessaire pour rétablir le service à la normale.

Il est également plus facile de diagnostiquer ce qui n'a pas fonctionné, car vous verrez ce qui a changé sur le service. Et avec cartographie des services, vous pouvez comprendre l’impact global sur le système.

Lors de la résolution, vous pouvez travailler plus rapidement avec les intégrations dont votre service a besoin et tenir les parties prenantes informées. Vous pouvez rationaliser la communication uniquement avec les personnes qui, selon vous, seront affectées par votre incident, en limitant l'impact au minimum, même au sein de l'organisation.

Enfin, vous tirerez de meilleurs enseignements des incidents. En tant qu'expert en la matière pour votre service, vous bénéficierez d'un contexte historique et pourrez réintégrer ces enseignements dans votre processus de réponse, ce qui vous rendra plus résilient au fil du temps.

À mesure que vous développez la propriété des services dans toute l'organisation, ces améliorations font une différence considérable pour les clients et les membres de l'équipe. Si vous cherchez à adopter la propriété des services ou à améliorer votre maturité opérationnelle et que vous souhaitez un partenaire capable de vous guider tout au long du processus, essayez PagerDuty gratuitement pendant 14 jours . Si vous souhaitez en savoir plus sur la normalisation de la propriété des services à grande échelle, consultez ce webinaire .