Co-écrit par Chris Bonnell, Data Scientist VI PagerDuty

Bonjour et bienvenue dans le quatrième article de notre série sur l'architecture EI, consacré au regroupement intelligent d'alertes. Nous avons déjà abordé la formation du regroupement intelligent d'alertes à l'aide de fusions d'incidents ( ici ) et comment configurer vos titres d'alerte pour améliorer la correspondance par défaut. Dans cet article, nous allons voir comment la conception des services peut également influencer votre expérience avec le regroupement d'alertes intelligent et l'application PagerDuty en général.

Un peu sur les services

Avant de vous lancer dans la conception ou la refonte de vos services, il est important d'avoir une définition de service adaptée à votre organisation. Cette définition doit être suffisamment précise pour être comprise, mais suffisamment large pour que plusieurs équipes aient la même compréhension de ce qu'est un service de manière abstraite. est. Chez PagerDuty, nous utilisons la définition suivante :

UN service est une fonctionnalité distincte qui apporte de la valeur et qui appartient entièrement à une équipe.

Il est important de connaître l'équipe propriétaire, car c'est elle qui construira et maintiendra le service, et qui interviendra notamment en cas d'incident. Pour un récapitulatif des services et de la propriété, veuillez consulter notre Guide complet des opérations de propriété des services. Définition d'un service .

En plus de réfléchir aux services et à qui les possède, vous devrez également être attentif au service noms. Vous devriez pouvoir parcourir le Annuaire des services et être capable de comprendre facilement la nature de chaque service sans connaissances institutionnelles supplémentaires. En résumé, c'est la différence entre un service nommé « Service de paiement » et le fait de savoir/consulter la documentation interne indiquant que tous les services transactionnels portent le nom de dieux grecs, puis de rechercher à quel dieu grec correspond le service qui gère le paiement. Nous abordons ce sujet en détail dans le Services de dénomination section du Guide des opérations de propriété du service complet.

Un dernier point à savoir sur les services avant de poursuivre : dans l'application PagerDuty , les services sont distincts des services professionnels. Jusqu'ici, tout ce que j'ai mentionné ci-dessus s'applique à services Vous pouvez également les voir appelés services techniques dans notre documentation pour éviter toute confusion avec les services commerciaux. Services aux entreprises Il s'agit d'agrégats de services techniques ou d'autres services métier, généralement définis selon votre logique métier et/ou vos parties prenantes. Le regroupement d'alertes intelligent utilise uniquement des services techniques, et non des services métier. Par conséquent, lorsque je parle de services dans cet article, je fais uniquement référence aux services techniques.

Granularité

Trouver l'équilibre entre la séparation des services est une tâche complexe, et il n'existe pas de solution universelle. Il s'agit essentiellement d'équilibrer et d'alterner entre une granularité plus ou moins fine. Une utilisation très granulaire des services consisterait, par exemple, à utiliser un outil de surveillance unique dont toutes les fonctions sont réparties en services distincts dans l'application PagerDuty . À l'inverse, une utilisation plus large/moins granulaire des services consisterait à regrouper toutes les applications mobiles en un seul service, même si le développement iOS et Android est assuré par des équipes distinctes aux responsabilités distinctes. Ce dernier exemple illustre également l'impossibilité d'une recommandation unique pour la structuration des services, car certaines organisations auront une équipe mobile unique, d'autres pas, ou des équipes mobiles distinctes réparties selon des critères différents.

Et alors peut Et vous ? Nous pouvons vous donner quelques conseils pour vous aider à définir vos services. Commencez par la propriété. L'une des principales raisons de définir des services dans l'application PagerDuty est la gestion des incidents. Cela signifie que savoir qui peut intervenir efficacement en cas de problème avec un service est le propriétaire de ce service. Par conséquent, savoir qui possède les services dans votre organisation peut guider leur définition dans PagerDuty. Ceci est important, car si votre structure de service existante n'est pas un modèle de propriété complète, mais que vous connaissez les chemins d'escalade souhaités, vous pouvez exploiter ces connaissances. Dans ce cas, lorsque le regroupement intelligent des alertes regroupe les incidents, même si les services ne sont liés que par leur chemin d'escalade souhaité, c'est celui-ci qui compte dans ce contexte et qui constituera le résultat final.

Vous devez également examiner vos projets actuels et identifier ceux qui constituent une unité fonctionnelle, et les définir comme un service unique dans PagerDuty. Cela devrait garantir que les projets ayant les mêmes chemins d'escalade sont correctement regroupés, tout en évitant que plusieurs projets soient définis comme un seul service uniquement en raison de leur chemin d'escalade, ce qui entraînerait une perte de visibilité. Plus précisément, si deux services ou plus génèrent systématiquement des incidents en parallèle, il peut être nécessaire de les regrouper en un seul service. À titre d'exemple, imaginons que vous ayez un microservice de surveillance doté de composants distincts pour les métriques, les pulsations, les journaux, etc. Si chacun de ces services possède son propre service PagerDuty , il est fort probable qu'un incident survienne simultanément sur tous ces services ; il est donc préférable de les regrouper en un seul service, le microservice de surveillance lui-même. En revanche, si des projets distincts sont définis comme un seul service parce que les mêmes personnes y travaillent, mais qu'il s'agit d'entités distinctes, la granularité des services risque de manquer. Dans ce scénario, il serait difficile de déterminer lesquelles des entités du service nécessitent plus d’attention que les autres, car elles sont toutes une seule « chose » en ce qui concerne l’application PagerDuty .

Où aller à partir d'ici

Commencez à examiner vos services existants, et peut-être ceux qui seront bientôt créés, et vérifiez leurs :

• Chemins d'escalade
• Noms
• Unités de fonctionnalité

Utilisez-les ensuite pour définir les services dans l'application PagerDuty . Le regroupement intelligent des alertes prend le relais en regroupant les alertes sous des services corrélés. Si vous concevez des services de A à Z ou repensez leurs définitions, consultez notre Guide des opérations de propriété de service complet pour les meilleures pratiques en matière de dénomination et de propriété des réponses, ainsi que notre documentation sur (technique) services et services aux entreprises Dans notre prochain et dernier article de la série, nous récapitulerons tout ce que nous avons abordé. Utilisez le série ei-architecture tag pour jeter un œil à l'une des pièces de cette série.