Résoudre les incidents est complexe. Selon votre situation, vous perdez peut-être un temps précieux à identifier les notifications qui constituent un incident. Chaque notification doit être triée afin d'évaluer sa nature potentielle d'incident avant de pouvoir être résolue ou ignorée (considérée comme non incident). Ce processus peut paraître fastidieux, mais la meilleure façon de progresser est de définir précisément ce qu'est un incident. Et ça tombe bien ! Cet article de blog est justement consacré à ce sujet. Une fois cette étape franchie, vous serez en bonne voie pour optimiser vos processus et simplifier l'identification et la résolution des incidents à chaque itération.

Avant toute chose : qu’est-ce qu’un incident ? Chez PagerDuty, nous définissons un incident comme « toute interruption ou dégradation non planifiée du service qui affecte activement la capacité des clients à utiliser PagerDuty». Nous distinguons également ce que nous appelons un incident majeur, c’est-à-dire « tout incident nécessitant une réponse coordonnée entre plusieurs équipes ». Cela diffère d’un « événement », qui peut être de toute nature. La rédaction d’un message de journalisation est un exemple d’événement, mais l’impossibilité de rédiger un message de journalisation peut indiquer un incident (ou un incident imminent). Comprendre le caractère perturbateur d’un incident est essentiel pour l’identifier : si vous recevez un message (courriel, chat, SMS, appel) et que son contenu n’est pas perturbateur, il ne s’agit pas d’un incident.

Il est essentiel de consacrer du temps à la création et à la maintenance d'alertes bien conçues. Pourquoi ? Parce que toutes les alertes n'impliquent pas nécessairement des incidents, mais l'objectif est que tous les incidents soient identifiables grâce aux alertes. Si vous ne planifiez pas vos messages d'alerte, il est probable qu'un incident grave passe inaperçu dans le flux d'informations habituel des systèmes en fonctionnement normal. Cela comporte plusieurs aspects :

