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

Bonjour et bienvenue dans le quatrième article de notre série sur l'architecture EI, consacré au regroupement d'alertes intelligent. Nous avons déjà parlé de la manière de former le regroupement d'alertes intelligent à l'aide de fusions d'incidents ( ici ) et comment configurer les titres de vos alertes pour améliorer la correspondance par défaut. Dans cet article, nous allons expliquer comment la conception de services peut également avoir un impact sur votre expérience avec Intelligent Alert Grouping ainsi qu'avec 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 qui fonctionne dans votre organisation. La 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é discrète 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 va créer et maintenir le service, et cela inclut la réponse à tout incident. Pour un récapitulatif des services et de la propriété, veuillez consulter notre Guide complet des opérations de propriété du service sur 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 des noms. Vous devriez pouvoir parcourir le Annuaire des services et être capable de comprendre facilement ce qu'est chaque service sans aucune connaissance institutionnelle supplémentaire. En bref, c'est la différence entre un service nommé « Service de paiement » ou le fait de savoir/référencer la documentation interne selon laquelle tous les services transactionnels portent le nom de dieux grecs, puis de rechercher quel dieu grec correspond au 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.

Une dernière connaissance sur les services avant de continuer : dans l'application PagerDuty , les services sont distincts des services métiers. Jusqu'à présent, tout ce que j'ai mentionné ci-dessus est pertinent pour prestations de service . Vous pouvez également les voir désignés comme services techniques dans notre documentation pour éviter toute confusion avec les services commerciaux. Les services aux entreprises sont des agrégats de services techniques ou d'autres services métier, généralement en fonction de votre logique métier et/ou de vos parties prenantes. Intelligent Alert Grouping n'utilise que des services techniques, et non des services métier. Par conséquent, lorsque je fais référence aux services dans cet article, je fais uniquement référence aux services techniques.

Granularité

Trouver l’équilibre entre les services est une tâche non triviale et il n’existe pas de solution universelle pour y parvenir. Vous équilibrez et échangez essentiellement plus ou moins de granularité. Une utilisation très granulaire des services consisterait, par exemple, à disposer d'un outil de surveillance unique dont toutes les fonctions des composants sont décomposées en services distincts dans l'application PagerDuty . D'un autre côté, 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 géré par des équipes distinctes avec des responsabilités distinctes. Ce dernier exemple montre également pourquoi il ne peut y avoir une seule recommandation sur la façon de structurer vos services, puisque certaines organisations auront une équipe mobile unique, pas d'équipe mobile, des équipes mobiles distinctes divisées selon différents critères.

Et alors peut Nous faisons? Nous pouvons extraire quelques conseils qui peuvent vous aider à naviguer dans vos définitions de services. Le premier point de départ est la question de la propriété. L'une des principales raisons de définir des services dans l'application PagerDuty est à des fins de réponse aux incidents, ce qui signifie que savoir qui peut répondre de manière concrète aux problèmes liés à un service est à qui appartient le service, et donc qui possède les services dans votre organisation peut guider comment vous les définissez dans PagerDuty. Ceci est important car si vous disposez d'une structure de service existante qui n'est pas un modèle de propriété de service complet, mais que vous savez quels sont les chemins de remontée d'informations souhaités, vous pouvez utiliser ces connaissances. Dans ce cas, lorsque Intelligent Alert Grouping regroupe les incidents, le résultat est que même si les services ne sont liés que dans le chemin d'escalade souhaité, c'est celui qui compte dans ce contexte et sera le résultat final que vous obtiendrez.

Vous devez également examiner vos projets actuels et voir lesquels constituent effectivement une unité fonctionnelle, et définir ceux-ci comme un service unique dans PagerDuty. Cela devrait garantir que les projets qui ont les mêmes chemins d'escalade sont toujours correctement regroupés, mais éviter le scénario dans lequel plusieurs projets sont définis comme un seul service uniquement en raison de leur chemin d'escalade, perdant ainsi en visibilité. En allant un peu plus loin, si vous voyez deux services ou plus qui ont systématiquement des incidents en tandem, ils devront peut-être être regroupés en un seul service. À titre d'exemple spécifique, disons que vous disposez d'un microservice de surveillance doté de composants distincts pour les métriques, les pulsations, les journaux, etc. Si chacun d'entre eux dispose de son propre service PagerDuty , il est fort probable qu'un incident se produira simultanément sur tous ces services, et ils devraient plutôt être regroupés en un seul service en tant que microservice de surveillance lui-même. D’un autre côté, 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, les services risquent de ne pas être suffisamment granulaires. Dans ce scénario, il serait difficile de dire lesquelles des entités du service nécessitent plus d'attention que les autres, car elles constituent toutes une « chose » en ce qui concerne l'application PagerDuty .

Où aller en partant d'ici

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

• Chemins d'escalade
• Des noms
• Unités de fonctionnalité

Et puis utilisez-les pour vous guider dans la façon dont vous définissez les services dans l'application PagerDuty . Intelligent Alert Grouping partira de là, en regroupant les alertes sous des services corrélés. Si vous concevez des services à partir de zéro ou si vous révisez les définitions de services, jetez un œil à notre Guide des opérations de propriété à 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) prestations de service et les services aux entreprises . Dans notre prochain et dernier article de la série, nous récapitulerons tout ce que nous avons couvert. Utilisez le Série ei-architecture tag pour jeter un oeil à l'une des pièces de cette série.