Alors aujourd'hui dans ce podcast que je vous propose c'est de parler alerting
qui est un élément qui fait partie intégrante de l'observabilité finalement
et qui est extrêmement important et parfois sous-estimé.
Donc, digue-le, c'est parti !
Alors pour commencer, qu'est-ce que l'alerting ?
Alors si on devait le résumer, c'est un ensemble de règles à la fois pour définir des seuils
donc des seuils par rapport à des métriques qui évoluent au fur et à mesure au cours du temps.
Des seuils à partir desquels on va déterminer un niveau de gravité qui peut être critique,
qui peut être du warnier ou de l'information, c'est généralement les termes qu'on y retrouve
en fonction de la gravité finalement de l'incident qu'on relève.
Donc peut-être que c'est un accident qui est simplement informatif puisqu'on souhaite avoir une information
mais ça peut être critique, voire vitale pour la société en question.
Donc ça, c'est la notion de seuil.
Ensuite, pour ce seuil, on va y appliquer une fréquence,
c'est-à-dire la fréquence de vérification et la durée sur laquelle on souhaite en tout cas
alerter quelqu'un, si possible quelqu'un qui a en mesure d'agir pour pouvoir résoudre le problème.
Donc suivrant un laps de temps donné que cette alerte, que ce seuil a été dépassé,
on va considérer qu'on va avoir une règle qui a été, qui doit être transmis.
Et pour ça, on va utiliser un système de notification,
donc ça, ça fait partie intégrante des règles,
système de notification qui peut reposer sur différents canaux de notification,
soit des canaux de type SMS, du mail, éventuellement vers Slack, PagerDuty ou d'autres systèmes
qui peuvent exister et voire même on peut imaginer dupliquer les choses
pour pouvoir les envoyer aussi dans un système de type base de données ou messtéque,
pour pouvoir ensuite en tirer des statistiques ou générer pourquoi pas des actions directement.
Mais vous voyez qu'en fonction des canaux derrière,
on a déjà un premier effet qui va jouer, c'est qu'en fonction du canal vers lequel on diffuse,
ou des canaux vers lequel on diffuse, puisqu'on peut faire de la multidiffusion également,
on va avoir une implication où en tout cas on va rentrer plus ou moins dans la vie des gens,
potentiellement, et puis on va plus ou moins forcer les gens à l'intervenir.
Donc ça, c'est une première chose qui est importante à noter,
c'est que suivant les canaux de notification, on va avoir plus ou moins de réactions
et plus ou moins une attention plus ou moins importante sur les alertes qui vont être déclenchées.
Parfois, si c'est intrusif de type SMS par exemple,
on va chercher à résoudre les alertes et faire en sorte surtout qu'elles ne reviennent pas.
Et puis par contre, quand c'est quelque chose qui tombe trop facilement,
et ça on le retrouve assez souvent dans pas mal de sociétés,
quand on retrouve des notifications par exemple sur les canaux Slack,
il peut se passer simplement qu'au bout d'un laps de temps donné,
le canal ne fait qu'empiler des alertes et personne ne les traite
et ne cherche d'une part à les résoudre et à faire en sorte surtout qu'elles ne se reproduisent pas.
Donc ça, c'est quelque chose qui est très important pour à la fois donc la réaction
et l'implication qu'on va y mettre derrière.
Donc ça, c'est quelque chose qui est très important.
Alors derrière, c'est seuil.
Qu'est-ce qu'on en fait finalement ? C'est règle.
Qu'est-ce que l'on en fait ?
Et bien, je dirais, il y a deux cas de figure d'utilisation,
si on les prend au sens large.
D'une part, la production, on va y en venir, et d'autre part, la strainte.
On est dans deux contextes relativement différents qui peuvent sembler un petit peu similaires.
Néanmoins, il faut quand même les considérer comme différents
puisque derrière, on ne va pas intervenir de la même manière et de fait,
on ne va pas chercher à traiter les choses de la même manière
ou toutes les choses comme on va être dans un cas de figure ou dans l'autre.
Donc sur la production, le but, c'est de traiter l'ensemble des alertes,
en tout cas le maximum, par ordre de priorité.
Généralement, la priorité se base sur ce seuil de gravité
puisque si on a quelque chose qui est critique,
bien c'est bien plus important qu'à quelque chose qui va être du warning, par exemple.
Et puis, donc le caractère vital aussi pour la société et pour le business également.
Donc c'est généralement aussi ce qu'on englobe un petit peu sous forme de run.
En tout cas, c'est une sous-partie quand on parle de run,
c'est-à-dire que c'est quelque chose qui va se faire en journée de travail habituel, je dirais,
et qui va être vérifié un petit peu en permanence par pas mal de personnes
sous réserve de recevoir les notifications,
mais avec la possibilité éventuellement de pouvoir le consulter à la demande un petit peu plus facilement.
Donc ça, on va dire, c'est la production.
La strainte, c'est quelque chose de beaucoup plus délicat
parce que c'est quelque chose qui est hors période de travail, classique, j'entends.
Et qui va faire en sorte que le but derrière, c'est qu'une personne soit notifiée
et n'intervienne que sur notification.
Ça, c'est quelque chose qui est important au niveau de la strainte
et c'est là aussi où on détermine le bon niveau,
ou en tout cas la bonne constitution d'un système d'alerte.
C'est que la personne n'intervient que sur les alertes
et ne soit pas là à vérifier telle ou telle chose de manière manuelle
parce que du coup, on change complètement la posture de la personne en question.
Donc derrière, l'objectif de la strainte, c'est de résoudre ce qui va être critiqueau,
en tout cas ce qui est vital, important,
et ne pas s'intéresser forcément aux problèmes, aux petits incidents
qui eux ne restent que du bruit et qui peuvent attendre potentiellement un peu plus de temps,
qui est quelqu'un ou en tout cas des équipes qui pourront se charger de cette tâche potentiellement.
Alors derrière, donc du coup, on découle principalement au niveau de l'alerting
des bonnes pratiques ou des mauvaises pratiques,
une mauvaise alerting, un mauvais système d'alerting, c'est quoi ?
En tout cas, ce que ça entraîne, c'est surtout ça qui est important
et c'est là où ça se détermine finalement en regardant le quotidien des gens qui reçoivent cet alerting.
C'est combien de temps est passé, tout simplement, à vérifier les choses hors alerting.
C'est-à-dire que si j'ai besoin de regarder des dashboards ou autres,
parce que je ne reçois pas d'alerting, dans ce cas-là, j'ai un très mauvais alerting,
il faut que j'ai la capacité finalement pour l'alerting de pouvoir finalement fermer mon laptop,
notamment quand je suis en astreinte et surtout quand je suis en astreinte,
de manière à faire en sorte que je sois bien un système d'astreinte.
Si j'ai besoin de regarder et de checker en permanence et de diagnostiquer des choses
en concilitant des différents dashboards et graphiques,
bien finalement je passe à côté de l'exercice.
Donc ça c'est premier point.
Derrière en astreinte, derrière ça pose aussi des questions.
C'est finalement est-ce que ce qui est facturé en dehors du temps d'incident,
mais en temps de check, est-ce que finalement c'est le temps de check qui doit être facturé
ou c'est vraiment que le temps d'intervention.
Bien sûr, il faut prendre en compte cet élément en paramètre dans les décisions en tout cas
qui sont prises au niveau des rémunérations, au niveau de la astreinte.
Derrière, l'autre élément aussi qui est important, c'est qu'un bon système d'alerting
va faire en sorte de ne pas altérer la productivité des équipes.
Si on a des équipes qui sont sur des travaux mixtes, donc run, projet,
et qui doivent travailler, pouvoir se concentrer sur des tâches,
si en permanence ces personnes ont besoin de regarder des graphiques
pour pouvoir les diagnostiquer parce qu'on manque d'alerting,
et bien dans ce cas de figure-là, il y a des concentrations.
On ne peut pas gérer les projets de la même manière,
switcher de tâches administratives vers des tâches de vérification.
Donc ça alterne globalement le travail des personnes
et ça peut faire en sorte aussi que les personnes qui ont un salaire donné,
ça a éventuellement plus important, se retrouvent à faire finalement du run
ou en tout cas des tâches qui ne sont pas forcément attribués habituellement
à des salaires de ce niveau-là.
Au niveau financier, bien sûr, c'est un impact.
Ce n'est pas forcément là où on va performer,
où on va avoir la meilleure efficacité des équipes,
ou en tout cas le meilleur efficacité des euros investis
et du travail qui en est réalisé à la suite.
Donc ça, c'est quelque chose qui est important.
Et puis le troisième point qui est important,
c'est que si on ne dispose pas de ce système d'alerting,
comme on dit, on peut se retrouver dans le cas de figure,
on va regarder en permanence des différents graphiques, etc.
Et là, finalement, du coup, c'est laisser à la libre interprétation
des personnes qui regardent ces graphiques.
Et ça veut dire que suivant une journée,
si c'est Titi, Toto qui regarde les dashboards,
eh bien, on va avoir une interprétation qui va être assez différente.
Et la gestion du coup va être relativement hétérogène des solutions à apporter,
et surtout le filtre qui est en amont des solutions qui vont être apportées.
C'est qu'est-ce qui est réellement problématique et qu'est-ce que je regarde ?
Certains vont laisser filer plus de choses en étant plus confiants peut-être,
et puis d'autres vont regarder plus dans le détail plus de choses.
Donc ça, c'est quelque chose qui est aussi très, très important.
Bref, l'alerting, donc si on devait en tirer quelques bonnes pratiques,
en tout cas, c'est extrêmement important.
C'est un outil notamment, on n'a pas parlé jusqu'ici de prédiagnostique,
c'est-à-dire qu'il doit fournir des informations sur la criticité,
mais également sur l'alerte qui est déclenchée,
donc le libellé de l'alerte va être très important,
et les éléments, les méthodes d'attards, on va dire, autour de l'alerte,
si on devait parler de manière un petit peu plus tech,
ça va être par exemple sur quel serveur, sur quel applicatif,
quelle est la proportion, quel est le nombre, quels sont les valeurs,
quel est le trafic réseau, etc.
Donc ça, c'est quelque chose qui est très, très important.
Plus on va fournir d'informations, mieux c'est.
Il ne faut pas en fournir trop non plus,
parce que par exemple, quand une personne est en astreinte,
si on lui fournit une page entière à lire,
et qu'il est obligé de rediagnostiquer, relire les choses,
pour diagnostiquer les choses, pour se dire,
ok, il y a une alerte et je vais à tel endroit,
là aussi, on risque d'avoir quelque chose
qui finalement se tire un petit peu une balle dans le pied,
donc il faut savoir doser les choses.
La deuxième chose qui est importante aussi, c'est que le système d'alerting,
généralement, c'est aussi un moyen de documenter,
ou en tout cas de forcer de la documentation.
Ça, c'est extrêmement important, et donc de pouvoir discerner
quelques actions à réaliser pour chacune des alertes,
pouvoir les documenter, les stocker,
faire en sorte que si cette alerte se redéclenche,
ce soit une autre personne qui puisse le faire,
voire une personne qui n'a pas forcément les compétences à la base.
Ça, c'est aussi quelque chose qui est très, très important.
Et ce qui est aussi important, donc, à partir de ces systèmes d'alerting,
c'est de faire une revue de ces alertes régulièrement
pour pouvoir dire, OK, cette alerte-là est revenue très souvent,
est-ce que je peux la corriger, et comment je fais pour faire en sorte
qu'elle ne se reproduise jamais,
si elle se reproduit, quelles actions on peut mener,
est-ce que derrière, on va déclencher des systèmes de ticket,
de story, etc., parce qu'on veut impliquer encore plus les gens
dans les solutions, ça, c'est quelque chose qui est important.
Derrière vient aussi le fait qui est destinataire des alertes.
C'est aussi ça qui va faire en sorte que
on va avoir un système, une production au sens large
qui va bien fonctionner, c'est-à-dire faire en sorte que cette alerting,
eh bien, il y en est à relever avec des statistiques.
Alors, je ne demande pas quelque chose qui demande une étude poussée,
mais simplement de se dire comment évoluent les choses,
quelle est la température de notre production,
sur quels éléments finalement ont tiédi un petit peu,
et quelles actions on va pouvoir mener,
et ça, ça nécessite l'implication de personnes
qui sont en mesure de diriger, de prendre des actions,
en tout cas de donner des tâches à réaliser,
et puis aussi les personnes qui sont à côté,
et également, ça veut dire des ops,
mais ça veut dire aussi potentiellement des devs,
pour faire prendre en compte bien les évolutions qui sont amenées.
On retrouve par ailleurs parfois des canaux spécifiques
pour les équipes de devs, pour les équipes d'ops,
et les équipes de devs qui ont poussé un applicatif.
On se retrouve dans le you-build-it, you-run-it,
c'est-à-dire que les personnes qui n'ont pas forcément en instruits,
mais au moins en journée, en production,
se retrouvent qui ont développé les applicatifs.
En question, on se retrouve à un moment donné,
en mesure de pouvoir gérer la production de leur applicatif
de manière à avoir quelque chose qui est une sorte de boucle de rétroaction,
de faire en sorte que les développeurs se retrouvent encore plus impliqués
dans les solutions amenées.
Voilà, on a fait un tour un petit peu global de l'alerting,
quand même assez sommaire, une petite dizaine de minutes.
J'espère que ce podcast vous a plu.
N'hésitez pas à vous abonner sur Rochab,
vous retrouverez les liens à droite à gauche,
les applicatifs habituels de comment de podcast,
vous tapez Xavki, vous le retrouverz,
l'ensemble des podcasts de la chaîne.
Et moi, je vous dis à très bientôt sur Xavki.
Ciao à tous !