Close

Découvrez Jira Service Management et d'autres outils puissants lors de l'événement Atlassian présente : l'ITSM haute vélocité.

S'inscrire gratuitement

Gestion des incidents pour les équipes haute vélocité

Qu'est-ce que la gestion des incidents ?

La gestion des incidents désigne le processus utilisé par les équipes DevOps et des opérations informatiques pour répondre à un événement imprévu ou une interruption de service et rétablir le fonctionnement du service.

Chez Atlassian, nous définissons un incident comme un événement ayant provoqué une perturbation ou une réduction de la qualité d'un service nécessitant une réponse d'urgence. À la place, les équipes qui adoptent les pratiques ITIL ou ITSM préfèrent le terme « incident majeur ».

Manuel de gestion des incidents

Obtenez notre manuel de gestion des incidents en version imprimée ou PDF

Nous disposons d'un nombre limité de versions imprimées de notre manuel de gestion des incidents que nous fournissons gratuitement. Vous pouvez également télécharger la version PDF.

Un incident est résolu lorsque le service affecté fonctionne de nouveau de manière habituelle. Cela inclut uniquement les tâches requises pour atténuer l'impact et restaurer les fonctionnalités.

Ces types d'incidents peuvent être d'une gravité très variable, allant du crash de tout un service web mondial à un petit nombre d'utilisateurs subissant des erreurs intermittentes.

Rubriques sur la gestion des incidents

Tutoriels recommandés

[SUITE]

L'importance de la gestion des incidents

Valeurs de gestion des incidents

Valeurs d'Atlassian en matière de gestion des incidents

La gestion des incidents est l'un des processus les plus essentiels qu'une organisation doit mettre en place. Les interruptions de service peuvent être coûteuses pour l'entreprise, et les équipes ont besoin d'un moyen efficace pour répondre à ces tickets et les résoudre rapidement.

Selon Gartner, de nombreuses organisations signalent que les temps d'arrêt coûtent plus de 300 000 dollars par heure. Pour certains services web, ce chiffre peut être encore bien plus élevé.

Les équipes ont besoin d'une méthode fiable pour prioriser les incidents, parvenir à une résolution plus rapide et offrir un meilleur service aux utilisateurs.

Lorsque les équipes sont confrontées à un incident, elles ont besoin d'un plan qui leur permet de :

  • répondre efficacement pour une reprise rapide ;
  • communiquer clairement avec les clients, les parties prenantes, les Service Owners et les autres membres de l'organisation ;
  • collaborer efficacement pour résoudre le problème plus rapidement en équipe et éliminer les obstacles à la résolution ;
  • s'améliorer continuellement pour apprendre de ces pannes et appliquer les leçons pour optimiser un service et peaufiner leur processus pour l'avenir.

Vous souhaitez voir comment Atlassian gère les incidents majeurs ? Nous avons publié notre manuel interne de gestion des incidents. Tout le monde peut en tirer des enseignements, l'adapter et l'utiliser à sa guise.

Types de processus de gestion des incidents

Selon leur type, les entreprises ont tendance à s'orienter vers différents types de processus de gestion des incidents. Il n'existe pas de processus unique qui convienne à toutes les entreprises, c'est pourquoi il est probable que les approches varient d'une entreprise à l'autre.

De nombreuses équipes s'appuient sur un processus de gestion des incidents de type informatique plus traditionnel, tel que ceux décrits dans les certifications ITIL. D'autres équipes s'orientent vers un processus de gestion des incidents plus proche de celui de l'ingénieur chargé de la fiabilité du site (SRE) ou de DevOps.

Processus de gestion des incidents informatiques

Un processus de gestion des incidents aide les équipes informatiques à enquêter, à consigner et à résoudre les interruptions ou les pannes de service. Le workflow de gestion des incidents ITIL vise à réduire les temps d'arrêt et à minimiser l'impact sur la productivité des employés en cas d'incident. En utilisant des modèles conçus pour gérer les incidents, vous pouvez créer un workflow de gestion des incidents reproductible, qui garantit que les équipes consignent, diagnostiquent et résolvent les incidents et disposent d'un enregistrement de leurs activités.