• Toutes les alertes doivent être exploitables.
• Les alertes doivent être aussi « bruyantes que nécessaire » (nous y reviendrons dans un instant).
• Les alertes doivent être synchronisées avec les modifications apportées à votre système et/ou à votre code (par exemple, ne pas envoyer d'alerte pour un point de terminaison migré).

Examinons de plus près ce deuxième point : qu’entend-on par « aussi bruyant que possible » ? On peut parfois l’appréhender intuitivement. Vous ne voulez pas être réveillé en pleine nuit parce que la base de données utilise trop peu de mémoire (Hein ?). D’un autre côté, vous faire Vous souhaitez être alerté en cas d'impact sur vos clients suite à une interruption de connexion à votre base de données ? Pour les alertes plus vagues, et même certaines des plus fréquentes, il est nécessaire de définir clairement leur priorité, leur urgence et leur gravité afin de les catégoriser.

En termes simples :

• Priorité. L'ordre et la rapidité de traitement des alertes et incidents varient selon les cas. Une alerte de haute priorité exige une intervention immédiate, une alerte de basse priorité requiert une action ultérieure, et une alerte informative est simplement une alerte de « pour information ». Outre la mention « haute/basse priorité », on trouve généralement des classifications telles que « P1, P2 » ou « SEV1, SEV2 » pour cette catégorie.
• Urgence. Chez PagerDuty, nous utilisons ce système pour définir vos préférences de notification. En général, ces préférences sont directement liées au niveau de priorité. Autrement dit, une notification urgente (appel ou SMS) est réservée aux alertes prioritaires, tandis qu'une notification moins urgente (e-mail, messagerie instantanée) est réservée aux alertes non prioritaires.
• Gravité Cela permet de préciser la gravité du problème, généralement définie à l'aide de termes tels que critique, erreur, avertissement, information, etc.

Pour une analyse plus approfondie, veuillez consulter notre Guide des opérations de réponse aux incidents, et plus particulièrement : Principes d'alerte et Niveaux de gravité .

Puisque nous parlons d'alertes, abordons un sujet connexe : l'incident lui-même. Lorsqu'une alerte correspond aux critères d'un incident, celui-ci devient actif. C'est parfait ! 😅 Les incidents sont généralement résolus par un appel. Il peut s'agir d'un appel téléphonique, d'une visioconférence, des deux, ou, comme auparavant, les intervenants concernés pouvaient se réunir physiquement dans une salle de réunion. Quoi qu'il en soit, il est désormais essentiel que chacun puisse communiquer. Quelques règles de base faciliteront cette communication : veillez à ce que personne ne se coupe la parole.

Quelques règles de base permettront d'éviter que les participants ne se coupent la parole. Par exemple, utiliser des emojis de réaction sur Zoom ou lever la main devant la caméra. Assurez-vous que votre micro est coupé si vous n'êtes pas l'orateur principal et/ou utilisez un logiciel comme Krisp pour réduire les bruits de fond. De plus, que vous utilisiez la parole ou l'écrit, évitez autant que possible les acronymes et le jargon. Le simple fait de taper ou de dire « Expert en la matière » au lieu de « SME » évite de perdre du temps à définir les acronymes pendant l'appel. Ceci est particulièrement important car, surtout en cas d'incident majeur, tous les participants à l'appel n'utilisent pas forcément les mêmes acronymes et le même jargon. Il peut y avoir des représentants des équipes front-end, back-end, UI, juridiques et RH parmi les participants ou ceux qui reçoivent les mises à jour. En réalité, il est fort probable que… volonté Que les personnes présentes lors de l'appel ne soient pas des ingénieurs.

Pourquoi ? La gestion d'un incident actif implique de nombreux processus, et le triage et la résolution n'en constituent qu'une partie. C'est le rôle des ingénieurs (experts métiers) ; cependant, qui communique les mises à jour de statut aux équipes, à l'entreprise, voire en externe ? Qui documente les actions entreprises et leur calendrier ? Idéalement, l'équipe d'ingénierie travaillant à la résolution de l'incident ne devrait pas être affectée à d'autres tâches. Cela signifie que d'autres groupes peuvent, et doivent, être d'astreinte. Chez PagerDuty, nous avons défini ces rôles distincts dans le cadre de notre processus de gestion des incidents. Ces rôles comprennent :

• Commandant des opérations
• Adjoint
• Scribe
• Expert en la matière
• Liaisons avec les clients et/ou les communications internes

En bref, le responsable des incidents prend la décision finale quant aux mesures à prendre et à leur calendrier. Il s'appuie sur les informations fournies par les ingénieurs et les experts métiers concernés pour orienter sa décision, mais aucune action n'est entreprise sans son accord. Son adjoint est son second et peut prendre le relais si nécessaire. Le secrétaire documente l'incident en temps réel, par exemple : « Redémarrage du cluster Kubernetes à 8 h, cluster de nouveau en ligne ». Les experts métiers comprennent les services et systèmes impactés par l'incident et travaillent activement à sa résolution. Enfin, les chargés de liaison sont responsables de la communication des mises à jour. Il est essentiel que ce rôle soit distinct, car les cadres et représentants internes auront besoin d'informations qu'ils pourront également communiquer à leurs propres parties prenantes, clients, etc. Pour plus d'informations sur la formation à ces rôles, veuillez consulter notre [lien/ressource]. Formation au commandement des incidents page.

Ouf ! Je sais que c'était beaucoup d'informations, mais vous êtes maintenant en bonne voie pour simplifier la gestion de vos alertes et incidents. N'hésitez pas à nous contacter sur notre Forums communautaires Si vous avez des questions ou si vous souhaitez simplement discuter, n'hésitez pas à nous contacter !

Cet article a été initialement publié le 17 juillet 2020. Offrir de meilleurs résultats.