Kolumne: DevOps Stories

Site Reliability Engineering – Muss man das alles von Hand machen?

Konstantin Diener

© SuS_Media

Gordon kennt Lukas von der gemeinsamen Arbeit in einer Community of Community of Practice . Er hat ihn gebeten, ihm bei einem Programmierproblem zu helfen. Deshalb sitzen sie in Gordons Teamraum gemeinsam vor dessen Computer.

  • Gordon: „Lukas, ich habe ein Problem mit diesem Key Value Store. Ich komme nie an die aktuellen Werte und habe das Gefühl, dass es mit dem Clustering zu tun hat. Außerdem dauert das Laden sehr lange.“
  • Lukas: „Wofür verwendet ihr den Store denn?“
  • Gordon: „Wir konfigurieren mittlerweile die komplette Businessfunktionalität über diese Datenquelle – haben sogar einige Skripte dort stehen, die zur Laufzeit ausgeführt werden.“
  • Lukas: „Ehrlich? Gibt das keine Laufzeitprobleme?“
  • Gordon: „Doch, schon. Wir müssen aber zügig Features liefern, um mit dem Produkt voranzukommen. Wenn ich da den normalen Weg gehen würde, wäre ich in Rente, bevor wir die Änderungen ausgeliefert haben!“
  • Lukas: „Wieso?“
  • Gordon: „Im Gegensatz zu euch haben wir noch ein Betriebsteam, das unsere Lösung betreut. Diese Jungs haben sich eine Production-Readiness-Checklist einfallen lassen, die sie vor jedem Deployment in Produktion abarbeiten müssen und die gefühlt mit jeder Woche um zwei bis drei Einträge länger wird.“
  • Lukas: „Und die umgeht ihr mit eurem Trick über die Konfiguration?“
  • Gordon: „Ja. Genauso wie die manuellen Deployments, die ewig lang dauern …“
  • Lukas: „Haben die Kollegen euch mal gesagt, warum sie die Checkliste eingeführt haben?“
  • Gordon: „Es gab da wohl das eine oder andere Problem in Produktion. Die mussten deswegen wohl auch nachts raus, konnten es aber nicht richtig beheben und sind morgens im Endeffekt uns damit auf den Wecker gegangen. Keine Ahnung, warum die das nicht auf die Reihe kriegen. An der Teamgröße kann‘s nicht liegen – da fangen ständig neue Leute an.“
  • Lukas: „Sollte das Betriebsteam nicht eigentlich reduziert werden?“
  • Gordon: „Doch. Aber das Produkt geht durch die Decke. Und niemand weiß, wie das ohne Betriebsteam funktionieren soll. Wenn du mich fragst, fummeln die da viel zu viel mit der Hand und brauchen deswegen so viele Leute.“
  • Lukas: „Habt ihr auch mal Rufbereitschaft?“
  • Gordon: „Wir? Vom Produktteam? Nein.“
  • Lukas: „Habt ihr ihnen irgendwelche Infos gegeben, was im Fehlerfall zu tun ist?“
  • Gordon: „Nein.“
Abb. 1: Gordon und Lukas diskutieren die Probleme mit dem Key Value Store – und dem Betrieb

Abb. 1: Gordon und Lukas diskutieren die Probleme mit dem Key Value Store – und dem Betrieb

Der DevOps-Konflikt: Das Produktteam möchte viele Änderungen, der Betrieb Stabilität

Zwischen Gordons Team und den Kollegen vom Betrieb (Ops) zeigt sich das klassische Dilemma, wenn diese beiden Funktionen in unterschiedlichen Silos angesiedelt sind: Die Entwickler des Produktteams möchten möglichst schnell neue Funktionen releasen und die Betriebsmitarbeiter möchten verhindern, dass irgendetwas kaputt geht, während sie Dienst haben. Offenbar haben Gordons Betriebskollegen damit schon konkrete Erfahrungen gemacht. Sie wurden nachts geweckt und durften unter Stress versuchen, das Produkt wieder funktionsfähig zu bekommen. Offenbar haben sie außerdem zu wenig Informationen, um die Probleme zügig zu beheben.

