Resiliente Systeme – das Endziel. Denn Ausfälle sind unvermeidlich

Dieser Artikel ist Teil der XPRT. Magazin Nr. 21

Kleiner Hinweis: Ich koche sehr gerne, daher ist dieser Artikel reichlich mit Anspielungen auf das Thema Essen gespickt. Holen Sie sich doch etwas Leckeres, damit das Lesen noch mehr Spaß macht!

Stellen Sie sich Folgendes vor: Sie haben einige Freunde zum Abendessen eingeladen. Sie haben eine Woche lang alles geplant: ein köstliches Menü, frische Zutaten, erlesene Getränke und eine tolle Playlist. Sie haben bereits am frühen Nachmittag mit der Zubereitung der Moussaka begonnen. Die Fleischsauce köchelte langsam bis zur Perfektion – reichhaltig und vollmundig. Die Béchamelsauce gelang seidig und cremig. Der Tisch war gedeckt. Die Gäste hatten bereits per SMS mitgeteilt, wann sie eintreffen würden. Alles verlief nach Plan.

Gerade als es an der Zeit ist, die Moussaka wieder in den Backofen zu schieben, stellen Sie fest, dass dieser nicht mehr funktioniert. Und einfach so bricht der Abend zusammen. Nicht, weil das Essen schlecht war, nicht, weil Sie etwas falsch gemacht haben, sondern weil Ausfallsicherheit nie Teil des Plans war. Kein Ersatzgericht, keine alternative Zubereitungsmethode, nicht einmal ein flüchtiger Gedanke daran, was passieren würde, wenn das eine entscheidende Gerät, auf das Sie sich verlassen haben, den Geist aufgeben würde. Ein einziger Schwachpunkt, und das gesamte System ist zusammengebrochen.

Dies ist keine Geschichte über Pech. Es ist eine Geschichte über einen Plan, der ausschließlich für den „Happy Path“ optimiert wurde.

Wir Ingenieure verbringen viel Zeit damit, Systeme zu entwickeln, die unter normalen Bedingungen hervorragend funktionieren: reibungsloser Netzwerkverkehr, einwandfreie Abhängigkeiten, stabile APIs, Datenbanken, die rechtzeitig reagieren – was auch immer man sich vorstellen kann. Der „Happy Path“ ist schnell, elegant und gründlich getestet. Doch dann kommt es zu einem Traffic-Anstieg. Ein nachgelagerter Dienst beginnt, Zeitüberschreitungen zu verursachen. Ein falsch konfigurierter Verbindungspool wird mit einer Bereitstellung ausgerollt. Und plötzlich bricht dieses sorgfältig aufgebaute, gut überwachte System auf eine Weise zusammen, die niemand vorhergesehen hat – denn das Team hat es zwar so konzipiert, dass es funktioniert, aber nicht unbedingt darauf, wie es im Fehlerfall reagiert.

Die Realität ist ganz einfach: Ein Scheitern ist kein Ausnahmefall. Es ist unvermeidlich. Jedes System wird irgendwann einmal Ausfälle erleben. Die Frage ist, ob Sie es so konzipiert haben, dass es diesen Ausfall auffangen, sich anpassen und weiterhin einen Mehrwert liefern kann.

Ich hoffe, dass Sie am Ende dieses Artikels ein klares Verständnis davon haben werden, was ein System widerstandsfähig macht, warum Widerstandsfähigkeit von Anfang an berücksichtigt werden sollte und wie die fünf Kernprinzipien Ihnen dabei helfen können, robuste Lösungen zu entwickeln.

Was ist ein widerstandsfähiges System?

Bevor wir uns eingehender mit widerstandsfähigen Systemen befassen, sollten wir uns zunächst ein klares Bild davon machen, was Resilienz eigentlich bedeutet und wie sie sich von verwandten Konzepten unterscheidet.

Resilienz ist die Fähigkeit eines Systems, Störungen standzuhalten, bei Bedarf einen kontrollierten Leistungsabfall zuzulassen, sich schnell wiederherzustellen und weiterhin wesentlichen Nutzen zu liefern. Beachten Sie, dass dies nicht dasselbe ist wie „ein System, das niemals ausfällt“. Das Ziel ist nicht Perfektion, sondern Kontinuität.