Le framework (ou référentiel) ITIL est principalement utilisé par les équipes informatiques qui fournissent des services au sein des entreprises. En général, les équipes prennent ce dont elles ont besoin dans ITIL, qui couvre presque tous les types d'incidents et de problèmes et processus auxquels les équipes informatiques peuvent être confrontées, et laissent le reste. ITIL est idéal lorsque les équipes doivent se concentrer sur l'instauration d'une culture de résolution active des problèmes. Les processus prescrits aident les équipes à suivre les incidents et les actions de manière cohérente, ce qui améliore les rapports et analyses, et peut conduire à un service plus sain et à une équipe plus performante.

Étapes du processus de gestion des incidents informatiques

Identifier un incident et le consigner

Un incident peut avoir de multiples causes : un employé, un client, un fournisseur, des systèmes de surveillance. Quelle que soit la source, les deux premières étapes sont simples : une personne identifie un incident et une autre le consigne. Ces journaux d'incident (c.-à-d. les tickets) comprennent généralement ce qui suit :

  • le nom de la personne qui signale l'incident ;
  • la date et l'heure de signalement de l'incident ;
  • une description de l'incident (le composant en panne ou qui ne fonctionne pas correctement) ;
  • un numéro d'identification unique assigné à l'incident, pour le suivi.

Catégoriser

Assignez une catégorie logique et intuitive (et une sous-catégorie, selon les besoins) à chaque incident. Cela vous permet d'analyser vos données pour rechercher des tendances et des schémas, une étape indispensable à une gestion efficace des problèmes et à la prévention d'incidents futurs.

Définir des priorités

Chaque incident doit se voir assigner une priorité. Commencez par évaluer son impact sur l'entreprise, le nombre de personnes qui seront touchées, tout SLA applicable, ainsi que les répercussions potentielles en termes de finances, de sécurité et de conformité. Comparez cet incident à tous les autres incidents ouverts pour déterminer sa priorité relative.

Répondre

  • Diagnostic initial : dans l'idéal, votre équipe de support de première ligne peut suivre un incident depuis le diagnostic jusqu'à sa clôture. Cependant, si elle n'y parvient pas, l'étape suivante consiste à consigner toutes les informations pertinentes et à les faire remonter à l'équipe du tier suivant.
  • Remontée : l'équipe suivante prend les données consignées et poursuit le processus de diagnostic, et, si cette équipe ne peut pas diagnostiquer l'incident, elle passe la main à l'équipe suivante.
  • Communication : l'équipe partage régulièrement des mises à jour avec les parties prenantes internes et externes impactées.
  • Enquête et diagnostic : le processus se poursuit jusqu'à ce que la nature de l'incident soit identifiée. Les équipes font parfois appel à des ressources extérieures ou à des membres d'autres services internes pour aider à la résolution.
  • Résolution et récupération : lors de cette étape, l'équipe établit un diagnostic et suit les étapes nécessaires pour résoudre l'incident. La récupération implique simplement le temps nécessaire pour reprendre le cours normal des opérations, car certaines corrections (comme les corrections de bug, par exemple) peuvent nécessiter des tests et un déploiement, et ce, même après que la résolution appropriée a été identifiée.
  • Clôture : si l'incident a fait l'objet d'une remontée, il est ensuite renvoyé au centre de services pour être clôturé. Afin de maintenir la qualité et d'assurer un processus en douceur, seuls les employés du centre de services sont autorisés à clôturer les incidents. En outre, le propriétaire de l'incident devrait vérifier auprès de la personne qui l'a signalé que la résolution est satisfaisante et que l'incident peut réellement être clôturé.

Incidents, problèmes et changements : quelle est la différence ?

Les équipes informatiques rencontrent généralement différents types de tickets. Nous les classons afin de pouvoir leur appliquer les techniques de gestion appropriées.

  • Demande de service : une demande formelle venant d'un client pour la fourniture de quelque chose, un nouvel ordinateur portable, par exemple.
  • Incident : toute interruption non planifiée d'un service informatique ou réduction de la qualité d'un service (la panne du site web, par exemple).
  • Problème : un problème est la cause profonde sous-jacente d'un incident (mauvaise configuration d'un serveur, par exemple). C'est ce que vous souhaitez maîtriser afin d'éviter les incidents.
  • Changement : une action que vous entreprenez. Il existe trois types de changement : standard, normal ou urgent. Un changement standard a une procédure établie. Un changement normal est souvent non banal et doit passer par un processus d'approbation. Un changement urgent est mis en place immédiatement et, idéalement, testé avant d'être déployé.

