DevOps lenkt den Blick auf Software als wertschöpfendes Produkt
Quirin Kögl, IT Consultant, ist DevOps-Engineer in einem Kundenprojekt zu automatisiertem Fahren. Er und seine Kolleg*innen arbeiten mit einem DevOps-Ansatz. Im Interview gehen Martin Scholz, Principal IT-Consultant, und Quirin Kögl auf die beiden Aufgaben Incidents und Alerting ein und erklären, warum DevOps den Blick auf Software als wertschöpfendes Produkt lenkt.
Martin Scholz: Quirin, worum geht es in diesem DevOps-Projekt?
Quirin Kögl: Wir entwickeln für unseren Kunden Datenprodukte für das hochautomatisierte Fahren. Dabei analysieren wir laufend die Events der Fahrzeugflotte und erzeugen durch Aggregation Informationen für die Fahrzeuge und Produkte für externe Nutzer. Ein Beispiel hierfür ist unser Baustellenservice. Dieser unterstützt die Fahrzeuge beim hochautomatisierten Fahren auf der Straße. Beim hochautomatisierten Fahren liegt die Verantwortung beim Fahrzeug und nicht mehr beim Fahrenden. Damit ist es für den Kunden und Anwender erlebbar.
Martin Scholz: Warum wollte der Kunde das als DevOps-Projekt aufsetzen?
Quirin Kögl: Der Fachbereich möchte nur mit einem Ansprechpartner für die Entwicklung und Betrieb der Produkte arbeiten. Deshalb arbeiten wir direkt mit dem Fachbereich zusammen, ohne dass eine IT-Abteilung für den Betrieb eingebunden ist. Wir haben von der IT lediglich unsere Azure Subscriptions bekommen. Entwicklung, Provisionierung, Infrastruktur und Betrieb liegen vollständig in unserer Verantwortung. Diese Verantwortung wurde vom Kunden explizit von uns eingefordert.
Martin Scholz: DevOps ist ein großes Wort mit einer großen Spanne. Fokussieren wir uns auf das Incident-Management: Wenn es zu einem Incident kommt, wie werdet ihr benachrichtigt? Wer von euch reagiert?
Quirin Kögl: Wir haben für all unsere Services zentrale Postfächer als offizielle Kommunikationskanäle. Dort bekommen wir in Fehlerfällen automatische Alerts – also E-Mails, die von Systemen geschickt werden. Damit in den Postfächern nichts untergeht, haben wir eine im Team rollierende Ops-Verantwortung (zwei Personen) etabliert. Zu dieser Verantwortung gehört der regelmäßige Blick ins Postfach und die Weitergabe der Neuigkeiten – wie neue Incidents – an das gesamte Team.
Martin Scholz: Wie stellt ihr dabei sicher, dass alles Relevante dokumentiert wird?
Quirin Kögl: Wir legen für jeden Incident ein Ticket an, um einen Informationsverlust zu vermeiden. In diesem werden alle nötigen Informationen dokumentiert. Zusätzlich haben wir pro Produkt eine Online-Dokumentationsseite in Confluence, die einen Überblick über alle Incidents bietet. Dort ist das entsprechende Ticket verlinkt. Wir nutzen diese Übersicht als Erfahrungsdatenbank.
Wir haben pro Produkt die ersten Schritte zur Analyse und Problembehebung der verschiedenen Komponenten dokumentiert. So kann jedes Teammitglied Probleme in jedem Produkt angehen, auch wenn es (dafür) nicht fachlich involviert ist. Außerdem läuft die Kommunikation mit dem Kunden nur über Postfächer, die von jedem Teammitglied eingesehen werden können. So geht keine Information verloren, falls jemand nicht da ist.
Martin Scholz: Euer Projekt ist sehr gut organisiert und hat jederzeit den Überblick über die aktuellen Incidents. Um den aktuellen Zustand der Produkte im Livebetrieb zu kennen, sind Metriken und Alerts essenziell. Wie ermittelt ihr diese Metriken für Incidents und Systemmeldungen, um Störungen schnell zu beheben?
Quirin Kögl: Wir arbeiten mit zwei verschiedenen Azure-Umgebungen des Kunden.
Auf der einen Umgebung nutzen wir Azure-eigene Services, um technische und fachliche Metriken unserer Produkte und Komponenten auf mehreren Dashboards darzustellen. Auf diesen produktspezifischen Dashboards sehen wir den Zustand unserer Produkte und Komponenten auf einen Blick. Dort betreiben wir Big-Data-Applikationen und den Großteil unserer Azure-Ressourcen.
Auf der zweiten Azure-Umgebung, vom Kunden bereitgestellt, laufen unsere Schnittstellen zum Fahrzeug-Backend als Microservices. Hier setzen wir auf das vom Kunden bereitgestellte Logging System. Dort definieren wir Alerts und Dashboards auf Basis von Micrometer Metriken. Zusätzlich nutzen wir Azure Services, die für die Nutzung der Daten freigegeben sind. Auf dieser Datenbasis installieren wir verschiedene Alerts, die uns über Fehlverhalten der Produkte automatisch informieren.
Martin Scholz: Wann ist ein Alert für euch sinnvoll?
Quirin Kögl: Grundsätzlich ist es unser Ziel, durch Alerts so schnell wie möglich und vor den Anwendern von möglichen Problemen in unseren Produkten zu wissen. Alerts müssen sinnvoll und nicht inflationär sein, damit die wichtigen Probleme nicht im Grundrauschen untergehen. Daher haben wir im Projekt folgende Fragen definiert, die wir für jeden Alert beantworten:
Was passiert, wenn wir den Alert ignorieren?
Wenn wir den Alert ignorieren und es passiert nichts Schlimmes, dann brauchen wir den Alert nicht.
Wie können wir das aufgetretene Problem analysieren?
Die Dokumentation hilft uns, schneller zur Ursache des Problems zu kommen, besonders wenn das Problem selten auftritt.
Wie können wir das aufgetretene Problem beheben?
Diese Information hilft uns, damit wir nicht jedes Mal erneut über die Lösung nachdenken müssen und schneller wieder in den Normalzustand zurückkommen. Wenn die Lösung darin besteht, das betroffene Produkt neu zu starten, dann können wir das auch automatisieren.
Martin Scholz: Ihr seid wahrscheinlich initial mit null Alerts gestartet. Wie viele habt ihr aktuell? In welchen Fällen habt ihr euch für neue Alerts entschieden und löscht ihr Alerts auch mal?
Quirin Kögl: Wir sind mit ein paar Standard-Alerts gestartet wie zum Beispiel Heartbeat Alerts, die die Erreichbarkeit der Anwendung prüfen. Inzwischen sind wir bei knapp einhundert Alerts über alle Produkte hinweg. Alerts legen wir meist iterativ an, wenn neue Probleme auftauchen und wir davon ausgehen, dass diese wieder auftreten können.
Kürzlich wurden tatsächlich sechs Alerts ausgelöst. Allerdings lagen die Probleme nicht bei uns, sondern bei verschiedenen Schnittstellenpartnern. Wir sehen hier noch Potenzial, solche Themen automatisiert an das betroffene Produkt weiterzuleiten, wenn sich die Nichtverfügbarkeit eines Nachbarsystems auf uns auswirkt.
Martin Scholz: Gibt es ein Beispiel für einen zentralen Service in den Produkten?
Quirin Kögl: Bei uns handelt es sich um Produkte, die jeweils aus mehreren Komponenten bestehen können. Das sind bei uns Schnittstellen-Services oder verteilt rechnende Pipelines – in unserem Fall Spark-Pipelines. Ein wichtiges Produkt ist unsere Topology Map. Das ist die Basiskarte, auf der sowohl die Streckenfreigaben für das hochautomatisierte Fahren als auch z. B. erkannte Baustellen abgelegt werden. Das Produkt besteht aus einer Spark-Pipeline, die die Karte regelmäßig erzeugt, sowie einem REST-Service, der die Karte an Umsysteme bereitstellt.
Martin Scholz: Was ist das Fazit aus dem Projekt?
Quirin Kögl: Wir haben sehr viel erreicht! Wir haben einen vollständig automatisierten CI/CD-Prozess und provisionieren unsere Infrastruktur sowie unser Monitoring und Alerts automatisiert mit Terraform (Infrastructure-as-Code). Durch diesen hohen Automatisierungsgrad entstehen weniger Fehler und wir können mit dem Kunden stärker auf die Weiterentwicklung der Produkte konzentrieren.
Dadurch haben wir viel Vertrauen beim Kunden gewonnen. Durch dieses Vertrauen übernehmen wir viel Verantwortung. Im Gegenzug wird uns aber auch die Freiheit und Autorität gegeben, dieser Verantwortung gerecht zu werden. Zum Beispiel übernehmen wir das fachliche Design der Produkte.
Martin Scholz: Vielen Dank für den Einblick in das komplexe Thema DevOps am Beispiel Incidents und Alerting! Im nächsten Teil des Interviews wollen wir uns über eine effiziente Teamorganisation des Betriebs in einem großen DevOps-Projekt unterhalten. Ich freue mich darauf!
