Keep CALMS — Start DevOps
Ein Beitrag von Markus Koschier und Valentino Pola
DevOps ist in aller Munde — der nächste Vorgehens-Hype nach Agile, Scrum und Less? Schwer zu sagen, denn eine einheitliche Definition von DevOps gibt’s nicht. Und dann kommen auch noch Scrum-Master und Projektleiter um die Ecke und stellen die Frage, wie DevOps mit Scrum++ unter einen Hut zu bringen ist.
CALMS erweist sich momentan als das am stärksten genutzte Modell zum Beschreiben von DevOps:
Das Akronym steht für Culture, Automation, Lean, Measurement und Sharing. Es geht also um mehr um eine ganzheitliche Sicht auf DevOps als um einen rein methodische Ansatz — gerade deshalb gefällt es uns so gut.
Culture
Culture (Kultur) zielt darauf ab, gemeinsame Verantwortung anstatt der (leider immer noch sehr üblichen) „Wir gegen die“-Denkweise zu fördern. Wichtige Aspekte sind Fehlertoleranz und das Verständnis von Fehlern als Chance zum Lernen. Retrospektiven und Post Mortems sind effektive Mittel, um diese Denkart in Teams zu etablieren.
Außerdem verfolgt eine DevOps-Kultur das Ziel, dass sich das Team nicht nur um die Umsetzung, sondern auch Betrieb und Weiterentwicklung kümmert. Lange Release-Zyklen mit endlosen Releaseplanungs- und -Management- Runden sind hier Gift — nur durch eigenverantwortliche Entwicklung und Produktivnahme von Features bleiben Teams auch gern dabei. Und ganz nebenbei wird Overhead entfernt und die Velocity steigt.
Umgekehrt bedeutet das in der Extremform auch, dass alle (oder kein) Mitarbeiter Prod- und root-Zugänge benötigen. Hier wird es dann auch schwierig. Gerade in der Finanzdienstleistungsbranche ist beispielsweise der Zugriff auf Kundendaten stark einzuschränken. Das liegt auch daran, dass regulatorische Vorgaben, wie die Trennung von Entwicklung und Betrieb, eng ausgelegt so etwas nicht erlauben.
Spätestens bei der Anbindung übergreifender Prozesse gestaltet sich eine gemeinsame Verantwortung von Dev und Ops schwierig: Das Call-Center möchte einen dedizierten Ansprechpartner, die Tester weisen Bugs Entwicklern zu und der Chef hätte dann doch gern einen Verantwortlichen im Jour-Fixe.
Automation
Automatisierung soll dafür sorgen, dass so viel wie möglich von der verfügbaren Zeit für die Entwicklung neuer Features verwendet wird. Automatisierung kann hierbei an unterschiedlichen Stellen eingesetzt werden. Es muss auch nicht von Anfang an die große Continuous-Delivery-Infrastruktur sein, deren Aufbau extrem zeitintensiv sein kann — das wäre dann auch nicht mehr wirklich agil.
Meist ist es schlauer, mit einfachen Tasks, wie beispielsweise dem Aufbau von (Test-) Umgebungen, oder dem Starten und Stoppen von Containern und Servern loszulegen. Ein anderes Beispiel ist ChatOps, wozu Gregor Tudan bereits einiges geschrieben hatte.
Ein sehr gut geeignetes Tool zur Automatisierung manueller Tasks ist Rundeck, welches wir in unseren Projekten immer häufiger verwenden.
Mit der Automatisierung ergeben sich auch Diskussionen und Entscheidungen, die man nicht unterschätzen sollte: Wer kümmert sich um die Skripte und den Zugriff darauf? Wer sorgt dafür, dass das Know-How über die automatisierten Tasks auch weiterhin im Team vorhanden ist? Sonst weiß irgendwann niemand mehr, was bei fehlgeschlagenen Deployments oder gestopptem Server zu tun ist, da das ja sonst das Skript übernimmt.
Ein weiterer Punkt ist der Faktor Zeit: Automatisierung erfordert einen initialen Invest, der sich im Laufe der Zeit amortisiert. Dies steht immer auch in Konkurrenz mit den fachlichen Anforderungen.
LEAN
Spätestens durch die Lean Startup Methode erlebt der Lean-Hype der späten 1990er Jahre wieder eine Renaissance. Im Kontext von DevOps geht es darum, Aufgaben nach dem Pull-Prinzip zu übernehmen, anstatt sie per Push-Prinzip zugewiesen zu bekommen. Außerdem verfolgt das Lean-Prinzip das Ziel, Prozesse schlank und leichtgewichtig zu halten.
Ein anderer Aspekt betrifft das Sichtbarmachen der Arbeitslast und und die Limitierung der Anzahl an parallel laufenden Aktivitäten: Die Konzentration auf weniger gleichzeitig laufende Aufgaben führt auch zu erhöhter Geschwindigkeit und als Nebeneffekt zu mehr Qualität.
Im Zentrum von Lean wird Kanban benutzt — diese Methode ist maximal flexibel und sollte an das konkrete Projektsetup angepasst sein.
Bei uns hat sich als hilfreich erwiesen, insbesondere betriebsnahe und teamübergreifende Prozesse (bspw. bei Kooperation mit dem Kundenservice) stetig zu verbessern. Häufig wiederkehrende und schwer zu automatisierende Aktivitäten (Löschung von Kunden, Änderung von Telefonnummern) lassen sich über Komfortfunktionen zur Verfügung stellen und somit ein Stück weit an Kunden „abgeben“. Die Aspekte „schlank“ und „leichtgewichtig“ sollten nicht nur für Prozesse, sondern auch für Technologien und Tools gelten — ein unüberschaubarer Tool-Zoo sorgt im schlimmsten Fall für mehr Wartungsaufwand als Nutzen (Software-Updates, Patching von Sicherheitslücken etc.).
Measurement
Schätzen, wiegen, messen — nur durch die Erfassung objektiver Kennzahlen lassen sich Aussagen über das System und seine Nutzer treffen. Durch die Erfassung und Interpretation von Daten lassen sich potentielle Fehler oder Engpässe frühzeitig erkennen und darauf reagieren. Das liefert wiederum den notwendigen Freiraum für Innovation, Qualität und Automatisierung.
Wichtige Fragen an der Stelle sind: Was sind die wichtigsten Kennzahlen des Produkts / Systems? Sind diese in ausreichender Dichte vorhanden? Der Traffic auf der Plattform ist hierfür oft eine guter Kandidat— allerdings bei einer hochspeziellen Anwendung, die nur von 3–4 Usern parallel genutzt wird, wenig hilfreich. Daraus lassen sich kaum Trends ableiten — am Ende sind wir doch nicht alle Netflix.
In der Finanzdienstleistungsbranche interagieren Systeme viel mit anderen Systemen. Messungen über Systemgrenzen hinweg gestalten sich meist schwierig: Die Abhängigkeit von externen Partnern steigt und die Definition und Entwicklung von gemeinsamen Messpunkten ist eine echte Herausforderung.
In der immer stärker wachsenden VUCA-Welt (volatility, uncertainty, complexity und ambiguity) schaffen Metriken die Basis für Experimente und echte Agilität: Zunächst werden neue Themen prototypisch verprobt — wenn die Zahlen nicht stimmen, werden sie wieder eingestampft, und nur wenn sie passen weiter ausgebaut. Ähnlich wie bei der Automatisierung gilt auch hier: Zur Erfassung und Interpretation der „richtigen“ Daten ist zunächst ein Invest notwendig —der kann (zumindest anfangs) zu Lasten der eigentlichen Features gehen.
Sharing
Wenig überraschend: Kommunikation ist der Schlüssel zum Erfolg. Bereits Scrum verfolgt das Ziel, ein möglichst heterogenes und cross-funktionales Team ohne Spezialistentum aufzubauen. Das ist auch im Sinne von DevOps. Erreicht werden kann das insbesondere durch den Aufbau und Austausch von Wissen innerhalb von Teams und über Teams hinweg. Collaboration Tools á la Slack, appear oder Mattermost bieten hierfür die ideale technologische Unterstützung.
Auch hier bringt die Finanzbranche Herausforderungen mit sich: In einem verteilten Umfeld mit hohen Sicherheitsanforderungen ist beispielsweise die Speicherung von projekt- oder gar kundenspezifischen Daten auf fremden Servern häufig nicht denkbar. Außerdem ist es in der Realität sehr schwierig, die gewünschten cross-funktionalen Mitarbeiter zu finden und langfristig ans Projekt zu binden.
In der Praxis hat sich in unseren Projekten insbesondere der praktische Know-how-Austausch bewährt, wobei die Formate hier sehr vielfältig sein können — von Brownbags bis zum Klassiker Pair Programming ist alles denkbar. Und so toll der Einsatz von Collaboration- und Chat-Tools auch ist: Manchmal ist es schneller und effizienter, ein paar Meter weiter zum Kollegen zu gehen und das Thema persönlich zu besprechen.
