Es ist offensichtlich, dass ein Restaurant wesentlich effektiver (also gewinnbringender) funktioniert, wenn Köche und Kellner ihre Aufgaben beherrschen und gut zusammenarbeiten. Sowohl Koch als auch Kellner haben Aufgaben, die sie wiederholt ausführen. Der Koch muss die Erwartungen der Gäste des Restaurants erfüllen und die Speisen so zubereiten, wie sie in der Speisekarte stehen. Der Kellner muss wissen, wie er einen Tisch eindeckt und wie er Getränke und Speisen serviert. Das Konzept der DevOps überträgt diese Gedanken auf die agile Software-Entwicklung. Product-Owner (Chefkoch) und das cross-funktionale Scrum-Team (Entremetier, Gardemanger, Pâtissier und Saucier) liefern ein Produkt (Speisen). Die Betriebsorganisation (u.a. Kellner) definiert Qualitätsanforderungen, achtet auf die Einhaltung der Qualität des Produktes und macht es für die Nutzer (Gäste) verfügbar.

Motivation

Entwicklung und Betrieb von Software sind zwei Seiten einer Medaille. Sie sollte auf beiden Seiten glänzen. Darum müssen wir uns bereits zu Beginn der Entwicklung Gedanken über Einführung und Betrieb der Software machen. Der Weg von der Programmierung bis zur Einführung einer Software ist mitunter sehr lang, trotz agiler Methoden. Schuld ist die häufig komplexe Systemlandschaft mit einer Mischung aus modernen und alten, oft monolithischen Systemen. Die Vielfalt technischer Lösungen, wie sie häufig bei der Umsetzung des Konzeptes ‘Microservice’ entsteht, trägt ihren Anteil zum komplexen Umfeld moderner IT-Systeme bei. Es steckt also viel Wissen in den Köpfen von den Personen, die sich um den Betrieb der Software kümmern. Diese Wissen muss gesichert werden, will man Software jahrelang benutzen.

Abgrenzung

Anforderungen, fachliche und technische und Entscheidungen, die zum vorliegenden Produkt geführt haben, sind hier nicht mehr relevant. Der Fokus liegt auf Betrieb und Benutzung des Produktes. Der Einsatz des Produktes steht im Mittelpunkt. Die Zielgruppe ist ganz eindeutig die Betriebsorganisation. Dabei spielt es keine Rolle, ob im Projekt die Idee der DevOps gelebt wird oder ob es ein klassische Betriebsorganisation gibt, die den Betrieb übernimmt.

Betriebsanweisungen

Betriebsanweisungen beinhalten die anwendungsfallbezogene Dokumentation, welche für den Betrieb einer Anwendung/einer Komponente erforderlich ist. Betriebsanweisungen sind zum Teil im Verlauf der Software-Entwicklung zu erstellen, können jedoch bei Bedarf erweitert bzw. angepasst werden. Die Leitfrage beim Erstellen einer Betriebsanweisung ist: “Was muss ich tun, um ein gegebenes Ziel zu erreichen bzw. auf eine gegebene Situation angemessen zu reagieren?”. Der Ansatz, den die Methode CARDS+ an dieser Stelle verfolgt, heißt Betriebsanweisungen. Sie sind wie das Produkt ein wichtiges Ergebnis der agilen Software-Entwicklung. Betriebsanweisungen sind somit auch Teil der Produktdokumentation. Bei agiler Software-Entwicklung gehört die Erstellung und Pflege der Betriebsanweisungen zu den Aufgaben des Scrum-Teams. CARDS+ stellt für die Dokumentation der Betriebsanweisungen den Baustein Task zur Verfügung. Der Baustein wird in den Kategorien Aufgabe, Analyse und Alarm verwendet.

In diese Kategorie fallen alle Betriebsanweisungen für den Regelbetrieb. Dazu zählen sowohl manuell auszuführende Aufgaben als auch teilweise oder vollständig automatisierte Aufgaben. Bei den Betriebsanweisungen geht es nicht darum, jeder Aufgabe einen Namen zu geben. Die Beschreibung kann sich darauf beschränken, zu erklären, wie die erfolgreiche Ausführung überprüft werden kann. Durch diese Praxis bilden die Betriebsanweisungen einen vollständigen Katalog von Aufgaben. Der Katalog umfasst alle manuellen und automatische ausgeführten Tätigkeiten für den reibungslosen Betrieb der Software.

