SRE suchen

Kapitel 1. Kontext vs. Kontrolle in SRE

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Ein Gespräch mit Coburn Watson, Microsoft (ehemals Netflix) und David N. Blank-Edelman

David: In der Zeit, in der wir uns kennen, hatten wir das Vergnügen, über eine Menge Dinge zu sprechen. Eines der interessantesten Dinge, über die ich von dir gehört habe, ist eine Art von SRE, die sich auf die Bereitstellung von Kontext konzentriert, anstatt Prozesse zu nutzen, die sich auf die Kontrolle konzentrieren (die häufigste Art, SRE zu praktizieren). Können wir das näher erläutern? Kannst du erklären, was du unter Kontext und Kontrolle verstehst und was ein gutes Beispiel für beides wäre?

Coburn: Ich verstehe unter Kontext die Bereitstellung zusätzlicher, relevanter Informationen, die es jemandem ermöglichen, die Beweggründe hinter einer bestimmten Anfrage oder Aussage besser zu verstehen. Auf der höchsten Ebene wäre der verfügbarkeitsbezogene Kontext, wie er bei Netflix mit einem Entwicklungsteam geteilt wird, die trendmäßige Verfügbarkeit ihrer Microservices und wie diese mit dem gewünschten Ziel zusammenhängt, einschließlich der Verfügbarkeit nachgelagerter Abhängigkeiten. Mit diesem domänenspezifischen Kontext hat ein Entwicklungsteam die Verantwortung (und den Kontext), die notwendigen Schritte zur Verbesserung seiner Verfügbarkeit zu unternehmen.

In einem kontrollbasierten Modell kennt ein Team das Ziel der Verfügbarkeit seiner Microservices, aber wenn sie dieses Ziel verfehlen, kann es zu einer Bestrafung kommen. Diese Maßnahme könnte darin bestehen, dass ihnen die Möglichkeit genommen wird, Code in die Produktion zu bringen. Bei Netflix bevorzugen wir das erste Modell, indem wir uns über die Verfügbarkeit der Microservices austauschen und dann bei Bedarf mit den Teams zusammenarbeiten, um die Verfügbarkeit zu verbessern.

Die Herausforderung besteht darin, sicherzustellen, dass den Teams ausreichend Kontext zur Verfügung gestellt wird. Wenn jemand bei Netflix eine nicht optimale betriebliche Entscheidung trifft, ist die erste Frage, die man sich stellen muss, ob diese Person genügend Kontext hatte, um eine bessere Entscheidung zu treffen. Oft stellt das SRE-Team fest, dass eine Beeinträchtigung der Verfügbarkeit darauf zurückzuführen ist, dass dem Team nicht genügend Kontext zur Verfügung gestellt wurde, vor allem in Bezug auf die Zuverlässigkeit. Das sind die Lücken, die wir als SRE-Team zu schließen versuchen, um die Gesamtverfügbarkeit zu verbessern.

In einer sehr großen Organisation kann es eine Herausforderung sein, genügend Kontext bereitzustellen, damit die Mitarbeiter allein aufgrund des Kontexts die gewünschten Verfügbarkeitsziele für ihre Dienste erreichen können. In Organisationen dieser Größenordnung musst du oft auf weitere Prozesse zurückgreifen, um deine Verfügbarkeitsziele zu erreichen. Ein Beispiel dafür ist das Fehlerbudgetmodell von Google.¹ Ein anderer Fall für ein stärker kontrollbasiertes Modell ist, wenn Leben auf dem Spiel stehen. Wenn jemand häufig unsichere Software für ein Flugzeug-Autopilotsystem schreibt, hat diese Person (und das Unternehmen) wahrscheinlich eine sehr geringe Toleranz für einen hauptsächlich kontextbasierten Ansatz. Sie wollen sich nicht zusammensetzen und herausfinden, wie sie ihre Verfügbarkeit durch zusätzlichen Kontext verbessern können, wenn Flugzeuge vom Himmel fallen. Jede SRE-Organisation muss selbst bestimmen, wie viel Risiko sie eingehen kann, um den Spagat zwischen einem kontext- und einem kontrollbasierten Modell zu schaffen.

Ich glaube, es gibt einen Unterschied zwischen Informationen und Kontext. Bei der Systemüberwachung können Informationen einfach ein Haufen Verfügbarkeitskennzahlen sein, die ich in ein Dashboard packe und per E-Mail an das Team schicke. Ein typischer Ingenieur, der eine solche E-Mail erhält, würde sie ignorieren, weil er 1) für das Schreiben der Geschäftslogik eines Dienstes zuständig ist und 2) nicht über das nötige Fachwissen verfügt, um die als Zeitreihen dargestellten Ressourcen- und Verfügbarkeitsmetriken zu verstehen.

