Qu'est-ce qu'une politique de remontée ?

Points clés : une politique de remontée définit qui est averti lorsqu'une alerte d'incident se déclenche, à qui l'incident est transmis si le premier intervenant n'est pas disponible ou ne parvient pas à le résoudre, et comment ces transferts s'effectuent. Ces modalités varient généralement en fonction de la gravité, de la durée et du périmètre de l'incident.

• En quoi elle consiste : un parcours documenté, souvent consigné dans une matrice de remontée, qui repose sur trois types de remontée : hiérarchique (par ancienneté), fonctionnelle (par expertise) et automatique (par règle, lorsqu'une alerte n'est pas prise en compte à temps).

• Pourquoi c'est important : sans ce processus, les incidents s'enlisent pendant que les équipes cherchent à déterminer qui appeler. Avec ce processus, le bon intervenant est mobilisé en quelques minutes, et personne n'est alerté pour une raison injustifiée.

• Comment Jira Service Management peut vous aider : son planning d'astreinte et son système d'alertes permettent aux équipes de définir des règles de remontée par service et par gravité, de remonter automatiquement les alertes non prises en compte et d'effectuer la remontée directement dans la fiche d'incident afin que chaque transfert soit suivi.

Une politique de remontée est le plan documenté décrivant ce qui se passe lorsque la première personne alertée d'un incident ne peut pas le gérer seule : qui est averti en premier, qui prend le relais si cette personne est indisponible ou incapable de résoudre le problème, à quelle vitesse le transfert s'effectue et par quel canal. C'est le pendant d'un planning d'astreinte : le planning indique qui est disponible, tandis que la politique définit comment l'incident est transféré d'une personne à l'autre.

Dans le meilleur des cas, l'ingénieur d'astreinte résout l'incident seul. Lorsque la résolution nécessite une équipe plus importante, des connaissances spécialisées ou des compétences plus pointues. Les cas dont la résolution nécessite plusieurs techniciens ont souvent besoin d'un plan de remontée. Ce guide aborde les types de remontée, la matrice de remontée et les bonnes pratiques pour rédiger une politique efficace.

Qu'est-ce que la remontée d'incident ?

La remontée d'incident se produit lorsqu'un collaborateur ne peut pas résoudre un incident lui-même et doit transférer la tâche à un collaborateur plus expérimenté ou spécialisé.

Qu'est-ce qu'une politique de remontée ?

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'alerte d'incident, la réponse peut varier selon la personne d'astreinte ou disponible, mais aussi en fonction des niveaux de gravité, de la durée de l'incident, etc. 

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 probablement besoin de cet ingénieur, quelle que soit l'heure de la journée. En cas d'incidents multiples, votre ingénieur devra savoir lequel traiter en premier et s'il doit immédiatement effectuer une remontée d'un incident à un deuxième ingénieur.   

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.