Stellen Sie sich vor, Sie sind gerade mitten bei der Zubereitung eines Gerichts, als Ihnen plötzlich auffällt, dass Ihnen eine wichtige Zutat fehlt: Ein belastbarer Hobbykoch findet einen Ersatz, passt das Gericht an und serviert das Abendessen dennoch. Ein Koch, der nicht vom Rezept abweichen kann, hört ganz auf. Auch hier geht es bei Belastbarkeit nicht darum, Misserfolge zu verhindern. Es geht darum, Vorkehrungen für den Moment zu treffen, in dem ein Misserfolg eintritt.

Die Begriffe „Zuverlässigkeit“ und „Verfügbarkeit“ werden oft synonym mit „Ausfallsicherheit“ verwendet, doch jeder dieser Begriffe bezieht sich auf ein grundlegend anderes Problem.

Ein System kann hochgradig zuverlässig oder hochgradig verfügbar sein und dennoch nicht widerstandsfähig sein. Bei der Zuverlässigkeit steht im Vordergrund, dass das System unter erwarteten Bedingungen einwandfrei funktioniert, während es bei der Verfügbarkeit darum geht, dass das System in Betrieb und erreichbar ist. Beide setzen eine stabilen Betriebsumgebung voraus.

Bei der Ausfallsicherheit geht es jedoch darum, was geschieht, wenn etwas Unerwartetes eintritt. Ein System kann jeden Zuverlässigkeitstest bestehen und eine hervorragende Verfügbarkeit aufweisen, dennoch zusammenbrechen, wenn es mit einer plötzlichen Störung wie einem regionalen Ausfall, einem Konfigurationsfehler oder einem plötzlichen Anstieg des Datenverkehrs konfrontiert wird. Es mag unter normalen Umständen einwandfrei funktionieren, versagt jedoch katastrophal in dem Moment, in dem etwas Unerwartetes eintritt. Resilienz schließt diese Lücke, indem sie sicherstellt, dass das System auch dann weiterläuft, wenn alles um es herum zusammenbricht.

Warum ist es wichtig?

Kein seriöses Restaurant setzt den Abendbetrieb auf einen einzigen Ofen, einen einzigen Koch oder einen einzigen Lieferanten. Das wäre ein fragiler Plan, der als Selbstvertrauen getarnt ist. Dennoch gehen Entwicklungsteams genau dieses Risiko ein, jedes Mal, wenn sie ein System ausliefern, das über keine Ausweichmöglichkeiten, keine Redundanz und keinen Plan für den Fall verfügt, dass die Komponenten nicht mehr zusammenarbeiten.

Um zu verstehen, warum Ausfallsicherheit wichtig ist, muss man dasselbe Problem aus drei verschiedenen Blickwinkeln betrachten: welche Kosten entstehen, wenn etwas ausfällt, wie sich dies auf das Vertrauen der Nutzer auswirkt und wie es die Arbeitsgeschwindigkeit des Teams beeinflusst.

Kosten

Jede Minute Ausfallzeit bedeutet direkten Umsatzverlust, doch die versteckten Kosten sind oft noch höher: der Techniker im Bereitschaftsdienst, der die ganze Nacht durcharbeitet, der Krisenstab, der die Arbeitszeit von Führungskräften im Umfang eines ganzen Sprints in Anspruch nimmt, und die Aufräumarbeiten nach dem Vorfall, die nie ganz enden. Kettenausfälle verstärken diesen Effekt exponentiell: Der Ausfall eines Dienstes sollte nicht dazu führen, dass zwei weitere ausfallen.

Das Ziel ist jedoch nicht, überall maximale Ausfallsicherheit zu erreichen. Umfangreiche Investitionen in die Ausfallsicherheit eines nächtlichen Batch-Jobs sehen ganz anders aus als entsprechende Maßnahmen für ein Zahlungsgateway. Eine Überdimensionierung eines Dienstes mit geringer Kritikalität verschwendet Ressourcen; eine Unterdimensionierung eines Dienstes mit hoher Kritikalität führt zu einem schleichenden Risiko, bis etwas die Diskussion erzwingt. Komplexität, die an den richtigen Stellen hinzugefügt wird, verringert den Auswirkungsbereich eines Ausfalls; Komplexität, die an den falschen Stellen hinzugefügt wird, führt lediglich zu weiteren möglichen Fehlerquellen.