Bei Netflix stehen uns Hunderttausende von Betriebskennzahlen zur Verfügung. Um ein kontextbezogenes Modell zur Verbesserung der Verfügbarkeit zu unterstützen, müssen wir die Daten mit spezifischem Fachwissen ausstatten. Dazu müssen wir die Informationen in ein Format umwandeln, das eine Geschichte über die Verfügbarkeit erzählt. Durch eine solche Umwandlung sind wir in der Lage, den Teams diesen Kontext bei Bedarf zur Verfügung zu stellen, damit sie messen können, ob sich die Verfügbarkeit eines bestimmten Microservices verbessert. Ein Beispiel: Eine wichtige Verfügbarkeitskennzahl ist die Erfolgsrate der von einem bestimmten Microservice abhängigen Dienste (gemessen auf der Client-Seite und aufgeschlüsselt nach Ursachen).

Mein Team ist nicht für die Verfügbarkeit verantwortlich, aber unsere Aufgabe ist es, sie mit der Zeit zu verbessern. Warum? Weil immer jemandem ein Reifen vom Auto platzen kann. Oft melden sich Teams und sagen: "Ich bin mir nicht ganz sicher, warum meine Verfügbarkeit gesunken ist; können wir darüber reden?" Bei der Untersuchung der Situation könnte sich herausstellen, dass jemand eine Client-Bibliothek modifiziert oder eine Timeout-Einstellung geändert hat. Wie bereits erwähnt, ist es wichtig, von dem Grundsatz auszugehen, dass die Menschen nicht fahrlässig handeln; ihnen fehlt nur der Kontext, um bessere Entscheidungen zu treffen. Wir dürfen auch nicht vergessen, dass die Systeme übermäßig komplex sein können und die Messlatte für die Vermeidung von Zwischenfällen zu hoch oder unnötig hoch ist. Ein Beispiel aus der letztgenannten Kategorie ist die Einstellung von statischen Timeouts in einem dynamischen System.

Obwohl ein kontextbezogenes Modell ideal ist, kannst du in Richtung der benötigten Kontrolle abdriften, wenn du siehst, dass ein Team wiederholt Zwischenfälle hat. Sie haben den gleichen effektiven Verfügbarkeitskontext wie andere Teams und trotzdem leidet ihre Verfügbarkeit weiter. In manchen Unternehmen erfolgt die Kontrolle in Form eines Verbots, Code in die Produktion zu geben, und dann kommen die Ingenieure natürlich zum Management, weil sie den Code in die Produktion geben müssen. Bei Netflix beginne ich das Gespräch mit einem technischen Leiter mit dem Satz "Du stehst auf meiner Liste", um die Erwartungen an die Serviceverfügbarkeit persönlich zu klären. Wenn es eine gemeinsame Sichtweise gibt, erwähne ich, dass sie viele Funktionen entwickeln, aber nicht die notwendigen Änderungen vornehmen, um die Verfügbarkeit zu verbessern. Zum Schluss frage ich: "Wie bekommen wir die auf deine Liste?" Meiner Meinung nach ist das das Ausmaß an Kontrolle, das ich wirklich will. Ich habe das Glück, in einem Unternehmen zu arbeiten, in dem es reife Mitarbeiter gibt, die die Bedeutung der Verfügbarkeit für das Unternehmen erkennen und entsprechende Prioritäten setzen. Ich finde, dass diese Art von Diskussion in der Regel die Nadel in die richtige Richtung lenkt.

Bevor ich Kontext gegen Kontrolle als eine Utopie hinstelle, die jeder erreichen kann, erinnere dich daran, dass wir ein Unternehmen führen, in dem bei einem Ausfall vielleicht keine Ströme geliefert werden. Bei uns fallen keine Flugzeuge vom Himmel oder die Herzmaschinen von Menschen bleiben stehen. Das gibt uns mehr Flexibilität, wenn es um die Frage geht, wo wir auf dem Spektrum zwischen Kontext und Kontrolle stehen.

David: Bedeutet das, dass ein kontextbasierter Ansatz in kleineren Maßstäben funktioniert, aber in größeren Maßstäben nicht so gut?

Coburn: Ich glaube, die "Größenordnung", in der Kontext über Kontrolle funktioniert, hat wenig mit der Größe der Produktionsumgebung oder des Kundenstamms zu tun. Es geht vielmehr um die Größe der Organisation und die Art und Weise, wie sie zwischen den Teams arbeitet. Wenn ein Unternehmen wächst, kann die effektive Nutzung von Kontext für die Verfügbarkeit eine Herausforderung sein. Ein wichtiger Faktor kann sein, dass mit dem Wachstum des Unternehmens weniger persönliche Kommunikation oder Zeit für persönliche Gespräche zur Verfügung steht.

Bei Netflix habe ich den Luxus, dass sich alle Ingenieurteams, mit denen ich zu tun habe, auf einem Campus befinden. Ich kann mit jedem Manager bei Netflix einen Kaffee trinken. Ich habe bei großen Unternehmen wie HP gearbeitet, deren Teams auf der anderen Seite des Globus sitzen. In einer solchen globalen Situation bekomme ich immer noch einen angemessenen Kontext, aber es erfordert mehr Arbeit, diesen Kontext effektiv zu vermitteln. Ich gehe davon aus, dass ein Unternehmen, das mit Kontrolle anfängt, vor allem deshalb so viel Spaß daran hat, mit Prozessen und Kontrolle zu führen (unabhängig von der Größe).

