Chaos Engineering

Das Letzte, was Sie beim Debuggen von Code sehen möchten, ist das Chaos . Aber was ist, wenn dieses Chaos von den Händen des Entwicklers selbst kontrolliert und ausgelöst wird? Lesen Sie PavelOsipov im Gespräch zwischen dem führenden AppsCast-Podcast und Pavel Osipov, warum Sie absichtlich Turbulenzen im reibungslosen Betrieb Ihrer Anwendung arrangieren, wie Sie bei der Veröffentlichung wichtiger Funktionen beruhigt sein können und wo genau die Praxis des Chaos Engineering nützlich ist.



Alexey Kudryavtsev: Hallo allerseits! Heute ist unser Gast Pavel Osipov von Mail.ru Cloud, mit dem wir über Chaos Engineering sprechen werden.

Pavel Osipov: Hallo allerseits! Seit sechs Jahren leite ich die Entwicklung von Mail.ru Cloud. In dieser Zeit haben wir viele Praktiken wirtschaftlicher Tests gesammelt, und eine davon ist Chaos Engineering. Mit dieser Vorgehensweise können Sie eine Reihe kontrollierter Experimente durchführen, um den Zustand Ihres Systems in einer feindlichen Umgebung zu ermitteln. Basierend auf den Ergebnissen dieser Experimente erhalten Sie nützliche Einblicke. Beispielsweise ist es unwahrscheinlich, dass Sie regelmäßig sehen, wie sich das System in einem instabilen Netzwerk verhält. Wenn Ihr Benutzer häufig mit der U-Bahn fährt oder sich in einer Hotel-WLAN-Umgebung ausruht, ist das Netzwerk nicht so stabil wie der Arbeitsplatz eines Programmierers. Nach jedem meiner Ferien auf See bringe ich ein ganzes "Portfolio" von Protokollen darüber mit, was mit der Anwendung schief gelaufen ist.

Persönlich kann ich durch das manuelle Chaos in der Zucht eine zusätzliche Dosis Vertrauen gewinnen, dass alles gut läuft, auch wenn außerhalb der Anwendung alles schlecht ist.

Es gibt Situationen, in denen ich dem manuellen Chaos mehr vertraue als automatischen Tests.

Die Wurzel des Chaos sehen

Alexei Kudryavtsev: Woher stammen die Wurzeln einer solchen Praxis?

Pavel Osipov: Dies ist eine Serverpraxis, bei der es noch viele weitere Probleme gibt. Wir sind an das Konzept der technischen Verschuldung gewöhnt, und im Westen gibt es auch dunkle Schulden - eine versteckte Schuld, die in komplexen Systemen unvermeidlich entsteht. Im Gegensatz zu technischen Schulden, bei denen wir die Zeit der Zukunft bewusst selbst aus der Gegenwart entlehnen, sind versteckte Schulden in der Phase der Schaffung des Systems unsichtbar. Es tritt an der Schnittstelle von Komponenten oder Hardware und Software auf und kann zu einer Kaskade von Problemen führen: Bei einer Komponente bricht etwas zusammen, überlappt eine andere, und jetzt liegt das gesamte System.

Zum Beispiel lag 2016 aufgrund des kaskadierenden Herunterfahrens der Datenbank 2,5 Stunden auf Facebook. Dann begann das System, das die Gültigkeit der Konfigurationsdateien überprüfte, diese versehentlich zu löschen, nicht nur im Caching-Subsystem, sondern auch in der Datenbank, die die primäre Quelle war.

Ich mag das Interview mit Oleg Anastasiev aus Odnoklassniki über die Durchführung von Übungen zur Verhinderung von Infrastrukturunfällen sehr. Sie haben drei Rechenzentren, die rund um die Uhr in Alarmbereitschaft sein sollten, aber einmal im Quartal tritt ein Fehler auf. Sie führen solche Übungen zur Produktion durch. Auf der einen Seite scheint dies beängstigend zu sein, denn wenn etwas Unvorhersehbares passiert, fällt das gesamte Rechenzentrum und ist nicht auf dem Produkt verfügbar. Auf der anderen Seite wird dieser Prozess gesteuert und wenn etwas schief geht, werden Sie es sofort sehen, stoppen und alles wird wiederhergestellt. Wenn dies unter Bedingungen des Kampflebens geschieht, funktioniert das Wiedereinschalten einfach nicht, und die Analyse der Gründe für das Herunterfahren wird sich lange hinziehen.

