Site Reliability Engineering: Software in Produktion betreiben

Keine Kommentare

In letzter Zeit hat Site Reliability Engineering (SRE) viel Aufmerksamkeit erregt. Mit SRE kamen Metriken wie Service-Level Objectives (SLO), Service-Level Indicator (SLI) und Error Budget auf. Ebenso widmet sich SRE stark dem Betrieb von Software in der Produktion. Aber die oben genannten Schlagworte beschreiben mehr oder weniger nur das, was Site Reliability Engineers ermöglicht, ihre Arbeit zu erledigen.
Es gibt noch ein weiteres Schlagwort: „production-ready“. Hier geht es mehr darum, was ein SRE oder Softwareentwickler tun kann, um die Software hinter den Metriken zu verbessern. Dieser Blog-Beitrag wird einen Blick darauf werfen, wie diese Schlagwörter zusammenwirken – und ob es nur Schlagwörter sind oder mehr dahintersteckt.

Die oben genannten Themen sind nicht nur Schlagwörter. Über sie wurden Bücher geschrieben. Es gibt die Google-SRE-Bücher und es gibt auch Bücher über produktionsreife Software:
Production-ready Microservices” von Susan Fowler und
Release It! — Design and Deploy Production-Ready Software” von Michael Nygard.

Abgesehen davon, dass es Schlagwörter sind, die Bücher füllen, helfen diese Konzepte, Software besser zu machen. Obwohl es um Microservices geht, gilt dies auch für Software, die auf Servern, als Funktionen oder auf Edge-Geräten läuft. Schauen wir uns also genauer an, worum es geht. Beginnen wir dazu mit zwei Beispielen, die für die meisten Anwendungen gültig sein sollten: Protokollierung und wiederholte Verbindungsversuche.

Protokollierung

Nehmen wir als Beispiel diese Fehlermeldung irgendwo in einem Protokoll:

Zeitüberschreitung der Verbindungsanfrage.

Falls sich deine Software mit nur einem Dienst verbindet, mag diese Meldung in Ordnung sein, nicht schön, aber in Ordnung. Sobald zwei oder mehr Backend-Dienste in der Software genutzt werden, tauchen Fragen auf. Welchen Host versuchst du zu erreichen? Welchen Port hast du verwendet? Nach welcher Zeit hast du die Zeitüberschreitung erhalten?
Diese Protokollnachricht ist hilfreicher:

Zeitüberschreitung beim Verbindungsversuch zu Host service.abc.de auf Port 12345 nach 100ms.

Auf den ersten Blick mag das 100-ms-Timeout seltsam erscheinen. Dies kann eine gültige Zeitüberschreitung sein, falls der konsumierte Dienst im selben Rechenzentrum ausgeführt wird. Es ist definitiv nicht gültig, wenn sich der Dienst auf der anderen Seite der Welt befindet. Bei diesem Beispiel stellen sich andere Fragen. Ist diese Zeitüberschreitung aufgrund einer Fehlkonfiguration aufgetreten? Blockiert eine Firewall die Verbindung? Oder ist das Backend nicht verfügbar? Zu diesen Fragen wäre man auch bei der ersten Log-Meldung gekommen, aber erst, nachdem auch die oben genannten Fragen beantwortet wären. Diese zusätzlichen Informationen in den Protokollen helfen also, wertvolle Zeit zu sparen und Nerven zu schonen.

Diese Log-Meldung führt direkt zu unserem nächsten Beispiel.

Wiederholte Verbindungsversuche

Falls kein Backend verfügbar ist, sollte die Software nicht nach dem ersten Versuch aufgeben. Vielleicht hat ein Load Balancer das Backend gewechselt oder ein Switch irgendwo auf dem Weg wurde neu gestartet. Einfach noch einmal versuchen. Nicht direkt, sondern nach einer kurzen Pause. Mit der Protokollmeldung des vorherigen Abschnitts könnte dies so aussehen:

... zu Host service... auf Port 12345 nach 100 ms. Versuche: 2/5