David: Spielt die Infrastruktur eine Rolle bei der Zuverlässigkeit im Zusammenhang mit dem Kontext?

Coburn: Wir sind der Meinung, dass wir mit unserem Push-Modell sehr zuverlässig sind, weil wir von Natur aus unveränderlich sind. Ich glaube, wir haben alle schon in Unternehmen gearbeitet, in denen wir ein Upgrade durchgeführt haben, das sich dann als schlecht herausstellte, und wir haben die ganze Nacht damit verbracht, die Seite wieder zum Laufen zu bringen, weil der Patch nicht funktioniert hat. Wenn wir neuen Code in die Produktion einführen, führen wir keine Upgrades durch, sondern stellen einfach eine neue Version neben die aktuelle Codebasis. Das ist das Rot/Schwarz oder Blau/Grün - wie auch immer die Leute es in ihrem Unternehmen nennen. Die neue Version des Codes wird eingeführt, und wenn etwas kaputt geht, nehmen wir es einfach wieder heraus und machen sofort ein Rollback, oder wir machen gar nicht erst mit der vollständigen Einführung weiter. So verkürzt sich die Wiederherstellung von Stunden auf Minuten.

Obwohl wir unveränderlichen Code einsetzen, haben wir auch so genannte Fast Properties. Das bedeutet, dass wir in die Produktion gehen können, um später eine Anwendungseigenschaft dynamisch zu aktualisieren. Da dies unser unveränderliches Modell durchbricht, aber oft erforderlich ist, wird diese Möglichkeit übermäßig genutzt und führt zu Produktionsproblemen. Ähnlich wie bei anderen häufigen Problemen in der Produktion suchen wir, wenn wir sehen, dass ein Team oder eine Gruppe von Teams über das Problem der dynamischen Eigenschaftsverwaltung stolpert, nach Möglichkeiten, das Risiko durch verbesserte Werkzeuge zu beseitigen. In unserer Produktionsumgebung verwenden wir jetzt Spinnaker, unsere Continuous-Delivery-Plattform, um gestaffelte Rollouts von dynamischen Eigenschaften zu verwalten, um den Radius der Explosion zu minimieren und Probleme frühzeitig zu erkennen. Wir bezeichnen diese allgemeine Strategie als "Leitplanke".

Selbst wenn wir das getan haben, ändern die Teams manchmal immer noch etwas manuell, anstatt eine schnelle Property Pipeline zu nutzen, und machen die Produktion kaputt. Wenn das noch einmal passiert, sagen wir: "OK, sie haben die Botschaft offensichtlich nicht verstanden. Wir müssen uns mit ihnen treffen und ihnen sagen: "Bitte drückt diesen Knopf nicht". Wir versuchen um jeden Preis, den Knopf nicht wegzunehmen, aber irgendwann werden wir es wohl tun.

David: Das wirft eine Frage zu Feedbackschleifen auf. Es hört sich so an, als ob einige deiner Rückmeldungen lauten: "Ist die Website abgestürzt?", "Hat sich etwas positiv entwickelt?" oder in Bezug auf Geld: "Hat es sich so negativ entwickelt, wie du es wolltest?" Gibt es einen direkteren Weg, um von den Menschen zu erfahren, ob sie den benötigten Kontext erhalten haben, als das System in einer Blackbox zu beobachten und zu sehen, ob sich die Indikatoren, die du betrachtest, verändert haben?

Coburn: Das ist eine der Entwicklungen, die wir gemacht haben, als unser Unternehmen gewachsen ist. Bei Netflix haben wir wahrscheinlich 2.000 Ingenieure, und die decken alle verschiedenen Produktbereiche ab. Ich baue zum Beispiel eine interne Benutzeroberfläche für Tools, eine Kodierungs-Engine, einen Infrastruktur-Stack oder etwas, das dir bessere Empfehlungen gibt. Einige dieser Aufgaben haben einen größeren Einfluss auf die Verfügbarkeit für den Kunden als andere. Rein rechnerisch können wahrscheinlich 50 % unserer Ingenieurteams an einem bestimmten Tag in der Produktion tun, was sie wollen, ohne dass dies die Verfügbarkeit unserer Dienste in irgendeiner Weise gefährdet.

Anfangs sind wir in der Halle herumgelaufen und haben mit der virtuellen Pfanne geklopft und geschrien: "Hey, unsere Verfügbarkeit ist bei drei Neunen; das ist ein Problem!" Das Problem ist, dass es eine sehr diffuse Botschaft ist und 50 % der Leute sagen: "Okay, toll, ihr sagt, dass die Verfügbarkeit nicht gut ist, aber was kann ich dagegen tun, da meine Dienste die Verfügbarkeit nicht beeinflussen können?"