Die Vorteile des Chaos in der mobilen Entwicklung

Daniil Popov: Bisher sprechen wir über die Serverentwicklung, bei der Microservices beliebt sind und kaskadierende Ausfälle möglich sind. Können Sie weitere Beispiele dafür geben, was Sie durch Chaos Engineering in der mobilen Entwicklung überprüfen können?

Pavel Osipov: Mein Lieblingsbeispiel ist die Anwendungsprotokollierung. Unter Testbedingungen können unsere Aktionen in Bezug auf die Anwendung sehr sanft sein: Wir haben die Kontoeinstellungen aufgerufen, auf die Schaltfläche "Beenden" geklickt, die Anwendung beendet und beim Anzeigen des Anmeldebildschirms scheint alles in Ordnung zu sein. Benutzer haben oft exotischere Situationen. Beispielsweise hat der Client das Kennwort über die Weboberfläche geändert oder es ist eine große Anzahl von Protokollen auf anderen Geräten aufgetreten, und das Aktualisierungstoken wurde ersetzt. Diese Protokollierung erfolgt nicht im Fenster mit dem Benutzerkonto, sondern beispielsweise zum Zeitpunkt des Vollbild-Fotobetrachters.

Wir haben viele Situationen festgestellt, in denen die Anmeldung an verschiedenen Stellen der Anwendung zu Konsequenzen wie Speicherlecks führt. Der gleiche Betrachter mit einem Abschlussblock könnte sich einen wichtigen Dienst schnappen, der schließlich durchgesickert ist.

Wir simulieren Bedingungen mithilfe von Chaos Engineering. Das System verfügt über einen Dienst, der für Anwendungsdienste auf hoher Ebene das Anwendungszugriffstoken mithilfe des Aktualisierungstokens der Anwendung transparent aktualisiert. Wir haben ein Chaos eingeführt, bei dem der Dienst, anstatt das Token mit einer gewissen Wahrscheinlichkeit zu aktualisieren, es verdirbt und jeder Entwickler mehrmals täglich an einem unerwarteten Ort auf ein Protokoll stößt.

Dank dessen haben wir ein interessantes UIKit-Verhalten in iOS entdeckt: Wenn beim Hervorheben eines gerooteten ViewControllers ein anderes Fenster modal blockiert wird, leckt der gerootete ViewController und bleibt für immer im System. Wenn der ViewController gleichzeitig eine Verbindung zu Diensten hatte, die gemäß der Logik der Architektur in einem Fall im System vorhanden sein müssen, können Probleme nicht vermieden werden. In der Cloud gibt es beispielsweise einen Dienst zum automatischen Laden von Fotos. Wenn zwei solcher Dienste im System verbleiben, erledigen sie eine Menge unnötiger Arbeit und legen den Akku des Geräts doppelt so schnell ein, wie er sollte.

Ein weiterer merkwürdiger Fall. Als iOS 8 angezeigt wurde, gab es Probleme mit Erweiterungen: Auf einigen Geräten gab das System zu Beginn an, dass die Anwendung keinen Zugriff auf die freigegebene App-Gruppe hat, als alle Berechtigungen in den Anwendungseinstellungen erteilt wurden.

Typologie des Chaos

Daniil Popov: Chaos wird automatisch aufgrund von Interesse oder einer Konfiguration in das System eingeführt, aber braucht eine Person einen Blick, um zu verstehen, was schief gelaufen ist?

Pavel Osipov: Chaos ist anders: sowohl manuell als auch automatisch. Im Fall des Betriebssystems, das besagte, dass die Anwendung keinen Zugriff auf die gemeinsam genutzte App-Gruppe hatte und Erweiterungen nicht auf gemeinsam genutzte Ressourcen und die Datenbank zugreifen konnten, wurde manuelles Chaos verwendet, das mithilfe eines Häkchens in den Systemeinstellungen der Anwendung aktiviert wurde. Dies könnte leicht von den Jungs aus dem QA-Team modelliert werden.

