NetOps beachten den SRE-Fokus auf MTTR, um Verfügbarkeit zu erreichen

Der Site Reliability Engineer (SRE) ist eine relativ neue Rolle – normalerweise im Bereich Technik oder Betrieb – und konzentriert sich, wenig überraschend, auf die Aufrechterhaltung der Standortzuverlässigkeit. Damit ist im Allgemeinen die Verfügbarkeit von Anwendungen gemeint, es umfasst jedoch auch die Leistung. Das ist sinnvoll, da nicht reagierende Apps von den meisten Endbenutzern heutzutage als nicht verfügbar angesehen werden.

Beim Durchlesen des SRE-Berichts 2018 von Catchpoint fielen mir die Diagramme auf, in denen Service Level-Indikatoren und SRE-Kennzahlen verglichen wurden. Wenn Sie „Verfügbarkeit“ als Servicelevelindikator der obersten Ebene sehen, sehen Sie als Messgröße normalerweise auch „Betriebszeit“ oder „Ausfallzeit“. Dies gilt nicht für die SREs in dieser Umfrage. 

Auf die Frage, welche Service-Level-Indikatoren für ihre Dienste am wichtigsten seien, antworteten mit überwältigender Mehrheit 84 % der Befragten, dass die „Endbenutzerverfügbarkeit“ die wichtigste Aussage sei. An zweiter Stelle folgte mit 61 % die Latenz und knapp dahinter die Fehlerrate mit 60 %. Die Leistung – im Bericht als Reaktionszeit des Endbenutzers beschrieben – entfiel auf beeindruckende 58 % der Antworten.

Beachten Sie nun die Kennzahlen, die zur Definition des Erfolgs verwendet werden. In der Welt der Infrastruktur und des Betriebs sind wir eher an Kennzahlen wie „Betriebszeit“ und eingängige Phrasen wie „5 9er“ gewöhnt.

SREs tendieren eher dazu, den Erfolg anhand der Vorfallsrate und der MTTR zu betrachten. Angesichts der Tatsache, dass im selben Bericht festgestellt wurde, dass 41 % der SREs vor ihrer SRE-Karriere die Rolle eines „DevOps Engineers“ innehatten, dürfte dies nicht überraschend sein. DevOps selbst beschäftigt sich mehr mit der MTTR als mit der Berechnung der Betriebszeit, weil davon ausgegangen wird, dass es zu Ausfallzeiten kommen wird . Der Schlüssel liegt darin, das Problem durch eine schnelle Lösung zu minimieren, anstatt Zeit mit dem Versuch zu verschwenden, es ganz zu vermeiden.

Aufmerksame Leser werden jedoch feststellen, dass durch die Minimierung der MTTR die Ausfallzeiten minimiert werden. Schnellere Lösung, weniger Ausfallzeiten.

Der subtile Unterschied zwischen beiden besteht darin, dass Menschen dazu neigen, das zu optimieren, woran sie gemessen werden. Wenn Sie anhand der Anzahl der Codezeilen gemessen werden, werden Sie eine Menge Codezeilen schreiben – ob Sie diese nun brauchen oder nicht. Wenn Sie anhand von Sicherheitsvorfällen gemessen werden, werden Sie alles sperren und NEIN zu allen Änderungen schreien, die einen Verstoß begünstigen könnten. Wenn Sie die Mitarbeiter anhand der Betriebszeit messen, konzentrieren sich die Betriebsabläufe darauf, die Systeme betriebsbereit und verfügbar zu halten – und nicht auf die Architektur und Instrumentierung von Systemen und Anwendungen, die die MTTR verkürzen.

Dies ist einer der „kulturellen“ Aspekte von DevOps – eine Änderung unserer Herangehensweise an den Betrieb – der auf NetOps übertragen werden muss. Wenn wir weiterhin die Betriebszeit optimieren, verpassen wir die Gelegenheit, Warn- und Beobachtungssysteme (wie Überwachung und robuste Protokollierung) einzurichten, die die durchschnittliche Zeit bis zur Lösung des Problems verkürzen und unser Ziel der Minimierung von Ausfallzeiten erreichen.

Das Durchforsten von Protokollen – selbst zentralisierter – ist kein effizientes Mittel, um zum Kern eines Problems vorzudringen und es zu lösen. Durch Echtzeitüberwachung und Warnmeldungen zu wichtigen Variablen mit Auswirkungen auf die Verfügbarkeit, wie etwa Kapazität, Konnektivität und Leistung über den gesamten Datenpfad (Netzwerk, Infrastruktur, Anwendung), lässt sich die Zeit zur Lösung von Problemen ausnahmslos verkürzen, wenn Sie feststellen, dass die Leistung von Systemen oder Diensten nachlässt oder plötzlich ausgefallen ist.

NetOps muss diesen Ansatz hinsichtlich der Zuverlässigkeit in der Produktionspipeline übernehmen, da er insgesamt einen besseren Ansatz für den Umgang mit unvermeidlichen Fehlern bietet und mit den DevOps-Gegenstücken übereinstimmt. Es gibt schließlich einen Grund, warum wir nur 5 9er erreicht haben, nicht wahr? Weil wir erkannt haben, dass wir scheitern können, egal wie sehr wir uns anstrengen, und dass Perfektion unmöglich ist.

Der Wechsel von Betriebszeit/Ausfallzeit zu MTTR als Erfolgsmaßstab fördert die teamübergreifende Zusammenarbeit und den Einsatz von Beobachtungstools über die gesamte Länge der Produktionspipeline. Es gibt einen Grund, warum Überwachungs- und Warntools in der Umfrage ganz oben auf der Liste der „unverzichtbaren Tools“ für SREs standen. Um sicherzustellen, dass alle – NetOps, DevOps und auch App Dev – ihr Ziel erreichen können, Apps schnell und verfügbar zu halten, ist Beobachtbarkeit (mit dem Ziel, bei Fehlern/Vorfällen Warnungen zu geben) plus Zusammenarbeit die bessere Formel.