Noter. trad.: Cet article poursuit une grande série d'articles de l'évangéliste de la technologie AWS Adrian Hornsby, qui vise à expliquer de manière simple et claire l'importance de l'expérimentation pour atténuer les conséquences des pannes des systèmes informatiques.
"Si vous ne parvenez pas à préparer un plan, alors vous envisagez d'échouer." - Benjamin Franklin
В Dans cette série d'articles, j'ai présenté le concept d'ingénierie du chaos et expliqué comment elle permet de trouver et de corriger les défauts du système avant qu'ils n'entraînent des échecs de production. Il a également discuté de la manière dont l’ingénierie du chaos favorise un changement culturel positif au sein des organisations.
À la fin de la première partie, j'avais promis de parler des « outils et méthodes pour introduire des pannes dans les systèmes ». Hélas, ma tête avait ses propres projets à cet égard, et dans cet article, je vais essayer de répondre à la question la plus courante qui se pose parmi les personnes qui souhaitent se lancer dans l'ingénierie du chaos : Que casser en premier ?
Excellente question ! Cependant, il ne semble pas particulièrement gêné par ce panda...
Ne plaisante pas avec le panda du chaos !
Réponse courte : ciblez les services critiques tout au long du chemin de la demande.
Réponse plus longue mais plus claire: Pour comprendre par où commencer à expérimenter le chaos, faites attention à trois domaines :
- Regarder historique des accidents et identifier des modèles ;
- Décidez de dépendances critiques;
- Utilisez ce qu'on appelle effet d'excès de confiance.
C'est drôle, mais cette partie pourrait tout aussi bien s'appeler "Un voyage vers la découverte de soi et l'illumination". Dans ce document, nous commencerons à « jouer » avec des instruments sympas.
1. La réponse réside dans le passé
Si vous vous en souvenez, dans la première partie, j'ai introduit le concept de Correction d'Erreurs (COE) - une méthode par laquelle nous analysons nos erreurs - erreurs de technologie, de processus ou d'organisation - afin de comprendre leur(s) cause(s) et prévenir récidive dans le futur. En général, c'est par là qu'il faut commencer.
"Pour comprendre le présent, il faut connaître le passé." - Carl Sagan
Examinez l'historique des échecs, étiquetez-les dans le COE ou les post-mortems et classez-les. Identifiez les schémas courants qui conduisent souvent à des problèmes et, pour chaque COE, posez-vous la question suivante :
"Cela aurait-il pu être prédit et donc évité par injection de fautes ?"
Je me souviens d'un échec au début de ma carrière. Cela aurait pu être facilement évité si nous avions mené quelques expériences simples de chaos :
Dans des conditions normales, les instances backend répondent aux contrôles d'état de ). ELB utilise ces vérifications pour rediriger les requêtes vers des instances saines. Lorsqu'il s'avère qu'une instance est « mauvaise », ELB cesse de lui envoyer des requêtes. Un jour, après une campagne marketing réussie, le volume de trafic a augmenté et les backends ont commencé à répondre aux contrôles de santé plus lentement que d'habitude. Il faut dire que ces contrôles sanitaires ont été , c'est-à-dire que l'état des dépendances a été vérifié.
Cependant, tout allait bien pendant un moment.
Puis, déjà dans des conditions plutôt stressantes, l’une des instances a commencé à exécuter une tâche cron ETL régulière et non critique. La combinaison d'un trafic élevé et d'une tâche cron a poussé l'utilisation du processeur à près de 100 %. La surcharge du processeur a encore ralenti les réponses aux contrôles de santé, à tel point que l'ELB a décidé que l'instance rencontrait des problèmes de performances. Comme prévu, l'équilibreur a cessé de lui distribuer du trafic, ce qui a entraîné une augmentation de la charge sur les instances restantes du groupe.
Soudainement, toutes les autres instances ont également commencé à échouer au bilan de santé.
Le démarrage d'une nouvelle instance nécessitait le téléchargement et l'installation de packages et prenait beaucoup plus de temps qu'il n'en fallait à l'ELB pour les désactiver - un par un - dans le groupe de mise à l'échelle automatique. Il est clair que l'ensemble du processus a rapidement atteint un point critique et que l'application s'est écrasée.
Ensuite, nous avons toujours compris les points suivants :
- L'installation d'un logiciel lors de la création d'une nouvelle instance prend beaucoup de temps, il vaut mieux privilégier l'approche immuable et .
- Dans des situations complexes, les réponses aux contrôles de santé et aux ELB doivent avoir la priorité – la dernière chose que vous voulez est de compliquer la vie des instances restantes.
- La mise en cache locale des contrôles de santé est très utile (même pendant quelques secondes).
- Dans une situation difficile, n'exécutez pas de tâches cron ni d'autres processus non critiques - économisez des ressources pour les tâches les plus importantes.
- Lors de la mise à l'échelle automatique, utilisez des instances plus petites. Un groupe de 10 petits spécimens vaut mieux qu’un groupe de 4 gros spécimens ; si une instance échoue, dans le premier cas, 10 % du trafic sera réparti sur 9 points, dans le second, 25 % du trafic sur trois points.
ainsi, cela aurait-il pu être prévu, et donc évité en introduisant le problème ?
Oui, et de plusieurs manières.
Premièrement, en simulant une utilisation élevée du processeur à l'aide d'outils tels que ou :
❯ stress-ng --matrix 1 -t 60s
stress de
Deuxièmement, en surchargeant l'instance avec et d'autres utilitaires similaires :
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Les expériences sont relativement simples, mais peuvent donner matière à réflexion sans avoir à subir le stress d’un véritable échec.
Mais ne t'arrête pas là. Essayez de reproduire le crash dans un environnement de test et vérifiez votre réponse à la question "Cela aurait-il pu être prévu et donc évité en introduisant un défaut ?" Il s'agit d'une mini expérience de chaos dans une expérience de chaos visant à tester des hypothèses, mais commençant par un échec.
Était-ce un rêve ou est-ce réellement arrivé ?
Alors étudiez l'histoire des échecs, analysez COE, étiquetez-les et classez-les par « rayon de réussite » (ou plus précisément, le nombre de clients concernés), puis recherchez des modèles. Demandez-vous si cela aurait pu être prédit et évité en introduisant le problème. Vérifie ta réponse.
Passez ensuite aux modèles les plus courants avec la gamme la plus large.
2. Créez une carte de dépendances
Prenez un moment pour réfléchir à votre candidature. Existe-t-il une carte claire de ses dépendances ? Savez-vous quel impact ils auront en cas d’échec ?
Si vous n'êtes pas très familier avec le code de votre application ou si celui-ci est devenu très volumineux, il peut être difficile de comprendre ce que fait le code et quelles sont ses dépendances. Comprendre ces dépendances et leur impact possible sur l'application et les utilisateurs est essentiel pour savoir par où commencer avec l'ingénierie du chaos : le point de départ est le composant ayant le plus grand rayon d'impact.
L'identification et la documentation des dépendances s'appellent "construire une carte de dépendances» (cartographie des dépendances). Cela est généralement effectué pour les applications avec une base de code importante à l'aide d'outils de profilage de code. (profilage de code) et instruments (instrumentation). Vous pouvez également créer une carte en surveillant le trafic réseau.
Cependant, toutes les dépendances ne sont pas identiques (ce qui complique encore le processus). Quelques critique, autres - secondaire (du moins en théorie, puisque les crashs se produisent souvent en raison de problèmes avec des dépendances considérées comme non critiques).
Sans dépendances critiques, le service ne peut pas fonctionner. Dépendances non critiques "ne devrait pas» pour influencer le service en cas de chute. Pour comprendre les dépendances, vous devez avoir une compréhension claire des API utilisées par votre application. Cela peut s'avérer beaucoup plus difficile qu'il n'y paraît, du moins pour les applications volumineuses.
Commencez par parcourir toutes les API. Mettre en valeur le plus important et critique... Prendre dépendances depuis le référentiel de code, vérifiez-le journaux de connexion, puis visualisez documentation (bien sûr, s'il existe - sinon vous avez toujoursоde plus gros problèmes). Utilisez les outils pour profilage et traçage, filtrer les appels externes.
Vous pouvez utiliser des programmes comme netstat - un utilitaire de ligne de commande qui affiche une liste de toutes les connexions réseau (sockets actifs) du système. Par exemple, pour répertorier toutes les connexions actuelles, tapez :
❯ netstat -a | more
Dans AWS, vous pouvez utiliser (journaux de flux) VPC est une méthode qui vous permet de collecter des informations sur le trafic IP entrant ou sortant des interfaces réseau dans un VPC. Ces journaux peuvent également être utiles dans d'autres tâches, par exemple trouver une réponse à la question de savoir pourquoi certains trafics n'atteignent pas l'instance.
Vous pouvez aussi utiliser . X-Ray vous permet d'obtenir des informations détaillées et "ultimes" (de bout en bout) aperçu des requêtes à mesure qu'elles progressent dans l'application, et crée également une carte des composants sous-jacents de l'application. Très pratique si vous avez besoin d'identifier des dépendances.
Console AWS X-Ray
Une carte des dépendances du réseau n’est qu’une solution partielle. Oui, cela montre quelle application communique avec laquelle, mais il existe d'autres dépendances.
De nombreuses applications utilisent DNS pour se connecter aux dépendances, tandis que d'autres peuvent utiliser la découverte de services ou même des adresses IP codées en dur dans les fichiers de configuration (par ex. /etc/hosts).
Par exemple, vous pouvez créer par iptables et voyez ce qui casse. Pour ce faire, entrez la commande suivante :
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Trou noir DNS
Si l' /etc/hosts ou d'autres fichiers de configuration, vous trouverez des adresses IP dont vous ne savez rien (oui, malheureusement, cela arrive aussi), vous pouvez à nouveau venir à la rescousse iptables. Disons que vous avez découvert 8.8.8.8 et je ne sais pas qu'il s'agit de l'adresse du serveur DNS public de Google. En utilisant iptables Vous pouvez bloquer le trafic entrant et sortant vers cette adresse à l'aide des commandes suivantes :
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Fermeture de l'accès
La première règle supprime tous les paquets du DNS public de Google : ping fonctionne, mais les paquets ne sont pas renvoyés. La deuxième règle rejette tous les paquets provenant de votre système vers le DNS public de Google - en réponse à ping nous obtenons Opération non autorisée.
Remarque : dans ce cas particulier, il serait préférable d'utiliser whois 8.8.8.8, mais ce n'est qu'un exemple.
Nous pouvons aller encore plus loin dans le terrier du lapin, car tout ce qui utilise TCP et UDP dépend également d'IP. Dans la plupart des cas, IP est liée à ARP. N'oubliez pas les pare-feu...
Si vous prenez la pilule rouge, vous restez au pays des merveilles et je vous montrerai jusqu'où va le terrier du lapin. »
Une approche plus radicale consiste à déconnecter voitures une par une et voyez ce qui est cassé... devenez un "singe du chaos". Bien entendu, de nombreux systèmes de production ne sont pas conçus pour une telle attaque par force brute, mais cela peut au moins être essayé dans un environnement de test.
Construire une carte des dépendances est souvent une entreprise très longue. J'ai récemment parlé avec un client qui a passé près de 2 ans à développer un outil qui génère semi-automatiquement des cartes de dépendances pour des centaines de microservices et de commandes.
Le résultat est cependant extrêmement intéressant et utile. Vous en apprendrez beaucoup sur votre système, ses dépendances et ses opérations. Encore une fois, soyez patient : c'est le voyage lui-même qui compte le plus.
3. Méfiez-vous de l’excès de confiance
« Celui qui rêve de quoi y croit. » — Démosthène
Avez-vous déjà entendu parler de effet d'excès de confiance?
Selon Wikipédia, l’effet d’excès de confiance est « un biais cognitif dans lequel la confiance d’une personne dans ses actions et ses décisions est nettement supérieure à l’exactitude objective de ces jugements, en particulier lorsque le niveau de confiance est relativement élevé ».
Basé sur l'instinct et l'expérience...
D’après mon expérience, cette distorsion est un bon indice pour savoir par où commencer en matière d’ingénierie du chaos.
Méfiez-vous de l'opérateur trop confiant :
Charlie : "Ce truc n'est pas tombé depuis cinq ans, tout va bien !"
Crash : "Attends... je serai bientôt là !"
Les préjugés résultant d’un excès de confiance sont une chose insidieuse et même dangereuse en raison des divers facteurs qui l’influencent. Cela est particulièrement vrai lorsque les membres de l’équipe ont investi tout leur cœur dans une technologie ou ont passé beaucoup de temps à la « réparer ».
En résumé
La recherche d'un point de départ pour l'ingénierie du chaos apporte toujours plus de résultats que prévu, et les équipes qui commencent à casser les choses trop rapidement perdent de vue l'essence plus globale et intéressante du (chaos-)ingénierie - utilisation créative Méthodes scientifiques и preuves empiriques pour la conception, le développement, l'exploitation, la maintenance et l'amélioration de systèmes (logiciels).
Ceci conclut la deuxième partie. S'il vous plaît, écrivez des commentaires, partagez des opinions ou appuyez simplement sur vos mains . Dans la partie suivante, je vraiment J'examinerai les outils et les méthodes pour introduire des pannes dans les systèmes. Jusqu'à!
PS du traducteur
A lire aussi sur notre blog :
- «";
- «";
- «";
- «».
Source: habr.com