Es gibt automatisiertes Chaos. Dies sind insbesondere Fehler, die aus den Microservices unseres Backends und dem Chaos bei der Aktualisierung des Tokens modelliert werden. Die Folgen sind unterschiedlich. Das zurückgelegte Layout kann durch visuelle Beobachtung bestimmt werden. Es gibt Stellen, an denen Sie Anomalien im automatischen Modus erkennen können. In unserer Anwendung werden beispielsweise Speicherlecks automatisch erkannt. Es gibt zwei IoC-Container im System. Ein Manager ist die Lebensdauer globaler Dienste, die mit der Lebensdauer der Anwendung selbst übereinstimmt. Ein anderer Container ist der Manager von Diensten, die zeitlich mit dem Benutzer übereinstimmen. Jeder IoC-Container, der einen Dienst erstellt, überprüft, ob er in einer Instanz vorhanden ist.

Kehren wir zum Beispiel mit den Protokollen zurück. Irgendwann kam es plötzlich zu einer Anmeldung, und der Entwickler gab das Konto erneut ein, um weiterarbeiten zu können. Zu diesem Zeitpunkt meldet der IoC-Container, dass ein Speicherverlust aufgetreten ist, und der Dienst, der theoretisch in einem Fall vorhanden sein sollte, wird erneut erkannt.

Wann ist die Zeit des Chaos?

Alexei Kudryavtsev: Was diente als Auslöser für die Umsetzung der Praxis?

Pavel Osipov: Wir sind dazu gekommen, weil wir die Testkosten senken mussten. Wie kann man mit den gleichen Problemen des Razlogins umgehen? Sie können Komponententests für Lecks schreiben, Sie können verwirrt werden und UI-Tests schreiben.

Chaos Engineering ist die billigste Methode, da es nicht an Benutzerfälle gebunden ist, sondern automatisch für alle Benutzerfälle zusammen wirkt.

Der zweite Auslöser - bevor die Praxis eingeführt wurde, wurden in unserem Absturzbericht häufig ähnliche Abstürze mit derselben Grundursache beobachtet. Zum Beispiel, dass der Absturz nicht aufgrund des Systemprotokolls im Profil aufgetreten ist, sondern weil der Benutzer zu diesem Zeitpunkt durch die Fotogalerie gescrollt hat. Die Situationen sind unterschiedlich und es ist unmöglich, alle Kombinationen von Razlogins zu testen. Also wollte ich mir etwas einfallen lassen, das den Prozess automatisiert.

Chaos Engineering hat eine verwandte Praxis - Mutationstests . In dieser Übung ändern wir kleine Codeteile und sehen, wie sich dies auf die Tests auswirkt. Wenn die Tests nach der Änderung korrekt ausgeführt werden, bedeutet dies, dass für diese Codefragmente die Tests nicht ausreichen.

Der Unterschied zwischen Chaos Engineering und Mutationstests besteht darin, dass wir den Produktionscode selbst, sondern seine Umgebung nicht automatisch ändern.

Alexei Kudryavtsev: Könnte es möglich sein, die Ursache zu lokalisieren und zu beheben, ohne Chaos Engineering?

Pavel Osipov: Es gibt keinen einzigen Grund, der zu Abstürzen führt. Jeder Fall ist auf seine Weise einzigartig. Zum Beispiel erschien die modale Schaltfläche oben im Fenster, und dies führte dazu, dass der ruinöse ViewController während des Razlogs auslief. Es ist nicht möglich, alle Kombinationen von Fensterhierarchien vorherzusehen, die Sie während der Protokollierung haben. Chaos Engineering lokalisierte Muster, in denen Lecks und Abstürze auftreten.

Alexei Kudryavtsev: Wie lange verwenden Sie diese Praxis schon?

Pavel Osipov: Wir haben zu Beginn des Projekts im Jahr 2012 damit begonnen, weil es schnell entwickelt werden musste und keine Zeit für umfangreiche Tests zur Verfügung stand. Darüber hinaus ist dies nicht nur beeindruckend, sondern auch eine positive Erfahrung.

Daniil Popov: Wenn etwas in meiner Anwendung abgestürzt ist und ich eine Aufgabe in JIRA starten muss, was kann ich in Zukunft beheben, wie kann ich diese Situation reproduzieren?

Pavel Osipov: Es gibt kein universelles Rezept. Chaos Engineering wird zum Zeitpunkt des Debuggens von Anwendungen aktiviert und zum Zeitpunkt der Erstellung der Release-Version deaktiviert. Daher können solche Situationen in den Protokollen in der Entwicklungsumgebungskonsole angezeigt werden, anhand derer Sie herausfinden können, wie die Aufgabe in JIRA gestellt wird.

