Das zeigt sich an der HARTING MICA: eine Edge Computing Lösung, die den digitalen Retrofit älterer Maschinen und Anlagen ermöglicht. Gehäuse und Hardware zeigen den HARTING-Perfektionsanspruch. Bei der Software hingegen ist „gut genug“ die Zielgröße, denn ein Microservice ist weder jemals fertig noch perfekt. Fehlentscheidungen und Fehler können sehr zügig behoben werden, Systeme können schneller reifen und sich dem Zustand der Antifragilität annähern. Wenn sich Anforderungen ändern, oder bessere Software-Technologien verfügbar werden, wird der jeweilige Microservice einfach verworfen und ein neuer erstellt. Damit gewinnt man an Geschwindigkeit und kann schnell und in überschaubarem Kostenrahmen alte Maschinen digitalisieren und an die Cloud anbinden.
Den Fehlern ihren Schrecken nehmen
Um antifragil, mehr als robust zu werden, wie HARTING und andere Unternehmen, muss man proaktiv nach den Schwachstellen in Systemen suchen und gleichzeitig experimentieren. In einem System, das sich ständig weiterentwickeln soll, werden alle möglichen Fehler auftauchen, die nicht vorhersehbar sind – speziell wenn sich die Systeme in unbekannte Gebiete vorwagen. Deshalb ist es hilfreich, Ausfälle zu provozieren, wie das bei Netflix Chaos Monkey der Fall ist.
Wer all das tut, objektiviert Dinge, die nicht funktionieren, und macht den Umgang mit ihnen zum Alltag. Sobald der Umgang mit Fehlern zur Routine geworden ist, wird sich auch niemand mehr scheuen, ein Risiko einzugehen, eine neue Idee für ein Produkt oder einen Service auszuprobieren, um zu sehen, wie Kunden damit umgehen. So kommen Unternehmen ganz schnell zu Lösungen, die in der Zukunft funktionieren. Bei Amazon haben wir eine Vorgehensweise entwickelt, systematisch und konstruktiv mit Fehlern umzugehen. Unsere „Cause of Error“-Methode verzichtet bewusst darauf, nach „Schuldigen“ zu suchen. Es geht darum, Lernerfahrungen zu dokumentieren und Aktionen abzuleiten, die am Ende die Verfügbarkeit der Systeme verbessern.
Von der Fehlerursache zur Innovation
Die Methode sieht zunächst vor, dass wir ein Problem so schnell wie möglich aus der Welt schaffen, um den Schaden zu begrenzen und das System so schnell wie möglich wieder zum Laufen zu bringen. Damit alleine sind wir jedoch nicht zufrieden. Wir versuchen, das Maximum an Erkenntnisgewinn aus einem Vorfall zu erzielen. Und dieser Prozess beginnt, sobald beim Kunden wieder alles läuft: Im Zentrum unserer Methode stehen 5-Warum-Fragen (5 Whys) Sie helfen uns, die Wurzel eines Problems zu ergründen (eine Herangehensweise, die ursprünglich aus der Qualitätssicherung in der Fertigung stammt).
Nehmen wir den Fall einer Website: Wir fragen: Warum war unsere Website letzten Freitag nicht erreichbar? Die Webserver haben Timeouts gemeldet. Warum gab es Timeouts? Weil unsere Webserver überlastet sind und den hohen Traffic nicht ausgehalten haben. Warum waren die Webserver überlastet? Weil wir nicht genügend Webserver haben, um alle Anfragen zu Stoßzeiten abzuarbeiten. Warum haben wir nicht genug Webserver? Weil wir bei der Planung mögliche Lastspitzen nicht berücksichtigt haben. Warum haben wir bei der Planung keine Lastspitzen berücksichtigt? Am Ende wissen wir genau, was passiert ist, welche Kunden betroffen waren. So können wir davon einen Aktionsplan ableiten, der dafür sorgt, dass genau dieser Fehler nicht noch einmal passiert.
Oft gelingt es uns sogar aus einer Fehleranalyse herausbahnbrechende Innovationen anzustoßen, ganz im Sinne von Nassim Taleb. So ist die Lösung Amazon Auto Scaling entstanden, weil ein bestimmtes Kundensegment mit stark schwankenden Zugriffen auf ihrer Website zu kämpfen hatte. Wenn die Last für eine Webseite ansteigt, installiert Auto Scaling automatisch einen weiteren Webserver, um die gesteigerte Anzahl der Anfragen zu bedienen. Umgekehrt schaltet Auto Scaling nicht-benötigte Webserver ab, um Kosten zu sparen, wenn die Last wieder abfällt.