Dann änderten wir unsere Botschaft und konzentrierten uns auf die Teams, die sich tatsächlich auf die Verfügbarkeit auswirken, also auf die anderen 50% der Bevölkerung. Jetzt erreicht unsere Nachricht über die Serviceverfügbarkeit zumindest die richtige Zielgruppe. Der nächste Schritt ist der Trichter-Kontext, der für jedes Technikteam spezifisch ist und es ihnen ermöglicht, zu beurteilen, ob sie eine unterdurchschnittliche Verfügbarkeit haben.

Aber es ist nicht immer einfach, herauszufinden, wem man diese Informationen zur Verfügung stellen kann. In einer Microservice-Architektur gibt es vielleicht mehr als 40 Teams, die zu einem bestimmten Zeitpunkt Microservices betreiben, was die Verfügbarkeit auf dem kritischen Pfad des Dienstes beeinflussen kann. Wenn wir die Verfügbarkeit am Rande unseres Dienstes messen und feststellen, dass ein Zehntel von 1 % der Nutzer/innen in einer bestimmten Stunde keine Filme abspielen konnte, ist es ziemlich schwierig herauszufinden, welches Team tatsächlich für den Ausfall verantwortlich war. Noch schwieriger ist es, weil der Ausfall in vielen Fällen von außen verursacht wurde. Denk zum Beispiel an eine Online-Spieleplattform, die verfügbar sein muss, um einen Titel auf dem Dienst zu spielen. In diesem Fall muss ich mich vielleicht an das UI-Team von Netflix wenden, das von diesem Dienst abhängt, und herausfinden, ob sie eine Ausfallsicherheit für den Ausfall des externen Anbieters schaffen können (was wir getan haben).

Ich finde es hilfreich, wenn du dich innerhalb deines Unternehmens über die Begriffe "Verfügbarkeit" und "Zuverlässigkeit" im Klaren bist. In Analogie dazu, wie wir diese Begriffe bei Netflix im Zusammenhang mit unserem Streaming-Dienst verwenden, beziehe ich mich auf ein Festplatten-Array, das Teil eines Storage-Area Networks sein könnte. Wenn das Disk-Array den Dienst repräsentiert, stellen die zugrunde liegenden Festplattenlaufwerke im Array Microservices dar. Bei der Planung des Disk-Arrays wird berücksichtigt, dass einzelne Laufwerke fehlschlagen können, aber das Array sollte trotzdem funktionieren und Daten bereitstellen und aufbewahren. Mit diesem Modell würdest du die Verfügbarkeit als den Prozentsatz der Zeit berechnen, in der das Festplatten-Array (in meiner Welt der Netflix-Streamingdienst) in der Lage ist, einem Kunden einen Dienst zu erbringen. Die Häufigkeit, mit der die Laufwerke im Array fehlschlagen, steht für die Zuverlässigkeit des Laufwerks (in meinem Fall ein Microservice).

Ähnlich wie bei Festplattenkonfigurationen (RAID-Konfiguration, Caching usw.) kannst du in einer Microservice-Architektur Betriebsmuster anwenden, um die Gesamtverfügbarkeit des Dienstes im Hinblick auf mögliche Microservice-Ausfälle zu verbessern. Ein Beispiel dafür ist das Hystrix-Framework von Netflix, das auf dem Bulkhead-Muster basiert und "Schaltkreise" zwischen Microservices öffnet, wenn ein nachgelagerter Microservice fehlschlägt. Das Framework dient als Ausweichlösung, wenn es möglich ist, den Endnutzern weiterhin Dienste zur Verfügung zu stellen.

Zusammenfassend lässt sich sagen, dass das Festlegen und Messen von Zuverlässigkeitszielen auf Microservice-Ebene es dir ermöglicht, die gewünschte Gesamtverfügbarkeit des Dienstes zu erreichen. Die Begriffe Verfügbarkeit und Zuverlässigkeit werden in verschiedenen Unternehmen unterschiedlich verwendet, aber wir definieren sie im Rahmen unseres Betriebsmodells folgendermaßen.

David: Was für Informationen kannst du dem Team geben, die es umsetzen kann?

Coburn: Ein anderes Unternehmen, mit dem ich gesprochen habe, hatte einen Microservice-Verfügbarkeitsbericht. Sie untersuchten die Rate, mit der die Dienste erfolgreiche Anrufe an ihre Nachbarn weiterleiteten. Wenn ich ein Dienst bin, der Abonnenten- oder Mitgliederinformationen verarbeitet, und 30 Dienste mit mir kommunizieren, sollte mein wichtigstes Maß für die Verfügbarkeit die Erfolgsrate meiner Abhängigkeiten sein. Oftmals konzentrieren sich Teams auf die Sichtweise ihrer Dienste, dass sie erreichbar sind und funktionieren. Das ist zwar keine Garantie dafür, dass die Anfragen erfolgreich und in der gewünschten Geschwindigkeit bearbeitet werden, aber es kommt auf die Maßnahmen an.