Alexei Kudryavtsev: Versuchen Sie, reproduzierbares Verhalten zu erzeugen, damit Ihr Chaos-System Sie über Problemzustände informiert und vorschlägt, es zu Beginn in die Konfiguration einzugeben, um diesen Zustand zu wiederholen?

Pavel Osipov: Klingt kosmisch und möglicherweise in Architekturen wie Redux. Wenn Sie mit der Architektur alle Aktionen aufzeichnen können, die kritischen Ereignissen vorausgingen, ist dies möglich. Das ist bei uns nicht so. Dies wurde praktiziert, als ich als Serveride-Programmierer in der Telekommunikation arbeitete. Es gab Tests, bei denen der Zugang zum Subsystem randomisiert und auf eine angemessene Ausgabe überprüft wurde. Wir haben festgestellt, dass beim Absturz des Tests mit zufälliger Eingabe das System und in dem Programm, das für die Testautomatisierung verantwortlich war, alle erforderlichen Parameter der Eingabeanforderung verschoben wurden, damit sie reproduziert werden konnten.

Wenden Sie Chaos in der Anwendung an

Daniil Popov: Ist es richtig, dass ein solches Chaos von Hand in den Code eingeführt wird?

Pavel Osipov: Ja, unser Netzwerkclient verfügt über eine integrierte Funktionalität, mit der Sie eine Konfiguration senden können, die den Chaos-Parameter beschreibt, der reproduziert werden soll. Basierend auf der Konfiguration beschließt er, eine Client-Anfrage an den Server zu senden oder Unsinn selbst zu beantworten. Die Ebene für die Arbeit mit dem Netzwerk ist so, dass Sie das Chaos anpassen können, das durch den Microservice im Backend verursacht wird. Es ist nicht sinnvoll, Fehler in der Gültigkeit von Autorisierungsdaten zu modellieren, wenn für Microservice-Anforderungen keine Autorisierung erforderlich ist.

Wir randomisieren nicht nur alles, spielen den perfekten Code ab, sondern randomisieren sinnvoll, was der Benutzer im wirklichen Leben reproduzieren kann.

Alexei Kudryavtsev: Was randomisieren Sie außer dem Netzwerk und den Dateien?

Pavel Osipov: Wir haben die Praxis der Randomisierung von Antworten von bestimmten Endpunkten getestet, um das Verhalten und das Chaos jedes Mikrodienstes separat zu modellieren. Wir haben die Arbeit zum Verschieben des Dateisystems in separate Subsysteme abgeschlossen, und ich versuche, verschiedene Arten von Fehlern zu modellieren, wenn eine Anwendung versucht, eine Datei zu schreiben oder zu lesen. Manuell simulierter Zugriff auf die gemeinsam genutzte App-Gruppe in der Anwendung, und ich möchte wirklich damit beginnen, das Verhalten der Anwendung zu modellieren, wenn sie mit extrem kleinem Speicherplatz beginnt, in dem es nicht einmal möglich ist, eine Datenbank zu erstellen.

Alexei Kudryavtsev: Ist das alles was Sie tun?

Pavel Osipov: Im Prinzip ja. Wir haben noch nicht alle Fehler geharkt, die mit dem vorhandenen Chaos gefunden wurden. Natürlich ist es interessant, das Chaos zu erhöhen und auf andere Subsysteme zu übertragen, aber dann werden wir nicht die Zeit haben, so viel zu reparieren, wie das Chaos finden wird.

Wo ist der Ort des Chaos? Sie können immer einen Ort finden, an dem Sie weitere Turbulenzen für die Anwendung erzeugen können. Es ist wichtig, auf Problemen aufzubauen. Wir haben Chaos für die Protokollierung gemacht, weil wir eine große Anzahl ähnlicher Probleme beobachtet haben.

Wenn die Überwachung zeigt, dass in anderen Subsystemen keine besonderen Probleme auftreten, ist es nicht sinnvoll, Zeit mit der Modellierung unvorhergesehener Umstände zu verbringen.

Dies gilt nicht für die Abrechnung, bei der ein korrekter Betrieb wichtig ist.

Alexei Kudryavtsev: Andererseits wissen wir nicht, was mit den Benutzern los ist - das ist an sich schon Chaos, weil Sie nicht wissen, wo Sie es ablegen sollen oder nicht, und Sie müssen es nur simulieren.

