Close

La voie vers une meilleure gestion des incidents
débute ici

Comprendre les niveaux de gravité des incidents

Identifiez et hiérarchisez les incidents pour accélérer la résolution

Trois vérités absolues caractérisent la gestion des incidents.

La première veut que les incidents sont inévitables, en particulier pour les entreprises qui se développent et innovent ne permanence.

La deuxième veut qu'une pratique de gestion des incidents efficace est indispensable pour garantir la bonne santé d'une entreprise (une pratique inefficace coûte cher en termes d'engagement et de satisfaction des employés et de chiffre d'affaires).

La troisième veut que tous les incidents ne se valent pas. Perdre des données dans une base de données n'est pas la même chose que perdre des données dans toutes vos bases de données. Traiter une panne qui affecte 20 % de vos utilisateurs est très différent d'en traiter une qui affecte 90 ou 100 % d'entre eux. Gérer une panne système pendant les heures de pointe est beaucoup plus stressant qu'en gérer une lorsque la plupart de vos clients sont au lit. Même deux incidents qui semblent identiques sur le papier sont uniques lorsque vous approfondissez la question.

Logo OpsGenie

Découvrez l'approche Atlassian de la gestion des incidents

Il est plus que jamais essentiel de disposer d'un processus de gestion des incidents rapide et simple.

C'est pourquoi les entreprises ayant mis en place des programmes de gestion des incidents robustes disposent de niveaux de gravité des incidents bien définis et de bonnes pratiques claires pour hiérarchiser les incidents au fur et à mesure qu'ils surviennent.

Que sont les niveaux de gravité ?

Les niveaux de gravité des incidents constituent une mesure de l'impact d'un incident sur l'entreprise. En règle générale, plus le niveau de gravité est faible, plus l'impact de l'incident est important.

Par exemple : chez Atlassian, nous définissons un incident SEV 1 (SEV = gravité) comme « un incident critique ayant un impact très élevé ». Il peut s'agir d'une perte de données client, d'une violation de la sécurité ou d'un service orienté client en panne pour tous les clients.

Un incident SEV 2 est « un incident majeur ayant un impact significatif », y compris lorsqu'un service orienté client est en panne pour un sous-ensemble de clients ou qu'une fonction critique d'un système ne fonctionne pas.

Un incident SEV 3 est « un incident mineur ayant un faible impact », notamment un problème système qui cause de légers inconvénients aux clients.

Chez Atlassian, les incidents SEV 3 peuvent être traités pendant la journée et les heures de travail, tandis que les incidents SEV 1 et SEV 2 génèrent une alerte destinée aux professionnels d'astreinte afin qu'ils apportent une correction immédiate, peu importe le moment de la journée.

Gravité Description Exemples
1 Un incident critique à grand impact
  • Un service orienté client, comme Jira Cloud, est en panne pour tous les clients
  • Violation de la confidentialité
  • Perte de données client
2 Un incident majeur sans impact significatif
  • Un service orienté client n'est pas disponible pour un sous-ensemble de clients
  • Une fonctionnalité principale (par exemple, git push, création de ticket) est considérablement affectée
3 Un incident mineur avec un faible impact
  • Inconvénient mineur pour les clients, solution de contournement disponible
  • Dégradation des performances utilisables

Les niveaux de gravité sont utiles pour comprendre rapidement l'impact et établir des priorités pour les équipes informatiques et DevOps.

Mieux vos niveaux SEV sont définis, plus les membres de votre équipe seront susceptibles d'être sur la même longueur d'onde et capables de réagir rapidement et de manière appropriée en cas d'incident. Si vos niveaux de gravité ne sont pas bien définis, vous passerez un temps précieux à définir et à expliquer l'urgence d'un incident au lieu de le résoudre.

Quand et où les niveaux de gravité sont-ils utiles ?

La valeur fondamentale des niveaux de gravité ? Ils font gagner du temps aux équipes. Une équipe disposant de niveaux de gravité et d'une feuille de route claire pour traiter chaque niveau peut se concentrer directement sur la correction à apporter. Une équipe ne disposant pas de niveaux de gravité passera probablement les premières minutes cruciales d'un incident majeur à évaluer son importance et à déterminer qui doit le gérer et comment.

Plus l'incident est critique, plus il est essentiel de gagner le maximum de temps en planifiant non seulement la résolution de l'incident et les plans de communication, mais aussi en établissant des niveaux de gravité clairs et des priorités.

En quoi la gravité est-elle différente de la priorité ?

À première vue, la gravité et la priorité d'un incident semblent être similaires. Après tout, un incident grave aux conséquences désastreuses devrait être traité avant un incident moins grave, non ?

Mais pour la plupart des entreprises, c'est plus compliqué que ça.

La gravité est une mesure de l'impact. Quel impact un incident a-t-il sur les utilisateurs ? Affecte-t-il l'intégralité de leur système ? Les empêche-t-il d'accomplir une tâche essentielle ? Ou peut-être crée-t-il simplement du stress et rend-il les tâches plus difficiles ?

