PRINCIPLES OF CHAOS ENGINEERING

Last Update: 2018 May

Chaos Engineering is the discipline of experimenting on a system
in order to build confidence in the system’s capability
to withstand turbulent conditions in production.

Advances in large-scale, distributed software systems are changing the game for software engineering.  As an industry, we are quick to adopt practices that increase flexibility of development and velocity of deployment.  An urgent question follows on the heels of these benefits: How much confidence we can have in the complex systems that we put into production?

Even when all of the individual services in a distributed system are functioning properly, the interactions between those services can cause unpredictable outcomes.  Unpredictable outcomes, compounded by rare but disruptive real-world events that affect production environments, make these distributed systems inherently chaotic.

We need to identify weaknesses before they manifest in system-wide, aberrant behaviors.  Systemic weaknesses could take the form of: improper fallback settings when a service is unavailable; retry storms from improperly tuned timeouts; outages when a downstream dependency receives too much traffic; cascading failures when a single point of failure crashes; etc.  We must address the most significant weaknesses proactively, before they affect our customers in production.  We need a way to manage the chaos inherent in these systems, take advantage of increasing flexibility and velocity, and have confidence in our production deployments despite the complexity that they represent.

An empirical, systems-based approach addresses the chaos in distributed systems at scale and builds confidence in the ability of those systems to withstand realistic conditions.  We learn about the behavior of a distributed system by observing it during a controlled experiment.  We call this Chaos Engineering.

CHAOS IN PRACTICE

To specifically address the uncertainty of distributed systems at scale, Chaos Engineering can be thought of as the facilitation of experiments to uncover systemic weaknesses.  These experiments follow four steps:

  1. Start by defining ‘steady state’ as some measurable output of a system that indicates normal behavior.
  2. Hypothesize that this steady state will continue in both the control group and the experimental group.
  3. Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc.
  4. Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group.

The harder it is to disrupt the steady state, the more confidence we have in the behavior of the system.  If a weakness is uncovered, we now have a target for improvement before that behavior manifests in the system at large.

ADVANCED PRINCIPLES

The following principles describe an ideal application of Chaos Engineering, applied to the processes of experimentation described above.  The degree to which these principles are pursued strongly correlates to the confidence we can have in a distributed system at scale.

Build a Hypothesis around Steady State Behavior

Focus on the measurable output of a system, rather than internal attributes of the system.  Measurements of that output over a short period of time constitute a proxy for the system’s steady state.  The overall system’s throughput, error rates, latency percentiles, etc. could all be metrics of interest representing steady state behavior.  By focusing on systemic behavior patterns during experiments, Chaos verifies that the system does work, rather than trying to validate how it works.

Vary Real-world Events

Chaos variables reflect real-world events.  Prioritize events either by potential impact or estimated frequency.  Consider events that correspond to hardware failures like servers dying, software failures like malformed responses, and non-failure events like a spike in traffic or a scaling event.  Any event capable of disrupting steady state is a potential variable in a Chaos experiment.

Run Experiments in Production

Systems behave differently depending on environment and traffic patterns.  Since the behavior of utilization can change at any time, sampling real traffic is the only way to reliably capture the request path.  To guarantee both authenticity of the way in which the system is exercised and relevance to the current deployed system, Chaos strongly prefers to experiment directly on production traffic.

Automate Experiments to Run Continuously

Running experiments manually is labor-intensive and ultimately unsustainable.  Automate experiments and run them continuously.  Chaos Engineering builds automation into the system to drive both orchestration and analysis.

Minimize Blast Radius

Experimenting in production has the potential to cause unnecessary customer pain. While there must be an allowance for some short-term negative impact, it is the responsibility and obligation of the Chaos Engineer to ensure the fallout from experiments are minimized and contained.

Chaos Engineering is a powerful practice that is already changing how software is designed and engineered at some of the largest-scale operations in the world.  Where other practices address velocity and flexibility, Chaos specifically tackles systemic uncertainty in these distributed systems.  The Principles of Chaos provide confidence to innovate quickly at massive scales and give customers the high quality experiences they deserve.

Join the ongoing discussion of the Principles of Chaos and their application in the Chaos Community Google Group.

Translations: FR | IT | DE | RU | 中文 (简体) | 한국어 | Spanish | TR | PT-BR | العَرَبِيَّة‎ | 日本語 | UA‎ | CZ‎ | PL | HU | HIN‎
If you want to add your translation, please submit a pull request against the Github repository.

