J'adore écrire des logiciels, mais je déteste m'occuper des bugs. Ils vous éloignent de ce que vous voulez faire et vous conduisent souvent dans un terrier de lapin. Sentinelle — une plate-forme de suivi des erreurs open source qui fournit une logique d'application complète, un contexte approfondi et une visibilité sur l'ensemble de la pile en temps réel — nous avons quelques conseils que nous avons perfectionnés au fil du temps pour rendre la résolution des erreurs indolore (ok, moins douloureuse), y compris un intégration officielle avec PagerDuty .

Vous trouverez ci-dessous une liste de ces bonnes pratiques. Nous vous souhaitons un rapide voyage dans le terrier du lapin où se trouve ce bug et comment puis-je le corriger la prochaine fois que vous serez averti à 3 heures du matin

Identifier l'impact du problème

Alors, dans votre brume de sommeil profond de 3 heures du matin, vous vous dirigez vers votre ordinateur et essayez de penser clairement à ce qui se passe. Alerte PagerDuty vous venez de recevoir. La première chose que vous voudrez faire est d'identifier l'impact du problème.

Ce problème concerne-t-il uniquement Internet Explorer ? Uniquement les clients d'un centre de données particulier ? Vous savez quelles sont les questions d'impact les plus pertinentes à poser, et c'est le moment de le faire.

Sentry implémente un système appelé Mots clés —diverses paires clé/valeur attribuées à un événement, qui sont résumées au niveau du problème. Vous pouvez gagner du temps et réduire le stress en évitant les allers-retours avec vos clients au sujet des informations de leur navigateur en permettant aux balises de découvrir les points chauds du bogue.

Retracez les étapes de votre utilisateur pour reproduire le problème

Si la cause du problème n'est pas évidente (et ce n'est probablement pas le cas, sinon vous ne l'auriez pas expédié en premier lieu), il peut être utile de comprendre comment votre utilisateur y est arrivé. Sentry suit automatiquement le chemin emprunté par votre utilisateur. chapelure . Bien sûr, vous pouvez également le reconstituer manuellement en recherchant dans vos journaux, mais cela semble vraiment pénible.

Obtenir du contexte à partir des traces de pile

À ce stade, vous avez identifié le terrier du lapin et fait un ou deux pas à l'intérieur. Faites maintenant quelques pas de plus. Et encore quelques autres.

Idéalement, vous avez déjà reproduit le bug et vous pouvez maintenant fouiller dans le code pour découvrir exactement ce qui s'est passé et pourquoi. La clé pour répondre à ces questions est le contexte : vous aurez besoin de tout ce que vous pouvez pour trouver la sortie de ce trou.

Une façon d'obtenir ce contexte est de jeter un œil à votre trace de pile, ce qui vous donne probablement une idée de l'endroit où l'exception a été levée. Les traces de pile devraient vous donner un aperçu de la séquence d'événements qui ont conduit au bogue ainsi que de la ligne de code où vous pouvez trouver le bogue. Tellement utile !

Vous souhaitez encore plus de contexte ? Sentry vous donne un aperçu de votre trace de pile, mais l'enrichit également de tout ce que vous souhaiteriez qu'elle contienne, y compris votre code source non minifié et les variables locales de la pile.

Ajoutez le développeur d'origine si nécessaire

Bien sûr, une fois que vous avez localisé le bug et que vous savez ce qui le cause, vous pouvez continuer à travailler jusqu'à ce que vous le résolviez. Ou pas. Ou vous pouvez retourner à vos occupations habituelles (manger, dormir, profiter de la vie) en laissant la bonne personne gérer le bug. Déléguer les bugs n'est peut-être pas la tâche la plus agréable, mais cela devrait finalement simplifier et accélérer le processus de résolution des erreurs.

En tant que clients PagerDuty , nous sommes en mesure d'ajouter des développeurs en tant que Parties prenantes ou les intervenants en conséquence.

Sentry fournit des intégrations approfondies avec des plateformes de gestion de code source pour découvrir les commits qui ont probablement introduit l'erreur. le suspect commet .

Sentinelle aussi suggère le développeur qui peut le mieux résoudre le problème.

Donnez la priorité à vos alertes

Soyons honnêtes : toutes les erreurs ne méritent pas qu'on vous alerte. Si vous recevez des notifications qui ne vous permettent pas d'agir, faites quelque chose. Utilisez vos outils à votre avantage.

Peut-être souhaitez-vous uniquement être averti via PagerDuty si une erreur affecte plus de 100 clients en une minute. Peut-être que sur un autre, vous souhaitez être averti chaque fois que des types d'erreurs très spécifiques sont générés. Vous pouvez facilement configurer tout cela via Règles d'alerte de Sentry .

Vous souhaitez filtrer les avertissements ou les erreurs JavaScript causés par des plugins loufoques que vous ne contrôlez pas ? Utilisez Gestion des événements de PagerDuty ou supprimez-les directement depuis le problème Sentry en utilisant Supprimer et rejeter .

Bien que ces meilleures pratiques puissent être appliquées en dehors de Sentry et PagerDuty, pourquoi s'embêter avec autre chose que les meilleures ? Après tout, des dizaines de milliers de clients ne peuvent pas se tromper.

Et, comme vous l'avez peut-être deviné, Sentry et PagerDuty fonctionnent très bien ensemble. Tellement génial, en fait, que nous avons un intégration officielle avec PagerDuty . Notre intégration envoie des alertes via PagerDuty pour les workflows de réponse aux incidents et de renseignement que vous définissez. Permettez à vos équipes de développement et d’exploitation d’obtenir une vue complète des erreurs, des alertes en fonction de la politique d’escalade, de l’urgence des notifications et du comportement de réponse, partout dans votre application.

Neil Manvar est responsable des solutions d'ingénierie chez Sentry. Après des années d'expérience dans le développement de logiciels, Neil s'est orienté vers l'ingénierie des solutions pour DevOps. Toujours disponible et toujours prêt à s'arrêter pour Cinnabon.