Processus de gestion des incidents DevOps et SRE

Grâce à une approche DevOps ou SRE de la gestion des incidents, l'équipe qui conçoit le service l'exécute et le corrige également en cas de problème. Cette approche a explosé en popularité parallèlement à la croissance des services cloud disponibles en continu, des apps web consultées à l'international, des microservices et des logiciels en tant que service.

De plus en plus, les logiciels sur lesquels vous comptez pour vivre et travailler ne sont plus hébergés sur un serveur au même endroit que vous. C'est comme une app déployée sur un data center et accessible sur le Web par des milliers ou des millions d'utilisateurs à travers le monde. Pour les équipes chargées d'exécuter ces services, l'agilité et la vitesse sont primordiales. De plus, tout temps d'arrêt peut affecter des milliers d'organisations, pas seulement une.

Un des avantages de l'approche « you build it, you run it » (Vous le concevez, vous en êtes responsable) ? Elle offre la flexibilité dont les équipes Agile ont besoin. Cependant, elle peut aussi être floue quant aux responsabilités de chacun et aux délais. Les équipes DevOps peuvent être à l'aise et réussir grâce à des processus de développement moins structurés. Il est cependant préférable de standardiser un ensemble de processus de base pour la gestion des incidents. Ainsi, vous n'aurez aucun doute sur la manière de répondre à un incident, et vous pourrez suivre les tickets et créer des rapports sur leur résolution.

Trois croyances des équipes de gestion des incidents DevOps

  • Soyez d'astreinte à tour de rôle : plutôt que de laisser certains membres de l'équipe se spécialiser dans les astreintes, les équipes DevOps alternent généralement selon un planning d'astreinte dans lequel tous leurs membres partagent le fardeau d'être potentiellement réveillé en pleine nuit pour répondre à un incident.
  • L'ingénieur qui a développé la fonctionnalité est la meilleure personne pour corriger le bug : l'idée centrale de la philosophie « you build it, you run it » est que les personnes les plus familières avec le service (les développeurs) sont les plus à même de corriger une panne.
  • Développez rapidement, mais soyez responsable : lorsque les ingénieurs et les membres de leur équipe savent qu'ils doivent assumer les pannes, ils vous incitent d'autant plus à déployer un code de qualité.

Cette approche garantit des temps de réponse rapides et un feedback accéléré aux équipes qui ont besoin de savoir comment développer un service fiable.

Nous présentons une approche de la gestion des incidents compatible avec DevOps dans notre manuel de gestion des incidents Atlassian.

Outils de gestion des incidents

La gestion des incidents ne se fait pas uniquement grâce à un outil, mais en associant les bons outils, les bonnes pratiques et les bonnes personnes. Voici certaines des catégories d'outils les plus courantes pour une gestion des incidents efficace :

  • Suivi des incidents : chaque incident doit être suivi et documenté afin que vous puissiez identifier les tendances et faire des comparaisons au fil du temps.
  • Groupe de discussion : une communication écrite en temps réel est fondamentale pour diagnostiquer et résoudre l'incident en équipe. De plus, elle offre un riche ensemble de données pour l'analyse ultérieure des réponses.
  • Chat vidéo : le chat vidéo complète le chat écrit pour de nombreux incidents. Le chat vidéo d'équipe peut permettre d'aborder les résultats et de cartographier une stratégie de réponse.
  • Système d'alerte : un outil comme Opsgenie s'intègre à votre système de surveillance et gère les rotations d'astreinte et les remontées.
  • Outil de documentation : un outil tel que Confluence peut consigner les documents d'état d'incident et les post-mortems.
  • Statuspage : communiquer l'état aux parties prenantes internes et aux clients via Statuspage permet de tenir en permanence tout le monde au courant.

Vous souhaitez en savoir plus sur la gestion des incidents dans Jira Service Management ?

Inscrivez-vous pour recevoir davantage d'articles et de tutoriels

Thank you for subscribing