Die Reaktion darauf ist genauso typisch wie verständlich: Um sich möglichst gut gegen Störungen abzusichern, hat das Betriebsteam eine umfangreiche Checkliste definiert, die für jede Änderung am Produktivsystem abgearbeitet werden muss – was sehr viel Zeit kostet.

Weil ihnen dieses Prozedere zu lange dauert, haben die Entwickler des Produktteams angefangen, immer mehr Änderungen am offiziellen Changeprozess vorbei ins Produktivsystem zu schmuggeln. Mit ihrem Ansatz, einen Großteil der Anwendungslogik in einen Key Value Store auszulagern, ist das eigentliche Problem aber noch größer geworden, was Gordon auch bestätigt. Durch die komplexe Konfiguration ist die Software insgesamt wesentlich komplexer und anfälliger für Fehler geworden, womit ist die Stabilität gesunken ist.

Klassische Betriebsteams haben meist zu viele manuelle Tätigkeiten

Dabei ist die Idee einer Production-Readiness-Checklist eigentlich gar nicht so verkehrt. Das Betriebsteam hat zu jedem bislang aufgetretenen Problem einen Check in die Liste aufgenommen, um zu verhindern, dass ein ähnliches Problem in Zukunft wieder auftritt. In anderen Bereichen der Softwareentwicklung ist ein solches Vorgehen ebenfalls gebräuchlich. So gibt es zum Beispiel die verbreitete Praxis, zu jedem Bug einen Unit-Test zu schreiben.

Die Checkliste ärgert die Entwickler, weil sie im Gegensatz zu Unit-Tests nicht automatisiert, sondern manuell abgearbeitet wird. Das dauert wesentlich länger und führt – da das Deployment ebenfalls von Hand erfolgt – zu erheblichen Verzögerungen bei den ohnehin langsamen Changes.

Nach Meinung von Benjamin Treynor Sloss (Vice President, Engineering bei Google) ist ein Überfluss an manuellen Tätigkeiten ein generelles Problem klassischer Betriebsteams [1]. Diese allgemeine Aussage scheint auch auf das Team zuzutreffen, mit dem Gordon und seine Kollegen zusammenarbeiten. Nicht nur im Changemanagement (Checklist und Deployment), sondern auch im Event Handling (Bearbeiten von Störungen) scheint es wenige automatisierte Prozesse und viele manuelle Abläufe zu geben.

Gordon erzählt Lukas, dass das Produkt und seine Nutzerbasis in der letzten Zeit stark gewachsen sind. Um die vielen manuellen Tätigkeiten bei einem solchen Wachstum noch abdecken zu können, ist das Betriebsteam gezwungen, in gleichem Maße mitzuwachsen.

Site Reliability Engineering – Wenn Entwickler Betrieb machen

Google hat für den Betrieb seiner Produkte deshalb das Konzept sogenannter Site-Reliability-Engineering-(SRE-)Teams entwickelt [1]. Dabei handelt es nicht um klassische Betriebsteams. SRE-Teams bestehen aus zwei Arten von Teammitgliedern: 50 bis 60 Prozent sind klassische Google Software Engineers; bei den restlichen 40 bis 60 Prozent handelt es sich um Google Software Engineers, die wichtige zusätzliche Kenntnisse für den Softwarebetrieb haben (zum Beispiel Netzwerkschicht 1 bis 3 oder UNIX-Systeminterna).

Die Idee hinter diesem Team-Set-up ist, dass ein Team aus Softwareentwicklern sowohl gewillt als auch in der Lage ist, manuelle Tätigkeiten durch Entwicklung zu automatisieren. Damit das Team diese Automatisierungsaufgaben auch umsetzen kann und nicht vom Tagesgeschäft erdrückt wird, gibt es eine feste Obergrenze von maximal 50 Prozent für Ops-Tätigkeiten.

Droht die 50-Prozent-Grenze überschritten zu werden, kann das SRE-Team zum Beispiel Tickets an das Produktteam weiterreichen oder dessen Mitglieder in die rotierenden Bereitschaftsdienste aufnehmen, bis die Lage sich entspannt. Das sorgt zum einen dafür, dass das SRE-Team ausreichend Zeit für Automatisierung und Verbesserung hat, und zum anderen, dass es im eigenen Interesse des Produktteams liegt, eine stabile Software in Produktion auszuliefern.