ZASADY INŻYNIERII CHAOSU

Ostatnia modyfikacja: Sierpień 2019

Inżynieria Chaosu to zestaw praktyk, które polegają na wykonywaniu kontrolowanych eksperymentów na systemie w celu zidentyfikowania, analizy i usunięcia jego słabych punktów, tak aby później mógł on utrzymać pełną stabilność na produkcji pomimo pojawiających się problemów.

Postęp w budowaniu rozproszonych systemów dużej skali zmienia zasady, którymi rządzą się procesy wytwarzania oprogramowania. Jako branża, musimy stosować kolejne ulepszenia, które pozwolą nam na większą elastyczność i szybsze wdrożenia oprogramowania na produkcję. Ciągła pogoń za szybkością wprowadzania zmian do naszego systemu pozostawia nas z pytaniem: jak dużą mamy pewność, że nasze złożone systemy będą spisywały się bez zastrzeżeń w dłuższej perspektywie?

Nawet jeżeli wszystkie usługi, które wchodzą w skład naszego rozproszonego systemu, działają poprawnie w izolacji, interakcje pomiędzy nimi mogą doprowadzić do nieprzewidywalnych skutków. Te z kolei, połączone z rzadkimi, ale zakłócającymi pracę zdarzeniami losowymi, powodują, że nasze systemy zachowują się z natury chaotycznie.

Naszym zadaniem jest identyfikacja tych słabych punktów, zanim one spowodują nieprawidłowości w działaniu całego systemu. Przykładem takich słabych punktów systemu są: nieprawidłowe zachowanie w przypadku awarii zewnętrznej usługi, grad ponowień spowodowany nieprawidłowym ustawieniem czasów oczekiwania na odpowiedź, awarie spowodowane niedostępnością zależnej usługi, która jest przeciążona, kaskadowe awarie spowodowane niedostępnością krytycznej i jedynej zależności itp. Wszystkie słabe punkty, muszą zostać zidentyfikowane oraz proaktywnie naprawione, zanim wpłyną na klientów końcowych i działanie systemów produkcyjnych. Potrzebujemy mechanizmów, które pozwolą ujarzmić istniejący w nich naturalny chaos, tak aby uzyskać większą elastyczność i szybkość wdrożeń, oraz upewnić się, że systemy, które zbudowaliśmy, będą zachowywały się stabilnie, pomimo ich stopnia złożoności.

Jedynie empiryczne podejście, skupione na analizie systemowej, pozwala okiełznać problem istniejącego chaosu w rozproszonych systemach dużej skali i zyskać pewność, że ich architektura pozwala na przetrwanie w rzeczywistych warunkach. Sprawdzamy to za pomocą obserwacji zachowania analizowanego systemu podczas kontrolowanego eksperymentu. A taką praktykę nazywamy Inżynierią Chaosu.

INŻYNIERIA CHAOSU W PRAKTYCE

Inżynieria Chaosu wprowadza reguły, w jaki sposób przeprowadzać kontrolowane eksperymenty, aby wykrywać słabości systemu. Oto cztery kroki, według których eksperymenty te powinny przebiegać:

  1. Rozpocznij od zdefiniowania ‘stanu bazowego’, udokumentowanego za pomocą pomiarów i wyników działania wskazującego na normalne zachowanie badanego systemu.
  2. Postaw hipotezę, że stan bazowy zostanie utrzymany na czas eksperymentu dla grupy badanej oraz grupy kontrolnej.
  3. Wprowadź zmienne, które odzwierciedlają rzeczywiste zdarzenia np. awaria serwera, uszkodzenia dysków twardych, spowolnione lub zerwane połączenia sieciowe itp.
  4. Spróbuj obalić hipotezę, porównując różnice pomiędzy stanem bazowym grupy badanej oraz grupy kontrolnej.

Im trudniej jest zakłócić stan bazowy, tym większa pewność, że system będzie zachowywał się poprawnie w przypadku problemów. Jeśli za pomocą eksperymentu, udało się odkryć słabość, mamy w tym momencie scenariusz pozwalający na odtworzenie niepożądanego zachowania, w celu jego usunięcia, zanim doprowadzi on do awarii.

ZAAWANSOWANE ZASADY

Zasady przedstawione poniżej pomogą Ci zaaplikować Inżynierię Chaosu do procesu opisanego w powyższych krokach. To, jaki nacisk położysz na podążanie za zasadami, bezpośrednio przekłada się na pewność, z jaką będziesz rozwijać i utrzymywać swój system.

