Verteilte Softwaresysteme bringen ein sehr komplexes Verhalten unter echten Einsatzbedingungen mit sich, meist resultiert dies auch in sehr komplexen Fehlerzuständen, die durch den Betrieb unter widrigen Netzwerkbedingungen wie beispielsweise hohen Latenzen und zunehmenden Paketverlusten entstehen. Diese Fehlerzustände können mit herkömmlichen Softwaretestverfahren wie Unit- und Integrationstests nicht mehr hinreichend provoziert, getestet und verifiziert werden. Mit der Methode des Chaos-Engineerings werden komplexe Chaos-Szenarien entworfen, die es ermöglichen dieses unbekannte Verhalten der Software in Grenzfällen strukturiert zu entdecken. Am Beispiel einer verteilten Software, die bereits seit über 10 Jahren am Deutschen Zentrum für Luft- und Raumfahrt (DLR) entwickelt wird, werden Chaos-Engineering-Methoden angewandt und sowohl konzeptuell in existierende Softwaretestverfahren eingeordnet als auch praktisch in einer Experimental-Cloud-Umgebung erprobt. Innerhalb eines Experteninterviews mit den RCE-Entwicklern wird ein Chaos-Szenario entworfen, in der die Robustheit der Software mit Chaos-Experimenten auf die Probe gestellt wird. Aufbauend auf einem Softwareprojekt zur automatischen Erstellung von RCE-Testnetzwerken, wird eine Softwarelösung entwickelt, die eine automatische Ausführung von Chaos-Szenarien innerhalb der Experimental-Cloud-Umgebung ermöglicht. Anschließend wird das aus den Experteninterviews resultierende Chaos-Szenario in der Praxis durchgeführt. Abschließend werden die Erkenntnisse aus der Ausführung des Chaos- Szenarios vorgestellt und weiterführende Fragestellungen und Arbeiten aufgezeigt:1 Einleitung 2 Grundlagen 2.1 Softwareentwicklung und Testverfahren 2.2 Verteilte Software 2.3 Containerorchestrierung 2.4 Chaos Engineering 3 Betrachtetes System 3.1 Remote Component Environment 3.2 Testing von RCE Releases 3.3 Methode Experteninterview 3.4 Fragestellungen entwerfen 3.5 Resultate aus Interview 3.6 Integration von Chaos-Engineering 4 Konzepte des Chaos-Engineering am Beispiel 4.1 Ausgangssituation 4.1.1 Systemumgebung 4.1.2 Automatisierte Erstellung von Testnetzwerken 4.1.3 Microservices 4.1.4 Systemarchitektur 4.1.5 Netzwerkbeschreibung 4.2 Anforderungen an die zu entwickelnde Software 4.3 Erweiterung des vorhandenen Gesamtsystems 4.3.1 Chaos Mesh 4.4 Chaos-Operator Microservice 4.4.1 Erweiterung der Systemarchitektur 4.4.2 Erweiterung der Schnittstellen 4.4.3 Beschreibung eines Chaos-Experiments 4.4.4 Probes 4.4.5 Ablaufsteuerung 5 Evaluierung und Diskussion 5.1 Geplantes Chaos-Szenario 5.1.1 JSON Beschreibung eines Chaos-Szenarios 5.2 Durchführung des entworfenen Chaos-Szenarios 5.2.1 Ausführung mit Chaos-Sequencer 5.2.2 Validierung 5.3 Resultate 6 Fazit Literaturverzeichnis Abbildungsverzeichnis Listings

Software complexity continues to accelerate, as new tools, frameworks, and technologiesbecome available. This, in turn, increases its fragility and liability. Despite the amount ofinvestment to test and harden their systems, companies still pay the price of failure. Towithstand this fast-paced development environment and ensure software availability, largescalesystems must be built with resilience in mind. Chaos Engineering is a new practicethat aims to assess some of these challenges. In this thesis, the methodology, requirements,and iterations of the system design and architecture for a chaos engineering tool arepresented. In a matter of only a couple of months and the working hours of two engineers, itwas possible to build a tool that is able to shed light on the attributes that make the targetedsystem resilient as well as the weaknesses in its failure handling mechanisms. This toolgreatly reduces the otherwise manual testing labor and allows software engineering teamsto find potentially costly failures. These results prove the benefits that many companiescould experience in their return of investment by adopting the practice of ChaosEngineering.

