Gestion des incidents pour les équipes haute vélocité
Politiques de remontée pour une gestion efficace des incidents
Lorsqu'un incident survient, dans le meilleur des cas votre ingénieur d'astreinte ou SRE peut le résoudre rapidement et seul.
Bien sûr, dans la réalité, ce n'est pas toujours le cas. Parfois, une résolution requiert une équipe, des connaissances spécialisées ou des compétences plus avancées. C'est pourquoi toute organisation comptant plus de deux techniciens professionnels doit avoir un plan et une politique de remontée d'incident.
Qu'est-ce que la remontée d'incident ?
La remontée d'incident est la procédure à suivre lorsqu'un employé ne peut pas résoudre un incident lui-même et doit transférer la tâche à un employé plus expérimenté ou spécialisé.
Qu'est-ce qu'une politique de remontée ?
Une politique de remontée détermine comment votre organisation traite ces transferts de tâche. Elle stipule qui doit être averti lorsqu'une alerte d'incident est émise, vers qui l'incident doit être remonté si le premier intervenant n'est pas disponible, qui doit prendre le relais lorsque le premier intervenant ne peut pas résoudre le ticket, et comment ces transferts doivent être effectués (via le centre de services ? Directement d'un technicien à l'autre ? Par un outil de gestion des incidents ?).
À première vue, ces questions semblent simples, mais plus votre organisation est grande et plus votre écosystème technologique est complexe, plus les réponses doivent être détaillées. Par exemple, lorsque vous déterminez qui doit être averti en cas d'incident, la réponse peut varier selon la personne disponible ou d'astreinte, mais aussi selon les niveaux de gravité, la durée de l'incident, et bien d'autres aspects.
Pour certaines entreprises, une seule personne d'astreinte peut être avertie en premier lieu, quelle que soit la gravité de l'incident. Pour d'autres, il peut être judicieux de prévenir un développeur junior si l'incident présente un degré de gravité 3, ou une personne plus expérimentée ou spécialisée s'il s'agit d'un incident de gravité 1.
De même, certaines entreprises comptent sur le premier intervenant pour faire remonter un incident lorsque nécessaire. D'autres peuvent déclencher une remontée automatique vers un développeur plus expérimenté ou une équipe spécialisée si un incident dépasse une certaine durée ou commence à toucher d'autres systèmes ou utilisateurs.
Une politique de remontée doit non seulement établir la façon dont votre entreprise va faire remonter les incidents et vers qui, mais aussi les exceptions selon le type d'incident, le niveau de gravité, la durée et le périmètre de l'incident.
Processus de remontée des incidents
Dans les entreprises suivant les bonnes pratiques ITSM, le centre de services est généralement au centre de la remontée d'incident. Si le premier intervenant ne peut pas résoudre l'incident, il se tourne vers le centre de services, qui fait remonter le ticket vers la ligne de défense suivante. Jira Service Management permet aux intervenants de faire remonter les incidents dans le ticket d'incident. Les intervenants ont accès aux workflows pour guider le processus de résolution, et peuvent automatiser ou personnaliser les actions selon les besoins. La désignation d'un niveau de gravité peut orienter les intervenants vers le workflow approprié.
D'autres entreprises, comme Google, désignent un ingénieur SRE en charge des incidents. Cette personne est chargée de toutes les remontées nécessaires, avec la responsabilité de geler les nouvelles livraisons si un incident pousse l'équipe au-delà d'un temps d'arrêt acceptable d'après les SLA/SLO.
Pour d'autres entreprises encore, le premier intervenant peut être un développeur ou un gestionnaire d'incident. Plusieurs points de contact initiaux peuvent aussi exister, notamment lorsqu'une alerte concerne un incident de gravité élevée. La remontée peut se faire par des processus prédéfinis au sein des équipes et entre ces dernières.
Que le processus passe par le centre de services, soit assuré par un SRE ou traité automatiquement au sein de vos systèmes de suivi des incidents, les politiques de remontée suivent habituellement trois chemins différents.
Remontée hiérarchique
La remontée hiérarchique se produit lorsqu'un incident est remonté vers une équipe ou une personne en raison de son niveau d'expérience ou de son ancienneté dans l'organisation.
Par exemple, le premier intervenant d'astreinte peut être un développeur junior intégré récemment à l'équipe. S'il ne peut pas résoudre le ticket, ce dernier est transmis à un développeur plus expérimenté dans la hiérarchie. Si le développeur plus expérimenté ne peut également pas résoudre le ticket, il le transmet à un développeur encore plus qualifié, et ce, jusqu'à ce que le ticket soit résolu.
Remontée fonctionnelle
La remontée fonctionnelle se produit lorsqu'un incident est transmis à une équipe ou une personne plus apte à le résoudre grâce à ses compétences ou ses connaissances des systèmes, et non son ancienneté.
Par exemple, le premier intervenant d'astreinte peut être un développeur junior issu d'une équipe qui travaille sur l'interface du produit X. S'il constate que le problème central vient de l'intégration avec le produit Y, il peut faire remonter l'incident à un autre développeur junior de l'équipe du produit Y.
Remontée automatique
Pour les équipes travaillant sur une plateforme comme Opsgenie, vous pouvez aussi configurer des règles qui demandent au système de faire remonter automatiquement un incident si le premier intervenant n'en prend pas connaissance ou ne ferme pas l'alerte.
Certaines équipes peuvent favoriser une méthode de remontée par rapport à une autre, mais généralement ces méthodes ne s'excluent pas mutuellement : de nombreuses équipes appliquent un mélange de remontées hiérarchiques, fonctionnelles et automatiques.
Matrice de remontée
Une matrice de remontée est un document ou un système qui établit à quel moment une remontée doit se produire et qui doit traiter les incidents à chaque niveau de remontée.
Ce terme est employé dans plusieurs secteurs. Les ressources humaines peuvent avoir une matrice de remontée pour les tickets internes. Les centres d'appels peuvent avoir une matrice de remontée pour les tickets relatifs au service client. Les équipes informatiques et DevOps peuvent avoir une ou plusieurs matrices qui aident les ingénieurs à savoir quand et comment faire remonter un incident.
Le niveau de détail d'une matrice varie fortement d'une entreprise à l'autre. Certaines organisations peuvent utiliser un simple organigramme hiérarchique, chaque développeur remontant les problèmes vers un développeur plus compétent si nécessaire. D'autres organisations peuvent utiliser des matrices situationnelles, qui indiquent aux développeurs quelles sont les équipes à contacter selon le type d'incident ou le niveau de gravité. Comme c'est souvent le cas dans la gestion des incidents, il n'existe pas de modèle unique pour développer la matrice de votre organisation.
Bonnes pratiques pour l'élaboration d'une politique de remontée
Considérez votre politique de remontée comme un jeu de recommandations, pas comme un ensemble de règles à appliquer à la lettre.
La technologie n'est pas statique, et vos équipes non plus. Selon les règles de Google, si votre ingénieur SRE considère qu'un cas spécifique nécessite une politique de remontée différente, il doit avoir les mains libres pour prendre cette décision. L'objectif n'est donc pas de créer des règles rigides, mais d'élaborer des recommandations qui peuvent s'appliquer dans presque toutes les situations.
Auditez régulièrement votre planning d'astreinte
Le planning présente-t-il des trous ? Les personnes d'astreinte sont-elles les bonnes ? Les personnes aux deuxième et troisième niveau d'astreinte sont-elles les bonnes ? Vos plannings d'astreinte et votre politique de remontée doivent être accordés pour accélérer la gestion des incidents.
Définissez des seuils intelligents pour la remontée
Tous les incidents ne se valent pas, donc ils ne peuvent et ne doivent pas tous suivre la même politique de remontée.
Pour les incidents mineurs, vous ne souhaitez peut-être pas avertir l'ingénieur d'astreinte en dehors des heures ouvrables. Pour les incidents majeurs, vous avez certainement besoin de cet ingénieur quels que soient l'heure ou le jour. En cas d'incidents multiples, votre ingénieur devra savoir lequel traiter en premier et/ou si l'un des incidents doit être remonté à un deuxième ingénieur immédiatement.
Vous devez réaliser un délicat numéro d'équilibriste : d'un côté, garantir un temps d'activité maximal pour vos systèmes en respectant les promesses du SLA et les objectifs SLO et, de l'autre, veiller à ce que les ingénieurs ne soient pas surchargés, en burn-out, privés de sommeil et sujets à la fatigue d'alerte.
Définissez des processus de remontée clairs
Le développeur qui déclenche la remontée doit-il contacter directement l'équipe ou la personne adéquate, ou doit-il passer par le centre d'assistance ? Existe-t-il un système en place que le développeur doit utiliser ? Comment allez-vous suivre la remontée ? Quelle est la procédure à suivre par le premier intervenant pour s'assurer que l'incident est pris en charge par le deuxième intervenant ?
Ces questions doivent être clairement abordées par votre politique, et les réponses communiquées explicitement aux développeurs d'astreinte pour que les remontées soient fluides et que la résolution d'incidents soit plus rapide.
Découvrez comment Jira Service Management peut enrichir vos pratiques de gestion des incidents en proposant une solution collaborative pour la remontée des incidents afin de les résoudre plus rapidement.
Configuration d'un planning d'astreinte grâce à Opsgenie
Ce tutoriel vous apprendra à configurer un planning d'astreinte, à appliquer des règles de remplacement, à configurer les notifications d'astreinte, etc. Et tout cela, sans quitter Opsgenie.
Lire ce tutorielAdopter une approche optimale des plannings d'astreinte
Un planning d'astreinte efficace est essentiel pour garantir une culture d'astreinte saine. Découvrez les erreurs courantes, les types de plannings de rotation et la marche à suivre.
Lire cet article