Uns gefiel das Modell des anderen Unternehmens und wir überlegten, wie wir es auf unsere eigene Infrastruktur anwenden könnten. Glücklicherweise haben wir ein gemeinsames IPC-Framework [Interprozesskommunikation] und wir haben Metriken rund um Hystrix und andere Befehle, die die Rate der erfolgreichen Aufrufe eines Clients (abhängiger Dienst) aufzeichnen. Wir fassen diese Informationen für alle unsere kritischen Microservices zusammen und vergleichen den Trend mit den vorherigen 30 Tagen. Dabei geht es nicht um Echtzeit, sondern eher um die Frage, ob es besser oder schlechter wird.

Nehmen wir an, ein Team besitzt drei Microservices und das Ziel ist, dass die Microservices eine Verfügbarkeit von vier Neunen für Anrufe von Kunden haben. Wenn diese Microservices über vier Neunen bleiben, erhält das Team nie eine E-Mail (Verfügbarkeitsbericht). Wenn die letzten 7 Tage im Vergleich zu den vorherigen 21 Tagen eine negative Abweichung aufweisen oder wenn die Microservices die vier Neunen nicht erreichen, wird ein Bericht an das Team geschickt. Der Bericht zeigt den Wochenverlauf in Form eines Balkendiagramms an. Grün bedeutet, dass du das Ziel für eine bestimmte Woche erreichst. Rot oder gelb bedeutet, dass du das Ziel nicht erreichst. Gelb bedeutet eine Verbesserung gegenüber der Vorwoche, rot eine Verschlechterung. Wenn du auf einen Balken im Diagramm klickst, erhältst du einen detaillierten Bericht, der für das gesamte Fenster die Aufrufraten der vorgelagerten (Client-)Dienste, die mit dem Microservice kommunizieren, und die Verfügbarkeit dieser Aufrufe anzeigt. Auf der rechten Seite werden die Aufruf- und Erfolgsraten der nachgelagerten Dienste angezeigt, was hilfreich ist, da die Verfügbarkeit des Microservices durch die nachgelagerten Dienste beeinträchtigt werden kann. Wir nennen diese interne Implementierung das "Microservice Availability Scorecard Framework". An diesem Punkt hat das SRE-Team (in Zusammenarbeit mit Data Analytics) einem Team Informationen über die Microservices, die es besitzt, und insbesondere über die Microservice-Verfügbarkeit für abhängige Client-Services zur Verfügung gestellt, unabhängig von der Verfügbarkeit der Netflix-Services. Diese Informationen sollten sehr nützlich sein. Wenn Dashboards ständig an Ingenieure weitergegeben werden, können sie relativ schnell aufhören, sie zu betrachten. Die SRE-Lösung bei Netflix besteht darin, eine Scorecard nur dann zu pushen, wenn sich etwas ändert, auf das ein Team achten sollte.

David: Das klingt also ziemlich reaktiv, oder? Du schickst ihnen eine Scorecard, weil du möchtest, dass etwas, das bereits passiert ist, in Zukunft anders wird. Was ist die proaktive Seite davon? Wie hilfst du jemandem, der versucht, eine gute Entscheidung zu treffen, lange bevor er eine Scorecard bekommt?

Coburn: Eine gute Analogie für die Scorecard ist die Meldung auf dem Armaturenbrett deines Autos: "Dein rechter Vorderreifen verliert an Druck". Sie sagt dir nicht, was du dagegen tun sollst, sondern informiert dich nur darüber, dass ein Trend in die falsche Richtung geht. Als ich darüber nachdachte, wie ich die Menschen am besten informieren kann, nutzte ich die Erfahrungen aus meiner früheren Arbeit im Leistungsbereich, wo wir nicht so sehr darauf bedacht sind, große Leistungsabweichungen zu erkennen. Wir haben Kanarienvögel, die ein System auf signifikante Abweichungen untersuchen. Wenn also die CPU-Nachfrage auf einen Schlag um 20 % ansteigt, gehen die Alarme los. Langfristig gesehen ist der Anstieg von fünf Millisekunden pro Woche über einen Zeitraum von sechs Monaten das, was dich am meisten interessiert. Am Ende dieses Zeitraums sagst du: "Wow, ich habe plötzlich dreimal so viel Kapazität für diesen Dienst; was ist passiert?" Die Aufgabe der Scorecard ist es, auch kleinere Abweichungen zu erfassen, um dieses langsame und gefährliche Abdriften zu vermeiden. Bei der Zuverlässigkeit verhält es sich ähnlich: Wenn du die kleinen Abweichungen ignorierst und es versäumst, sie proaktiv anzugehen, wartest du nur auf den großen Ausfall.

David: OK, was tust du also aus einer kontextuellen Perspektive heraus, damit die Leute im Moment die richtigen Entscheidungen treffen können? Theoretisch bedeutet das Konzept des Fehlerbudgets, dass ich zu jedem Zeitpunkt T eine Möglichkeit habe, zu entscheiden, ob ich etwas tun oder lassen soll, z. B. eine neue Version einführen. Was ist die kontextbezogene Version davon? Ist die Theorie, dass Menschen synchron auf eine Scorecard schauen und dann die richtige Entscheidung treffen?

