L'auteur tient à souligner que ce blog n'a certainement pas été retardé plusieurs fois par ses collègues contributeurs, Dave Bresci et Arup Chakrabarti.

La surveillance est une forme d'art. Cela peut paraître ringard et paresseux, mais le bon type de surveillance dépend fortement du contexte et la même pratique fonctionne rarement sur plusieurs logiciels ou personnes.

Cela devient encore plus difficile lorsque l'on pense aux architectures logicielles modernes. Microservices ? Planificateurs de conteneurs ? Groupes de mise à l'échelle automatique ? Sans serveur ? ${New-technology-that-will-solve-all-of-my-problems-but-probably-creates-other-problems}?

En plus de tout cela, la définition de ce qu’est un « service » dépend de la personne à qui vous parlez.

Pour un ingénieur logiciel, un service est un élément isolé de fonctionnalité qui s'appuie sur les technologies mentionnées précédemment. Pour un client, un service est un produit pour lequel il paie. Pour un PDG, un service est quelque chose qui tombe en panne pour pouvoir crier après son vice-président senior de l'ingénierie.

Dans cet article, nous partagerons comment nous, PagerDuty, configurons et surveillons nos services au sein de notre propre instance de PagerDuty. Vous apprendrez quelques conseils pour aborder la propriété d'un service complet sans perdre (beaucoup) de sommeil et satisfaire vos clients et parties prenantes de votre entreprise.

Déterminer le service et les composants

Un service est généralement constitué de plusieurs composants. La plupart des équipes bien formées possèdent 5 à 10 services en production, avec 3 à 5 composants par service. Idéalement, un service appartient à une seule équipe qui détient la propriété totale des composants. Si ce n'est pas le cas, les composants sont le premier domaine sur lequel il faut envisager de répartir la propriété.

Jetons un œil à un service Web typique à trois niveaux.

1. Vous aurez votre Load Balancer pour le routage des requêtes
2. Vos serveurs d’application exécuteront la logique métier (souvent, c’est la seule partie considérée comme faisant partie du « Service »)
3. Votre base de données sert réellement à conserver les données de vos clients.

Dans ce scénario, nous avons trois composants faisant partie d’un même service.

Maintenant, commençons à faire évoluer ce service Web. Vous ajouterez probablement une couche de mise en cache pour sauvegarder votre base de données médiocre, ajouterez des nœuds CDN pour accélérer les performances et utiliserez un service hébergé pour vous décharger d'une partie du travail.

Vous disposez désormais d'un service unique composé de six composants distincts. Chaque composant nécessite un certain niveau de télémétrie et de visibilité, mais cela ne signifie pas que vous devez surveiller et alerter sur chaque composant. Cela vous amènerait à vous concentrer sur l'état de santé des composants, alors que vous devriez plutôt vous concentrer sur l'état de santé global du service.

Il existe différentes manières de modéliser même un service « unique » comme celui-ci : certaines organisations considèrent les couches d’infrastructure partagées, telles que les couches réseau ou les bases de données, comme un service distinct des services destinés aux clients.

Se concentrer sur les alertes impactant le client

Pour commencer, visez les alertes les plus basiques pour les comportements qui intéressent vos clients. N'oubliez pas que les clients peuvent être des équipes internes ou des personnes externes qui paient pour votre produit. Cela commence généralement par des contrôles de ping de base (est-il opérationnel ?) et évolue vers des questions plus sophistiquées (fonctionne-t-il assez vite ?).

Le plus difficile ici est qu'il est très difficile d'anticiper toutes les façons dont vos clients vont utiliser votre service. C'est pourquoi il est tout à fait acceptable de laisser certains problèmes surgir trop tard, puis de déterminer plus tard comment surveiller et prévenir les problèmes à l'avenir. Si vous essayez d'anticiper tous les problèmes, vous finirez par créer des centaines d'alertes qui deviendront du bruit. Pensez d'abord à des catégories générales telles que la disponibilité et les performances, puis, au fur et à mesure de vos itérations, devenez plus précis.

Par exemple, avec la disponibilité, vous pouvez commencer par le pourcentage de requêtes HTTP traitées avec succès, puis passer aux répartitions des erreurs, aux répartitions par composant, etc. Pour les performances, vous pouvez commencer par le temps de chargement global de la page, puis passer aux composants de page individuels, au contenu tiers, aux transactions multipages, etc. Tenez compte du danger des moyennes et adoptez la méthode des centiles. Vous pouvez en savoir plus à ce sujet ici : https://www.dynatrace.com/news/blog/why-averages-suck-and-percentiles-are-great/ et ici: https://medium.com/@djsmith42/how-to-metric-edafaf959fc7