Pavel Osipov: Sie müssen immer den ROI betrachten. Natürlich können Sie die exotischsten Fälle reproduzieren, aber wenn sie einzeln sind, sind sie möglicherweise nicht kritisch, und es macht keinen Sinn, sie zu modellieren.

Herausforderungen bei der Einführung von Chaos

Alexei Kudryavtsev: Was von dem, was bereits getan wurde, war für Sie einfach und was hat Schwierigkeiten verursacht?

Pavel Osipov: Für Anfänger ist es ungewöhnlich, sich an das Chaos zu gewöhnen, da dies keine übliche Praxis ist. Es ist schwer, sich an die Tatsache anzupassen, dass Sie eine Reihe von Fehlern haben. Auf fast jedem Bildschirm können Sie eine Packung mit "fünfhundert" oder unverständlichen "404" erhalten, der Server antwortet einmal. Erst mit der Zeit gewöhnt man sich daran, dass dies alles langweilig ist und die Antworten vom Server vom System selbst modelliert werden.

Es ist schwierig, wenn Sie eine kritische Funktion haben, die bereits in Flammen steht, und Sie müssen sie so schnell wie möglich beenden. Dann wird das Razlogin plötzlich anstelle der Ansammlung von Anfragen angezeigt. Zum Beispiel müssen Sie den Bildschirm korrekt zusammenstellen und alle Anforderungen müssen erfolgreich ausgeführt werden. Dies ist so unwahrscheinlich, dass Sie einige Dutzend Mal gehen müssen, um den gewünschten Status zu erreichen. In solchen Fällen wird das Deaktivieren des Chaos zu einer Gegenmaßnahme, und es ist wichtig, nicht zu vergessen, es wieder einzuschalten.

Ein weiterer Punkt, der Unzufriedenheit verursacht, ist die Nutzung des Chaos in Infrastrukturdiensten mit einer Vielzahl von Nebenwirkungen.

Daniil Popov: Haben Entwickler das Chaos immer standardmäßig aktiviert?

Pavel Osipov: Auf jeden Fall. Manchmal, wenn Sie sich nicht einmal für das Chaos und die exotischen Situationen interessieren, die er für Sie reproduzieren kann, nervt es Sie. Sie müssen es aushalten, aber Sie können das Chaos immer anpassen, wenn Ihr Bildschirm intensiv mit dem Netzwerk arbeitet. Auf der anderen Seite kann das Chaos ein Problem aufdecken, das weit entfernt von dem Ort liegt, an dem Sie es suchen, und nicht von dem Entwickler, der diese Funktion entwickelt. Es kommt vor, dass Ihre Funktion, in der Chaos hinzugefügt wird, zu Konsequenzen führt, die sich auf die Funktion Ihres Kollegen auswirken. Sie wissen nicht, ob das Chaos nur zu einem bestimmten Zeitpunkt der Entwicklung berücksichtigt wird.

Die Bedeutung von Chaos besteht darin, unvorhergesehene Konsequenzen für das Zusammenspiel einer großen Anzahl von Komponenten zu identifizieren.

Wenn Sie das Chaos gemessen und präzise einbeziehen, sind diese seltenen, aber zielgerichteten Schüsse unsichtbar.

Daniil Popov: Verhindert Chaos die Lesbarkeit von Code?

Pavel Osipov: Wenn Chaos außerhalb des Systems eingeführt wird, bleibt es beim fertigen, dann sieht es chaotisch aus. Bei uns ist das Chaos aufgrund langjähriger Nutzungserfahrung organisch in das System eingebunden und so isoliert, dass Sie es im Code nicht bemerken.

Alexei Kudryavtsev: Sie fangen viele seltene Fälle auf, beheben sie und der Code ist von Krücken umgeben. Erschwert dies die Anwendungslogik?

Pavel Osipov: Dies ist immer ein großer Teil unseres Codes, aber ansonsten werden keine großen Produktionsanwendungen geschrieben. Natürlich hängt alles von den Fähigkeiten des Entwicklers ab, der weiß, wie man den Code repariert, damit er die Augen nicht belästigt.

Vorteile der Einführung von Chaos

Daniil Popov: Gibt es quantitative Indikatoren, die sich nach Einführung der Chaos-Technik verbessert haben?

Pavel Osipov: Für mich ist die wichtigste Messgröße die innere Sicherheit, wenn ich ein Feature zur Veröffentlichung sende.

