Gestion des incidents#
Liens utiles#
- Jira Dashboard
- Tableau niveaux de monitoring par environnement
- Document de référence pour la résolution des incidents: help_alerts
- Critères fermeture incidents
- Annuaire Astreinte
Important
Le ticket d'incident ne doit pas être une solution de contournement pour réaliser un changement rapidement et sans ticket CAASCHR.
Principes des incidents#
Pourquoi organiser une gestion des incidents ?#
- Résolution des dysfonctionnements
- Visibilité des dysfonctionnements
- Communication auprès des clients
- Communication auprès des équipes
- Traçabilité des dysfonctionnements
Quand doit-on faire une déclaration d'incident ?#
- Lorsqu'un service n'est pas rendu de façon nominale. Les différents niveaux de monitoring par environnement sont detaillés dans ce tableau.
- Pour les alertes avec une sévérité Warning ou Critical en heures ouvrées.
- Pour les alertes avec une sévérité Critical en astreinte.
Exemples :
- Le service ne fonctionne pas
- Le service fonctionne partiellement
- Le service fonctionne plus lentement qu'observé habituellement
- etc.
Info
Les alertes de sévérité info ne rentrent pas dans le périmètre de la gestion d'incident.
Comment créer un incident ?#
Une déclaration d'incident se fait par le biais d'un ticket CAASINC dans Jira.
La communication d'ouverture d'un ticket CAASINC est faite automatiquement sur Mattermost dans #jira_Caasinc.
Que doit contenir un ticket d'incident à sa création ?#
À la détection de l'incident le ticket d'incident doit être créé et il doit contenir les éléments nécessaires à sa compréhension.
Les priorités sont les suivantes :
- Création du ticket le plus rapidement possible.
- Diagnostic et évaluation de l'impact de l'incident.
- Résolution de l'incident et enrichissement du ticket.
- Lorqu'il n'y a plus d'urgence, mettre en forme le ticket.
Comment remplir une déclaration d'incident ?#
À la création d'un ticket incident, il n'est pas nécessaire de remplir tous les champs avec précision. À cette étape, il est important d'aller vite.
Champs à remplir :
Projet
Caascad Incident.
Type de ticket
Incident.
Titre
Description de l'alerte sous la forme suivante: [Criticité][Zone]: Alertname.
Exemple: [CRITICAL][OCB-CORP]: PVCSpaceAlmostOutOfSpacePVC
Rapporteur/Reporter
La personne qui rédige le ticket CAASINC.
Caascad Labels
Alertname (ou Labels permettant de contextualiser l'alerte).
L'objectif est de pouvoir trouver l'incident en faisant une recherche en utilisant ce label.
Pour mettre un label constitué de plusieurs mots, comme entry out of order, on pourra le mettre en CamelCase : EntryOutOfOrder.
En cas d'hesitation sur plusieurs labels, il faut se mettre dans l'état d'esprit d'une recherche ultérieure : ce ticket doit-il remonter si on recherche chacun de ces labels?
Caascad Team
Équipe CaaSCAD en charge de l'analyse de l'incident.
Zone/Client
Zones et clients impactés/concernés par l'incident.
Descriptif
Description de l'incident, voir la section dédiée ci-dessous.
Priorité
Priorité attribuée à l'incident pour sa hiérarchisation dans le traitement, voir la section dédiée ci-dessous.
Pièce jointe
Peut servir à joindre un fichier si besoin.
Tickets liés
Indiquer les tickets liés et leur relation à ce CAASINC.
Il peut y avoir plusieurs cas :
- autre CAASINC similaire à celui-ci
- CAASCHR si l'incident fait suite à l'exécution d'un changement
- le ticket SUPIT et/ou CW si l'incident est en rapport avec un ticket client
Important
La stabilisation de la plateforme ne nécessite pas de ticket CAASCHR quand la correction se fait dans l'urgence.
Quand la correction n'est pas faite dans l'urgence (exemple: pérennisation de la correction, alignement configuration), il est nécessaire de créer un ticket CAACHR qui sera lié au ticket CAASINC.
Responsable/Assignee
La personne qui sera porteuse du ticket d'incident.
Comment remplir le descriptif ?#
La description doit être suffisamment compréhensible par un opérateur n'ayant pas expérimenté lui-même l'incident.
Le champ description doit contenir au moins une des descriptions suivantes, pour décrire l'incident :
- Alerte issue de la supervision.
- Capture de commandes illustrant le dysfonctionnement.
- Capture d’écran de l'alerte (example:
!capture.png|width=720!). - Une description textuelle caractérisant le dysfonctionnement.
- Une qualification fonctionnelle de l'impact sur le service.
Warning
Il peut y avoir des tickets sans alerte, il faut donc dans ce cas être le plus précis possible dans la rédaction du ticket et ajouter un label explicite.
Comment choisir le niveau de priorité ?#
Le niveau de priorité est lié au niveau de contrat de service que nous avons avec le client.
Nous appliquons les mêmes règles pour nos services internes.
| Niveau de priorité | Contexte |
|---|---|
| P1 | Perte complète du service ou impact sur l'activité (GTR 4h premium, 8h standard) |
| P3 | Service accessible mais dégradé (GTR 8h premium, 24h standard) |
| P3 | Service pas significativement impacté (GTR 32h premium, 48h standard) |
Warning
En cas de doute sur la priorité, préférez une priorité plus forte. Elle pourra être revue à la baisse ultérieurement.
Comment traiter un incident#
Pendant la résolution#
Le but lors de la résolution de l'incident est de stabiliser/corriger au plus vite. Dans ce cas, pas de ticket CAASCHR pour les modifications faites dans le cadre de la stabilisation (seul le ticket CAASINC suffit).
Warning
Un ticket CAASCHR est nécessaire une fois que la plateforme est stabilisée et qu'il est nécessaire de pérenniser la correction.
Escalade#
Lorsque le traitement de l'incident nécessite un travail à réaliser par une équipe de Build, le CAASINC peut être escaladé.
Il faut alors :
- vérifier que tout ce qui a déjà été réalisé dans le cadre du CAASINC est bien indiqué dans les commentaires ;
- ajouter un commentaire dans le CAASINC indiquant pourquoi on escalade et ce qui est demandé à l'équipe de Build ;
- indiquer à quelle équipe on escalade (Caascad Team) ;
- changer le CAASINC d'état et le passer à Request for Analysis ;
- vider le champs Responsable/Assignee.
Le CAASINC sera alors vu au prochain rituel de vérification des incidents escaladés par l'équipe de Build.
Après la résolution#
Après la résolution il est nécessaire de vérifier si le ticket CAASINC remplit tous les critères de fermeture d'un incident, puis passer le ticket en état In Review.
Seuls les membres de l'équipe Supervision sont habilités à fermer un CAASINC en état In Review. Ils peuvent également remettre le ticket CAASINC en état Open si les critères de fermeture ne sont pas en totalité remplis.
Conditions de fermeture d'un incident#
La clôture de l'incident doit se faire par un membre des équipes Support ou Opérations, et différente de celles qui ont travaillé dessus (procédure de revue par un pair).
Un incident doit remplir les conditions suivantes, afin d'être fermé.
Modèle pour Jira:
h1. Validation conditions de fermeture de l'incident
* (x) Le titre de l'incident est explicite
* (x) L'incident est terminé : retour à un mode de fonctionnement nominal du service
* (x) L'incident est expliqué : l'origine de l'incident est connue.
* (x) Le diagnostic est expliqué : les commandes, manipulations, consultations de dashboard sont expliquées.
* La résolution de l'incident est détaillée :
** (x) en commentaire du ticket avec une explication de la résolution,
** (x) les MR qui ont permis la résolution du ticket sont liées au CAASINC et sont en état mergé,
** (x) les tickets Jira participant à la résolution sont liés au CAASINC ;
* (x) La documentation de help_alerts est à jour.
* (x) Si nécessaire, mention d'un ticket de création/modification d'une alerte.
* Caractérisation de l'alerte :
** (x) Vérifier la pertinence des labels permettant d'identifier l'incident (caascad labels = alertname).
** (x) La description du ticket ne doit pas être vide.
* (x) Si nécessaire d'apporter une solution pérenne, un ticket est créé dans l'équipe appropriée.
Important
Si les tickets en état In Review ne remplissent pas les conditions de fermeture avant la fin du créneau de supervision pendant lequel le ticket a été évalué pour fermeture, le ticket sera remis dans l'état précedent son passage dans l'état In Review :
-
In Progress - si le ticket a été traité par l'équipe Supervison
-
Request for Analysis - si le ticket a été traité par une équipe
La personne en charge du ticket pour remplir toutes les conditions de fermeture, sera décidée au sein de l'équipe :
- Supervison - si le ticket est mis en état In Progress
- Les autres équipes - si le ticket est mis en état Request for Analysis
Traitement d'un incident de niveau P1#
Étapes :
-
Création du ticket et qualification
- cette étape n'est pas spécifique aux incidents P1.
- Lorsque le ticket est qualifié P1, on passe a l'étape suivante de communication.
-
Communication
- Sollicitation du manager responsable du suivi long terme (au choix : Elvis Tombini, Pierre Bonachera).
- Ouverture d'une war room Jitsi sous la forme https://jitsi.corp.caascad.com/CAASINCXXX communiquée sur Mattermost #opérations_et_incidents.
- Communication aux autres équipes sur Rocket.Chat. Mentioner l'existence de la war room Jitsi.
- Communication nominative au PO si l'incident impacte le client.
-
Répartition des taches
- Un membre de l'équipe support doit intégrer la war room (par défaut, la personne qui est sur le créneau de supervision) pour gérer les communications clients.
- Le porteur technique en charge de la communication interne.
- Une ou plusieurs personnes en charge de résoudre l'incident.
-
Résolution de l'incident
- Arrêt des opérations en interne.
- Communication aux clients si nécessaire.
- Résolution de l'incident.
Important
Le manager en charge du suivi long terme doit s'assurer que le traitement de l'incident est en cours jusqu'à sa résolution et que les actions nécessaires sont priorisées dans les backlog des équipes concernées.
Traitement d'un incident de niveau P1 en astreinte#
En astreinte, les étapes sont les mêmes.
Les personnes impliquées sont :
- La personne d'astreinte Support
- La personne d'astreinte Ops
- Un manager d'astreinte (Elvis Tombini ou Pierre Bonachera)
Le manager sera libre de faire appel à d'autres personnes si besoin.
Cycle de vie d'un incident#
Quelles sont les étapes d'un CAASINC ?#
Open#
| Que signifie cet état ? | Le CAASINC est en cours de rédaction |
|---|---|
| Qui travaille dessus un ticket en etat Open ? | Le Rapporteur /Reporter |
| Qui va le passer dans l'état suivant ? | Le Rapporteur/Reporter |
In Progress#
| Que signifie l'état In Progress ? | L'incident est en cours de traitement (on passe dans ce mode en cliquant sur Acknowledge) |
|---|---|
| Qui travaille dessus ? | Le Responsable/Assignee. Il peut être accompagné d'un ou plusieurs membres des équipes Support et Opérations |
| Qui va le passer dans l'état suivant ? | Le Responsable/Assignee ou une des personnes ayant travaillé dessus. Cela peut se faire également dans le cadre du DSM, par un des participants |
Request for Analysis#
| Que signifie cet état ? | L'incident requiert une analyse spécifique de la part d'une autre équipe |
|---|---|
| Qui travaille dessus ? | Personne. Le ticket est en attente pour être pris en compte par l'équipe |
| Qui va le passer dans l'état suivant ? | La personne de l'équipe désignée pour analyser l'incident. Celle-ci doit s'assigner le ticket d'incident |
Analysis in Progress#
| Que signifie cet état ? | L'analyse spécifique de la part d'une équipe dédiée est en cours |
|---|---|
| Qui travaille dessus ? | Un ou plusieurs membres de l'équipe dédiée |
| Qui va le passer dans l'état suivant ? | Le Responsable/Assignee. Cela peut se faire également dans le cadre du DSM de son équipe, par un des participants |
On hold#
Le ticket d'incident est mis en attente. Cela peut se faire pour une des raisons suivantes.
Cloud Provider#
| Que signifie cet état ? | L'incident est lié à un dysfonctionnement chez le cloud provider |
|---|---|
| Qui va le passer dans l'état suivant ? | Toute personne en mesure de faire évoluer le ticket. Cette personne doit s'assigner le ticket |
Bug upstream#
| Que signifie cet état ? | L'incident est lié à un bug dont la correction ne peut se faire qu'upstream |
|---|---|
| Qui va le passer dans l'état suivant ? | Toute personne en mesure de faire évoluer le ticket. Cette personne doit s'assigner le ticket |
Zone in deletion#
| Que signifie cet état ? | L'incident est lié à la suppression d'une zone qui peut prendre un peu de temps |
|---|---|
| Qui va le passer dans l'état suivant ? | Un membre des équipes Support ou Opérations |
Zone in creation#
| Que signifie cet état ? | L'incident est lié à la création d'une nouvelle zone |
|---|---|
| Qui va le passer dans l'état suivant ? | Un membre des équipes Support ou Opérations ou la personne en charge de la création de la nouvelle zone |
Client Side#
| Que signifie cet état ? | L'incident est lié à l'activité du client |
|---|---|
| Qui va le passer dans l'état suivant ? | Toute personne en mesure de faire évoluer le ticket. Cette personne doit s'assigner le ticket |
For observation#
Important
Ajouter en commentaire une date à partir de laquelle on peut revoir le ticket ( exemple: En attente MVPMON 445/en observation jusqu'au 30/07 ).
| Que signifie cet état ? | L'incident est lié à un dysfonctionnement d'un service |
|---|---|
| Qui va le passer dans l'état suivant ? | Un membre de l'équipe ayant travaillé dessus |
Team Task#
| Que signifie cet état ? | Un ticket PF a été créé dans l'équipe appropriée, afin d'apporter une solution pérenne |
|---|---|
| Qui va le passer dans l'état suivant ? | Un membre de l'équipe ayant travaillé dessus |
Pending Review#
| Que signifie cet état ? | La réponse à l'incident à été apportée par l'équipe consultée |
|---|---|
| Qui travaille dessus ? | Un membres des équipes Support ou Opérations qui doit vérifier que le ticket d'incident respecte toutes les critères de fermeture |
| Qui va le passer dans l'état suivant ? | Un membre des équipe Support ou Opérations |
Closed#
| Que signifie cet état ? | L'incident a été traité |
|---|
Cancelled#
| Que signifie cet état ? | Cet état ne doit pas être utilisé. Il n'existe dans Jira que pour des raisons historiques. |
|---|