Als weitere Faustregel hat Google definiert, dass ein Mitglied des SRE-Teams in einer Schicht von acht bis zwölf Stunden maximal zwei Incidents zur Bearbeitung bekommt. Wären es mehr, könnte jeder einzelne Fall nicht sauber aufgearbeitet werden:

  • Incident schnell und gründlich behandeln.
  • Das Produkt in einen sauberen Zustand zurückführen.
  • Ein Postmortem-Meeting für den Incident durchführen.

Treten über eine gewisse Zeit gar keine Incidents oder deutlich weniger als zwei pro Schicht auf, kann das SRE-Team hingegen verkleinert werden. Das ist auch der angestrebte Zielzustand. Als Benjamin Sloss bei Google seinerzeit die SRE-Teams ins Leben rief, war das Ziel, Services zu schaffen, die von selbst stabil laufen und sich reparieren.

Wie viel Verfügbarkeit darf‘s denn sein?

Aber was bedeutet „stabil“ eigentlich? Aus Sicht des Betriebs läuft eine Anwendung stabil, wenn es nie oder zumindest nur sehr selten zu Ausfällen kommt. Ein Ausfall bedeutet, dass die Kunden die Anwendung nicht verwenden können. Stabilität wird gemeinhin also über Verfügbarkeit (Availability) definiert.

Benjamin Sloss argumentiert, dass es sinnlos und unnötig teuer ist, eine Verfügbarkeit von 100 Prozent für seine Anwendung anzustreben. Damit sie die Anwendung verwenden können, sind die Kunden auf Infrastrukturkomponenten wie WLAN, Mobilfunknetz oder Internetprovider angewiesen, die alle keine Verfügbarkeit von 100 Prozent haben. Es brächte also nichts, viel Aufwand in eine absolut durchgehende Verfügbarkeit zu investieren, wenn das den Kunden überhaupt nicht auffiele.

Ein weiteres wichtiges Element des SRE-Konzepts ist die Definition einer angestrebten Verfügbarkeit. Das Team definiert sie allerdings nicht selbst, sondern das Produktteam beziehungsweise die Produktverantwortlichen. Ausgehend von der angestrebten Verfügbarkeit wird das sogenannte Error Budget definiert: Error Budget = 100% – angestrebte Verfügbarkeit.

Bei einer angestrebten Verfügbarkeit von 99,99 Prozent bedeutet das ein Error Budget von 0,01 Prozent, was gleichbedeutend mit 7,2 Stunden im Monat ist. Dieses Budget kann für jede Art von Downtime (Changes, Fehler, …) „ausgegeben“ werden und entspannt den Konflikt zwischen Entwicklung und Betrieb, da die beiden damit vom Zero-Downtime-Dogma abrücken.

Playbooks helfen dem SRE-Team im Fehlerfall

Gordon erzählt, dass das Betriebsteam im Fehlerfall aufwendig nach einer Lösung für das Problem gesucht hat und schlussendlich die Entwickler hinzuziehen musste. Immer wenn menschliches Eingreifen notwendig ist, dauert es sehr viel länger, bis das System wieder ordnungsgemäß funktioniert (Mean Time to Repair = MTTR). Auch Google ist sich im Klaren darüber, dass sich menschliche Eingriffe nicht vollständig vermeiden lassen. Damit die dadurch entstehende Verzögerung so kurz wie möglich ist, arbeiten SRE-Teams mit sogenannten Playbooks und sind damit dreimal schneller als ohne. Ein Playbook ist eine Schritt-für-Schritt-Anleitung für auftretende oder mögliche Fehlerszenarien.

Lukas hat Gordon vom Konzept der SRE-Teams berichtet, und die beiden wollen in einer ihrer nächsten Communitysitzungen mal mit den anderen Kollegen diskutieren, inwiefern sich das auf ihren Kontext übertragen lässt.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: