Site Reliability Engineering (SRE): Endlich richtig DevOps!

Wird DevOps nur als Prinzip eingeführt, finden das meist alle Beteiligten aus Fachabteilungen, Entwicklung und Betrieb gut und unterstützen dies noch.

Im Alltag zeigen sich später jedoch kaum Unterschiede zum früheren Vorgehen: Eventuell gibt es mal ein Meeting zum Handover des Codes vom Entwicklungsteam zu Operations mehr oder eine gemeinsam erstellte Go-Live-Checkliste. Das war es dann meist aber auch schon.

Ein zusätzliches DevOps-Team ist tatsächlich sogar ein Antipattern zu DevOps: Statt Entwicklung und Betrieb zusammenzubringen, wird ein Team aus dem Boden gestampft, das eigentlich ein drittes Silo hinzufügt. Der klassische Operations-Betrieb bleibt dabei separat bestehen – und kommt gerade in Zeiten von Agile, Microservices und immer kleineren Deployments in höherer Frequenz an seine Grenzen. Hier müssen wir neu denken.

Was ist BizDevOps?

DevOps ist zu allererst ein Prinzip. Der Name ist ein Akronym, das Development und Operations vereint, denn beide Bereiche sollten weniger in Silos getrennt voneinander arbeiten als vielmehr kooperieren. BizDevOps erweitert das Prinzip nun um das Business: Zur Zusammenarbeit in einem Team aus Vertretern der Fachseite, Entwicklung und des Betriebs. Das SRE Framework schließlich sorgt dafür, dass dieses Prinzip auch in der Realität vollständig umgesetzt wird.

Wichtig ist es, die Teams konsequent nach Produkten zu restrukturieren und die alten Fehler bei der DevOps-Implementierung zu vermeiden. Meist haben Unternehmen versucht, DevOps schlicht als Prinzip in den alten Team-Strukturen umzusetzen – oder über ein zusätzliches DevOps-Team zur Schnittstellenkoordination. Beides funktioniert nicht.

Das Produkt bestimmt die Organisation

Eine zukunftsweisende Vision ist die von der produktzentrierten Organisation mit produktorientierten Teams. Eine solche Organisation teilt sich nicht mehr nach ihren Fähigkeiten in Silos und wird entsprechend bewertet. Sie bildet jeweils ein Team aus verschiedenen Akteuren für jedes Produkt. Konkret heißt das, dass es nicht mehr Business bzw. Fachseite, Development bzw. Entwicklung und Operations bzw. Betrieb gibt, sondern ein Team pro Produkt, das beispielsweise ein Microservice sein kann. In jedem dieser Teams sind Product Owner, Architekten, Entwickler und Kollegen vom Betrieb angesiedelt.

Diese Team-Struktur erleichtert es allen Mitgliedern eines Produktteams, gemeinsame Ziele zu verfolgen statt unterschiedliche, die in Konkurrenz zueinander stehen. Das wichtigste Teamziel ist der Erfolg des Produkts. Es incentiviert die Zusammenarbeit entlang der gesamten Wertschöpfungskette. Damit ein BizDevOps-Produkt-Team aber sein volles Potenzial ausspielen kann, braucht es Reliability Engineering.

Das Framework für die produktzentrierte Organisation

Unternehmen können mit Site Reliability Engineering bzw. dem Site Reliability Engineering Framework die Vision einer produktzentrierten Organisation realisieren, denn es implementiert DevOps und den „One Team“-Gedanken. Das Framework besteht aus zwei Komponenten: dem Site Reliability Engineer sowie dem selbstregulierenden Modell – und es ist wichtig, beide umzusetzen. Die Gefahr durch eine nur halbe Umsetzung ist vergleichbar mit der beim Agile-Prinzip. Wenn man in Sprints arbeitet, aber nur einmal im Jahr deployed, ist man nicht agil.

1. Der Site Reliability Engineer

Der Site Reliability Engineer hat zwei Aufgaben: In maximal 50 Prozent seiner Arbeitszeit kümmert er sich im Feuerwehr-Modus darum, dass der Betrieb stabil läuft. Mindestens 50 Prozent seiner Zeit widmet er Engineering-Aufgaben wie der Automatisierung von wiederkehrenden manuellen Aufgaben. Der SRE ist ein höchst erfahrener und talentierter Coder, der wirklich keine Lust auf redundante Fleißarbeit hat. Er kennt sich mit dem Betrieb und der Cloud aus, beherrscht effektives Monitoring, versteht Architekturkonzepte und weiß, wie man Code fixt. Nur ein solcher Site Reliability Engineer wird die Aufgabenlast nachhaltig senken. Er ist zudem der wichtigste Berater für den Product Owner (PO), Architekten und Entwickler in Sachen Service-Stabilität, Monitoring, Performanz und anderen nicht-funktionalen Anforderungen.

2. Das selbstregulierende Modell

Es kann vorkommen, dass das produktorientierte Team es versäumt, die Verlässlichkeit von aufwändig konzipierten und entwickelten Features sicherzustellen. Ein selbstregulierendes Modell kann dafür sorgen, dass dieser entscheidende Punkt nicht aus dem Fokus gerät. Es arbeitet mit Service Level Objectives (SLOs), einem Error Budget und automatischen Konsequenzen: Ein SLO ist ein konkretes Ziel – beispielsweise eine 99-prozentige Verfügbarkeit des Services. Daraus abgeleitet, ist das Error-Budget 1 Prozent, mit dem das Team machen kann, was es will, beispielsweise Chaos Engineering. Das Error Budget sollte jedoch bestenfalls für Releases verwendet werden, da Veränderungen meist mit Fehlern einhergehen. Wird ein Ziel jedoch nicht erreicht und das Error Budget überschritten, treten automatische Konsequenzen in Kraft. Diese können vielfältig sein. Eine klassische Konsequenz ist ein Feature Deployment Stop, bis der Service wieder im Budget ist. Diese Ziele gelten für alle, nicht nur für die SREs/ den Betrieb.

Maßgeschneidert zum Erfolg

So einfach das Framework auch wirkt, so komplex ist seine Implementierung. Es ist nicht damit getan ein paar sehr erfahrene und talentierte SREs einzusetzen und diese den Betrieb verantworten zu lassen. Wichtig ist auch, dass sie das max-50/ min-50-Prinzip einhalten und SLOs, Error Budget und Konsequenzen implementieren. Diese Transformation ist ähnlich aufwendig wie die agile Transformation – und den Aufwand ebenso wert. Produkte werden nachhaltig zuverlässiger, die Time-to-Market verkürzt sich und alle aus dem Team, inklusive der Endnutzer, freuen sich über eine schnell fortschreitende Entwicklung und höhere Verfügbarkeit der Services.

Was es nicht gibt, ist ein Blueprint, der einfach über jede Organisation gelegt werden kann. Der Erfolg kommt mit einem maßgeschneiderten Konzept vom Experten, das zur Organisation passt.