Stellen Sie sich ein Restaurant vor, in dem mitten im Samstagsbetrieb ein schwerwiegender Geräteausfall auftritt. Die entgangenen Einnahmen dieses Abends sind dabei noch der geringste Teil der Kosten. Hinzu kommen Gesundheitsinspektionen, Berichterstattung in der Presse und ein Ruf, dessen Wiederherstellung Monate in Anspruch nimmt. Die Kosten dieses einzelnen Vorfalls übersteigen regelmäßig die Kosten, die eine ordnungsgemäße Wartung und ein Notfallplan über Jahre hinweg verursacht hätten.

Vertrauen Sie

Vertrauen lässt sich schwerer quantifizieren, ist aber leichter zu verlieren. Nutzer, deren Plattformen stets verfügbar sind, bei Ausfällen reibungslos funktionieren und sich schnell wieder erholen, entwickeln eine Form der Loyalität, die von Wettbewerbern nur schwer zu verdrängen ist. Umgekehrt entwickeln Nutzer, die schwerwiegende Ausfälle erleben, eine ganz bestimmte Art von Misstrauen, von der man sich nur schwer wieder erholt. Resilienz, die Nutzer im Laufe der Zeit wiederholt erleben, wird zu einem Markenmerkmal.

Stellen Sie sich ein Restaurant vor, in dem an einem stark frequentierten Abend die Hälfte der Speisekarte ausverkauft ist, kalte Gerichte serviert werden und die Gäste fünfundvierzig Minuten lang warten müssen. An allen anderen Abenden mag das Essen hervorragend sein. Doch die Bewertungen, die an diesem Abend aus Frustration verfasst werden, sind es, die neue Gäste in den nächsten zwei Jahren lesen werden. Von einem schwerwiegenden Misserfolg erholt man sich nur langsam. Nutzer erinnern sich an Ausfälle genauso, wie Restaurantgäste sich an schlechte Erfahrungen erinnern.

Entwicklungsgeschwindigkeit

Die Entwicklungsgeschwindigkeit ist der sich vervielfachende Ertrag einer frühzeitigen Investition in Resilienz. Teams, die frühzeitig in Resilienz investieren, verbringen mit zunehmender Reife der Systeme deutlich weniger Zeit mit der reaktiven Behebung von Vorfällen. Diese Zeit wird in neue Funktionen, die Leistungsfähigkeit und weitere Maßnahmen zur Stärkung der Resilienz reinvestiert. Die Vorabinvestition zahlt sich durch sich vervielfachende Erträge aus. Teams, die diese Investition nicht tätigen, sehen ihre Entwicklungsgeschwindigkeit zunehmend durch die operative Verschuldung eines anfälligen Systems eingeschränkt.

Stellen Sie sich eine Küche vor, in der nichts beschriftet ist, die Vorbereitungsarbeiten während des Service ad hoc erfolgen und das Team die Hälfte seiner Schicht damit verbringt, nach Zutaten zu suchen. Die Bearbeitung von Bestellungen dauert doppelt so lange. Der Küchenchef ist zu sehr damit beschäftigt, Probleme zu lösen, um die Speisekarte zu verfeinern. Das Verbesserungspotenzial der Küche wird vollständig durch ihre eigene Unordnung aufgebraucht. Entwicklungsteams in instabilen Systemen arbeiten auf dieselbe Weise: Es wird so viel Zeit für die Behebung von Störungen und für Notlösungen aufgewendet, dass keine Zeit mehr bleibt, um das zu entwickeln, worauf es wirklich ankommt.

Letztendlich sollte dies der Unternehmensleitung so dargestellt werden, wie es tatsächlich ist: Resilienz ist Risikomanagement. Jede Abkürzung, bei der Robustheit zugunsten von Geschwindigkeit geopfert wird, ist ein Risiko, das das Unternehmen stillschweigend trägt – ein Risiko, dessen Kosten nicht beziffert werden können und das stetig wächst. Diese Rechnung wird irgendwann fällig, sei es durch einen Vorfall, einen verlorenen Kunden oder einen Wettbewerber, der einfach sorgfältiger vorgegangen ist. Resilienz ist das, was ein System und das dahinter stehende Team langfristig tragfähig macht.

5 Grundsätze widerstandsfähiger Systeme

