.. _Incidents: Incidents ========= Le ticket d'incident est le point d'entrée de l'alerting. A 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 :ref:`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 : * la description du problème * un statut (*Ouvert*, *Pris en compte* ou *Résolu*) * une priorité (de 1 - critique - à 5 - non critique) * des commentaires pour assurer le suivi de l'incident * des évènements sur l'incident * et des méta-données (tags, identifiants, date d'ouverture, ...) Processus de travail lorsqu'un incident est levé ------------------------------------------------ Lorsqu'un incident survient, un ticket est levé (via email, API, Prometheus, ... : voir :ref:`Integrations`) et apparaît à l'état **Ouvert**. 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é). 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 :ref:`stratégie de notifications`). 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 est d'astreinte n'est plus alerté. L'incident peut néanmoins repasser à l'état Ouvert, soit manuellement, soit automatiquement via les :ref:`stratégies d'escalade`. 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. .. image:: _static/Astry_States_and_assignment.png :alt: States and assignment .. 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 sera indiquée sur 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). .. _EscalationPolicies: Stratégies d'escalade --------------------- 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 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. L'image ci-dessous décrit l'exemple d'une escalade d'un incident d'une équipe N1 à une équipe N2, en automatique ou en manuel. .. image:: _static/Astry_Escalation_workflow.png :alt: Escalation workflow Votre organisation et vos processus peuvent nécessiter des stratégies d'escalade différents. Si vous souhaitez par exemple une escalade managériale (l'incident est escaladé du collaborateur responsable de l'astreinte vers son responsable hierarchique si aucune action effectuée au bout de quelques heures, puis vers le responsable hierarchique suivant ensuite, etc) plutôt qu'une escalade technique comme dans l'exemple plus haut, c'est possible par configuration. Vous pouvez par exemple définir une stratégie d'escalade comme celle-ci : .. image:: _static/Astry_management_escalation_example.png :alt: Escalation workflow