Eine gesunde On-Call-Kultur aufbauen

• SoundClouds Tipps zum „On-Call“-Modell, bei dem ein Engineer festgelegt wird, der bei Problemen außerhalb der Arbeitszeit per Paging alarmiert wird und diese löst

1. On-Call ist freiwillig (optional, nur für Freiwillige).

2. Da es sich um Arbeit außerhalb der regulären Arbeitszeit handelt, wird sie stundenweise vergütet; bei einer Reaktion auf ein Paging erfolgt zusätzlich eine weitere stundenweise Bezahlung.

3. On-Call-Engineers sind in mehrere Rotationen eingeteilt.

4. Jede Rotation besteht aus

→ einer Gruppe von Engineers, die ein oder mehrere Teams repräsentieren

→ genau einem Engineer, der jederzeit Bereitschaft hat und den First-Level-Support für Probleme aller Teams innerhalb der Rotation übernimmt

→ weiteren Engineers, die Bereitschaft haben, um als Second-Level-Support Probleme in den Services ihrer eigenen Teams zu übernehmen

→ Second-Level-Support auf Best-Effort-Basis: Man kann jederzeit per Paging alarmiert werden und hilft nach Möglichkeit so gut wie möglich, muss aber nicht zwingend reagieren, wenn es gerade nicht geht

Warum ist On-Call-Arbeit gut für Engineers?

• Neben DevOps und SREs (Site Reliability Engineers) ist es auch für das Unternehmen und die Engineers selbst vorteilhaft, verschiedene Engineers in den On-Call-Dienst einzubinden.

• Es reduziert die Belastung der Operations-Team-Engineers, die sonst ständig viele Einsätze außerhalb der Arbeitszeit haben.

• Es motiviert Engineers dazu, stabile und gut dokumentierte Systeme aufzubauen.

→ Probleme selbst zu sehen, wenn sie auftreten, liefert Einsichten dazu, wie sich Systeme verbessern und robuster machen lassen.

• Die eigenen Systeme und zugleich die Systeme anderer zu unterstützen, ist für Engineers eine gute Lerngelegenheit.

Verfahrensbezogene Best Practices: Jede Organisation ist anders, aber dies ist der Prozess, den SoundCloud als optimal gefunden hat.

• Die Schichtzyklen unterscheiden sich je nach Rotation, meist wird aber täglich oder alle zwei Tage gewechselt.

• Optimal sind etwa 3 On-Call-Tage pro Monat. Mehr als das führt zu Burnout, weniger ist nicht effizient.

→ Das heißt: Die optimale Größe einer Rotation liegt bei 8 bis 12 Personen. Mit 10 ist es ideal.

• Innerhalb einer Rotation werden formelle oder informelle Verantwortliche bestimmt, die die Rotation verwalten, etwa Dienstpläne und personelle Änderungen.

→ Beispiel: Anpassungen des Schichtplans während Feiertagszeiträumen

Rotationsteams und Organisationen

• Die Organisation von SoundCloud hat sich im Lauf der Zeit weiterentwickelt; es gab Zusammenlegungen, Aufteilungen, neue Teams und Teamwechsel zwischen Abteilungen.

• Die On-Call-Rotationsteams haben sich jedoch nicht im gleichen Tempo wie die Engineering-Organisation weiterentwickelt.

• Heute wirken viele Rotationen teilweise wie zufällige Gruppen völlig unzusammenhängender Teams.

• Das ist aber kein Problem, und Versuche, das zu ändern, wurden eingestellt, nachdem Engineers Einwände erhoben hatten.

Kulturelle Best Practices: Zum Nutzen der On-Call-Engineers und des gesamten Unternehmens sollten folgende Normen und Haltungen gefördert werden.

• Menschen im On-Call-Dienst wollen dort sein. Engineers, die freiwillig Verantwortung übernehmen (und dafür kompensiert werden), sind bei der Reaktion auf Incidents stärker motiviert.

• Fragen wie der Schichtzyklus werden von den Engineers jeder Rotation gemeinsam entschieden. Das Unternehmen gibt keine Standardverfahren für Schichtmuster, Wechselzeitpunkte oder die Übergabe zwischen einzelnen Personen vor.

• On-Call-Engineers verwenden innerhalb der regulären Arbeitszeit oft Zeit darauf, diese Probleme zu untersuchen, damit sie nicht eskalieren oder dazu führen, dass andere außerhalb der Arbeitszeit per Paging alarmiert werden müssen.

• Bei der Incident Response können Engineers andere Engineers hinzuziehen und um Hilfe bitten. Niemand freut sich über einen nächtlichen Second-Level-Support-Alarm, aber wenn es möglich ist, hilft man durch eine Reaktion mit, sodass die betroffene Person später ähnliche Situationen allein bewältigen kann.

• Nach einer angemessenen Zeit kann Arbeit ohne Weiteres an andere übergeben werden. Bei schweren oder lang andauernden Incidents gilt: Wenn Engineers zu erschöpft sind, um effizient weiterzuarbeiten, sollte die Übergabe nach 4 Stunden oder auch früher erfolgen.

• Am wichtigsten ist es, „eine Lernkultur statt einer Kultur der Schuldzuweisung zu fördern“. Das kann man kaum genug betonen.

→ Fehler sind ein unvermeidlicher Teil der Incident Response, und wenn man aus ihnen lernt, entsteht eine stärkere und technisch kompetentere Engineering-Organisation.

→ Wenn Menschen für Fehler bestraft werden, bekommen Engineers Angst, in neuen Situationen zu handeln, um Hilfe zu bitten und transparent zu sein.

→ Am Ende führt eine Kultur der Schuldzuweisung dazu, dass Menschen die On-Call-Rotation verlassen oder das Unternehmen ganz verlassen.

Wenn ein großer Incident eintritt

• Auf einen vollständigen Site-Ausfall oder einen schweren Incident zu reagieren, ist für alle stressig.

• Das ist zugleich auch ein Stresstest für die On-Call-Kultur des Unternehmens.

• Dass Engineers zusammenarbeiten und einander vertrauen, ist wichtiger als alles andere.

• Wenn man zugeben kann, etwas nicht zu wissen, andere um Hilfe bitten kann, ehrlich über eigene Fehler spricht und sagen kann, dass man zu erschöpft ist, um weiterzumachen, lassen sich Probleme schneller lösen.

• Solches Verhalten muss gefördert werden, bevor ein großer Incident auftritt. Engineers lernen dies durch Erfahrung, indem sie auf kleinere Incidents reagieren und mit Kolleginnen und Kollegen zusammenarbeiten.

→ Kleine Incidents sind Übung für große Incidents.

[xguru]

• Die von GitHub aufgebaute On-Call-Kultur https://de.news.hada.io/topic?id=3551

• GitLab On-Call Runbooks https://de.news.hada.io/topic?id=966

In Startups hat man das Gefühl, immer On-Call sein zu müssen, weil es an Leuten fehlt..

Sobald die Organisation etwas größer wird, sind dann oft nur noch einige wenige ständig On-Call, und man sieht, wie sie ausbrennen, während sie auch abends und am Wochenende Probleme lösen.

Im Grunde scheint es wichtig zu sein, von Anfang an eine gute Kultur zu etablieren (eigentlich habe ich das selbst wohl auch nicht gut hinbekommen, weshalb ich gerade darüber nachdenke..)