Zu wissen, dass Resilienz wichtig ist, ist eine Sache. Zu wissen, wo man ansetzen soll, ist eine andere. Resilienz ist keine einzelne Eigenschaft, die man am Ende einfach hinzufügt; es handelt sich vielmehr um eine Reihe von Entwurfsaspekten, die jeweils auf eine andere Art und Weise abzielen, wie sich ein System unter Belastung verformen oder versagen kann. Hier sind die fünf Grundsätze, auf die ich immer wieder zurückgreife, wenn ich einen Systementwurf überprüfe.

Fehlertoleranz

Stellen Sie sich vor, Sie sind gerade dabei, eine Soße zuzubereiten, und der Mixer gibt den Geist auf. Wenn Sie in Ihrer Küche einen Stabmixer in der Schublade haben, geht das Abendessen ohne Probleme weiter. Das Gericht kommt pünktlich auf den Tisch, und niemand wird bemerken, dass etwas schiefgelaufen ist. Die Küche wurde so eingerichtet, dass kein einzelnes Küchengerät zum alleinigen Schwachpunkt bei der Zubereitung der Mahlzeit wird.

In der Softwareentwicklung bedeutet Fehlertoleranz, Systeme so zu konzipieren, dass einzelne Komponenten ausfallen können, ohne dass dadurch der gesamte Betrieb beeinträchtigt wird. Hier sind einige bewährte Muster:

Eine schwierige Frage: „Was genau passiert mit dem Rest des Systems, wenn diese Komponente gerade jetzt ausfällt?“

Graceful Degradation

Sie sind wieder in der Küche und bereit, die Crème brûlée mit einem Gasbrenner fertigzustellen. Doch die Gasflasche ist leer, und Sie haben keine Nachfüllflasche. Anstatt das Dessert ganz ausfallen zu lassen, improvisieren Sie und streuen stattdessen etwas Zimt darüber. Es ist zwar nicht das, was Sie geplant hatten, aber es schmeckt trotzdem köstlich. Auch ein eingeschränkter Genuss ist immer noch wertvoll und weitaus besser als gar kein Genuss.

In der Softwareentwicklung bedeutet „Graceful Degradation“, die wesentlichen Komponenten Ihres Systems zu identifizieren und für jede einzelne davon eigene Reaktionsstrategien zu entwickeln und zu optimieren. Hier sind einige Möglichkeiten, wie Sie dies erreichen können:

Eine schwierige Frage: „Was ist das Mindestmaß an funktionsfähiger Benutzererfahrung, das wir noch bieten können, wenn diese Abhängigkeit ausfällt?“

Automatische Wiederherstellung

Stellen Sie sich eine gut organisierte Küche während eines hektischen Service vor. An jedem Kochfeld befindet sich ein Timer, im Backofen ein Temperaturfühler und ein Rauchmelder, der die Dunstabzugshaube sofort einschaltet, sobald etwas anfängt zu verbrennen. Die Küche wurde so konzipiert, dass kleine Pannen automatisch erkannt und eingedämmt werden, sodass der Kochbetrieb ohne Zwischenfälle fortgesetzt werden kann. Es wird nicht von Ihnen erwartet, dass Sie am Herd stehen und jeden Topf endlos anstarren.

Dies ist in groß angelegten verteilten Systemen von entscheidender Bedeutung, da menschliche Bediener ab einer bestimmten Anzahl von Diensten und Instanzen schlichtweg nicht mehr schnell genug auf jeden Ausfall reagieren können, um Auswirkungen auf die Nutzer zu verhindern. In solchen Szenarien lässt sich eine automatische Wiederherstellung wie folgt aktivieren:

Eine schwierige Frage: „Wie lange dauert die Wiederherstellung, und ist ein menschliches Eingreifen erforderlich?“

Isolierung

Stellen Sie sich vor, Sie bereiten vier Gerichte gleichzeitig zu. Das Nudelwasser kocht über und verursacht eine Unordnung. Da jedoch jeder Herd und jeder Topf unabhängig voneinander ist, beeinträchtigt dies weder das im Ofen brutzelnde Gemüse noch das Brot im Ofen oder den Salat, der gerade auf der Arbeitsplatte angerichtet wird. Die Unordnung bleibt auf einen Bereich beschränkt. In einer gut organisierten Küche führt ein einzelner Fehler nicht zwangsläufig zu einem ruinierten Essen.

Wenn etwas schiefgeht, sollte der Schaden begrenzt bleiben. Ein Ausfall in einem Teil des Systems sollte sich nicht ungehindert auf alle anderen Teile ausbreiten können. Die Isolierung lässt sich mithilfe der folgenden Muster umsetzen:

Eine schwierige Frage: „Wenn dies fehlschlägt, was scheitert dann ebenfalls, und warum?“

Beobachtbarkeit

Ein erfahrener Koch setzt beim Kochen alle seine Sinne ein. Er nimmt den Karamellgeruch wahr, noch bevor es anbrennt. Er lauscht dem Brutzeln, um zu beurteilen, ob die Pfanne die richtige Temperatur hat. Er probiert während des Kochens immer wieder. Er wartet nicht, bis das Gericht auf dem Teller liegt, um festzustellen, dass bereits vor vierzig Minuten etwas schiefgelaufen ist. Ohne diese ständige, mehrkanalige Überwachung häufen sich Probleme unbemerkt an, bis es zu spät ist, um das Gericht noch ordnungsgemäß zu retten.

In Softwaresystemen wird die Beobachtbarkeit durch die folgenden wesentlichen Säulen gewährleistet:

Eine schwierige Frage: „Könnten wir diesen Vorfall allein anhand der von unserem System erzeugten Signale diagnostizieren und beheben?“

Belastbarkeit vom ersten Tag an

Kein ernsthafter Koch wartet bis zur Mitte des Service, um zu überprüfen, ob der Ofen funktioniert. Küchen werden lange bevor der erste Gast die Türschwelle überschreitet getestet, bestückt und vorbereitet. Der Zeitpunkt, um festzustellen, dass der Temperaturfühler unzuverlässig ist, sollte nicht erst dann sein, wenn ein Lammkarree im Ofen steht und acht Gäste am Tisch warten. Belastbarkeit entsteht durch Vorbereitungsarbeit, die in der Ruhe vor dem Ansturm des Abendessens geleistet wird. Sobald der Service begonnen hat, schränken sich Ihre Möglichkeiten drastisch ein.

Die Kosten für die Nachrüstung zur Erhöhung der Widerstandsfähigkeit

Die nachträgliche Integration von Ausfallsicherheit in ein laufendes System ist in einer Weise kostspielig, die nicht auf den ersten Blick erkennbar ist:

Ein widerstandsfähiges System spiegelt eine widerstandsfähige Denkweise wider. Teams, die Misserfolge offen anerkennen und sie als Gelegenheit zum Lernen betrachten, sind diejenigen, die wirklich vorankommen.

„Game Days“ und „Chaos Engineering“ sind das technische Äquivalent zu einem Probeessen: Dabei werden bewusst Probleme herbeigeführt – beispielsweise durch das Herunterfahren von Instanzen, das Überlasten von Warteschlangen oder das Einfügen von Latenz –, um herauszufinden, was nicht funktioniert, bevor Ihre Nutzer dies bemerken. „Blameless Postmortems“ sind die ehrliche Nachbesprechung, nachdem etwas schiefgelaufen ist: Was stand im Rezept, welche Technik wurde angewendet, was sollten wir beim nächsten Mal anders machen? Das Ziel ist das Lernen, nicht die Schuldzuweisung. Und die Festlegung von SLOs (Service Level Objectives) vor der Entwicklung des ersten Dienstes entspricht der Vereinbarung darüber, wie ein großartiges Essen aussehen soll, bevor man einkaufen geht. Damit wird der Standard festgelegt, auf den alle hinarbeiten.

Eine Architektur, bei der Resilienz an erster Stelle steht, ist kein „Over-Engineering“. Es ist einfach gute Technik. Die Systeme, die langfristiges Vertrauen gewinnen, werden von Menschen entwickelt, die sich schon früh die unbequeme Frage gestellt haben: „Was passiert, wenn dies ausfällt?“, und diese Frage mit mehr als nur Optimismus beantwortet haben.

Mise en Place

„Mise en place“ ist die französische Kochpraxis, bei der alle Zutaten, Arbeitsgeräte und Küchenutensilien vor Beginn des Kochvorgangs vorbereitet und geordnet werden. In professionellen Küchen gilt dies als unabdingbar: Es wird erst begonnen, wenn alles an seinem Platz ist.

Das technische Äquivalent dazu ist ein auf Ausfallsicherheit ausgelegtes Design als Grundvoraussetzung und nicht als nachträglicher Einfall. Definieren Sie die Ausfallmodi, bevor der erste Dienst bereitgestellt wird. Entwerfen Sie Ausweichlösungen. Implementieren Sie die Zustandsprüfungen. Einigen Sie sich auf die SLOs. Richten Sie die Dashboards ein.
Köche, die die „Mise en place“ überspringen, verbringen den gesamten Dienst damit, sich abzumühen. Entwicklerteams, die die Ausfallsicherheitsplanung überspringen, verbringen jeden Vorfall damit, genau dasselbe zu tun.