La priorité, en revanche, est une mesure de l'urgence. À quelle vitesse devons-nous corriger ce problème ? Quel problème résoudre en premier ?

Parfois, les deux mesures s'alignent parfaitement. Un incident de gravité élevé qui affecte l'ensemble de l'entreprise constitue probablement aussi la priorité absolue pour les équipes DevOps et informatiques.

Mais, parfois, la priorité et la gravité ne s'alignent pas. Par exemple : supposons que le titre de la page d'accueil de votre site web comporte une faute de frappe. Il s'agit d'un problème de faible gravité, car il n'a pas réellement d'impact sur le fonctionnement du site web. Les utilisateurs peuvent toujours continuer à faire ce qu'ils ont prévu de faire, et les employés aussi.

Mais l'entreprise pourrait considérer la correction comme une priorité absolue pour une raison de branding ou parce que l'erreur entraîne une certaine confusion ou fait tout simplement mauvais effet. Cet incident pourrait donc afficher une faible gravité, mais un niveau de priorité élevé.

Prenons encore l'exemple d'un incident qui entraîne le plantage de votre app. Le niveau de gravité est élevé, car il empêche les utilisateurs de faire ce qu'ils ont prévu de faire. Mais précisons à présent que l'incident n'affecte que 0,05 % de vos utilisateurs. Si d'autres incidents ayant un impact plus large se produisent, un problème comme celui-là pourrait ne pas être la priorité absolue, même si l'expression « plantage système » implique généralement une mobilisation générale.

Les deux mesures sont importantes dans la gestion des incidents, mais il est essentiel de savoir quand elles s'alignent ou non. Une gravité élevée ne propulse pas automatiquement un incident en haut de la liste des priorités, et une priorité élevée n'implique pas toujours une panne système.

Étant donné que la priorité est plus concrète que la gravité, elle constitue la principale mesure que nous utilisons dans Opsgenie. De plus, comme la gravité est souvent un facteur clé qui détermine la priorité, nous avons proposé des définitions claires dans notre manuel de gestion des incidents pour illustrer notre propre pratique de gestion des incidents.

Définition des niveaux de gravité des incidents pour votre organisation

Tous les incidents ne se valent pas, et leur gestion peut varier d'une organisation à l'autre. Lorsque vous définissez les niveaux de gravité, les attentes et les processus associés, ainsi que l'impact d'un incident, vous devez tenir compte des variables suivantes :

  • La taille de votre équipe technique
  • Plannings d'astreinte
  • Les heures de trafic élevé et faible au cours de la journée pour votre service
  • La fréquence des incidents

Pourquoi ? Parce que chacune de ces variables peut influencer votre définition des niveaux de gravité.

Par exemple, l'utilisation d'une app qui dessert les marchés locaux dans un seul fuseau horaire peut varier fortement entre 2 h et 7 h. Donc, si l'ensemble de votre système tombe en panne à 3 h, le niveau de gravité sera-t-il le même que pour une panne système pendant les heures de pointe ?

Qu'en est-il d'une start-up disposant d'une petite équipe, mais enregistrant un grand nombre d'incidents de gravité 3 ? Devrait-elle s'en tenir au niveau de gravité 3 et laisser l'équipe déterminer la priorité des incidents lorsque plusieurs se produisent en même temps ? Ou devrait-elle subdiviser les niveaux de gravité en 3, 4, voire 5, pour faire la différence entre une perte partielle de fonctionnalité dans un système orienté client, un problème de performance et un autre incident encore plus mineur (par exemple, un bug qui n'affecte pas l'utilisation du système, mais qui doit tout de même être corrigé) ?

L'essentiel ici est de comprendre votre entreprise, votre équipe et les niveaux de gravité et de priorité adaptés à votre activité.

Atlassian Niveau 3 Niveau 4 Niveau 5
SEV 1

Incident critique ayant un impact très élevé.

Par exemple : un service orienté client, comme Jira, est en panne pour tous les clients.

SEV 2

Incident majeur ayant un impact significatif.

Par exemple : un service orienté client est en panne pour un sous-ensemble de clients.

SEV 3 Incident mineur ayant un faible impact.

Par exemple : un bug système entraîne un inconvénient mineur pour les clients.

Incident susceptible de devenir un incident majeur s'il n'est pas géré rapidement.

Par exemple : perte partielle de fonctionnalités pour un petit sous-ensemble de clients.

SEV 4 Demande de support qui affecte un client, mais n'a aucun impact sur le fonctionnement global du système.

Incident mineur qui affecte l'utilisation du produit, mais qui ne l'empêche pas de fonctionner.

Par exemple : temps de chargement plus lents que la moyenne.

SEV 5

Bugs ou tickets de support qui n'affectent pas l'utilisation du produit.

Par exemple : un logo s'affiche au mauvais endroit ou obscurcit partiellement la dernière lettre d'un titre.