In den meisten Fällen muss man es nicht selbst umsetzen, z. B. hat es Google als HTTP-Client in Java implementiert. Es ist auch schön, diese Informationen über die Anzahl der Versuche hinzuzufügen oder dass der Client aufgegeben hat. Dies hilft bei der Fehlersuche.

Dies sind zwei gängige Beispiele. Wie du anhand der oben genannten Büchern erraten kannst, gehört mehr dazu, Software produktionsreif zu machen. Diese Beispiele sollen dir lediglich den Einstieg erleichtern, anstatt dich über das gesamte Thema aufzuklären.

Schon diese beiden kleinen Beispiele helfen der Software und noch mehr den Leuten, die die Software in der Produktion betreiben. Dazu später mehr.

Aber nicht alle Kapitel der Production-ready- oder SRE-Bücher gelten für jede Software. So muss etwa eine Backoffice-Versicherungssoftware nicht innerhalb von Sekunden von 100 auf 1000 Benutzer hochskaliert werden. Sie muss auch nicht einige Minuten später herunterskaliert werden. Aber es ist auch gut zu wissen, dass dies nicht notwendig ist. Daher ist es nützlich, auch solche Punkte zu dokumentieren.

Es gehört mehr dazu, Software in Produktion auszuführen

In diesem Artikel geht es jedoch um das Ausführen von Software in Produktion, nicht nur um produktionsreife Software. Es gehört also mehr dazu.

„Production-ready“ beschreibt meist die in die Software integrierte Funktionalität. Diese Funktionalität hilft, Situationen zu bewältigen, die während des Betriebes in Produktion auftreten. Um Software in der Produktion ausführen zu können, muss man sich auch um einige Infrastrukturen, Systeme und Prozesse rund um die Software kümmern.

Schauen wir uns noch einmal zwei Beispiele an: Sicherung/Wiederherstellung und Zertifikate.

Sicherung/Wiederherstellung

Stateless ist ein Schlagwort, das ich oben nicht erwähnt habe. Und obwohl du zustandslose Dienste anstreben solltest, hast du irgendwo in deiner Anwendung irgendeine Art von Zustand. Und dieser Zustand benötigt eine Sicherung.
Die Fragen, die sich hier stellen werden, sind:

  • Wie oft müssen die Daten gesichert werden?
  • Wie lange müssen die Backups aufbewahrt werden?

Diese Funktionalität wird nicht Bestandteil der Software sein, aber diese Fragen stellen sich früher oder später. Andernfalls kann ein Ausfall zu einem vollständigen Datenverlust führen. Dies ist z. B. GitLab schon vor einiger Zeit passiert. Wir sollten GitLab dafür nicht an den Pranger stellen, sondern eher dankbar sein, dass sie ein Postmortem darüber veröffentlicht haben, aus dem wir lernen können.

Zertifikate

Dein Dienst wird höchstwahrscheinlich über HTTPS zugänglich sein. Oder er greift über eine Art gesichertes Kommunikationsprotokoll auf andere Dienste zu. Daher sind einige Themen, die von der Software nicht abgedeckt werden, aber bei Nichtbearbeitung zu erheblichen Ausfallzeiten führen können, die folgenden:

  • Benötigt die Software ein Client-Zertifikat?
  • Werden Zertifikate automatisch verlängert?
  • Sind selbst signierte Zertifikate beteiligt?

Abhängig von den Antworten auf diese Fragen benötigst du möglicherweise zusätzliche Prozesse rund um die Software, damit sie reibungslos funktioniert. Andernfalls können Dinge wie diese passieren:
SRE: nicht produktionsreifes Zertifikat

Man war so freundlich, dies in einem öffentlich zugänglichen Ticket zu diskutieren. Und wie man im Screenshot sehen kann, erlaubt der Browser nicht einmal, fortzufahren. Dieses defekte Zertifikat ist also eigentlich ein Dienstausfall. Vielen Dank an Jenkins für die öffentliche Diskussion und die Möglichkeit, daraus zu lernen.