IoT (Internet of Things) systems implement event-driven architectures that are deployed on an ever-increasing scale as more and more devices (things) become connected to the internet. Consequently, IoT cloud platforms are becoming increasingly distributed and complex as they adapt to handle larger amounts of user requests and device data. The complexity of such systems makes it close to impossible to predict how they will handle failures that inevitably occur once they are put into production. Chaos engineering, the practice of deliberately injecting faults in production, has successfully been used by many software companies as a means to build confidence in that their complex systems are reliable for the end-users. Nevertheless, its applications in the scope of IoT systems remain largely unexplored in research. Modern IoT cloud platforms are built cloud native with containerized microservices, container orchestration, and other cloud native technologies, much like any other distributed cloud computing system. We therefore investigate cloud native chaos engineering technology and its applications in IoT cloud platforms. We also introduce a framework for getting started with using cloud native chaos engineering to verify and improve the resilience of IoT systems and evaluate it through a case study at a commercial home appliance manufacturer. The evaluation successfully reveals unknown system behavior and results in the discovery of potential resilience improvements for the case study IoT system. The evaluation also shows three ways to measure the resilience of IoT cloud platforms with respect to perturbations, these are: (1) success rate of user requests, (2) system health, and (3) event traffic. / IoT(Sakernas Internet)-system implementerar händelsedrivna arkitekturer som driftsätts i allt större skala i och med att allt fler enheter (saker) blir anslutna till internet. IoT-molnplattformar blir därmed alltmer distribuerade och komplexa i takt med att de anpassas till att hantera större mängder användarförfrågningar och enhetsdata. Komplexiteten hos sådana system gör det nära omöjligt att förutsäga hur de hanterar problem som oundvikligen inträffar när de väl körs i produktionsmiljö. Kaosteknik, att avsiktligt injicera fel medans ett system körs i produktionsmiljön, har framgångsrikt använts av många mjukvaruföretag som ett sätt att bygga förtroende för att deras komplexa system är tillförlitliga för slutanvändarna. Trots det är dess tillämpningar inom ramen för IoT-system i stort sett outforskade inom dataforskning. Moderna IoT-molnplattformar byggs molnäkta med containeriserade mikrotjänster, containerorkestering, och andra molnäkta teknologier, precis som andra distribuerade molntjänstsystem. Vi undersöker därför molnäkta kaosteknik och dess tillämpningar i IoT-molnplattformar. Vi introducerar även ett ramverk för att komma igång med att använda molnäkta kaosteknik för att verifiera och förbättra motståndskraften hos IoT-system och utvärderar det genom en fallstudie hos en kommersiell tillverkare av hushållsapparater. Utvärderingen lyckas avslöja okänt systembeteende och resulterar i upptäckten av potentiella motståndskraftsförbättringar för IoT-systemet i fallstudien. Utvärderingen visar också tre sätt att mäta motståndskraften hos IoT-molnplattformar med hänsyn till störningar, dessa är: (1) andel framgångsrika användarförfrågningar, (2) systemhälsa och (3) händelsetrafik.

Chaos Engineering (CE) intentionally disrupts distributed systems by introducing faults into the system to better understand and improve their resilience. By studying these intentional disruptions, CE provides insights that help enhance system performance and the overall user experience. However, two main challenges exist: reducing the negative impact or ”blast radius” of these CE experiments without diluting the value of the CE experiment and identifying a standardized set of metrics to monitor during such CE experiments. This research addresses these challenges by monitoring application and system-level metrics known as the Golden Signals, and a steady-state metric called the Apdex score during a CE experiment. Using Pearson and Spearman correlation analyses alongside Granger Causality tests, a strong connection between the Golden Signals and Apdex score is identified. The study also introduces a new health-check system design that uses the Apdex score to automatically stop a CE experiment if a preset threshold is violated. Furthermore, the design also introduces a method for early termination of the CE experiment based on forecasted Apdex scores. This method not only limits potential system damage but also reveals key system weaknesses, striking a balance between risk and discovery. / Chaos Engineering (CE) stör medvetet distribuerade system genom att införa fel i systemet för att bättre förstå och förbättra deras motståndskraft. Genom att studera dessa medvetna störningar ger CE insikter som hjälper till att förbättra systemprestanda och den övergripande användarupplevelsen. Två huvudutmaningar finns dock: att minska den negativa effekten eller ”blast radius” av dessa CE-experiment utan att försämra värdet av CE-experimentet och att identifiera en standardiserad uppsättning av mätvärden att övervaka under sådana CE-experiment. Denna forskning tar itu med dessa utmaningar genom att övervaka applikations- och systemnivåmätvärden kända som Golden Signals, och en jämviktsmetrik kallad Apdex-poängen under ett CE-experiment. Genom att använda Pearson och Spearmans korrelationsanalyser tillsammans med Granger orsakssambandstester identifieras en stark koppling mellan Golden Signals och Apdex-poängen. Studien introducerar också en ny hälsocheck-systemdesign som använder Apdex-poängen för att automatiskt stoppa ett CE-experiment om ett förinställt tröskelvärde överskrids. Vidare introducerar designen också en metod för tidig avslutning av CE-experiment baserat på förutsagda Apdex-poäng.. Denna metod begränsar inte bara potentiell systemskada utan avslöjar också nyckelsystemsvagheter och skapar en balans mellan risk och upptäckt.