MTTR ist nicht „mittlere Zeit bis zum Neustart“
„Schnell scheitern“ ist heutzutage das Mantra der Geschwindigkeit. Ob DevOps oder Business: Um in einer digitalen Wirtschaft agieren zu können, ist eine möglichst perfekte Betriebszeit erforderlich.
Obwohl die Theorie dieser Philosophie gut ist, führt sie in der Praxis oft nur zu weiteren Misserfolgen. Indem wir uns nicht auf die Suche nach der Grundursache (MTTR) konzentrieren, sondern nur auf die Gewährleistung der Verfügbarkeit (Betriebszeit), verlieren wir wertvolle Daten in beispiellosem Ausmaß. Seien Sie ehrlich: Wenn für Sie nur die Betriebszeit zählt, wird MTTR zur mittleren Zeit bis zum Neustart und nicht zur mittleren Zeit bis zur Problemlösung . Und ohne eine Lösung – also einen Grund für die Ausfallzeit – können Sie ein erneutes Auftreten nicht verhindern.
Dieses Vorgehen ist geschäftsschädigend.
Sie sehen, Sie werfen keine Pakete weg, sondern Teile von Pennys. Und wie uns das klassische kriminelle Klischee lehrt, Bruchteile von Centbeträgen aus Transaktionen abzuzweigen, um Millionen anzuhäufen, zählt jeder Bruchteil eines Cents. Mit jeder Sekunde, in der eine Komponente, ein Dienst oder ein Server nicht reagiert, geht ein Wert verloren – sowohl erfahrungsmäßig als auch existentiell. Verbraucher dulden keine schlechte Leistung oder Ausfallzeiten, und auch die Geschäftsbücher können beides nicht tolerieren.
Und wenn Sie sich mit Durchsatz und Bandbreite auskennen, wissen Sie, dass die Grundlage für beide Berechnungen die Pakete pro Sekunde sind, die vom zugrunde liegenden System verarbeitet werden können. Dies gilt nicht nur im Netzwerk, sondern für jede Komponente, die mit einer Transaktion interagiert. Die App. Die Application . Router. Schalter. Datenbanken. Wenn eine Netzwerkverbindung besteht, unterliegt es derselben Berechnung und ist durch seine Kapazität zur Paketweiterleitung eingeschränkt.
WARNUNG: MATHEMATIK VORAUS
Die Geschwindigkeit der heutigen Netzwerke stellt sicher, dass wir genau dies mit einer Rate von Millionen Paketen pro Sekunde tun. Geschäftstransaktionen werden natürlich in erster Linie über ein (buchstäbliches) Netz aus HTTP-Transaktionen abgewickelt, von denen jede für die Geschäftsabwicklung entscheidende Informationen weitergibt. Die Anzahl der zur Durchführung einer Transaktion erforderlichen Pakete hängt von der erforderlichen Datenmenge ab. Das durchschnittliche Paket enthält 1500 Byte Daten (das ist die MTU). Wenn also eine HTTP-basierte Nachricht mit einer JSON-Nutzlast, die eine Transaktion darstellt, 4500 Bytes erfordert (natürlich nach der Verschlüsselung), sind das ungefähr drei Pakete. Seien wir also großzügig und gehen davon aus, dass für eine typische digitale Geschäftstransaktion fünf Pakete erforderlich sind. Ein 10-Gbit/s-Netzwerk kann knapp 15 Millionen Pakete pro Sekunde verarbeiten. Vorausgesetzt, es steht genügend Rechenkapazität zur Verfügung, könnte man sagen, dass dies 3 Millionen Transaktionen entspricht. Nehmen wir an, jede Transaktion ist einen Bruchteil (ein Drittel) eines Pennys wert. Das entspricht 1 Million Dollar pro Sekunde.
Heutzutage verarbeitet niemand Transaktionen tatsächlich mit dieser Geschwindigkeit oder in diesem Umfang. Sogar Visa – das Daten unbestreitbar mit einer Geschwindigkeit verarbeitet, die die meisten Unternehmen nicht benötigen – gibt an, dass seine Kapazität bei etwa 24.000 Transaktionen pro Sekunde liegt. Selbst wenn wir den gleichen Wert dieser Transaktionen annehmen – ein Drittel eines Pennys –, sind das immer noch 8.000 Dollar pro Sekunde.
Der Punkt ist, dass ein Fehler in der Transaktionskette, die aus Routern, Switches, Netzwerk- und Application , App-Infrastruktur und Komponenten besteht, eine sehr schlimme Sache ist. Dies ist kostspielig, da im Falle eines Fehlers weder die Pakete noch die darin enthaltenen Centbeträge verarbeitet werden. Und es gibt keinen Bereich der digitalen Wirtschaft, der nicht auf die Übermittlung von Paketen angewiesen ist.
Die Antwort liegt bislang im Mantra des „schnellen Scheiterns“: Starten Sie einfach eine neue Instanz von X oder Y oder Z oder welcher Komponente auch immer das Problem aufgetreten ist. Aber diese Komponente hat *aus einem bestimmten Grund* versagt und es ist von größter Wichtigkeit, dass der Grund dafür aufgedeckt und behoben wird. Schnell. Denn zwischen Ausfall und Wiederherstellung liegen noch immer teure Sekunden, die Geschäftswert kosten. Wenn es einmal fehlgeschlagen ist, wird es wahrscheinlich erneut fehlschlagen. Und nochmal.
SICHTBARKEIT: Der Grundstein, auf dem MTTR ruht
Aus diesem Grund ist Sichtbarkeit für den Erfolg in der digitalen Wirtschaft so entscheidend. Denn erst durch die Transparenz ist es allen operativen Mitarbeitern möglich, die Fehlerursache zu finden und zu beheben. Leider wird die Sichtbarkeit häufig der Geschwindigkeit geopfert. Es geht nicht um die tatsächliche Geschwindigkeit der Transaktionen, sondern um die Zeit bis zur Wertschöpfung. In unserer Eile, Apps immer schneller und häufiger auf den Markt zu bringen, haben wir nicht ausreichend in die nötige Transparenz investiert, um Fehler zu vermeiden.
Man könnte sogar behaupten, dass die „Fail Fast“-Philosophie von DevOps eine Reaktion auf dieses Versagen sei. Da es nicht möglich ist, die Fehlerursache zu finden und zu beheben, ist DevOps zu dem Schluss gekommen, dass es besser ist, die Verfügbarkeit wiederherzustellen, als Zeit zu verschwenden. Diese Fähigkeit wird immer schwieriger zu erreichen, da Unternehmen Multi-Cloud-Ansätze zur Bereitstellung von Applications verfolgen.
Im Jahr 2018 nannten weniger als ein Drittel (31 %) die Herausforderung der Sichtbarkeit bei Multi-Cloud-Anwendungen. Im Jahr 2019 stieg dieser Wert auf mehr als ein Drittel (39 %) und lag damit gleichauf mit Leistung und Sicherheit als größte Herausforderungen für Multi-Cloud-Anwendungen. Sichtbarkeit ist eine entscheidende Komponente der übergreifenden „Beobachtbarkeit“, die Überwachung, Analyse und Warnmeldungen zusammenbringt, um jederzeit wertvolle Einblicke in den Zustand eines Systems zu bieten. Dies ist insbesondere bei einem Ausfall wichtig, da der Zustand des Systems auf mehrere IT-Bereiche verteilt ist, die möglicherweise den Austausch von Informationen ermöglichen, der schnell zu einer Lösung statt nur einem Neustart führen kann, oder auch nicht.
Die Fähigkeit eines Service Mesh, durch verteiltes Tracing einen Mehrwert zu schaffen, ist ein hervorragendes Beispiel für die Ermöglichung von Sichtbarkeit. Aber wir müssen dies erweitern, um die gesamte Kette von Application einzubeziehen, die die in einer Containerwelt ausgeführten Applications skalieren und sichern. Dazu gehören verteilte Komponenten und Applications , die in der öffentlichen Cloud ausgeführt werden und Teil der Ausführungskette sein können. Um Probleme zu erkennen und zu beheben, die zu Ausfallzeiten oder schlechter Leistung führen, ist Transparenz über alle Umgebungen, Infrastrukturen und Applications hinweg erforderlich.
Transparenz ist zwingend erforderlich, damit Unternehmen ihren Erfolg wieder anhand der MTT -Lösung und nicht anhand des MTT- Neustarts messen können.