Aber – warum?

Nehmen wir die entgegengesetzte Perspektive ein. Was könnte möglicherweise schiefgehen?

Doch zunächst eine Definition.
Manche Leute haben eine sehr spezifische Definition dessen, was ein verteiltes System ist. Für diesen Artikel verwenden wir eine nicht so strenge Definition:

Ein verteiltes System ist nach der Definition von Andrew S. Tanenbaum ein Zusammenschluss unabhängiger Computer, die sich für den Benutzer als ein einziges System präsentieren.

https://de.wikipedia.org/wiki/Verteiltes_System

Die Irrtümer

Nach der Definition im vorherigen Absatz ist also fast jedes System, das heutzutage entwickelt wird, ein verteiltes System. Werfen wir in diesem Zusammenhang einen Blick auf die Irrtümer bezüglich verteilter Systeme:

Das Netzwerk ist ausfallsicher.
Die Latenzzeit ist gleich null.
Der Datendurchsatz ist unbegrenzt.
Das Netzwerk ist sicher.
Die Netzwerktopologie wird sich nicht ändern.
Es gibt immer nur einen Netzwerkadministrator.
Die Kosten des Datentransports können mit null beziffert werden.
Das Netzwerk ist homogen.

https://de.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

Eine detailliertere Erklärung zu jedem Irrtum findest du in diesen Blog- Artikeln.

Manche erscheinen offensichtlich, manche sind unvermeidlich. Aber du kannst einige dieser Irrtümer dank produktionsreifer Software umgehen. Das ist einer der Gründe, warum “production-ready“ deine Software robuster macht.

Allerdings sind nicht alle Irrtümer auszuschließen. Je komplexer die Systeme werden, desto mehr gilt folgendes Zitat:

… complex systems run as broken systems. The system continues to function because it contains so many redundancies and because people can make it function, despite the presence of many flaws.

https://how.complexsystems.fail/#5

Kurzer Umweg

Hier kommt die Beobachtbarkeit (Observability) einer Software ins Spiel. Da immer etwas kaputt geht, möchtest du wissen:

  • Was ist kaputt?
  • Wo ist der defekte Teil im System?
  • Wie wirkt sich das auf die Nutzer aus?

Aber das ist bei mehr als einer Handvoll Büchern ein ganz anderes Thema.

Die Irrtümer und Public Clouds

Wichtig ist, dass du dir dieser Irrtümer bewusst bist und deine Software entsprechend vorbereitest. Allerdings befinden sich nicht alle Teile unter deiner Kontrolle. Falls deine Software in einer öffentlichen Cloud ausgeführt wird, bieten die Cloud-Anbieter Einblicke, wie du deine Dienste auf ihren Plattformen robuster machen kannst:

Die Amazon Builders‘ Library
Azure-Anwendungsarchitekturleitfaden
Google Cloud – Cloud Architecture Center

Wie bereits oben erwähnt, kann dieser Artikel nicht das gesamte Thema abdecken. Er kann nur einige Hinweise geben, um dir den Einstieg zu erleichtern.

Fazit

Basierend auf unserer Erfahrung mit dem Betrieb von Software in der Produktion bieten wir Production-Readiness-Review-Workshops (ein anderer Begriff aus dem SRE) zu diesen Themen an. Sie richten sich nicht speziell an diejenigen, die die Software in der Produktion ausführen. Alle, die Software in Produktion betreiben, werden an Antworten auf o. g. Fragen interessiert sein.

Christian Zunker arbeitet als Senior Consultant Cloud Technologies für die cc cloud GmbH. Dort beschäftigt er sich mit der Entwicklung und dem Betrieb von verteilten Systemen.

Über 1.000 Abonnenten sind up to date!

Die neuesten Tipps, Tricks, Tools und Technologien.
Jede Woche direkt in deine Inbox.

Kostenfrei anmelden und immer auf dem neuesten Stand bleiben!
(Keine Sorge, du kannst dich jederzeit abmelden.)

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.