Gestion des incidents pour les équipes haute vélocité
Gérer le processus de gestion des incidents comme un pro des opérations informatiques
Par Nick Wright, Atlassian Service Operations Manager
Tout d'abord, permettez-moi de dire ce que j'ai sur le cœur : les membres du support de première ligne sont les héros méconnus de chaque entreprise.
Chaque. Entreprise.
J'estime sincèrement que le support technique devrait être considéré comme un secteur de services et que les clients devraient pouvoir laisser des pourboires aux agents qui fournissent un service d'excellence. J'en laisserais volontiers un à chaque crack du support qui résout mes problèmes rapidement (et avec le sourire) si seulement je le pouvais.
Mais je digresse. Si vous lisez ceci, vous gérez probablement une équipe de centre d'assistance ou vous en êtes membre. De plus, votre cerveau doit s'enflammer. L'incendie fait rage et l'odeur doit être insupportable. Il faut intervenir au plus vite et maîtriser votre processus de gestion des incidents informatiques.
Avant de nous plonger dans la gestion des incidents, mettons-nous d'accord sur la terminologie commune.
ITSM et gestion des incidents
Si vous travaillez dans le domaine informatique, vous connaissez sûrement ITIL, ITSM, les incidents et les problèmes. Mais afin de mettre tout le monde sur la même longueur d'onde, voici quelques courtes définitions que nous utilisons chez Atlassian :
ITIL (IT Infrastructure Library) est un ensemble de bonnes pratiques pour l'ITSM (il s'apparente à un playbook).
ITSM (IT Service Management ou gestion des services informatiques) est une approche commune de création, de support et de gestion des services informatiques. Le concept fondamental de l'ITSM repose sur la conviction selon laquelle l'informatique devrait être fournie en tant que service. La gestion des incidents constitue l'une des pratiques de base de l'ITSM.
Les incidents sont des événements imprévus de toute nature qui perturbent ou affectent la qualité du service (ou menacent de le faire). La panne d'une app métier constitue un incident, au même titre que la lenteur d'un serveur web en fin de vie. Ce dernier fonctionne lentement et nuit à la productivité. Pire encore, il risque d'entraîner une panne complète.
Un problème est la cause profonde encore inconnue derrière un ou plusieurs incidents. Dans l'incident ci-dessus, la lenteur du réseau et la panne d'une app métier pourraient découler de la mauvaise configuration d'un routeur.
L'importance de la gestion des incidents : une pratique ITSM
Pourquoi adopter la gestion des incidents ? Et pourquoi constitue-t-elle un élément de l'univers ITSM ?
La réponse est dans l'impact. Selon une étude, les incidents majeurs coûtent aux entreprises en moyenne entre 100 000 et 300 000 $ par heure d'arrêt d'un système.
L'adoption d'un processus de gestion des incidents bien défini peut contribuer à réduire considérablement ces coûts. Voici les avantages d'un tel processus :
- Accélération de la résolution des incidents
- Réduction des coûts ou pertes de revenus pour l'organisation
- Amélioration de la communication (interne et externe) pendant les incidents
- Apprentissage et amélioration continus
Workflow de gestion d'incidents
Je vais utiliser le framework ITIL pour vous présenter un aperçu général de la gestion adéquate des tickets, mais la plupart des autres frameworks populaires énonceront des concepts à peu près similaires en utilisant un jargon légèrement différent.
La clé de la gestion des incidents ? Adopter un processus de qualité et s'y tenir.
Il est vrai que la tâche peut sembler titanesque. Mais voici une bonne nouvelle : vous pouvez vous inspirer de l'expérience de milliers d'autres équipes de services informatiques.
L'une des principales erreurs commises par les organisations informatiques en pleine croissance est de vouloir tout réinventer et de créer des processus en partant de rien (sans s'appuyer sur les bonnes pratiques) ou en développant leurs propres outils internes pour gérer des tickets.
Identifier un incident et le consigner
Un incident peut avoir de multiples causes. Un employé peut vous appeler pour le signaler, ou il peut littéralement tomber du ciel, si votre hub réseau n'est pas au point. (Non pas que nous parlions d'expérience… *hum*)
Quelle que soit la source, les deux premières étapes sont simples : une personne identifie un incident et une autre le consigne.
Si l'incident qui vous est communiqué est déjà consigné par votre centre de services, vous pouvez ignorer ces deux premières étapes. Si vous recevez un appel téléphonique ou si l'incident est signalé par e-mail, par SMS ou par pigeon voyageur, l'équipe du centre de services doit le consigner correctement dans votre centre de services.
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égorisez votre incident
Les deux étapes suivantes (catégorisation et priorisation) sont à la fois critiques et souvent négligées. Elles séparent aussi les centres de services les plus « sains » avec lesquels je travaille depuis… pas tellement longtemps en fait.
Tout d'abord, vous devez assigner une catégorie logique et intuitive (et une sous-catégorie, selon les besoins) à chaque incident. Si vous ne le faites pas, vous limitez votre capacité à analyser ultérieurement vos données et à rechercher des tendances et des schémas, ce qui constitue un élément essentiel de la gestion efficace des problèmes et de la prévention des incidents futurs.
Par conséquent, n'oubliez pas d'assigner. En outre, optez pour une solution de centre de services informatique qui vous permet de personnaliser facilement les catégories d'incident.
Hiérarchisez votre incident
Ensuite, chaque incident doit se voir assigner une priorité.
Pour prioriser un incident, commencez par évaluer son impact sur l'entreprise. Tenez compte du nombre de personnes qui seront touchées et des répercussions potentielles de l'incident en termes de finances, de sécurité et de conformité. Vous pourrez ainsi déterminer les conséquences de l'incident et l'urgence avec laquelle l'entreprise doit le régler.
La bonne pratique consiste à définir vos niveaux de gravité et de priorité avant qu'un incident ne se produise, ce qui simplifie l'évaluation de la priorité pour les gestionnaires d'incident.
Lorsque vous avez des doutes sur le niveau de priorité, optez pour le niveau le plus élevé. Mieux vaut prévenir que guérir.
Une fois que vous avez défini ces priorités, traitez tous les incidents en cours par ordre de priorité. La plupart des organisations établissent des accords de service clairs autour de chaque niveau de priorité, afin que les clients connaissent les délais de réponse et de résolution. Je recommande vivement cette pratique.
Répondre
Le terme de réponse aux incidents a une acception large. Décomposons-le et analysons les étapes que vous êtes le plus susceptible de suivre lorsque vous aurez identifié, catégorisé et hiérarchisé un incident.
Diagnostic initial
Ce diagnostic s'apparente au tri effectué par un hôpital sur les nouveaux patients. L'employé du centre de services formule rapidement une hypothèse sur le problème, afin de pouvoir s'attaquer à sa résolution ou de suivre les procédures appropriées et compiler les bonnes ressources pour le résoudre.
Dans ce contexte, les bases de connaissances et les manuels de diagnostic constituent également des outils utiles.
Si l'agent du centre de services en première ligne est en mesure de résoudre l'incident en fonction de ses diagnostics initiaux et des connaissances et outils disponibles, l'incident est résolu. Sinon, faites remonter l'incident.
Remontée de l'incident
Le terme « remontée » peut sembler péjoratif, mais ce n'est pas le cas.
Votre équipe de support de première ligne devrait être en mesure de résoudre un grand nombre d'incidents les plus fréquents sans remontée. Pour les autres, l'objectif est de rassembler et de consigner les informations adéquates pour aider l'équipe de support de niveau 2 et 3 (plus technique) à les comprendre rapidement afin de les résoudre dans les meilleurs délais.
Enquête et diagnostic
Beaucoup considèrent cette étape comme propre à ITIL. En réalité, elle apparaît tout au long du cycle de vie de l'incident.
Votre agent de support en première ligne enquête déjà, dans une certaine mesure, lorsqu'il recueille des informations, et peut même diagnostiquer et résoudre l'incident sans qu'il soit nécessaire de le faire remonter.
Dans ce cas, vous pouvez passer aux étapes suivantes : résolution et récupération, et clôture de l'incident.
Sinon, l'enquête et le diagnostic seront réalisés à chaque étape du processus lorsque vous faites remonter un problème à l'équipe de support de niveau 2 et 3 ou que vous impliquez des ressources externes ou d'autres membres du service pour vous aider à le résoudre.
Résolution et récupération
Enfin (et dans l'idéal), dans le cadre de vos accords de niveau de service (SLA), vous établirez un diagnostic et suivrez 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 de l'incident
L'incident est ensuite renvoyé au centre de services (s'il a fait l'objet d'une remontée) 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é.
Conclusion : ne sautez pas d'étape
Le processus peut sembler inutilement formel, surtout si vous disposez uniquement de quelques analystes du centre de services. Mais quelle que soit la structure de votre équipe, le cycle de vie de l'incident reste le même.
Supposons que vous disposiez uniquement d'un analyste du centre de services, donc qu'aucun support de niveau 3 n'est a priori disponible. Cela dit, et vous en conviendrez, les incidents qui dépassent les connaissances de votre analyste doivent être signalés, que ce soit à votre ingénieur en chef, à un consultant externe ou à vous-même.
Voilà ! Vous disposez donc d'un support de niveau 2 ou 3 : votre ingénieur ou vous-même.
Conclusion ? Même si ITIL peut sembler se réduire à une question de sémantique, ne vous laissez pas piéger. Recherchez des moyens simples d'adapter votre hiérarchie organisationnelle et vos workflows de processus pour qu'ils s'intègrent dans un framework de gestion des services informatiques simple (déjà évoqué plus haut).
Ce faisant, vous fournirez un meilleur service client et une plus forte valeur ajoutée à votre entreprise. (De plus, votre cerveau arrêtera de s'enflammer, donc c'est gagnant-gagnant !)
Terminons par quelques rappels :
- Consignez chaque incident. Attribuez-lui un numéro unique. Capturez les informations importantes (comme la date, l'heure et la description) dans un système de centre d'assistance centralisé.
- Si le public interne ou externe à qui communiquer les mises à jour des incidents est conséquent, envisagez de créer une page d'état dédiée à la communication des incidents.
- Assignez une catégorie à chaque incident (et une sous-catégorie, selon les besoins).
- Attribuez un niveau de priorité à chaque incident et un SLA à chaque niveau de priorité.
- Définissez clairement les rôles des intervenants en cas d'incident, comme le coordinateur gestion des incidents, le responsable de la gestion des incidents majeurs et le responsable des communications.
- Dans la mesure du possible, fournissez à votre équipe de support en première ligne des articles de base de connaissances et des scripts de diagnostic d'incident pour l'aider à résoudre rapidement les incidents.
- Assurez-vous que le centre de services garde toujours le contrôle de la progression, du routage et de l'état de l'incident.
- Enfin, ne vous contentez pas de capturer les données d'un incident. Analysez-les ! Recherchez les tendances, les schémas et les éventuels problèmes sous-jacents qui peuvent réduire le volume des incidents et atténuer les risques.
À propos de l'auteur
Nick Wright
Service Operations Manager, Atlassian
Mon équipe et moi-même veillons à ce que les apps et l'infrastructure Atlassian Cloud soient performantes, et je tiens à expliquer comment nous procédons, tout en évoluant rapidement. Je suis Néo-Zélandais, mais cette « barrière » linguistique ne m'empêche pas de prononcer « Fish and Chips ». En dehors du travail, je fais du vélo, je joue à des jeux vidéos ou je me balade avec ma femme et ma petite fille.
Découvrez la communication sur les incidents grâce à Statuspage
Dans ce tutoriel, nous allons vous montrer comment utiliser des modèles d'incident pour communiquer efficacement pendant les pannes. Vous pouvez les adapter à de nombreux types d'interruption de service.
Lire ce tutorielModèles et exemples de communication sur les incidents
Lorsque vous répondez à un incident, les modèles de communication sont d'une valeur inestimable. Obtenez les modèles que nos équipes utilisent, ainsi que d'autres exemples pour les incidents courants.
Lire cet article