Si la dette technique était comparable à une dette monétaire, il serait difficile d'en assurer le suivi, à moins de la vérifier manuellement. Pour beaucoup, le seul moyen de savoir que leur compte courant est à court de fonds est de se connecter et de vérifier le solde – ou, pire encore, de recevoir un chèque sans provision ou une carte de débit refusée.

Mais la mesure de la dette technique peut être plus automatique. En effet, contrairement à votre compte bancaire, votre L'infrastructure informatique peut être surveillée de manière continue avec des outils spécialisés, et vous pouvez être averti sur indicateurs de santé critiques . À votre tour, vous pouvez utiliser données de surveillance pour obtenir des informations sur la dette technique. En d'autres termes, nul besoin d'effectuer un audit manuel pour détecter un problème dans votre centre de données. Inutile d'attendre la panne d'un serveur pour être informé d'un problème. Les outils de gestion des incidents vous fournissent ces informations. Par extension, ils vous permettent également de faire le point sur votre dette technique sans avoir à effectuer des mesures manuelles fastidieuses.

Voici comment la gestion des incidents peut vous aider à suivre la dette technique et à la corriger, sans investissement supplémentaire de votre part.

Définition de la dette technique

Tout d'abord, permettez-moi d'expliquer ce que j'entends par dette technique. La dette technique désigne les imperfections du code ou de l'architecture d'un logiciel qui, à long terme, créent des inefficacités ou d'autres problèmes. Même si l'imperfection elle-même est minime, elle peut générer beaucoup d'intérêt au fil du temps, car ses effets se répètent continuellement.

Par exemple, un programme dont le code contient plusieurs versions des mêmes fonctions, plutôt que d'adopter une approche modulaire, pourrait prendre quelques millisecondes de plus à s'exécuter qu'un programme mieux écrit. Ce n'est pas un problème si vous l'exécutez une fois. Mais s'il s'agit d'une application web côté serveur exécutée des milliers de fois par jour, la dette s'accumule rapidement sous forme de mauvaises performances et de perte de temps processeur.

La dette technique a beaucoup de causes potentielles . Parfois, vous pouvez sciemment acquérir une dette technique parce que vous devez mettre en œuvre quelque chose rapidement, vous n'avez pas le temps de suivre les meilleures pratiques et vous décidez que la dette vaut le coût (à ce moment-là du moins). Parfois, même l'administrateur le plus pointilleux a du mal à éviter la dette technique. À moins de pouvoir anticiper l'avenir (par exemple, vous ignoriez probablement qu'un commutateur vieux de dix ans, que vous utilisez encore aujourd'hui faute de moyens pour le mettre à niveau, ne fonctionnerait pas bien avec les pare-feu modernes). Dans ce cas, la dette technique est tout simplement inhérente à un monde imparfait.

Suivi de la dette technique

Bien que la dette technique ait de nombreuses origines, l'avantage de la gestion des incidents pour la mesurer est qu'elle facilite le suivi des problèmes, quelle qu'en soit la cause. Au lieu de procéder à un audit manuel fastidieux de vos systèmes pour identifier les inefficacités, vous pouvez exploiter vos données de gestion des incidents comme indicateur pour évaluer l'ampleur de la dette technique et la maîtriser.

Pour comprendre comment, examinons quelques exemples de différents types de données de gestion des incidents suivies par PagerDuty , et ce que cela peut révéler sur votre dette technique.

Pour commencer, prenez le nombre brut d'alertes générées par vos outils. Il s'agit d'une mesure très basique, qui peut être influencée par plusieurs facteurs. Cependant, si vos systèmes de reporting de gestion des incidents sont correctement configurés et que vous n'apportez aucune modification majeure à votre infrastructure, il existe probablement un lien entre l'ampleur de votre dette technique et le nombre d'incidents signalés par vos outils. En effet, une dette plus importante entraîne une baisse des performances, ce qui déclenche des alertes lorsque les temps de réponse ou les niveaux de ressources atteignent certains seuils. Ainsi, une diminution constante du nombre d'alertes d'un mois à l'autre pourrait signifier que votre dette technique diminue grâce à l'amélioration de l'efficacité de votre code.

Délai moyen de résolution Le MTTR (Mesure Moyenne de Résilience) est un autre indicateur de gestion des incidents qui offre un aperçu de votre dette technique. Une cause fréquente d'un MTTR médiocre est un code trop complexe. Par exemple, pour reprendre l'exemple précédent, un code rédigé à la hâte et contenant des fonctions redondantes sera difficile à comprendre rapidement pour un administrateur. Cela implique un temps de résolution plus long s'il doit le lire et le modifier pour répondre à un incident.

Le taux d'escalade dans vos données de gestion des incidents est également une mesure utile de la dette technique. Une escalade se produit lorsque le premier intervenant sur un incident n'est pas en mesure de résoudre le problème et doit faire appel à une assistance supplémentaire. Des escalades fréquentes peuvent signifier deux choses : premièrement, vos administrateurs ne sont peut-être pas compétents dans leur travail, mais si c'est le cas, vous le savez déjà bien avant d'examiner vos données de gestion des incidents. La deuxième cause principale d'escalade est un code trop complexe pour être traité facilement par la personne qui intervient sur un incident. Si c'est le type de code auquel vos administrateurs sont confrontés lorsqu'ils répondent aux alertes, il y a de fortes chances que ce code soit mal écrit et qu'il constitue une source de dette technique.

Trouver la source de la dette technique

Au-delà de vous aider à retracer les tendances générales concernant votre dette technique, les données de gestion des incidents sont également utiles pour identifier la source d'un problème.

Par exemple, si votre MTTR pour les incidents liés à un programme donné est supérieur à votre MTTR moyen, il y a de fortes chances que ce programme génère une dette technique. De même, si les serveurs exécutant un type de système d'exploitation génèrent un nombre disproportionné d'alertes, il y a probablement une faille de code ou de configuration en cause. Il s'agit d'une dette technique que vous pouvez corriger.

L'avantage d'utiliser les données de gestion des incidents pour localiser et traiter la dette technique est qu'elles ne nécessitent pas de travail supplémentaire important. Vous avez déjà systèmes de surveillance en place, avec (espérons-le) un centre d'opérations et de reporting centralisé comme PagerDuty. Tirer parti de ces ressources pour identifier et corriger la dette technique ne nécessite ni outils ni investissement supplémentaires. Cela vous aide à optimiser proactivement votre code et vos opérations, en utilisant les logiciels déjà en place.