Politiques de remontée pour une gestion efficace des incidents

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.

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.