Coburn: Wenn jemand ein Problem hat, das sich erheblich auf die tatsächliche Produktionsverfügbarkeit auswirkt, wie z. B. ständige Produktionsstörungen, die dazu führen, dass Kunden keine Inhalte streamen können, dann ist der Kontext der Microservice Availability Scorecard wahrscheinlich nicht der richtige Weg, um dieses Problem zu lösen. In diesem Fall haben sie wahrscheinlich den Bericht erhalten, aber nicht danach gehandelt. Um dieses Problem zu lösen, muss man sich in einem Raum versammeln und einen Weg nach vorne finden. Das heißt aber nicht, dass sie aufhören sollten, Code zu veröffentlichen, denn viele andere Dienste hängen von ihnen ab.

Zu deiner Frage nach mehr Echtzeit-Inputs, die den Technikern helfen, im Moment bessere Einsatzentscheidungen zu treffen: Wir bemühen uns, die Informationen in die Tools zu integrieren, mit denen sie arbeiten. Spinnaker zeigt jetzt Verfügbarkeitstrends im Cluster an (der AWS-Begriff lautet Autoscaling Group) und der Techniker hat sie direkt vor Augen, wenn er über die Benutzeroberfläche eine Änderung vornimmt.

Wenn es darum geht, die Verfügbarkeit kontinuierlich zu verbessern, gibt es zwei Hauptkategorien: die Vermeidung aller Vorfälle, egal welcher Art, und ein bestimmtes Fehlermuster, das einen Vorfall oder wiederholte Ausfälle verursacht.

Wenn sie ein Problem haben, bei dem sie immer wieder eine Reihe von Entscheidungen treffen, die zu produktionsbeeinträchtigenden Vorfällen führen, ist ein von Menschen erstellter Bericht erforderlich und nicht ein vom System erstellter. Bei Netflix ist das Core SRE-Team nicht dafür zuständig, Microservice-spezifische Probleme zu beheben, sondern es wird als "zentrales Nervensystem von Netflix" betrachtet. Um die Analogie zum zentralen Nervensystem noch ein bisschen weiter zu führen, ist dies das einzige Team bei Netflix, das alle Fehler sieht, egal ob es sich um externe, interne, CDN [Content Delivery Network], Netzwerk usw. handelt, und dementsprechend die Verantwortung hat, zu entscheiden, welche Teams zu erreichen und einzuschalten sind.

David: Wenn du deine Gruppe als das Nervensystem von Netflix betrachtest, wie funktioniert dann die Weitergabe von Informationen in der gesamten Organisation, damit die Menschen in einem Teil von den anderen Teilen lernen können (entweder eine gute Vorgehensweise oder eine schlechte Erfahrung nicht zu wiederholen)?

Coburn: Je nach dem spezifischen Mangel im Bereich des operationellen Risikos, den wir beheben möchten, haben wir mehrere Möglichkeiten, die bewährte Methode anzuwenden: Wir können die notwendigen Erweiterungen in unsere operationellen Tools (z. B. Spinnaker, Kanarienvogelanalyse) einbauen, um sie nahtlos allen Teams zugänglich zu machen, oder wir können die vorgeschlagene Änderung über einen monatlich erscheinenden Verfügbarkeits-Newsletter bekannt machen. In einigen Fällen handelt es sich bei der vorgeschlagenen bewährten Methode um eine der Erweiterungen, die bereits in das Tooling integriert wurden.

Beides sind Methoden, die helfen, die Verfügbarkeit insgesamt zu verbessern.

Einige Änderungen, die wir in die Werkzeuge einbauen, könnten als Leitplanken bezeichnet werden. Ein konkretes Beispiel ist ein zusätzlicher Schritt bei der Bereitstellung von Spinnaker, der erkennt, wenn jemand versucht, die gesamte Cluster-Kapazität zu entfernen, während er noch erhebliche Mengen an Datenverkehr aufnimmt. Diese Leitplanke hilft, die Aufmerksamkeit auf eine möglicherweise gefährliche Aktion zu lenken, von der der Ingenieur nicht wusste, dass sie riskant ist. Dies ist eine Methode des "just in time" Kontextes.

David: Was ist mit Fällen, in denen jemand eines eurer Tools wie Hystrix auf eine Art und Weise verwendet, die völlig in Ordnung ist, aber die Erfahrung hat gezeigt, dass diese Art und Weise zu negativen Ergebnissen führt? Es ist ja nicht so, dass ihr das Tool ändern wollt, denn das Tool ist einfach gut. Wie gibst du solche Erfahrungen in der Organisation weiter, wenn du diese Lektion gelernt hast? Das klingt so, als wären die Verfügbarkeitsberichte eines der Beispiele dafür?

Coburn: Das ist richtig. Der Verfügbarkeitsbericht ist tatsächlich schwierig zu interpretieren. Sobald du ihn erhältst, musst du an drei bis vier strategischen (und oft versteckten) Stellen des Berichts klicken, um an verwertbare Daten zu gelangen. Das war eine ziemlich große Hürde für die Akzeptanz des Berichts. Deshalb haben wir ein vierminütiges Video erstellt, das als Einführungsvideo für die Nutzung des Berichts dient. Wenn die Leute den Bericht erhalten, heißt es: "Bitte sehen Sie sich dieses vierminütige Video an, um zu verstehen, wie man diesen Bericht verwendet. Das hat zwar nicht viel gebracht, aber die Handlungsfähigkeit des Berichts für diejenigen, die sich die Zeit genommen haben, ihn zu nutzen, deutlich verbessert.

