Jazoon TechDays 2018

Christoph Raaflaub

Endlich sind sie da – die Videos der Beiträge von den Jazoon Techdays vom 6. und 7. September. Infolgedessen auch unser Blogpost mit unseren Eindrücken zu diesem Anlass. Die TechDays standen unter dem Motto «DevOps for Devs» und wurden auf dem Berner Hausberg Gurten durchgeführt. Christoph Raaflaub berichtet.

Workshop: Successful Production Microservices

Russ Miles: ChaosIQ

Die Techdays starteten mit einem Workshop unter der Leitung von Russ Miles zum Thema «Erfolgreicher Betrieb von Microservices». Dabei wurde der Fokus auf das Chaos Engineering gelegt.

Gut 20 Interessenten besuchten den Workshop. Wir konnten unsere eigenen Erfahrungen zu produktiven Problemen thematisieren und im Kurs aufarbeiten. Zuerst wurde ein allgemeines Verständnis des Begriffs „Microservice“ diskutiert. Mit Microservices kann eine komplexe Anwendung realisiert werden, welche aus unabhängigen Prozessen besteht.

Probleme in der Produktion

Nach dem Motto „Production hates you“ haben wir eigene Microservices auf Schwachstellen untersucht. Was könnte während dem produktiven Betrieb schiefgehen? Die meisten konnten bereits hier einige Tasks aufnehmen, die sie in ihrem Berufsalltag untersuchen und verbessern konnten.

Russ Miles stellte hierbei die Analogie zu einem Bewohner in einer Stadt her. Die Produktion wird als Stadt angesehen, wobei die Microservices die Bewohner der Stadt repräsentieren. Damit das Zusammenleben in der Stadt funktioniert sollte sich jeder Bewohner wie ein guter Bürger verhalten. Aber was ist also notwendig, dass ein Microservice ein guter und vorbildlicher Bürger ist?

Um einen reibungslosen Betrieb sicherzustellen müssen mindestens folgende zwei Zustände geprüft werden: liveness und readiness. Jeder Service sollte also über Endpoints verfügen, die über dessen Zustand informieren. Dies kennen wir von Container Plattformen wie OpenShift. Dort werden solche Checks verwendet, um zu entscheiden, ob ein Container Anfragen erhält oder ob er neu gestartet werden soll.

Für eine erweiterte Überwachung sind folgende Eigenschaften wichtig:

  • strukturiertes und zentrales Logging
  • Ausgabe von Metriken
  • Information / Meldungen wenn Probleme auftreten

Mögliche Bewältigungsstrategien in der Praxis

Nach diesem theoretischen Exkurs erhielten wir die Aufgabe ein produktives Problem zu analysieren.
1. Wer hat es bemerkt? (hoffentlich nicht der Kunde!)
2. Wie konnte die Ursache gefunden werden?
3. Was konnte sofort gemacht werden um das Problem zu Beheben/Umgehen?

Das Problem wird hierbei post-mortem, also erst im Nachhinein, betrachtet. Dabei können wir uns dieses Template zu Nutze machen. [postmortem template]

Das Ziel ist es, aus den Problembehebungen und Diagnosen zu lernen. Situationen, in denen die Produktion nicht richtig läuft, sind sehr stressig. Anhand der Diagnose wollen wir eine Liste mit klaren Instruktionen ableiten, die helfen kann, diesen Zustand besser zu meistern. Grundlegend geht es darum, im produktiven Betrieb besser auf Probleme reagieren zu können.

Aber wäre es nicht noch besser zu agieren, anstatt zu reagieren? Sollten Probleme nicht analysiert werden, bevor sie auftreten könnten? Das Chaos Engineering ist eine Möglichkeit, Probleme pre-mortem zu behandeln, also noch bevor sie überhaupt auftreten. Dies wird im nächsten Abschnitt thematisiert.

Chaos Engineering

Chaos Engineering ist eine experimentelle Vorgehensweise. Das produktive System wird ganzheitlich überprüft, auch die Build Pipeline und alle involvierten Personen. Am Anfang werden Hypothesen über mögliche Ausfälle und deren Konsequenzen aufgestellt. Ziel dieser Vorgehensweise ist, dass das Problem bei der Produktion gar nicht erst auftritt.

Beispiel
Hypothese: Die Verbindung zwischen Applikation und Datenbank ist plötzlich nur noch halb so schnell.
Erwartetes Problem: Komplexe Such-Funktionen werden abgebrochen, bevor ein Resultat zurückkommt (Request Timeout)

Beim Versuch/Experiment geht es darum, die Hypothese zu bestätigen.

