Bien que je m'intéresse aux ordinateurs depuis presque aussi longtemps que je me souvienne, ce n'est que lorsque j'étais en première année d'université que j'ai obtenu mon premier emploi lié à l'informatique, en tant que Administrateur des systèmes pour le Center for Integrated Plasma Studies. C'était, comme tous les emplois à l'université, une excellente occasion d'apprentissage pour un salaire inférieur au marché, l'accent étant mis sur l'autonomie. Mes fonctions à l'époque allaient de véritables tâches d'administration de systèmes à des services d'assistance de base pour le personnel. J'ai passé les 4 années suivantes à travailler comme administrateur système pour divers départements de l'université, et une autre année après comme ingénieur de diffusion (une histoire pour une autre fois). J'aimerais penser que c'est le travail que j'ai fait pendant ces quelques années qui m'a donné le respect que j'ai pour la difficulté de gérer correctement les incidents.

Arrêtez-moi si cela vous semble familier : un utilisateur signale un bug critique sur le système. Vous identifiez immédiatement qu'il s'agit d'un problème que l'équipe de développement doit résoudre, vous le transmettez à la personne appropriée et vous continuez votre journée. Vous pouvez recevoir une réponse de l'équipe de développement sur le problème, 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 se faire jeter une grenade dans sa charge de travail.

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 à nous. Ce n'est pas le problème en lui-même qui est dérangeant : 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 que cela s'est produit ? Quels utilisateurs sont concernés ? Où sont les journaux ? Avons-nous des journaux ? Comment puis-je le reproduire ? Est-ce que cela s'est déjà produit ? Qui est responsable de cette fonctionnalité ? Sont-ils au bureau aujourd'hui ? Comment vais-je équilibrer cela avec ma charge de travail actuelle ?

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

Mais tout ne dépend pas que de nous. Dans de nombreux cas, nous comprenons que nous recevons des tickets avec les informations disponibles à ce moment-là. Au fur et à mesure que les incidents remontent la chaîne, la chose la plus importante que vous puissiez faire pour aider le prochain intervenant 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 quelque chose (qu'il s'agisse simplement de poser des questions de clarification ou d'extraire des journaux), vous devez faire un effort pour créer un enregistrement des informations afin de résoudre efficacement le problème en question.

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 que l'équipe de développement doit résoudre, 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. Maintenant, après avoir compilé toutes ces informations, vous êtes prêt à les transmettre au membre de l'équipe de développement approprié qui reprendra là où vous vous êtes arrêté.

Un bon rapport de bug peut faire la différence entre un développeur qui peut dîner avec sa famille et une nuit blanche. Mais cela ne s'arrête pas là. Lorsque l'incident touche l'équipe de développement, le cycle d'enquête et de documentation doit perdurer tout au long du processus. Il s'agit non seulement d'une étape importante pour comprendre quoi Il est essentiel de comprendre comment réduire la probabilité qu'un incident similaire se reproduise à l'avenir. Une gestion efficace des incidents est un travail d'équipe. De la première ligne jusqu'aux experts en la matière, tout le monde joue un rôle crucial pour résoudre rapidement et efficacement les problèmes.