David: Lass uns über die Grenzen von Kontext und Kontrolle sprechen. Glaubst du, dass ein kontextbasiertes System auch in einem Umfeld funktioniert, in dem das Produkt und die Kennzahlen dafür komplexer sind als bei Netflix? Ist es die Einfachheit des Netflix-Produkts, die es für dich so gut funktionieren lässt?

Coburn: Zunächst einmal möchte ich darauf hinweisen, dass der Netflix-Service (in Bezug auf seine interagierenden Teile) insgesamt genauso komplex ist wie in jedem anderen Unternehmen. Es gibt eine Reihe von Faktoren, die es ermöglichen, dass der Kontext bei Netflix viel effektiver ist als bei anderen Unternehmen. Das hängt direkt mit der geringen Komplexität der technischen Organisation und der Struktur unseres Dienstes zusammen. Im Folgenden sind einige der Schlüsselfaktoren aufgeführt:

• Bei uns sitzen alle Ingenieure an einem Ort. Gemeinsame technische Grundsätze sind leicht zu vermitteln und zusätzliches Stammeswissen über bewährte Methoden wird implizit vermittelt und diskutiert.

• Wir haben eine dominante Version der Software, die in einer bestimmten Region zu einer bestimmten Zeit läuft. Außerdem haben wir die Kontrolle über diesen Software-Stack und können ihn ändern, wann immer wir wollen (er wird nicht an die Kunden ausgeliefert, mit Ausnahme der Geräteanwendungen).

• Wir haben einen Service, bei dem die Leute nicht sterben, wenn er kaputt geht.

• Wir haben ein wenig Spielraum und wir haben ein SRE-Team, das bereit ist, einen Haufen Kugeln einzustecken, wenn die Verfügbarkeit schlechter wird, und zu sagen: "Meine Aufgabe ist es, das zu beheben."

Was den letzten Punkt angeht, kann es für die Zuverlässigkeitsorganisation eine schwierige Situation sein zu sagen, dass sie für die Verbesserung der Verfügbarkeit verantwortlich ist, aber gleichzeitig nicht die volle Kontrolle über die Faktoren hat, die die Verfügbarkeit beeinflussen. Viele Leute fühlen sich nicht wohl dabei, wenn sie sagen, dass sie für die Verbesserung von etwas verantwortlich sind, über das sie nicht unbedingt die absolute Kontrolle haben.

Bei einem Unternehmen, das ein Produkt in die Praxis umsetzt (z. B. Software für selbstfahrende Autos), funktioniert dieses Modell vielleicht nicht. Du würdest nicht warten wollen und sagen: "Wow, das Auto ist von der Straße abgekommen. Das war ein Fehler. Wer hat das geschrieben? Dann machen wir es nächstes Jahr richtig." Im Gegensatz dazu haben wir in unserem Arbeitsbereich viel Spielraum, um den Kontext über die Kontrolle zu stellen, denn wir setzen keine Menschenleben aufs Spiel und können schnell Änderungen an der gesamten Produktumgebung vornehmen. Ich denke, dass es Situationen gibt, in denen Unternehmen mit der Skalierung beginnen, aber im Laufe der Zeit zu mehr Kontrolle übergehen, wenn die Bedürfnisse der Kunden und die Zuverlässigkeit dies rechtfertigen. Man könnte diese Perspektive verallgemeinern und sagen, dass man sich irgendwann dem anderen Ende des Spektrums annähert, mit dem man begonnen hat, wenn auch nur ein bisschen.

David: In der Vergangenheit haben wir ein wenig über Kontext und Kontrolle aus der Perspektive der technischen Investitionen gesprochen. Kannst du etwas mehr dazu sagen?

Coburn: Ich denke an vier Hauptdimensionen: Innovationsrate, Sicherheit, Zuverlässigkeit und Effizienz (Infrastruktur/Betrieb). Je nachdem, wie dein Unternehmen strukturiert ist, kannst du eine oder mehrere dieser Dimensionen besitzen. Auch wenn du nicht für eine bestimmte Dimension verantwortlich bist, können die Entscheidungen, die du in deinem eigenen Bereich triffst, erhebliche Auswirkungen auf die anderen haben. Ich bin in einer Situation, in der mir mindestens zwei davon gehören: Zuverlässigkeit und Effizienz, weil ich auch für die Kapazitätsplanung zuständig bin. Wenn ich darüber nachdenke, wie stark ich die Teams zur Verbesserung dieser Dimensionen drängen will, möchte ich so wenig wie möglich versuchen, die anderen Dimensionen (Innovationsrate, Sicherheit) zu beeinträchtigen. Wenn wir uns dieses Modell vor Augen halten, können wir als SRE-Organisation unsere Fragen an andere Ingenieurteams mit mehr Bedacht stellen.

