Incidents

Le ticket d'incident est le point d'entrée de l'alerting. À l'inverse d'un processus basé sur des dashboards de supervision qui nécessitent la surveillance constante d'opérateurs, l'alerting par ticket permet de notifier les intervenants de façon pro-active, et uniquement lorsqu'un problème est détecté. Il réduit donc le besoin de ressources liées à la surveillance d'un système, et améliore les temps de détection.

Sous quelle forme se présente un Incident ?

Sur Astry, tout problème est qualifié d'Incident. Il se présente sous la forme d'un ticket, qui comporte :

• un titre et la description du problème (les descriptions au format JSON, HTML ou Markdown sont automatiquement détectées et mises en forme)
• un statut (Ouvert, Pris en compte ou Résolu)
• une priorité, de P1 à P5 : Critique, Important, Moyen, Faible et Information
• une assignation, à une équipe ou directement à un utilisateur
• des tags
• des commentaires pour assurer le suivi de l'incident
• l'historique des évènements de l'incident (changements de statut, de priorité, d'assignation, escalades, ...)
• les alertes reçues pour cet incident, ainsi que les notifications envoyées
• des méta-données (identifiant, date d'ouverture, source, ressources impactées, incidents liés, ...)

Tous les incidents (et les crises) de votre organisation sont listés dans l'Inbox.

Processus de travail lorsqu'un incident est levé

Lorsqu'un incident survient, un ticket est levé (via email, API, Prometheus, sonde, appel téléphonique, ... : voir Intégrations) et apparaît à l'état Ouvert. Il est alors assigné à une équipe par les règles de routage, et la personne d'astreinte de cette équipe est notifiée. Puis on suit traditionnellement ces étapes lorsqu'on intervient sur l'incident :

1. On prend en compte (acknowledge) l'incident pour signaler aux membres de son équipe que l'incident a été vu et que quelqu'un a débuté l'investigation.
2. On analyse le problème en traçant ses avancées sur le ticket d'incident.
3. On remet le service impacté up si possible (sans nécessairement corriger la root cause).
4. On résout l'incident sur Astry.
5. Puis éventuellement on rédige un compte-rendu d'incident et on trace les tâches de résolution long terme (la résolution de la root cause si ça n'a pas été traité).

Note : Un incident peut aussi être créé manuellement depuis l'Inbox, via le bouton Créer un incident : vous renseignez alors son titre, sa priorité, sa description, et optionnellement une équipe (sinon ce sont les règles de routage qui l'assignent), des ressources et des tags.

Les états d'un incident

Un incident peut avoir trois états différents :

1. Ouvert : il s'agit de l'état par défaut lorsque l'incident est créé et qu'il n'a pas encore été vu ou pris en compte. Si un incident reste à l'état Ouvert, alors le membre de l'équipe qui est d'astreinte continuera à être alerté (régulièrement dans le temps, suivant sa stratégie de notifications). S'il reste trop longtemps dans cet état, il peut être automatiquement escaladé (voir Escalades).
2. Pris en compte : une fois l'incident pris en compte, il passe à l'état Pris en compte. Dans cet état, le membre de l'équipe qui est d'astreinte n'est plus alerté. L'incident peut néanmoins repasser à l'état Ouvert, soit manuellement, soit lors d'une réassignation, soit automatiquement via les stratégies de réouverture. Dans ce cas l'astreinte sera de nouveau alertée.
3. Résolu : une fois l'incident résolu, il ne peut plus changer d'état sans action manuelle. L'astreinte n'est bien sûr plus notifiée.

Note : Astry supporte la dé-duplication des incidents. Cela signifie que si deux incidents du même type sont levés alors que le premier des deux est toujours à l'état Ouvert ou Pris en compte, alors le deuxième incident ne sera pas créé, car Astry considère qu'il s'agit en réalité d'une seconde alerte pour le même incident (cela permet d'éviter d'ouvrir plusieurs tickets d'incidents pour le même problème et d'être spammé). Dans ce cas la seconde alerte est rattachée à l'incident existant, et apparaît dans l'onglet Alertes de la page de l'incident. Une fois l'incident passé à l'état Résolu alors, si l'alerte survient à nouveau, un nouvel incident sera créé. Astry se base sur un attribut correlationId pour détecter la dé-duplication (voir la documentation de chaque intégration sur l'outil Astry pour positionner cette valeur).

La page d'un incident

En cliquant sur un incident depuis l'Inbox, vous accédez à sa page. Elle regroupe :

• l'en-tête, avec le titre, le statut et les tags de l'incident, tous modifiables directement
• la description de l'incident
• trois onglets :
  • Commentaires et changements : l'historique complet de l'incident (changements de statut, de priorité, de titre, de tags, assignations, escalades, réouvertures automatiques, mises en sourdine, ...), ainsi que les commentaires. Les commentaires sont en texte riche et peuvent contenir des images.
  • Alertes : le contenu brut de chacune des alertes reçues pour cet incident (y compris les alertes dé-dupliquées).
  • Notifications : chaque tentative de notification effectuée pour cet incident, par canal (email, SMS, appel téléphonique, notification push, Microsoft Teams), avec son résultat (envoyée avec succès, ou la raison de l'échec, par exemple l'absence de canal vérifié).
• un panneau d'informations, avec l'identifiant, la date de création, l'assignation, la personne actuellement d'astreinte pour l'équipe assignée, la priorité, la source de l'incident, les ressources impactées et les incidents liés.

Un indicateur Vu par affiche par ailleurs quels membres de votre organisation ont consulté l'incident, et jusqu'à quel évènement.

Actions sur un incident

Depuis la page d'un incident, vous pouvez :

• le prendre en compte, le résoudre ou le ré-ouvrir
• le ré-assigner à une équipe ou à un utilisateur (s'il n'est pas à l'état Ouvert, l'incident est alors ré-ouvert par défaut, afin que la nouvelle cible soit notifiée)
• modifier sa priorité, son titre et ses tags
• le mettre en sourdine pour une durée donnée (en minutes, heures ou jours) ou indéfiniment : les notifications liées à l'incident sont alors suspendues jusqu'à la fin de la sourdine
• le surveiller : vous êtes alors informé par email de chaque action ou commentaire sur cet incident (voir Notifications)
• le lier à d'autres incidents, en précisant le type de lien (en relation avec, dépend de, est une dépendance de)
• lui associer des ressources
• le supprimer (réservé aux Propriétaires) : tous les commentaires et évènements associés sont alors définitivement supprimés

Note : Les Parties prenantes ont un accès en lecture seule aux incidents : elles ne peuvent pas en modifier le statut, l'assignation, la priorité ou les tags.

Stratégies d'escalade et de réouverture

Astry vous permet de définir des stratégies d'escalade flexibles. En fonction d'un ensemble de critères que vous définissez (tags, priorité, ...), les incidents assignés à une équipe qui restent à l'état Ouvert plus d'une heure (ou plus de 3 jours, etc) seront automatiquement assignés à l'équipe ou à l'utilisateur de votre choix. Vous avez ainsi la garantie qu'un incident sera toujours détecté et traité. Bien sûr vous avez aussi la possibilité d'escalader manuellement chaque incident en l'assignant à n'importe quelle équipe. Tous les détails sont décrits sur la page Escalades.

De la même façon, les stratégies de réouverture permettent de ré-ouvrir automatiquement un incident resté trop longtemps à l'état Pris en compte, afin qu'il ne soit jamais oublié.