Alexey Kudryavtsev: Frieden kann nicht an Unternehmen verkauft werden. Wie kann man die Einführung von Chaos Engineering im Unternehmen argumentieren?

Pavel Osipov: Chaos Engineering spart Zeit für Tester, da es automatische Tests gibt. Der gleiche Absturz mit Razlogin nach der Einführung der Praxis des Chaos verschwand fast aus unserer JIRA.

Chaos Engineering wirkt sich positiv auf den Release-Zyklus aus, da Sie schnelles Feedback erhalten. Es ist eine Sache, wenn die fertige Funktion getestet wird und Sie nach langer Zeit über die Anzahl der gefundenen Fehler informiert sind. Wenn Sie einen Robotertester haben, der während des gesamten Debug-Programms funktioniert, ist dies völlig anders.

Ich habe das Gefühl, dass die Ergebnisse von Unit-Tests viel geringer sind als das Chaos, das beim Herunterladen von Tausenden von Dateien um 50% ausgelöst wurde. Mit einer solchen Last werden definitiv die unglaublichsten Kombinationen behoben.

Von wem kann man lernen und wo soll ich anfangen?

Alexei Kudryavtsev: Welche Tools haben Sie dafür verwendet? Offene Bibliotheken genommen oder in Open Source geschrieben und gepostet?

Pavel Osipov: Wir haben eine Netzwerkbibliothek in Open Source veröffentlicht, aber es gibt keine speziellen Tools. Der einzige, den ich kenne, ist Netflix Chaos Monkey , der zufällig die AWS-Instanz „durchläuft“ und sie beendet. Er prüft, ob alles gut gelaufen ist, wenn eine bestimmte Anzahl von Containern gelöscht wurde. Ich glaube, dass das Schreiben von Konfigurationen, bei denen Sie mit benachbarten Systemen in Kontakt kommen, keine umfassende Automatisierung erfordert.

Daniil Popov: Wo kann ich mehr über Chaos Engineering lesen?

Pavel Osipov: Erstens die Website Principles of Chaos , auf die alle Ressourcen zu diesem Thema verweisen. Zweitens die Bücher Learning Chaos Engineering und Chaos Engineering Observability .

Im Allgemeinen ist Chaos Engineering die Praxis des gesunden Menschenverstandes und grundlegendes Wissen ist nicht vorhanden. Sie müssen immer verstehen, wo Sie Chaos auslösen können. Ist das Chaos gleichzeitig für jede Anwendung einzigartig? und Sie müssen zuerst verstehen, was mit Ihnen implementiert werden muss.

Alexei Kudryavtsev: Wo soll ich anfangen, wenn Sie sich immer noch dazu entschließen, Chaos einzuführen?

Pavel Osipov: Analysieren Sie zunächst die Probleme im System, die abstürzen und warum sie auftreten. Nachdem Sie die Wurzel des Bösen identifiziert haben, müssen Sie verstehen, wie Sie Situationen modellieren, die zu Problemen führen. Und der dritte Schritt besteht darin, das Chaos sorgfältig einzuführen und unter Kontrolle zu halten.

Alexei Kudryavtsev: Viele Dinge können in der Anwendung schaden, aber wie kann man Prioritäten setzen? Wo kann man sich besser nicht einmischen?

Pavel Osipov: Es gibt keine unwirklichen Dinge. Das Verhältnis von Preis und Auspuff ist wichtig. Wenn es eine umfangreiche System-API gibt, ist das Umschließen mit Ihren eigenen Wrappern teuer. Wenn Sie etwas nicht vollständig verstehen, werden Sie Chaos provozieren, das in der Natur unmöglich ist und zu einem vergeblichen Kampf führt. Zum Beispiel, wenn die gesamte UIKit- oder Shopping-API von Chaos bedeckt ist.

Chaos ist kein zufälliger Anstoß, sondern ein klares Verständnis für simulierte Situationen.

Alexei Kudryavtsev: Inwieweit empfehlen Sie die Implementierung dieser Praxis?

Pavel Osipov: Ich empfehle generell, mit der Einführung der Chaos-Technik zu beginnen, anstatt mit Unit-Tests, da dies die billigste Praxis ist.

Interessiert an Chaos Engineering? Erleben Sie Pavel Osipov auf der Herbst- AppsConf vom 21. bis 21. Oktober in St. Petersburg, wo er seinen neuen Bericht über Schlüsselwertdatenbanken vorstellt.