Stawiaj hipotezy dotyczące stanu bazowego

Skupiaj się bardziej na tym, co widać na wyjściu analizowanego systemu niż na jego wewnętrznych lub zaprojektowanych cechach. Pomiary metryk wyjściowych w krótkich odstępach czasu będą stanowić odzwierciedlenie stanu bazowego. Przykładami takich metryk mogą być: przepustowość systemu, liczba błędów, histogramy czasu opóźnień itp. Dzięki temu podczas eksperymentów możemy skupić się na analizie systemowych słabości w czasie rzeczywistym oraz weryfikujemy działanie systemu, zamiast analizować, jak teoretycznie nasz system powinien działać.

Przygotuj rzeczywiste scenariusze awarii

Niepożądane działanie naszych systemów spowodowane jest wydarzeniami ze świata rzeczywistego. Podczas eksperymentów, należy skupić się w pierwszej kolejności na tych zdarzeniach, które mają największy wpływ na działanie systemu lub występują najczęściej. Bierz pod uwagę zdarzenia, które odzwierciedlają awarie sprzętowe (np. awaria serwera), awarie oprogramowania (np. nieprawidłowe lub nieoczekiwane odpowiedzi) oraz akceptowalne wydarzenia związane z ruchem (np. nieoczekiwany skok w liczbie zapytań) lub skalowaniem infrastruktury. Każde zdarzenie, które może zakłócić stabilność stanu bazowego, jest potencjalną zmienną podczas eksperymentów Inżynierii Chaosu.

Wykonuj eksperymenty na systemach produkcyjnych

Systemy zachowują się inaczej w zależności od środowiska oraz wzorców ruchu. Skoro zachowanie związane z jego eksploatacją może zmienić się w każdym momencie, próbkowanie rzeczywistego ruchu jest jedynym sposobem, aby odtworzyć produkcyjne zachowanie systemu dla analizowanej ścieżki. W celu zagwarantowania autentyczności zachowania systemu oraz prawidłowego punktu odniesienia do rzeczywistego zachowania, zasady Inżynierii Chaosu sugerują, aby eksperymenty wykonywać bezpośrednio na systemie produkcyjnym.

Zautomatyzuj wykonywanie eksperymentów

Przeprowadzanie eksperymentów metodami manualnymi jest czasochłonne oraz nieefektywne. Podłącz zautomatyzowane uruchamianie eksperymentów do swojego procesu ciągłej integracji/ciągłych wdrożeń (CI/CD). Dzięki temu praktyki Inżynierii Chaosu pomogą w dążeniu do tego, aby budować prawidłową automatyzację naszego systemu, która pomaga w orkiestracji wydarzeń oraz analizie i obserwacji.

Minimalizuj strefę wpływu eksperymentu

Eksperymenty na systemie produkcyjnym mogą generować niepotrzebne problemy dla użytkowników końcowych. Oczywiście, przeprowadzenie takich eksperymentów musi być poprzedzone zgodą na pewne negatywne skutki uboczne, ale zadaniem i obowiązkiem Inżynierów Chaosu jest upewnienie się, że potencjalne konsekwencje kontrolowanej awarii będą jak najmniejsze.

Inżynieria Chaosu to zestaw potężnych praktyk, które zmieniły sposób, w jakim projektuje oraz implementuje się oprogramowanie w wielu firmach na całym świecie, także tych największych. Tam, gdzie inne praktyki skupiają się wyłącznie na szybkości wytwarzania i elastyczności, omawiane reguły skupiają się przede wszystkim na usuwaniu niepewności pojawiających się w systemach rozproszonych. Jako skutek uboczny ich stosowania, oprócz zaufania, uzyskujemy przewidywalność, i możliwość szybszego rozwoju. Dzięki temu jesteśmy w stanie dostarczyć klientom końcowym produkt i doświadczenia wysokiej jakości, na które zasługują.

Dołącz do oficjalnej grupy dyskusyjnej Chaos Community na Google Group, aby porozmawiać o zasadach inżynierii chaosu.

Tłumaczenia: EN | FR | IT | DE | RU | 中文(简体) | 한국어 | Spanish | TR | PT-BR | العَرَبِيَّة‎ | 日本語 | UA‎ | CZ‎ | HU‎ | HIN‎
Jeśli chcesz dodać swoje tłumaczenie, proszę stworzyć nowy pull request do tego repozytorium na Githubie.

Tłumaczenie: Wojciech Gawroński (Pattern Match) - Fork