Grundlegendes zu den Versuchen:

  • Wenn das Resultat eines Versuches bekannt ist, dann muss der Versuch nicht durchgeführt werden. Die Lösung kann direkt angegangen werden.
  • Versuche/Experimente nie auf Produktion machen.
  • Wenn das erwartete Problem eintrifft, den gefundenen Fehler feiern (Hypothese wurde bestätigt)!
  • Alle helfen bei der Fehlerbehebung mit, auch der Organisator des Versuches.
  • Wenn der Fehler eliminiert wurde, den Versuch noch einmal wiederholen (double-loop learning). Dabei erkennt man, ob ein weiteres Problem vorhanden ist und ob der zuvor erkannte Fehler behoben wurde.

Die Versuche werden wie Feuerwehrübungen durchgeführt. Das Feuer kann schnell gelöscht werden, da jeder weiss was zu tun ist. Diese Versuche stärken zudem das Vertrauen der beteiligten Person in das System und ihren Fähigkeiten, Probleme in der Produktion lösen zu können. Mit Hilfe von Resilient Software Design könnte ein System auch auf unerwartete Vorfälle reagieren. In diesem Blog wird jedoch nicht stärker darauf eingegangen.

Gameday

Der Gameday ist eine Methodik des Chaos Engineerings. Dabei werden Versuche für die Überprüfung des Experimentes gemacht – es wird ein Ernstfall geprobt. Ein Team unter der Leitung eines Chaos Engineers prüft das System.

Es ist eine gute Idee Stakeholder einzuladen, damit sie die Probleme live miterleben und sehen, wie damit umgegangen wird.
Zu Beginn wird das System nach Schwachstellen untersucht. Dazu soll die Architektur skizziert und analysiert werden. Die Teilnehmenden entscheiden sich für eine der Schwachstellen und erarbeiten mögliche Testfälle. Daraus resultiert eine Anleitung zum Experiment/Versuch.

Konkrete Beschreibung eines Versuchs:

  • Der Versuch benötigt eine messbare Definition vom stabilen Zustand des Systems.
  • Es wird genau definiert, was für eine Änderung am System gemacht wird.
  • Wie reagiert das System auf die in Schritt zwei definierte Veränderung? (Erwartetes Fehlverhalten)
  • Rollback der Änderung: Wie macht man die Änderung rückgängig?

Das Ziel ist es, mit dem Versuch die aufgestellte Hypothese zu bestätigen. Anschliessend wird definiert und geplant, wie die gefundene Schwachstelle behoben wird.

Automatisierung

Falls die an den Gamedays implementierten Testversuche vielversprechend sind und unvorhersehbare Schwachstellen aufzeigen, können sie automatisiert werden. Diese Tests zeigen, dass behobene Probleme tatsächlich repariert wurden und nicht mehr auftreten.

Zum Schreiben und Automatisieren solcher Tests wurde vom ChaosIQ ein Framework entwickelt. Dort werden die Experimente mit dem erwarteten Verhalten definiert und ausgeführt.

Mehr dazu auf der ChaosToolkit Webseite: https://chaostoolkit.org/
Das Framework ist OpenSource und Contributions sind willkommen: https://github.com/chaostoolkit
Als Einstieg gibt es online Kurse auf katacoda (Framework mit Aufgaben): https://www.katacoda.com/chaostoolkit

Fazit

Mir als Fahrer eines schweren Motorrades (BMW K1300R) hat die Aussage von Russ Miles gefallen: „treat production like a motorcyclist not like a car driver“

Warum? Weil Motorradfahrer keinen Schutz (Auto) um sich haben und im Vergleich zu Autofahrern bei Unfällen meist schlimmere Verletzungen erleiden. Mit diesem Hintergrund ist ein weiteres Vorausschauen und ein noch proaktiveres Verhalten im Strassenverkehr für Motorradfahrer lebenswichtig. So ist es auch in der Software-Entwicklung: «aktiv und vorausschauend» sind die Schlüssel zum erfolgreichen Betrieb von Microservices.

Links zu Chaos Engineering:

Konferenz

Am Tag nach dem Workshop fand die Konferenz statt. Diese fand bei vielen Techies Anklang. Bis auf den letzten Platz war der Saal auf dem Gurten gefüllt. Es wurden Talks zu folgenden Themen gehalten:

  • Kubernetes Day 2-5
  • Distributed Monitoring: How to Understand The Chaos
  • Docker Security: Start your Container Journey Safely
  • OpenShift for the Enterprise or What Could Possibly Go Wrong
  • Building an Evolutionary Infrastructure Using Pipelines
  • Observability for Emerging Infra: What Got You Here Won’t Get You There
  • Secrets as Code
  • Availability, Latency and Cost: Withstanding Outage
  • Severless Architecture: A Love Story

Die Talks sind als Videos auf https://jazoon.com/ verfügbar.

Schreibe einen Kommentar