Bien que je m'intéresse aux ordinateurs depuis presque aussi longtemps que je me souvienne, ce n'est qu'en première année d'université que j'ai obtenu mon premier emploi lié à l'informatique, en tant que Administrateur système pour le Centre d'études intégrées sur le plasma. Comme tous les emplois à l'université, c'était une excellente occasion d'apprentissage pour un salaire inférieur au marché, avec une priorité accordée à l'autonomie. Mes fonctions à l'époque allaient de tâches d'administration système à des services d'assistance basiques pour le personnel. J'ai passé les quatre années suivantes comme administrateur système pour différents départements de l'université, puis une autre année comme ingénieur en radiodiffusion (un autre article). J'aimerais croire que c'est le travail que j'ai accompli pendant ces quelques années qui m'a donné le respect que j'éprouve pour la difficulté d'une bonne gestion des incidents.

Arrêtez-moi si cela vous dit quelque chose : un utilisateur signale un bug critique sur le système. Vous identifiez immédiatement qu'il s'agit d'un problème à résoudre par l'équipe de développement, vous le transmettez à la personne compétente et vous reprenez votre journée. Vous pourriez recevoir une réponse de l'équipe de développement, ou non. Selon la complexité du problème, si vous recevez une réponse, il peut s'agir d'une réponse froide d'un développeur frustré qui vient de voir sa charge de travail bouleversée.

Laissez-moi vous dire ceci : ce n’est pas entièrement de votre faute.

En tant que développeurs, nous avons tendance à être frustrés lorsqu'un problème se présente. Ce n'est pas le problème en lui-même qui est agaçant : résoudre un problème est amusant ! Le problème réside dans la liste de questions sans réponse qui l'accompagne. Quand est-ce arrivé ? Quels utilisateurs sont concernés ? Où sont les journaux ? Disposons-nous de journaux ? Comment le reproduire ? Est-ce déjà arrivé ? Qui est responsable de cette fonctionnalité ? Sont-ils au bureau aujourd'hui ? Comment vais-je concilier cela avec ma charge de travail actuelle ?

Les questions font boule de neige et, franchement, c'est terrifiant.

Mais ce n'est pas tout pour nous. Dans de nombreux cas, nous comprenons que nous recevons des tickets contenant les informations disponibles à ce moment-là. À mesure que les incidents progressent, la chose la plus importante à faire pour aider le suivant est de tout documenter : mesures prises, notes, journaux. Plus vous avez d'informations, mieux c'est. Il n'appartient pas à une seule personne de tout savoir, mais si vous pouvez enquêter sur un problème (qu'il s'agisse simplement de poser des questions de clarification ou d'extraire des journaux), vous devez vous efforcer de constituer un enregistrement des informations afin de résoudre efficacement le problème.

Reprenons le scénario précédent. Un utilisateur signale un bug critique sur le système. Bien qu'il s'agisse évidemment d'un problème à résoudre par l'équipe de développement, avant de le transmettre à la chaîne, vous pouvez poser des questions de clarification à l'utilisateur et tenter de le reproduire. Les bugs reproductibles sont des bugs réparables. Si vous pouvez le reproduire, incluez tout : étapes, captures d'écran, messages d'erreur et chemins exacts empruntés. Après avoir compilé toutes ces informations, vous êtes prêt à les transmettre au membre de l'équipe de développement concerné qui reprendra là où vous vous êtes arrêté.

Un bon rapport de bug peut faire toute la différence entre un dîner en famille et une nuit blanche pour un développeur. Mais ce n'est pas tout. Lorsqu'un incident touche l'équipe de développement, le cycle d'investigation et de documentation doit perdurer tout au long du processus. C'est une étape importante pour comprendre le problème. quoi Il est essentiel de comprendre comment réduire la probabilité qu'un incident similaire se reproduise. Une gestion efficace des incidents est un travail d'équipe. Du personnel de première ligne jusqu'aux experts, chacun joue un rôle crucial pour résoudre rapidement et efficacement les problèmes.