Contenu
- Se préparer à l'échec
- Les prochaines étapes
- Pas de bugs, pas de stress - Votre guide étape par étape pour créer un logiciel qui change la vie sans vous détruire
- Apprendre et s'améliorer par des exercices
Source: pressureUA / iStockphoto
À emporter:
Les systèmes modernes doivent pouvoir gérer le chaos afin d'éviter les temps d'arrêt. C’est pourquoi il est plus important que jamais de tester minutieusement les systèmes et d’assurer leur résilience.
Malgré nos efforts les plus importants pour les éviter, les incidents informatiques font inévitablement partie du travail. Il est de plus en plus difficile de rester en tête des temps morts pour les activités de l'entreprise. Les systèmes actuels sont étroitement couplés et de plus en plus complexes, et avec des pièces plus mobiles, de plus en plus d'opportunités pour que les choses tournent mal.
C'est l'une des raisons pour lesquelles de plus en plus d'organisations se tournent vers les microservices pour accroître la disponibilité des services et améliorer la résilience aux pannes. Cependant, même s’ils sont parfaits pour la rupture d’applications monolithiques, ils peuvent également potentiellement aggraver le risque d’échec - à moins qu’ils ne soient conçus expressément dans un souci de résilience.
Se préparer à l'échec
Compte tenu de la nature chaotique inhérente aux systèmes distribués, les services doivent être développés non seulement pour anticiper les pannes, mais aussi pour récupérer automatiquement en cas de panne. Cela signifie que vous devez régulièrement provoquer des pannes pour vous assurer que vos systèmes peuvent gérer le chaos sans perturber le service fourni aux clients finaux. Et pour cela, vous devez avoir la possibilité de simuler un trafic de type production dans des environnements de test.
Bien sûr, c’est une bonne idée de tester la résilience avant que les modifications ne parviennent à la production. Si vous ne le faites pas, vous ne pourrez pas vérifier que vos services peuvent prendre en charge les charges moyennes et maximales. En fait, le pari le plus sûr est de vous assurer que votre produit peut gérer jusqu'à deux fois la quantité maximale sans avoir à passer à la vitesse supérieure.
En ce qui concerne les tests de résilience, les bons outils ne devraient pas être trop préoccupés par la façon dont les demandes sont traitées, mais simplement par leur impact. N'oubliez pas que dans certaines conditions, le service d'entrée peut ne pas transmettre une demande au reste du système, mais ne pas signaler l'échec. Ne risquez pas d’être sous le radar de la surveillance en vous assurant que la validation de bout en bout a bien lieu. (Pour plus d'informations, voir Tech Failures: pouvons-nous vivre avec?)
Les prochaines étapes
Après avoir compris comment les services se comportent sous charge, il est temps de commencer à introduire les événements de défaillance. Comme pour tous les tests de logiciels, il est préférable de disposer d'outils automatisés vous permettant de reproduire facilement et rapidement des scénarios, afin de pouvoir coordonner des événements complexes ayant une incidence sur différentes technologies d'infrastructure. Et au-delà de la possibilité de vérifier les correctifs et les modifications apportées aux services, cela vous permet d'exécuter des scénarios de défaillance aléatoires dans n'importe quel environnement et selon un planning.
Les événements d'échec significatifs dépendent en grande partie de la disposition de vos services, et vous pouvez les formuler en posant des questions spécifiques qui vous concernent. Par exemple, quel est l’impact pour les utilisateurs de la base de données quand une base de données devient inaccessible pendant un certain temps? Ces utilisateurs peuvent-ils toujours naviguer dans l'interface utilisateur Web? Peuvent-ils toujours publier des mises à jour de leurs informations, et ces mises à jour seront-elles traitées correctement lorsque la base de données redeviendra accessible?
Si vous exécutez plusieurs microservices, vous pouvez demander s'il y aura une panne globale si un service individuel tombe en panne. Ou si vous disposez d'un mécanisme de mise en file d'attente pour mettre en tampon la communication entre les services, que se passe-t-il lorsque le ou les services consommateurs cessent de fonctionner? Les utilisateurs seront-ils toujours en mesure de travailler avec votre application? Et avec une charge moyenne, combien de temps avez-vous avant que les files d'attente ne débordent et que vous ne perdiez plus?
Pas de bugs, pas de stress - Votre guide étape par étape pour créer un logiciel qui change la vie sans vous détruire
Vous ne pouvez pas améliorer vos compétences en programmation lorsque personne ne se soucie de la qualité des logiciels.
Une fois que vous avez défini quelques questions clés sur votre infrastructure, vous pouvez commencer à répertorier différentes manières de simuler ces défaillances. Cela pourrait être suffisant pour arrêter un service particulier ou un serveur de base de données. Vous souhaiterez peut-être bloquer le thread principal d'un service pour simuler un blocage immédiat, pendant que son conteneur est toujours réactif et en cours d'exécution. Vous pouvez décider d'introduire des règles dans votre réseau pour bloquer le trafic entre des services spécifiques. Sur les environnements Linux, vous pouvez utiliser des outils tels que «tc» pour émuler des situations réseau telles que des paquets à latence élevée, abandonnés, corrompus ou dupliqués. (Il peut être important d'impliquer les utilisateurs dans les tests. Pour en savoir plus, reportez-vous à 4 raisons pour lesquelles les utilisateurs finaux doivent participer aux tests avant UAT.)
Apprendre et s'améliorer par des exercices
L'un des aspects les plus précieux de la création de scénarios d'échec est qu'ils peuvent exposer tous les moyens potentiels d'échec du système, ouvrant ainsi la voie à une logique d'auto-guérison. Votre équipe passera par les étapes pour récupérer les services manuellement - un exercice formidable, en passant, pour confirmer qu’elle est capable de le faire dans les contrats de niveau de service. L'automatisation de ce processus de récupération peut être travaillée, mais entre-temps, vous pouvez être tranquille, sachant que votre équipe a suivi le processus de restauration des services. En rendant les scénarios d’échec aléatoires et réguliers et en ne divulguant pas tous les détails de l’exécution, vous pouvez également inclure la découverte et les diagnostics dans l’exercice - qui est, après tout, un élément essentiel des contrats de niveau de service.
À la base, l’ingénierie du chaos prend la complexité du système comme une donnée, la teste en simulant de nouvelles conditions loufoques et observe la réaction du système. Les équipes d’ingénierie de données doivent redéfinir et reconfigurer le système afin d’obtenir une résilience supérieure. Il y a tellement d'occasions d'apprendre de nouvelles choses utiles. Par exemple, vous pouvez trouver des cas où les services ne sont pas mis à jour lorsque les services en aval ont changé ou des domaines dans lesquels la surveillance est complètement absente. Les moyens excitants de rendre votre produit plus résistant et plus robuste ne manquent pas!