Bases de la réponse aux incidents
Aujourd’hui, les organisations bénéficient de l’accessibilité, de l’efficacité et de la commodité du cloud, mais elles ont de nombreux défis à relever pour réussir leur transformation numérique, qui implique de déplacer une partie de leur activité vers des services cloud.
Les défis courants suivants figurent parmi ceux auxquels vous pouvez être confronté dans votre organisation :
- Augmentation du nombre de perturbations de service
- Aucune méthode efficace de suivi et de réponse aux incidents (réaction ad hoc uniquement)
- Délai de résolution inacceptable
- Absence d’amélioration voire dégradation du délai de résolution
- Difficultés à trouver des informations ou connaître un statut
- Réapparition des mêmes problèmes et répétition des mêmes erreurs
Pour relever ces défis, vous avez besoin d’un plan de réponse aux incidents bien défini qui repose sur une base solide.
Fondations et piliers
L’objectif des fondations est de soutenir une structure et d’en assurer la stabilité. Dans un autre module introductif de ce parcours d’apprentissage, nous avons décrit l’idée que le travail de fiabilité s’appuie sur le niveau fondamental de la supervision et que la réponse aux incidents se trouve juste au-dessus dans la hiérarchie.
La réponse aux incidents repose elle-aussi sur des fondations. Il existe trois piliers prenant en charge un plan correct de réponse aux incidents :
- Tableaux de service
- Rôles
- Roulements
Dans cette unité, vous allez découvrir chacun de ces piliers et les rôles qu’ils jouent dans la conception d’une stratégie de réponse aux incidents capable de vous faire avancer pour atteindre vos objectifs de fiabilité.
Tableaux de service
Il est crucial d’avoir un bon plan, mais un plan sera inutile si personne ne l’exécute. Par conséquent, la meilleure chose à faire consiste à déterminer qui est supposé répondre aux problèmes et comment faire savoir à ces personnes que leur réponse est nécessaire.
La meilleure façon de relever ce défi consiste à concevoir un tableau de service. Un tableau de service est une liste de personnes affectées à l’équipe d’astreinte. Cette équipe doit être composée de plusieurs ingénieurs. Les membres de cette équipe doivent avoir les connaissances et les compétences nécessaires pour traiter les types de problèmes susceptibles de se produire dans votre environnement, ainsi qu’une formation sur les réponses aux incidents.
Mais une liste de noms ne suffit pas. Vous devez générer une infrastructure qui détermine qui est d’astreinte à tout moment donné et ce que chaque personne doit faire. C’est là qu’interviennent les rôles.
Rôles
Les rôles mettent de l’ordre dans une réponse qui serait sinon chaotique, ou une réponse ad hoc dans le meilleur des cas. Ils permettent de définir les fonctions spécifiques que chaque personne doit remplir dans une situation particulière, ainsi que la place de chacun dans la « chaîne de commandement ». Les rôles peuvent varier selon l’organisation ou même selon le type d’incident, mais toute équipe de réponse aux incidents organisée se doit généralement d’inclure les rôles suivants :
- Principal intervenant : Il s’agit de la « personne de référence » qui est habituellement la première personne sur place. Autrement dit, le premier ingénieur d’astreinte qui est appelé quand un incident se produit.
- Intervenant secondaire : Il s’agit d’une personne qui vient en renfort et qui peut intervenir si le principal intervenant n’est pas disponible ou si une deuxième personne est nécessaire.
- Experts en la matière (SME) : Ce sont des personnes qui ont des connaissances approfondie sur une facette particulière de vos opérations. Ils sont là lorsque le principal intervenant et l’intervenant secondaire ont besoin de soumettre le problème à une personne disposant de compétences plus approfondies. Ils ne sont pas d’astreinte en permanence, mais restent joignables lorsque leurs compétences spécialisées sont nécessaires. Vous devez tenir à jour une liste d’experts en la matière dans différents domaines (par exemple, les bases de données, les front-end, l’infrastructure réseau, les applications web, la cybersécurité, etc.).
- Coordinateur des incidents : Ce rôle est important en cas d’incident ou de panne à grande échelle qui impacte de nombreux composants différents et/ou nécessite de coordonner plusieurs équipes et systèmes différents. Le coordinateur des incidents est la personne qui organise une grande partie de la conversation et les efforts liés aux activités de réponse et de correction. Le coordinateur des incidents garde un œil sur la situation dans son ensemble, il supervise ce qui se passe et qui fait quoi. Il veille à ce que les ingénieurs restent concentrés sur leurs propres efforts de correction sans empiéter sur le travail des autres, ni le réduire à néant.
- Transcripteur : Le rôle du transcripteur consiste à documenter la conversation sur l’incident de façon aussi détaillée que possible. Les équipes utilisent couramment des ponts de téléconférence, des conférences téléphoniques ou des discussions vidéo pour rassembler tout le monde afin d’essayer de comprendre ce qui se passe, ce qui contribue certainement à créer un espace d’échange. Cependant, il est difficile de parcourir et comprendre en détail les conversations et actions des ingénieurs si personne ne les transcrit. C’est là qu’intervient le transcripteur, cette personne qui peut nous aider à documenter autant que possible le problème à des fins d’examen ultérieur. Le transcripteur capture toutes les données possibles, pas seulement ce que font les membres de l’équipe, mais également ce qu’ils disent, voire même ce qu’ils pensent ou découvrent.
- Coordinateur de la communication : Considérez cette personne comme le « responsable des relations publiques » pour l’incident. Le coordinateur de la communication travaille conjointement avec le coordinateur des incidents pour partager des informations sur l’incident avec les personnes qui ne sont pas impliquées activement dans le traitement du problème et la récupération après l’incident. Ces personnes peuvent inclure les clients, les équipes commerciales et marketing, le support et d’autres parties prenantes au sein de l’organisation ou en dehors qui doivent être informés sur ce qui se passe et l’état de progression de la réponse et de la correction.
Roulements
Vous avez maintenant défini votre tableau de service qui liste les membres de l’équipe de réponse et vous leur avez affecté les rôles appropriés. La prochaine et dernière étape consiste à créer un roulement, à savoir un planning qui attribue les dates et horaires pendant lesquels chaque personne est d’astreinte.
Il existe plusieurs façons de diviser les périodes d’astreinte. Leur planification peut être un processus stratégique complexe. Vous ne devez pas attribuer les astreintes de manière aléatoire. Vous devez bien réfléchir à leur planification pour qu’elles soient les plus efficaces possible, et les moins désagréables possible pour les membres de l’équipe.
Voici quelques méthodes de planification des périodes d’astreinte :
- 24 heures sur 24, 7 jours sur 7 : Dans ce type de roulement, les membres de l’équipe sont d’astreinte pendant plusieurs jours d’affilée. Il s’agit d’un moyen simple d’allouer les périodes d’astreinte, mais vous devez veiller à en limiter la durée. Les roulements d’astreintes qui durent plus de trois à quatre jours peuvent être préjudiciables à l’état de santé général du personnel d’ingénierie, et ainsi réduire la fiabilité de l’ensemble du système.
- Suivre le rythme du soleil pour les astreintes : Dans ce modèle de roulement, les ingénieurs planifient leurs périodes d’astreinte uniquement pendant leurs heures de travail normales, puis transmettent leur responsabilité d’astreinte à la fin de leur journée de travail à un autre collègue situé dans un autre fuseau horaire.
Il ne s’agit là que de quelques exemples de la manière d’allouer des périodes d’astreinte. Le plus important est de répartir les périodes d’astreinte d’une manière qui convient le mieux aux membres de votre équipe de réponse. Il existe de nombreuses façons d’adapter les astreintes, notamment pendant les week-ends lorsque les ingénieurs ont besoin d’une plus grande flexibilité. Les ingénieurs doivent être en mesure de transmettre facilement leur rôle à une autre personne quand des conflits non liés au travail surgissent.