In diesem Zusammenhang gehen wir auch explizit Kompromisse ein, um eine Dimension auf Kosten einer anderen zu verbessern. Es gibt Fälle, in denen wir einen bestimmten Microservice deutlich ineffizienter (überprovisioniert) betreiben, um die Innovationsrate oder die Zuverlässigkeit zu erhöhen. Wenn wir einen Dienst haben, der wegen des hohen Verkehrsaufkommens mit doppelt so viel Headroom betrieben werden muss, ist es mir egal, ob mich das zusätzlich Zehntausende von Dollar pro Jahr kostet, denn ich brauche nur einen großen Ausfall, um diese Menge an technischer Arbeit/Zeit schnell zu verbrauchen.

David: OK, und wie bringst du das mit Kontext und Kontrolle in Verbindung?

Coburn: Nehmen wir als Beispiel die Kontrolle: Ich nehme jemandem die Möglichkeit, Code zu pushen, weil ich diese Dimension der Zuverlässigkeit erhöhen muss. Auf der einen Seite verhindert das kurzfristige Ausfälle, aber es verlangsamt die Innovation. Das Ziel ist es, mehr Kontext zu bieten, um zu vermeiden, dass andere Dimensionen zwangsweise verlangsamt werden, und den Eigentümer eines bestimmten Dienstes entscheiden zu lassen, für welche Dimension er unter Berücksichtigung seiner aktuellen Anforderungen optimieren möchte. Im Gegensatz dazu hat die Kontrolle eine viel binärere Wirkung auf andere Dimensionen.

David: Hat der Kontext einen positiven oder negativen Einfluss auf eine dieser Dimensionen? Kontrolle hat eindeutig einen Einfluss, wie du gerade erwähnt hast, aber was ist mit dem Kontext?

Coburn: Context hat einen starken Aufwärtstrend und eine Erfolgsgeschichte, zumindest in unserem Fall. In den letzten fünf Jahren hat sich unsere Kundenzahl versechsfacht, unser Streaming hat sich versechsfacht, unsere Verfügbarkeit hat sich jedes Jahr verbessert, die Zahl unserer Teams hat sich jedes Jahr erhöht, und unsere Innovationsrate ist jedes Jahr gestiegen. Und das, ohne die Verfügbarkeit durch Kontrolle zu verbessern, sondern vor allem durch die Verbesserung des Kontexts in Kombination mit der Verbesserung der Plattform, damit die Ingenieure weniger Zeit mit operativen Aspekten verbringen, die in ihrer Rolle nicht erforderlich sind (z. B. wie man Pipelines so konfiguriert, dass sie regional gestaffelte Pushs haben).

David: Wenn sich Kontrolle negativ auf diese Dimensionen auswirken kann, kann dann der Kontext einen ähnlichen negativen Effekt haben?

Coburn: Das kann sein, aber ich habe noch nicht erlebt, dass der Kontext, den wir den Teams zur Verfügung stellen, zu einem unerwünschten Verhalten führt, das die Verfügbarkeit beeinträchtigt. Ein Bereich, in dem dies ein Risiko darstellen kann, ist die Infrastruktureffizienz. Obwohl wir den Teams detaillierte Informationen über die Infrastrukturkosten zur Verfügung stellen, haben wir keine Cloud-Kostenbudgets und setzen sie auch nicht durch. Die Ingenieure setzen einfach die Infrastruktur ein, die sie brauchen, und erhalten jeden Monat einen Kostenbericht, der ihnen Aufschluss über ihre Kosten gibt. Vor diesem Hintergrund entschied sich ein Team, die Effizienz zu optimieren, indem es bei einem älteren und weniger zuverlässigen Instance-Typ blieb, der natürlich viel billiger war. Daraufhin kam es zu einem Ausfall, weil die Instanzen schlecht liefen und weniger zuverlässig waren und oft unterprovisioniert waren. In diesem Fall haben wir die Kosten im Blick gehabt, aber die Entscheidung fiel zu Gunsten der Effizienz aus und die Zuverlässigkeit wurde dadurch beeinträchtigt. Wir beschlossen, den Teams mitzuteilen, dass wir lieber weniger effizient arbeiten, als die Zuverlässigkeit zu gefährden, was unserer expliziten Priorisierung der Domain-Anliegen entsprach.

Mitwirkende Bio

Coburn Watson ist derzeit Partner in der Production Infrastructure Engineering Organisation bei Microsoft. Vor kurzem beendete er ein sechsjähriges Abenteuer bei Netflix, wo er die Organisation leitete, die für Standortzuverlässigkeit, Performance Engineering und Cloud-Infrastruktur zuständig war. Seine mehr als 20-jährige Erfahrung im Technologiebereich reicht von der Systemverwaltung über die Anwendungsentwicklung bis hin zur Zuverlässigkeit und Leistung großer Websites.

¹ Siehe Kapitel 4, "Service Level Objectives", aus Googles erstem Site Reliability Engineering Buch.