Ajouter des alertes est facile, les supprimer est difficile

Ne vous limitez jamais aux anciennes alertes. Ce qui avait du sens lorsque votre service comptait 10 clients et trois composants n'a plus de sens lorsque vous avez des milliers de clients et une douzaine de composants.

Si vous répondez oui à l’une des questions suivantes, c’est le signe que vous devez vous débarrasser d’une alerte :

• Les gens ignorent-ils cette alerte ?
• La plupart du temps, vous mettez cette alerte en veille, en attendant qu'une autre alerte plus pertinente ou plus importante arrive ?
• La formulation de l’alerte reflète-t-elle une ancienne façon de penser ou quelque chose qui n’existe plus ?

Nous avons parlé de l’importance de Examens opérationnels et une partie essentielle de ces tâches consiste à comprendre quelles alertes vous pouvez supprimer. En règle générale, si une alerte n'a donné lieu à aucune action pendant trois cycles de révision consécutifs, supprimez-la ou transformez-la en alerte. événement supprimé que vous pourrez consulter plus tard. Il se peut que vous ayez besoin de optimisez la configuration de votre service dans PagerDuty .

Définir les SLI, les SLO et les SLA est très difficile

Vous trouverez ci-dessous les définitions que nous utilisons en interne chez PagerDuty, mais si vous n'êtes pas familier avec la terminologie, nous vous recommandons fortement de lire Les livres de Google sur le sujet.

En bref, pensez aux SLA, SLO et SLI comme suit.

SLA (Accord de niveau de service). Ce que vous publiez comme promesse à vos clients. Chaque service doit avoir exactement un SLA. Exemple : 99,9 % de disponibilité.
SLO (Objectif de niveau de service). Votre objectif interne pour votre SLA. En général, il s'agit d'une version plus conservatrice de votre SLA. Exemple : 99,99 % de disponibilité.
SLI (indicateur de niveau de service) . Des informations objectives sur l'état actuel de votre service qui vous aident à déterminer si vous atteignez votre SLO ou SLA. Par exemple, le pourcentage de requêtes ayant obtenu une réponse HTTP 200 en moins de 300 ms.

Comme pour la plupart des services que vous lancez, vous risquez de vous tromper dans vos SLA, SLO et SLI dès le premier essai, et ce n'est pas grave. Le plus important est de définir quelque chose afin de pouvoir l'affiner au fil du temps à mesure que vous en apprenez davantage sur votre service et votre entreprise.

Une bonne évolution pourrait ressembler à :

1. Pourcentage de demandes n’ayant pas donné lieu à une réponse 5XX.
2. Pourcentage de requêtes qui n'ont pas reçu de réponse 5XX et ont été traitées en moins de 300 ms.
3. Pourcentage de requêtes qui n'ont pas reçu de réponse 5XX et ont été traitées en moins de 150 ms.

Chez PagerDuty, il nous a fallu des années pour comprendre comment mesurer avec précision ce qui importait à nos clients, et ce qui compte pour eux a radicalement changé au fil du temps. Bien que nos définitions de nos SLA, SLO et SLI internes ne soient pas parfaites, nous disposons de quelque chose que nous pouvons affiner au fil du temps, à mesure que nos équipes en apprennent davantage sur ce qui compte pour les clients. Pour en savoir plus sur la façon dont les SLO peuvent assurer une surveillance saine des services et influencer les décisions commerciales, écoutez Liz Fong-Jones Discussion QCon, Cultiver l’excellence de la production.

Ça en vaut la peine

Réaliser tout ce travail n'est pas facile et il ne sera jamais terminé ou parfait. Mais cela en vaut la peine.

Votre équipe aura une idée plus claire de ce qui se passe au lieu de paniquer lorsque quelque chose ne va pas. Elle pourra se concentrer sur le problème et aura un signe clair du moment où elle a terminé.

Les gens ne peuvent pas réagir à tout comme s'il s'agissait d'une urgence absolue. Comprendre et publier vos accords de niveau de service permet aux gens de savoir quand et comment ils disposent d'un budget d'erreurs avec lequel travailler. Le réglage de vos alertes permettra aux gens de se concentrer sur les problèmes réels au lieu de rester insensibles au bruit des alertes.

Et surtout, faites cela parce que vous vous souciez de vos clients. Si vous n'ajustez pas et n'itérez pas la surveillance de vos services, vous leur transmettez directement la douleur. Pour en savoir plus sur la façon d'optimiser vos configurations de service dans PagerDuty, lisez ici : https://support.pagerduty.com/docs/best-practices-service-configuration

Dites-nous ce que vous pensez de la surveillance des services. Nous vous en serions reconnaissants. j'adore entendre comment d’autres personnes travaillent à travers ce processus.