Wie sich Resilienz in der Praxis zeigt

Theorie ist nützlich, doch konkrete Beispiele sind besser. Lassen Sie uns gemeinsam betrachten, wie sich die fünf Prinzipien in einem realen (wenn auch vereinfachten) Szenario widerspiegeln.

Stellen Sie sich eine Online-Plattform vor, auf der Kunden Kochsets für hausgemachte Mahlzeiten bestellen: sorgfältig ausgewählte Zutaten und Rezepte, die direkt an die Haustür geliefert werden, damit sie zu Hause ein Abendessen in Restaurantqualität zubereiten können. Die Plattform umfasst verschiedene Dienste: Auftragsabwicklung, Zahlungsabwicklung, Rezeptempfehlungen, Lieferlogistik und Benachrichtigungen.

So beeinflusst das Resilienz-Denken die Entwurfsentscheidungen, die getroffen werden, bevor die erste Zeile des Produktionscodes geschrieben wird:

Beachten Sie, was diese Entscheidungen gemeinsam haben: Sie wurden bereits in der Entwurfsphase getroffen, d. h. im Rahmen von Architektur-Reviews, Whiteboard-Sitzungen und der frühen Sprintplanung – und nicht im Chaos einer Retrospektive nach einem Vorfall. Genau wie ein erfahrener Koch, der ein Ersatzdessert vorbereitet und die Ernährungsbedürfnisse der Gäste abklärt, bevor diese eintreffen, hat das Team bereits vor der ersten Verbindung eines Nutzers Vorkehrungen für Ausfallszenarien getroffen.

Resilienz entsteht in Systemen nicht zufällig. Sie entsteht, weil jemand die schwierigen Fragen gestellt, diese offen mit dem Team diskutiert und beschlossen hat, etwas dagegen zu unternehmen.

Fazit

Kommen wir noch einmal auf die Dinnerparty zurück. Der Abend hätte nicht mit kalter Moussaka und peinlichen Entschuldigungen enden müssen. Ein vorausschauender Gastgeber plant für den Fall ein, dass der Backofen ausfällt – nicht, weil er damit rechnet, sondern weil er weiß, dass jede einzelne Schwachstelle ein Risiko darstellt. Ein Ersatzgericht im Hinterkopf. Eine alternative Zubereitungsmethode. Eine gut gefüllte Speisekammer, die Raum für Improvisation lässt.

Das Gleiche gilt für die Systeme, die wir entwickeln. Misserfolge sind unvermeidlich. Resilienz ist kein Ziel, sondern das Endergebnis jeder Entwurfsprüfung. Die fünf Prinzipien, die wir behandelt haben (Fehlertoleranz, Graceful Degradation, automatische Wiederherstellung, Isolation und Beobachtbarkeit), sind keine unabhängigen Funktionen, die nacheinander in ein Backlog aufgenommen werden können. Sie bilden eine schlüssige Philosophie des Systemdesigns. Eine Philosophie, die besagt: Meine Nutzer vertrauen mir etwas an, das ihnen wichtig ist. Ich bin ihnen ein System schuldig, das so konzipiert ist, dass es auch dann noch funktioniert, wenn die Realität nicht mehr mitspielt. Deshalb ist es keine Option, die fünf schwierigen Fragen ernst zu nehmen – es ist die Verpflichtung, die hinter jedem widerstandsfähigen System steht.

Hier fangen Sie an:

Das Ziel besteht nicht darin, ein System zu entwickeln, das niemals ausfällt. Das Ziel besteht vielmehr darin, ein System zu entwickeln, dem man vertrauen kann, wenn es doch einmal ausfällt.

Ein erfahrener Koch, der gut geplant, sorgfältig vorbereitet und Flexibilität in das Menü eingebaut hat, kann eine Dinnerparty selbstbewusst ausrichten – nicht, weil nichts schiefgehen wird, sondern weil er sich bereits Gedanken darüber gemacht hat, was zu tun ist, falls doch etwas schiefgeht.

Bauen Sie Ihre Systeme auf dieselbe Weise auf :)