Quelle est la cause de la notification ? Un message adressé à un Amazon Simple Notification Service .
Qu'est-ce qui a envoyé le message ? A alarme CloudWatch alarme. Amazon CloudWatch permet de définir une alarme et une action à exécuter lorsqu'une alarme est déclenchée, comme la publication d'un message SNS.
Le nombre d'erreurs HTTP 500 par heure est une mesure disponible pour plusieurs services AWS, tels que API Gateway. Une alarme pourrait être configurée pour se déclencher si cette mesure est différente de zéro.
Exceptions
Pourquoi le pipeline de traitement des demandes a-t-il renvoyé le code d'état 500 ? Il peut y avoir plusieurs raisons, mais toutes aboutissent à une exception non gérée ou, dans certains cas, à un plantage du processeur de requêtes.
Les frameworks de services HTTP disposent d'un gestionnaire d'erreurs par défaut qui génère des réponses 500 si une exception survient et n'est pas gérée par le processeur de requêtes. Ainsi, si une exception est soulevée et n'est pas gérée explicitement par le processeur de requêtes, l'utilisateur voit une erreur interne du serveur.
Une autre possibilité est que le processeur de demande s'est arrêté et que le gestionnaire d'erreur par défaut ne s'est pas exécuté. Dans ce cas, API Gateway renvoie 502.
Les causes peuvent être banales ou ésotériques. Examinons-en quelques-unes.
L'une des plus courantes est l'exception de référence nulle - l'utilisation d'une référence d'objet sans valider qu'elle n'est pas nulle.
Un type d'erreur similaire est la non-validation des paramètres de l'API. Par exemple, l'utilisation d'une chaîne de caractères fournie par l'utilisateur comme nom de godet S3 sans validation peut entraîner l'échec de l'opération de création de godet et la levée d'une exception.
Ce qui nous amène au type d'erreur suivant : la non-validation des réponses provenant d'autres services. La création d'un seau S3 peut échouer pour une multitude de raisons : nom ou autres paramètres non valides, nom déjà utilisé, manque de permissions ou panne de service. Le processeur de requêtes doit être prêt à gérer de telles erreurs.
Atténuations
Pour que les pagers restent silencieux la nuit, il faut plusieurs niveaux de défense. Beaucoup de choses peuvent être faites avant qu'un service (ou une mise à jour) ne soit publié, mais il est également impératif de se préparer à des circonstances imprévues.
Atténuations avant la publication
Conception
Cela commence au moment de la conception - comment le service va-t-il gérer un mauvais état ? Réfléchissez aux dépendances du service et à la manière dont elles peuvent échouer. Que faut-il faire pour que cette défaillance ne concerne qu'une seule demande ou qu'un seul utilisateur ? Comment cela affectera-t-il l'utilisateur ? Comment peut-il se rétablir ?
Les impacts sur la sécurité méritent des considérations distinctes : comment un utilisateur malveillant peut-il utiliser à mauvais escient les fonctionnalités prévues ? Comment le service doit-il s'en prémunir ?
Tests unitaires
Lors de la mise en œuvre, les tests unitaires constituent la première ligne de défense - veillez à ce que la couverture des tests soit élevée dès le départ. En outre, créez des tests unitaires qui reproduisent des scénarios spécifiques identifiés lors de la conception.
Les tests unitaires sont peu coûteux à exécuter et sont les plus rapides à fournir un retour d'information.
Tests d'intégration
Viennent ensuite les tests d'intégration qui permettent de vérifier le comportement du service de bout en bout.
Une fois qu'ils existent, il faut les intégrer dans le pipeline de construction et rejeter les modifications qui échouent aux tests d'intégration. Cela permet de s'assurer que la qualité du code ne se détériore pas.
Atténuations après la publication
Même si nous faisons de notre mieux, des situations imprévues peuvent survenir et entraîner des erreurs de service. Les ingénieurs chargés de la fiabilité des sites doivent disposer d'outils leur permettant de remédier efficacement aux erreurs. Ces outils sont les tests canari, les runbooks et l'API d'exploitation.
Tests canari
Une fois que le service est en cours d'exécution, les tests canari peuvent être utilisés pour confirmer qu'il fonctionne normalement. Les tests canaris sont des tests d'intégration qui sont exécutés périodiquement contre des déploiements de production. Leur échec est un avertissement précoce de l'impact sur les utilisateurs.
Les métriques et les alarmes doivent être dérivées des résultats des tests canaris afin de s'assurer qu'ils sont exécutés et réussissent.
Runbooks
Les runbooks documentent les processus de récupération des données et des services des utilisateurs dans un bon état. Ils incluent des étapes pour enquêter sur les erreurs et pour récupérer les données des utilisateurs ou des services.
Operations API
L'API Opérations permet d'automatiser les étapes communes ou compliquées. Par exemple, une API utile consisterait à restaurer les données des utilisateurs à partir de sauvegardes ou à supprimer en masse les données périmées ou erronées.
Ces opérations doivent être limitées à des utilisateurs spécifiques et, en fonction de leur gravité, inclure une étape d'approbation dans le cadre de leur flux de travail.
Jours de jeu
Il est impossible d'anticiper au moment de la conception les différents modes de défaillance d'un service en nuage. Les journées d'essai permettent d'observer comment le service réagit aux erreurs. Ils ressemblent à des reconstitutions de guerre civile : l'équipe dresse une liste de scénarios d'erreur, élabore un processus pour les induire, puis provoque les erreurs et les traite comme s'il s'agissait d'erreurs réelles.
Par exemple, que se passe-t-il si le service S3 est indisponible ? Comment le service se comporte-t-il ? Comment l'organisation réagit-elle ? Les bonnes alarmes sont-elles déclenchées ? Les bonnes personnes sont-elles informées ? Disposent-elles des outils nécessaires pour atténuer le problème et le communiquer à toutes les parties prenantes ?
Construire pour l'excellence opérationnelle
Sur le plan de la mise en œuvre, les outils opérationnels tels que les runbooks, les journées de jeu et les API d'exploitation reposent sur deux éléments : les indicateurs de fonctionnalité et l'observabilité.
Indicateurs de caractéristiques
Les indicateurs de caractéristiques sont applicables de plusieurs manières :
Un moyen de mettre en œuvre une simulation d'interruption de service pour les journées de jeu,
Un moyen de désactiver des fonctionnalités pour les clients ou pour l'ensemble du service en cas d'erreurs transitoires.
Observabilité
L'observabilité est un terme générique désignant les pratiques et les techniques permettant de comprendre l'état interne d'un service à l'aide de sorties externes. En pratique, il s'agit de s'assurer que le service génère suffisamment de métriques, de journaux et de traces pour remarquer que quelque chose s'est mal passé et comprendre comment cela s'est produit.
Par exemple, si le traitement d'une requête a échoué en raison d'une erreur du service S3, l'erreur S3 est-elle enregistrée ? Qu'en est-il des paramètres de la requête S3 ? Sur la base des journaux de service, l'ingénieur d'astreinte peut-il comprendre pourquoi le traitement de cette demande a nécessité cet appel S3 à ce moment précis ?
Une couverture d'observabilité élevée facilite la détermination de la cause première d'une erreur et permet d'écrire des tests unitaires, d'intégration ou canari pour s'assurer que le scénario d'erreur est mieux géré à l'avenir.
Pour les consultants en logiciels
Les erreurs de serveur internes indiquent une lacune critique dans la compréhension du produit par l'équipe de service. La gravité de leur impact peut varier considérablement. Leur apparition peut déclencher des processus correctifs qui absorbent le temps et les revenus des personnes concernées. Il est donc impératif que nos produits ne soient pas à l'origine de ces erreurs et que nous donnions à nos clients les outils et les connaissances nécessaires pour les éviter, les détecter et en gérer les conséquences.
Contactez Improving pour améliorer vos services REST API avec des stratégies robustes de gestion des erreurs et des pratiques d'excellence opérationnelle.