Jedes IT-System verursacht Fehler oder wird von Störungen beeinträchtigt. Ein resilientes System verschafft zwar der Betriebsorganisation mehr Zeit für die Analyse, aber die Mitarbeiter stehen häufig bei der Analyse unter Druck. Die Situation ist immer unerwartet, manchmal tritt ein Fehler zum ersten Mal auf. Somit kann es vorkommen, dass es für ein Problem noch keine vorbereitete Regelaufgabe gibt, die dieses Problem beseitigt. Betriebsanweisungen für die Analyse sind daher eine laufend wachsende Menge von Hilfestellungen für einen Operator, um ein Problem einzugrenzen. Dazu zählen vorgefertigte Grep- oder Awk-Skripte für die Auswertung von Dateien. Filtereinstellungen für Log-Auswertungen, die per Copy&Paste in Kibana, Splunk oder Graylog eingefügt werden, sind immer hilfreich.

Verteiltes Logging, Monitoring und Alerting ist aus einem moderne IT-System nicht mehr wegzudenken. Wenn nun ein solches System einen Alarm auslöst, muss ein Operator die Situation analysieren und abhängig vom Ergebnis die eine oder andere Regelaufgabe zur Entstörung ausführen. Die Betriebsanweisungen unterstützen ihn dabei im Sinne einer Checkliste. Schritt für Schritt geht er die Analyseaufgaben durch, um irgendwann bei der Regelaufgabe zu landen, die er ausführen muss.

Stack Overflow und Co sind eine Wissensquelle, die aus der Software-Entwicklung nicht mehr wegzudenken ist. Gerade Probleme im Zusammenhang mit Open-Source-Produkten werden gerne in Foren diskutiert. Entwickler und Nutzer geben wertvolle Hinweise zur Lösung oder zumindest Umgehung eines konkreten Problems mit einem Produkt. Die Nutzung dieser Art von Hilfe ist jedoch immer mit Arbeit verbunden. Der Hinweis muss übersetzt werden. Die Lösung muss in den Kontext des Projektes übertragen werden. Die Nutzung des Produktes ist nicht völlig gleich, eine Anpassung der Lösung ist notwendig. Eine Betriebsanweisung ist ein Medium, mit dem das Ergebnis dieser Arbeit dokumentiert werden kann. In der Ausgangslage wird nicht nur das Problem beschrieben, sondern auch der Link auf die ursprüngliche Quelle als zusätzliche Information gesichert. Und mit der Betriebsanweisung macht sich das Projekt unabhängig von der Quelle. Denn welche Quelle garantiert schon, dass sie immer verfügbar sein wird!

Betriebshandbuch

Die Gesamtheit der Betriebsanweisungen ergibt das vollständige Betriebshandbuch. Durch die Verwendung des Wiki ergibt sich hier der enorme Vorteil, dass wir nach Betriebsanweisungen suchen können (Volltext- und Stichwortsuche). Es kann auch von externen Betriebsorganisationen genutzt werden, entweder mit Leseberechtigung direkt im Wiki oder durch einen geeigneten Export.

ktip In Confluence reicht die Standardfunktion leider nicht für einen professionellen Export aus dem Wiki. Die Erweiterung (Add-on) Scroll-Office schafft hier Abhilfe.

Beim Export müssen wir unbedingt berücksichtigen, dass auch Teile der Architekturdefinition und der Systembeschreibung für das Betriebshandbuch relevant sind. Eine Betriebsorganisation profitiert vom Wissen über Entscheidungen (Baustein Decision) des Teams während der Entwicklung. Die genaue Kenntnis der Systemstruktur (vor allem Baustein Service) lässt einen Operator besser den Sinn und Zweck von Handlungsanweisungen verstehen. Jedes Sprint-Ende markiert einen Zeitpunkt, an dem die Betriebsanweisungen vollständig sind für das Produktinkrement. Wir nutzen diesen Zeitpunkt, um eine Baseline der Betriebsanweisungen zu erstellen:  Das Betriebshandbuch für das Produktinkrement.

Fazit

Betriebsanweisungen sind alternativlos. Solange IT-Systeme sich nicht selbst heilen können (mir graut vor dieser Vorstellung), muss es ‘Heiler’ unter den Mitarbeitern geben. Ein Operator ist aber in den seltensten Fällen der Entwickler des Produktes. Er kennt nur die äußerste Schale der technischen Komponenten in Form einer angemessenen Produktdokumentation, die Teil des gelieferten Produktes ist. Eine lernende Betriebsorganisation wird aktiv Betriebsanweisungen pflegen und erstellen. Mit jedem gelösten Problem gibt es eine verbesserte oder neue Betriebsanweisung. Mit dem Baustein Task der Methode CARDS+ geht das einfach und schnell.