La résolution des incidents est difficile. En fonction de votre situation actuelle, vous risquez également de perdre beaucoup de temps à déterminer quelles notifications constituent un incident. Cela se traduit par une perte de temps de plus en plus importante, car chaque notification doit être triée comme un incident potentiel avant de pouvoir passer à la résolution ou à l'ignorer (comme un non-incident). Tout cela peut sembler très fastidieux, mais le moyen le plus rapide de s'améliorer est d'apprendre et de définir ce que sont les incidents. Et vous avez de la chance ! C'est le sujet de cet article de blog. Une fois que vous aurez terminé, vous serez sur la bonne voie pour commencer à nettoyer vos processus afin de faciliter l'identification et la résolution des incidents à chaque itération.

Tout d’abord : qu’est-ce qu’un incident ? Chez PagerDuty, nous définissons un incident comme « toute interruption ou dégradation imprévue 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 ». Ceci est différent d’un « événement » qui pourrait être n’importe quoi. L'écriture d'un message de journal est un exemple d'événement, mais l'incapacité d'écrire un message de journal peut impliquer un incident (ou un incident entrant). Comprendre le caractère perturbateur d'un incident est essentiel pour son identification : si vous recevez un message (e-mail, chat, SMS, appel) et ses informations non perturbatrices, alors ce n'est pas 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 d'incidents, mais l'objectif est que tous les incidents soient identifiables via des alertes. Si vous ne planifiez pas vos messages d'alerte, il est probable qu'un incident grave ne soit pas signalé dans le bavardage général des systèmes d'exploitation réguliers. Cela comprend plusieurs éléments :

• Toutes les alertes doivent être exploitables
• Les alertes doivent être aussi « bruyantes que possible » (plus d’informations à ce sujet 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 alerter sur un point de terminaison migré)

Examinons de plus près ce deuxième point : qu'entends-je par « aussi bruyant que cela puisse paraître logique » ? Une partie de cela est identifiable par intuition. Vous ne voulez pas être réveillé au crépuscule parce que la base de données utilise trop peu de mémoire (Quoi ?). D'un autre côté, vous faire vous souhaitez être alerté en cas d'impact sur le client provenant d'une connexion à la base de données défaillante. Pour les alertes les plus nébuleuses, et même certaines des plus courantes, vous devrez définir des définitions claires afin de savoir comment catégoriser chacune d'elles : priorité, urgence et gravité.

Tout simplement:

• Priorité. La rapidité et l'ordre dans lesquels une alerte ou un incident doit être traité. Une alerte de priorité élevée doit être traitée immédiatement, une alerte de priorité faible nécessite une action à un moment donné et une alerte informative n'est qu'une « alerte pour information ». En plus de « haute/basse », vous verrez généralement des répartitions telles que « P1, P2 » ou « SEV1, SEV2 » pour cette catégorie.
• Urgence. Chez PagerDuty, nous l'utilisons pour définir la manière dont vous souhaitez être averti. En général, cela est en phase avec la priorité. J'entends par là qu'une notification de haute urgence (généralement un appel ou un SMS) est destinée à une alerte de haute priorité, une faible urgence (e-mail, chat) à une alerte de faible priorité.
• Gravité . Cela indique la gravité du problème, généralement défini à l'aide de termes critiques, d'erreurs, d'avertissements, d'informations, etc.

Pour une analyse plus approfondie de ces éléments, veuillez consulter notre Guide des opérations de réponse aux incidents, en particulier Principes d'alerte et Niveaux de gravité .

Pendant que vous réfléchissez aux alertes, abordons un sujet connexe, l'incident lui-même. Lorsqu'une alerte répond aux critères d'un incident, vous avez désormais un incident actif. C'est génial ! 😅 Les incidents sont généralement résolus par un appel. Il peut s'agir d'un appel téléphonique, d'une conférence Web, des deux ou, « avant », les intervenants concernés pouvaient se réunir physiquement dans une salle de conférence. Quoi qu'il en soit, tout le monde doit désormais pouvoir communiquer. Certaines règles d'engagement de base vous aideront à y parvenir : prenez des mesures pour vous assurer que les gens ne parlent pas les uns sur les autres.

Certaines règles de base permettent d'éviter que les gens parlent en même temps que les autres. Par exemple, utilisez les reactjis dans Zoom ou levez les mains devant la caméra. Assurez-vous que votre micro est coupé si vous n'êtes pas l'orateur actif et/ou utilisez quelque chose comme Krisp pour éviter le bruit de fond. De plus, que vous utilisiez la parole ou le texte, veillez à éviter autant que possible les acronymes et le jargon. Le travail supplémentaire nécessaire pour taper ou dire « expert en la matière » au lieu de « SME » évite d'avoir à passer du temps à définir des acronymes lors de l'appel. Cela est extrêmement pertinent car, en particulier dans le cas d'un incident majeur, tous les participants à l'appel ne partagent pas nécessairement le même usage des acronymes et du même jargon. Il se peut que des représentants du front-end, du back-end, de l'interface utilisateur, du service juridique et des ressources humaines soient présents lors de l'appel ou reçoivent des mises à jour. En fait, il est plus probable qu'improbable qu'il y ait des représentants du front-end, du back-end, de l'interface utilisateur, du service juridique et des ressources humaines lors de l'appel ou recevant des mises à jour. volonté ne pas être des ingénieurs lors de l'appel.

Pourquoi est-ce? La gestion d’un incident actif implique beaucoup de choses et le tri et la résolution n’en sont qu’une partie. C'est l'objectif des ingénieurs (c'est-à-dire les experts en la matière) ; cependant, qui communique les mises à jour de statut aux équipes, à l’entreprise ou même à l’extérieur ? Qui documente ce qui est essayé et quand ? Idéalement, l’équipe d’ingénierie qui travaille à la résolution de l’incident ne devrait assumer aucune autre tâche. Cela signifie que d’autres groupes peuvent et doivent être de garde. Chez PagerDuty, nous avons défini ces rôles distincts comme notre processus de gestion des incidents. Ces rôles comprennent :

• Commandant d'intervention
• Adjoint
• Scribe
• Expert en la matière
• Agents de liaison avec les clients et/ou les communications internes

En bref, le commandant de l'incident est celui qui prend la décision finale sur les mesures à prendre et le moment de leur mise en œuvre. Il s'appuie sur les contributions des ingénieurs et des experts en la matière concernés pour guider la décision, mais aucune action n'est entreprise sans leur feu vert. L'adjoint est le commandant en second pour aider le commandant de l'incident et prendre en charge la gestion de l'incident si nécessaire. Le scribe documente l'incident au fur et à mesure qu'il se produit, par exemple « redémarrage du cluster Kubernetes à 8 h, remise en ligne du cluster ». Les experts en la matière sont ceux qui comprennent les services et les systèmes impactés par l'incident et travaillent activement à le résoudre. Et enfin, les agents de liaison sont responsables de la communication des mises à jour de statut. Il est essentiel d'avoir un rôle distinct, car les cadres et les représentants internes auront besoin de mises à jour qu'ils pourront également communiquer à leurs propres parties prenantes, clients, etc. Pour plus d'informations sur la façon de former ces rôles, veuillez consulter notre Formation au commandement des interventions page.

Ouf ! Je sais que c'était beaucoup, mais vous êtes maintenant sur la bonne voie pour rationaliser vos alertes et incidents. N'hésitez pas à nous contacter sur notre Forums communautaires Si vous avez des questions complémentaires ou si vous souhaitez simplement discuter, nous serions ravis de vous entendre !

Cet article a été publié précédemment le 17 juillet 2020 sur Offrir de meilleures prestations.