La dernière chose que vous voulez voir pendant le débogage du code est le chaos . Mais que faire si ce chaos est contrôlé et lancé par les mains du développeur lui-même? Pourquoi organiser délibérément des turbulences dans le bon fonctionnement de votre application, comment obtenir la tranquillité d'esprit lors de la publication de fonctionnalités importantes et où la pratique de l'ingénierie du chaos est utile , lisez PavelOsipov dans la conversation entre le podcast principal AppsCast et Pavel Osipov.
Alexey Kudryavtsev: Bonjour à tous! Aujourd'hui, notre invité est Pavel Osipov de Mail.ru Cloud, avec qui nous parlerons de l'ingénierie du chaos.
Pavel Osipov: Bonjour à tous! Depuis six ans, je gère le développement de Mail.ru Cloud. Pendant ce temps, nous avons accumulé de nombreuses pratiques de tests économiques, dont l'une est l'ingénierie du chaos. Cette pratique vous permet de mener une série d'expériences contrôlées pour identifier la santé de votre système dans un environnement hostile. Sur la base des résultats de ces expériences, vous obtenez des informations utiles. Par exemple, il est peu probable que vous voyiez régulièrement le comportement du système dans un réseau instable. Si votre utilisateur voyage souvent dans le métro ou se repose dans un environnement wifi d'hôtel, le réseau n'est pas aussi stable que sur le lieu de travail du programmeur. Après chacune de mes vacances en mer, j'apporte tout un "portfolio" de journaux sur ce qui n'a pas fonctionné avec l'application.
Personnellement, l'élevage du chaos manuel me permet d'avoir une dose supplémentaire de confiance que tout se passera bien, même si tout va mal en dehors de l'application.
Il y a des situations où je fais plus confiance au chaos manuel qu'aux tests automatiques.
Voir la racine du chaos
Alexei Kudryavtsev: D'où viennent les racines d'une telle pratique?
Pavel Osipov: C'est une pratique de serveur, où il y a beaucoup plus de problèmes. Nous sommes habitués au concept de dette technique, et en Occident il y a aussi
une dette sombre - une dette cachée qui naît inévitablement dans des systèmes complexes. Contrairement à la dette technique, où nous empruntons consciemment le temps de l'avenir au présent, la dette cachée est invisible au stade de la création du système. Il se produit à la jonction de composants ou de matériel et de logiciels et peut entraîner une cascade de problèmes: quelque chose tombe en panne sur un composant, en chevauche un autre, et maintenant tout le système se trouve.
Par exemple, en 2016, en raison de la fermeture de la base de données en cascade, 2,5 heures ont été attribuées à Facebook. Ensuite, le système qui a vérifié la validité des fichiers de configuration a commencé à les supprimer par erreur, non seulement dans le sous-système de mise en cache, mais également dans la base de données qui était la source principale.
J'aime beaucoup l'entretien avec Oleg Anastasiev d'Odnoklassniki sur la conduite d'exercices pour prévenir les accidents d'infrastructure. Ils ont trois centres de données, qui devraient être en alerte 24 heures sur 24, 7 jours sur 7, mais une fois par trimestre, une sorte de défaillance se produit. Ils effectuent de tels exercices sur la production. D'une part, cela semble effrayant, car si quelque chose d'imprévisible se produit, le centre de données entier tombera et ne sera pas disponible sur le prod. Mais d'un autre côté, ce processus est contrôlé et si quelque chose ne va pas, vous le verrez immédiatement, l'arrêtez et tout sera restauré. Si cela se produit dans des conditions de vie au combat, le rallumer ne fonctionne tout simplement pas et l'analyse des raisons de l'arrêt durera longtemps.
Les avantages du chaos dans le développement mobile
Daniil Popov: Jusqu'à présent, nous parlons de développement de serveurs, où les microservices sont populaires et les pannes en cascade sont possibles. Pouvez-vous donner plus d'exemples de ce qu'il faut vérifier par l'ingénierie du chaos dans le développement mobile?
Pavel Osipov: Mon exemple préféré est la journalisation des applications. Dans les conditions de test, nos actions peuvent être très douces vis-à-vis de l'application: nous sommes entrés dans les paramètres du compte, cliqué sur le bouton "quitter", l'application a quitté et, lors de la visualisation de l'écran de connexion, tout semble aller bien. Les utilisateurs ont souvent des situations plus exotiques. Par exemple, le client a modifié le mot de passe via l'interface Web ou un grand nombre de journaux s'est produit sur d'autres appareils et le jeton d'actualisation a été remplacé. Cette journalisation ne se produit pas dans la fenêtre avec le compte d'utilisateur, mais, par exemple, au moment de la visionneuse de photos en plein écran.
Nous avons trouvé de nombreuses situations où la journalisation à différents endroits de l'application entraîne des conséquences telles que des fuites de mémoire. Le même téléspectateur avec un bloc d'achèvement pourrait récupérer un service vital, qui a finalement fuité.
Nous simulons les conditions en utilisant l'ingénierie du chaos. Le système dispose d'un service qui, de manière transparente pour les services d'application de haut niveau, met à jour le jeton d'accès à l'application à l'aide du jeton d'actualisation de l'application. Nous avons introduit le chaos dans lequel le service, au lieu de mettre à jour le jeton, avec un certain degré de probabilité le gâche, et chaque développeur rencontre un journal plusieurs fois par jour dans un endroit inattendu.
Grâce à cela, nous avons découvert un comportement intéressant d'UIKit dans iOS: si, lorsqu'un ViewController enraciné est mis en surbrillance, une autre fenêtre est modalement bloquée de la fenêtre, alors le ViewController enraciné fuit et reste dans le système pour toujours. Si en même temps le ViewController avait un lien avec des services qui, selon la logique de l'architecture, doivent exister dans le système en une seule fois, alors les problèmes ne peuvent être évités. Par exemple, le Cloud dispose d'un service de chargement automatique de photos, et si deux de ces services restent dans le système, ils feront beaucoup de travail inutile et mettront la batterie de l'appareil deux fois plus vite qu'il le devrait.
Un autre cas curieux. Lorsque iOS 8 est apparu, il y avait des problèmes d'extensions: sur certains appareils, lorsque toutes les autorisations dans les paramètres d'application ont été accordées, le système a déclaré au début que l'application n'avait pas accès au groupe d'applications partagées.
Typologie du chaos
Daniil Popov: Le chaos est introduit automatiquement dans le système sur la base de l'intérêt ou d'une configuration, mais une personne a-t-elle besoin d'un regard pour comprendre ce qui s'est mal passé?
Pavel Osipov: Le chaos est différent: manuel et automatique. Dans le cas du système d'exploitation, qui a déclaré que l'application n'avait pas accès au groupe d'applications partagées et que les extensions ne pouvaient pas accéder aux ressources partagées et à la base de données, le chaos manuel a été utilisé, qui a été activé à l'aide d'une coche dans les paramètres système de l'application. Cela pourrait facilement être modélisé par les gars de l'équipe QA.
Il y a un chaos automatisé. En particulier, il s'agit d'erreurs modélisées à partir des microservices de notre backend et du chaos associé à la mise à jour du jeton. Les conséquences sont différentes. La disposition parcourue peut être déterminée par observation visuelle. Il existe des endroits qui vous permettent de détecter des anomalies en mode automatique. Par exemple, dans notre application, les fuites de mémoire sont automatiquement détectées. Il y a deux conteneurs IoC dans le système. Un gestionnaire est la durée de vie des services globaux, qui coïncide avec la durée de vie de l'application elle-même, un autre conteneur est le gestionnaire des services qui coïncident dans le temps avec l'utilisateur. Chaque conteneur IoC, en créant un service, vérifie qu'il existe dans une instance.
Revenons à l'exemple avec les journaux. À un certain endroit, une connexion s'est soudainement produite et le développeur a de nouveau entré le compte pour continuer à travailler. À ce stade, le conteneur IoC signale qu'une fuite de mémoire s'est produite et le service, qui devrait en théorie exister dans une seule instance, est à nouveau détecté.
Quand est le temps du chaos?
Alexei Kudryavtsev: Qu'est
- ce qui a déclenché la mise en œuvre de la pratique?
Pavel Osipov: Nous y sommes arrivés grâce à la nécessité de réduire le coût des tests. Comment faire face aux mêmes problèmes du razlogin? Vous pouvez écrire des tests unitaires pour les fuites, vous pouvez être confus et écrire des tests d'interface utilisateur.
L'ingénierie du chaos est la pratique la moins chère, car elle n'est pas liée aux cas d'utilisateurs, mais agit automatiquement pour tous les cas d'utilisateurs ensemble.
Le deuxième déclencheur - avant l'introduction de la pratique, dans notre rapport de crash, des crashs similaires avec la même cause racine étaient souvent observés. Par exemple, que le crash s'est produit non pas à cause du journal système dans le profil, mais parce que l'utilisateur faisait défiler la galerie de photos à ce moment-là. Les situations sont différentes et il est impossible de tester toutes les combinaisons de razlogins. Je voulais donc trouver quelque chose qui automatise le processus.
L'ingénierie du chaos a une pratique connexe - les
tests mutationnels . Dans cette pratique, nous modifions de petits morceaux de code et voyons comment cela affecte les tests. Si, après la modification, les tests sont effectués correctement, cela signifie que pour ces fragments de code, les tests ne sont pas suffisants.
La différence entre l'ingénierie du chaos et les tests de mutation est que nous ne changeons pas automatiquement le code de production lui-même, mais son environnement.
Alexei Kudryavtsev: Serait-il possible de localiser la cause et de la réparer sans ingénierie du chaos?
Pavel Osipov: Il n'y a pas de raison unique qui provoque des accidents. Chaque cas est unique à sa manière. Par exemple, le bouton modal est apparu en haut de la fenêtre, ce qui a entraîné la fuite du ViewController ruineux pendant le razlog. Il n'est pas possible de prévoir toutes les combinaisons de hiérarchies de fenêtres que vous avez lors de la journalisation. Ingénierie du chaos modèles localisés dans lesquels se produisent des fuites et des plantages.
Alexei Kudryavtsev: Depuis combien de temps utilisez-vous cette pratique?
Pavel Osipov: Nous avons commencé à l'utiliser à l'aube du projet en 2012, car il était nécessaire de le développer rapidement et aucun temps n'était alloué pour les tests à grande échelle. De plus, c'est non seulement impressionnant, mais aussi une expérience positive.
Daniil Popov: Si quelque chose est tombé en panne dans mon application et que je dois démarrer une tâche dans JIRA, que puis-je corriger à l'avenir, comment reproduire cette situation?
Pavel Osipov: Il n'y a pas de recette universelle. L'ingénierie du chaos est activée lorsque l'application est déboguée et désactivée lors de la génération de la version finale, de sorte que de telles situations peuvent être vues dans les journaux de la console de l'environnement de développement, à partir desquels vous pouvez comprendre comment placer la tâche dans JIRA.
Alexei Kudryavtsev: Essayez-vous de créer un comportement reproductible afin que votre système de chaos vous informe des états problématiques et suggère de le saisir dans la configuration au début afin de répéter cet état?
Pavel Osipov: Cela semble cosmique et peut-être dans des architectures comme Redux. Si l'architecture vous permet d'enregistrer toutes les actions qui ont précédé les événements critiques, cela est possible. Ce n'est pas le cas avec nous. Cela a été pratiqué lorsque je travaillais comme programmeur côté serveur dans les télécommunications. Il y a eu des tests qui ont randomisé l'entrée du sous-système et vérifié une sortie adéquate. Nous avons réalisé que lorsque le test avec entrée aléatoire s'est écrasé dans le système, et dans le programme qui était responsable des tests d'automatisation, tous les paramètres nécessaires de la demande d'entrée ont été reportés afin qu'elle puisse être reproduite.
Appliquer le chaos dans l'application
Daniil Popov: Est-il exact qu'un tel chaos est introduit manuellement dans le code?
Pavel Osipov: Oui, notre client réseau a une fonctionnalité intégrée où vous pouvez soumettre une configuration, qui décrit le paramètre de chaos qui doit être reproduit. Sur la base de la configuration, il décide de mandater une requête client au serveur ou de répondre par lui-même un non-sens. La couche pour travailler avec le réseau est telle que vous pouvez personnaliser le chaos introduit par le microservice dans le backend. Il n'est pas logique de modéliser les erreurs de validité des données d'autorisation si les demandes de microservices ne nécessitent pas d'autorisation.
Nous ne nous contentons pas de tout randomiser, de jouer le code parfait, mais de randomiser de manière significative ce que l'utilisateur peut reproduire dans la vie réelle.
Alexei Kudryavtsev: Qu'est-ce que vous randomisez en dehors du réseau et des fichiers?
Pavel Osipov: Nous avons débogué la pratique de randomiser les réponses de points de terminaison spécifiques pour modéliser séparément le comportement et le chaos de chaque microservice. Nous avons terminé le travail de déplacement du système de fichiers vers des sous-systèmes séparés et j'essaie de modéliser différents types d'erreurs lorsqu'une application essaie d'écrire ou de lire un fichier. Accès simulé manuellement au groupe d'applications partagées dans l'application, et je veux vraiment commencer à modéliser le comportement de l'application lorsqu'elle commence avec un espace disque extrêmement petit, dans lequel il est même impossible de créer une base de données.
Alexei Kudryavtsev: C'est tout ce que vous faites?
Pavel Osipov: En principe, oui. Nous n'avons pas encore ratissé tous ces bogues trouvés en utilisant le chaos existant. Bien sûr, il est intéressant d'augmenter le chaos et de le transférer vers d'autres sous-systèmes, mais nous n'aurons alors pas le temps de corriger autant que le chaos le trouvera.
Où est le lieu du chaos? Vous pouvez toujours trouver un endroit où vous pouvez créer une autre turbulence pour l'application. Il est important de tirer parti des problèmes. Nous avons créé le chaos pour l'exploitation forestière car nous avons observé un grand nombre de problèmes similaires.
Si la surveillance montre que dans d'autres sous-systèmes, il n'y a pas de problèmes particuliers, cela n'a aucun sens de passer du temps à modéliser des circonstances imprévues.
Cela ne s'applique pas à la facturation, où le bon fonctionnement est important.
Alexei Kudryavtsev: D'un autre côté, nous ne savons pas ce qui se passe avec les utilisateurs - c'est le chaos en soi, parce que vous ne savez pas où le construire, mais où il ne le fait pas, il vous suffit de le simuler.
Pavel Osipov: Vous devez toujours regarder le retour sur investissement. Bien sûr, vous pouvez reproduire les cas les plus exotiques, mais s'ils sont uniques, alors peut-être qu'ils ne sont pas critiques, et il est inutile de les modéliser.
Les défis de l'introduction du chaos
Alexei Kudryavtsev: Lequel de ce qui a déjà été fait vous a été facile et qu'est-ce qui a causé des difficultés?
Pavel Osipov: S'habituer au chaos est inhabituel pour un débutant, car ce n'est pas une pratique couramment utilisée. Il est difficile de s'adapter au fait que vous avez un tas d'erreurs. Sur presque tous les écrans, vous pouvez obtenir un pack de "cinq cents" ou "404" incompréhensibles, le serveur répond une fois. Ce n'est qu'avec le temps que l'on s'habitue au fait que tout cela est ennuyeux et que les réponses du serveur sont modélisées par le système lui-même.
C'est difficile quand vous avez une fonctionnalité critique qui est déjà en feu et que vous devez la terminer le plus tôt possible, puis le razlogin apparaît soudainement à la place de l'accumulation de demandes. Par exemple, vous devez créer correctement l'écran et vous avez besoin de toutes les demandes pour réussir, et il est si peu probable que vous deviez aller quelques dizaines de fois pour atteindre l'état souhaité. Dans de tels cas, désactiver le chaos devient une contre-mesure, et il est important de ne pas oublier de le rallumer.
Un autre point qui suscite l'insatisfaction est l'utilisation du chaos dans les services d'infrastructure avec un grand nombre d'effets secondaires.
Daniil Popov: Les développeurs ont-ils toujours le chaos activé par défaut?
Pavel Osipov: Absolument. Parfois, lorsque vous ne vous souciez même pas du chaos et des situations exotiques qu'il peut reproduire pour vous, cela agace. Vous devez endurer, mais vous pouvez toujours régler le niveau de chaos si votre écran fonctionne intensément avec le réseau. D'un autre côté, le chaos peut révéler un problème loin de l'endroit où vous le recherchez et non du développeur qui développe cette fonctionnalité. Il arrive que votre fonctionnalité, dans laquelle le chaos est ajouté, entraîne des conséquences qui affectent la fonctionnalité de votre collègue. Vous ne saurez pas si le chaos sera inclus uniquement à un moment particulier du développement.
Le sens du chaos est d'identifier les conséquences imprévues de l'interaction d'un grand nombre de composants.
Si vous incluez le chaos de manière précise et mesurée, ces photos rares mais bien ciblées seront invisibles.
Daniil Popov: le chaos empêche-t
- il la lisibilité du code?
Pavel Osipov: Lorsque le chaos est introduit à l'extérieur du système, il reste fidèle au système fini, alors oui, il semble désordonné. Chez nous, en raison d'une longue expérience d'utilisation, le chaos est organiquement tissé dans le système et tellement isolé que vous ne le remarquez pas dans le code.
Alexei Kudryavtsev: Vous attrapez beaucoup de cas rares, les corrigez et le code est entouré de béquilles. Est-ce que cela complique la logique d'application?
Pavel Osipov: C'est toujours une grande partie de notre code, mais sinon les grandes applications de production ne sont pas écrites. Bien sûr, tout dépend de l'habileté du développeur, qui sait réparer le code afin qu'il ne dérange pas les yeux.
Avantages de l'introduction du chaos
Daniil Popov: Existe-t-il des indicateurs quantitatifs qui se sont améliorés après l'introduction de l'ingénierie du chaos?
Pavel Osipov: Pour moi, la mesure la plus importante est la tranquillité d'esprit intérieure lorsque j'envoie une fonctionnalité à publier.
Alexey Kudryavtsev: La paix ne peut pas être vendue aux entreprises. Comment argumenter l'introduction de l'ingénierie du chaos dans l'entreprise?
Pavel Osipov: l' ingénierie du chaos libère du temps pour les testeurs, car il existe des tests automatiques. Le même crash avec razlogin après l'introduction de la pratique du chaos a presque disparu de notre JIRA.
L'ingénierie du chaos a un effet bénéfique sur le cycle de publication, car vous obtenez un retour rapide. C’est une chose lorsque la fonctionnalité terminée est mise à l’essai, et après un long moment vous êtes informé du nombre de bogues trouvés, c’est complètement différent lorsque vous avez un robot testeur qui fonctionne tout au long du programme de débogage.
J'ai un sentiment de confiance des résultats des tests unitaires est beaucoup plus faible que du chaos activé à 50% lors du téléchargement de milliers de fichiers. Avec une telle charge, toutes les combinaisons les plus incroyables seront définitivement corrigées.
De qui apprendre et par où commencer?
Alexei Kudryavtsev: Quels outils avez-vous utilisés pour cela? A pris des bibliothèques ouvertes ou écrit et publié en open source?
Pavel Osipov: Nous avons publié une
bibliothèque réseau en open source, mais il n'y a pas d'outils spécialisés. Le seul que je connaisse est
Netflix Chaos Monkey , qui "s'exécute" au hasard à travers l'instance AWS et les termine, cherche à voir si tout s'est bien passé si un certain nombre de conteneurs sont éteints.
Je crois que l'écriture de configurations où vous entrez en contact avec des systèmes adjacents ne nécessite pas d'automatisation profonde.Daniil Popov: Où puis-je en savoir plus sur l'ingénierie du chaos?Pavel Osipov: Premièrement, le site Web des principes du chaos , auquel toutes les ressources sur ce sujet renvoient. Deuxièmement, les livres Learning Chaos Engineering et Chaos Engineering Observability .En général, l'ingénierie du chaos est la pratique du bon sens et les connaissances fondamentales ne sont pas là. Vous devez toujours comprendre où instiller le chaos. Dans le même temps, le chaos est-il unique pour chaque application? et vous devez d'abord comprendre ce qui doit être mis en œuvre avec vous.Alexey Kudryavtsev: , - ?
: , . , , . .
: , ? ?
: . . API, . - , , . , UIKit API .
— , .
: ?
: -, unit-, .
-? AppsConf - 21-21 , Key-value .