Poste d'invité.

En tant que développeur indépendant, hériter de projets est un mal nécessaire. Presque tous les projets comportent du code hérité que l’équipe a peur de toucher, mais lorsque vous héritez d’un projet en tant que développeur indépendant, le plus souvent, la base de code entière est « héritée ». S’il est difficile de gérer une base de code inconnue, ce qui peut être encore plus difficile est de faire fonctionner cette base de code dans un environnement de production.

Jeux de devinettes

En octobre dernier, j'ai hérité d'un projet qui m'a rendu presque fou. Le code source lui-même était en ruine, c'est sûr, mais ce qui a fait du projet un véritable cauchemar, c'est le manque de documentation et de communication de la part des développeurs précédents. Cela m'a obligé à procéder à une rétro-ingénierie de l'application afin de la faire fonctionner dans le nouvel environnement de production.

Je jouais essentiellement à un jeu de devinettes avec l'architecture. J'avais une idée du type de ressources que je devais fournir, mais sans le présenter aux utilisateurs, je ne savais vraiment pas à quoi m'attendre. Comme vous pouvez le deviner, cela ne s'est pas bien terminé. En raison de modèles de programmation inefficaces, le site a nécessité quatre fois plus de ressources qu'il aurait dû avoir pour atteindre un minimum de stabilité.

Heureusement pour moi, l’une des premières choses que j’ai faites a été d’intégrer des outils de gestion des incidents au projet. Cela m’a permis d’identifier rapidement et régulièrement des problèmes spécifiques et de les résoudre immédiatement. Cela a conduit à des mises à niveau stratégiques des ressources et du projet pour améliorer la stabilité du projet.

Alors, qu'est-ce que j'ai vu exactement ?

Même si j'avais l'impression de jouer au chat et à la souris avec une demi-douzaine de problèmes à la fois, deux d'entre eux survenaient suffisamment rarement pour que je n'en remarque pas l'impact si je n'avais pas intégré d'outils de gestion des incidents : verrouillage de la base de données et problèmes de mémoire Il s’agit de deux problèmes de développement relativement courants qui peuvent survenir, mais bien que courants, ils peuvent être difficiles à diagnostiquer et à résoudre.

Verrouillage de la base de données

Après avoir stabilisé le site de production, l'une des premières choses que nous avons remarquées était que le site plantait toutes les heures, à l'heure près, pendant environ 15 minutes à chaque fois. Grâce aux informations fournies par notre outils de gestion des incidents , J'ai pu réduire le problème à une tâche cron horaire. J'ai découvert qu'une tâche cron critique verrouillait une table de base de données principale à chaque fois qu'elle s'exécutait, ce qui bloquait le site jusqu'à ce que le processus soit terminé. Cela m'a conduit à refactoriser facilement ce script particulier, ce qui m'a permis d'augmenter la disponibilité du site et de réduire la frustration des utilisateurs.

Problèmes de mémoire

Les fuites de mémoire sont une vraie plaie. Dans une application complexe, elles peuvent être extrêmement difficiles à détecter, surtout lorsqu'elles se produisent dans un environnement de production. Malheureusement pour moi, ce projet en était rempli à ras bord. Certaines sont faciles à corriger, comme les entrées de journal indiquant que le serveur Redis manque de mémoire (insérer plus de mémoire ici), mais d'autres peuvent être assez difficiles à trouver.

Un problème de mémoire courant et apparemment aléatoire était celui des dépassements de délai. Parfois, le site commençait à expirer pour les utilisateurs après avoir essayé de charger pendant cinq minutes. Bien que je sache par expérience que cela était probablement dû à des requêtes de base de données plus inefficaces, affiner les requêtes exactes était un peu un défi. Encore une fois, grâce au cadre de gestion des incidents que j'avais mis en place, j'ai pu identifier un ensemble spécifique de pages de profil qui prenaient près d'une demi-heure pour récupérer les données de la base de données. Comme ce processus prenait trop de temps, les utilisateurs continuaient à recharger la page et à recommencer tout le processus.

La première chose que j'ai pu faire a été d'identifier exactement combien de temps les utilisateurs attendaient avant de recharger la page ou d'abandonner (environ 1 minute). Ensuite, j'ai apporté quelques modifications aux configurations du serveur Web et de la base de données pour tout arrêter après 1 minute. Cela m'a donné un peu de répit, de sorte que ces pages ne fassent pas planter le reste du site.

Ensuite, j'ai dû identifier les requêtes exactes qui causaient les problèmes. Malheureusement, ces pages particulières étaient assez lourdes en requêtes, mais après avoir consulté les journaux, j'ai pu les réduire à une ligne particulière qui interrogeait plus de 1 Go de données du serveur de base de données sans mettre en cache le résultat. À partir de là, les étapes suivantes consistaient à refactoriser la requête, à mettre en cache le résultat pendant une durée appropriée et à fournir le correctif aux utilisateurs dès que possible.

Bien que ce ne soient là que quelques exemples des problèmes que j'ai pu résoudre grâce à mes données historiques de gestion des incidents, si je n'avais pas mis en œuvre l'ensemble d'outils dès le début, je serais probablement encore en train de deviner et de vérifier diverses solutions. Ne vous méprenez pas, cependant. Les mêmes outils de gestion des incidents peuvent également être utilisés pour planifier les mises à niveau d'une application bien conçue. Il est essentiel d'identifier les circonstances dans lesquelles vos serveurs sont surchargés ou les choses commencent à ralentir faire évoluer votre projet pour s'adapter à la croissance.

Découvrez comment vous pouvez visualiser les modèles sur toutes les données de vos systèmes pour une meilleure gestion des incidents en consultant la console de commande des opérations PagerDuty .