Umarmung der Ausfallzeit: Warum 99,999...% Verfügbarkeit nicht immer besser ist

Vor ein paar Wochen organisierten meine stets aktiven Kollegen Marco Mulder und Serge Beaumont ein nlscrum Meetup zum Thema "Combining Scrum and Operations" mit Vorträgen von Jeroen Bekaert und devopsdays-Organisator Patrick Debois. Leider war ich zu spät dran und konnte nur das Ende von Patricks gut vorgetragenem Vortrag mitbekommen, in dem er erklärte, wie Dev/ops zu Devops werden kann. Glücklicherweise lieferten die lebhaften Open Space-Diskussionen im Anschluss eine Fülle interessanter Einblicke, Kommentare und allgemeiner Denkanstöße. Ein wiederkehrendes Thema, das mir besonders auffiel, war die von vielen aus dem Bereich Operations mit Bedauern geäußerte Bemerkung, dass sie den Entwicklungsteams sehr gerne helfen und sich mit ihnen abstimmen würden, aber zwangsläufig immer zu sehr damit beschäftigt seien, die Produktionsumgebung am Laufen zu halten. Mit anderen Worten: Die Unterstützung bei der Vorbereitung neuer Versionen mag zwar wünschenswert sein, aber das Erreichen der Five Nines oder der SLA, zu der sich Operations verpflichtet ^hat1, wird immer an erster Stelle stehen. Das ist ein Trugschluss! In der Tat ist für mich eine der wichtigsten Erkenntnisse der "Devops-Mentalität", dass eine Betriebszeit von 99,999...% kein Selbstzweck ist, sondern ein Mittel zum Zweck: den größtmöglichen geschäftlichen Nutzen zu liefern. Und die höchstmögliche Verfügbarkeit anzustreben, ist vielleicht nicht der beste Weg dazu^!2

Stellen Sie sich beispielsweise vor, dass ein Tag Ausfallzeit in der Produktion 500.000 $ kostet und Sie eine neue Funktion veröffentlichen wollen, die schätzungsweise 1 Million $ pro Tag zusätzlich einbringt. Dann können Sie sich für jeden Tag, um den Sie die Freigabe beschleunigen können, fast zwei Tage Ausfallzeit leisten^!3 Der Punkt ist: Die Fähigkeit, eine stabile aktuelle Umgebung aufrechtzuerhalten, kann nicht unabhängig von der Fähigkeit, Änderungen schnell umzusetzen, betrachtet werden. Vielmehr müssen sie gegeneinander abgewogen werden, um festzustellen, welche Kombination wahrscheinlich den größten Nutzen bringen wird. Diese Entscheidung kann nur der Geschäftsinhaber oder der Kunde treffen. Und natürlich muss dieses Gleichgewicht ständig überwacht und im Lichte neuer Anforderungen und Erfahrungen aktualisiert werden.

Es gibt immer noch die Meinung, dass die Aufgaben und Zuständigkeiten von Entwicklern und Betriebsleitern so unterschiedlich sind, dass sie unmöglich vom Input des jeweils anderen profitieren können. Aber ganz gleich, ob es um die Auswirkungen der Platzierung von Knoten eines verteilten Systems in verschiedenen Segmenten des Produktionsnetzwerks geht oder darum, wie sich die Sharding- und Replikationsstrategien der Datenbank auf die Abfrageleistung auswirken, oder auch nur darum, welche Version (und welcher Hersteller!) der JVM und des Containers in der Produktion unterstützt wird, wenn die Anwendung live ^geht4 - die Entwickler brauchen den Input von Operations, und je früher, desto besser. Und nur die Entwickler können die internen Zustandsprüfungen, Debugging- und Tracing-Informationen, Integrationspunkte für Überwachungstools usw. hinzufügen, die den Unterschied zwischen einer fünfminütigen Problembehebung und einer Woche frustrierter Protokollsuche für das Supportteam ausmachen können. Es ist aufschlussreich zu sehen, wie schnell diese entscheidende, aber oft vernachlässigte Funktion einer Anwendung verbessert wird, wenn die Entwickler auch für den Support verantwortlich sind - in der Regel macht der erste Anruf um drei Uhr morgens einen großen Unterschied.5Es versteht sich von selbst, dass das akzeptable Gleichgewicht zwischen Stabilität und Veränderung von Kunde zu Kunde und von Anwendung zu Anwendung unterschiedlich ist. Eine global gemeinsam genutzte Infrastruktur kann hier zu Problemen führen, da es schwierig ist, die Anforderungen der anspruchsvollsten Anwendung zu erfüllen, ohne dass alle anderen den Preis dafür zahlen müssen.Mit anderen Worten: Modularität ist ein wichtiges architektonisches Ziel, und wenn Sie mit einer gemeinsam genutzten Infrastruktur arbeiten, sollte diese auf Ihre Anforderungen abgestimmt werden können. Amazons Dynamo und in der Tat die meisten Cloud- und verteilten Plattformen auf dem Markt sind ein Beispiel für diesen Trend. Eine detaillierte Diskussion der technischen Auswirkungen möchte ich jedoch auf einen späteren ^Blog6 verschieben. Mein Kollege Robert van Loghem und ich werden über dieses und verwandte Themen auch in unserem kommenden Webinarplug^! sprechen. Um auf das nlscrum-Meeting zurückzukommen: Die Botschaft, die ich mitnehmen konnte, war klar: Zwei unabhängige Einheiten, nämlich Entwicklung und Betrieb, einzurichten, ihnen gegensätzliche Ziele zu geben (auf der einen Seite Veränderungen herbeizuführen, auf der anderen Seite Stabilität zu gewährleisten) und von ihnen zu erwarten, dass sie sich gegenseitig bekämpfen, wenn der unvermeidliche Konflikt auftritt, ist nicht der beste Weg, um geschäftlichen Nutzen zu erzielen. Wir sollten versuchen, unsere Teams und Aktivitäten so zu organisieren, dass sie ein Gleichgewicht zwischen neuen Funktionen und laufenden Systemen herstellen, das für eine bestimmte Anwendung am besten geeignet ist. Und das können wir nur, wenn wir zuerst zum Kunden gehen, ihm erklären, dass es einen Kompromiss gibt, und gemeinsam daran arbeiten! Nachtrag: In der unerwartet langen Zeit, die ich gebraucht habe, um diesen Beitrag fertigzustellen, hat mein Kollege Gero Vermaas ein Kundenszenario beschrieben, das eine reale Version dieser Herausforderung enthielt. Es ist schön zu sehen, dass der Kunde das Konzept schließlich akzeptiert hat, hoffentlich mit den erwarteten positiven Ergebnissen!