Die On-Call-Kultur, die GitHub aufgebaut hat
(github.blog)GitHub war ein großes monolithisches System, das auf Ruby on Rails basierte.
Der schwierigste Teil der On-Call-Struktur im Monolithen
-
Da es viele große Produkte und Funktionen umfasste, waren die meisten Engineers nicht sicher, ob sie die Codebasis gut genug verstanden, um während des On-Call-Dienstes auf Störungen reagieren zu können. Wenn sie alarmiert wurden und an ein anderes Team eskalieren mussten, fühlten sie sich eher wie eine Vermittlungsstelle als wie Engineers.
-
Die Abstände zwischen den On-Call-Diensten waren lang, und ein Dienst dauerte jeweils 24 Stunden. Engineers hatten höchstens viermal im Jahr On-Call und konnten währenddessen nicht genug Kontext aufbauen.
-
Monitoring und Alerting waren auf verschiedene Teams verteilt, und da man On-Call jeweils nur 24 Stunden erlebte, wurden On-Call-Monitoring und Dokumentation nicht gut gepflegt.
-
Da die meisten Engineers wenig Vertrauen in den monolithischen On-Call-Dienst hatten, beteiligten sich am Ende die 5 bis 10 Personen mit dem besten Gesamtüberblick an allen Produktionsstörungen, was zu einer ungleichen Verteilung der On-Call-Verantwortung führte.
Eine neue On-Call-Kultur
Organisatorische Hürden
-
Um die File-Ownership klar zu machen, wurde ein Servicekatalog erstellt, der Dateien Services zuordnete und diese Services wiederum Teams zuordnete.
-
Monitoring und Benachrichtigungen waren für den gesamten Monolithen eingerichtet, daher wurde jedes Team dazu gebracht, Monitoring für den Bereich zu erstellen, für den es verantwortlich ist.
-
Da viele Teams diese Arbeit erledigen mussten, wurde für jedes Team ein GitHub-Issue angelegt und eine Checkliste bereitgestellt.
Kulturelle und pädagogische Hürden
-
Die Pandemie hatte negative Auswirkungen auf die Menschen, daher war ein stärker empathieorientierter Ansatz nötig als ursprünglich gedacht.
-
Die meisten Engineers hatten weder On-Call-Erfahrung noch viel Betriebserfahrung, daher wurden Schulungen entwickelt und angeboten. Es wurden Sprechzeiten mit On-Call-Expert:innen eingerichtet, ausreichend Tools und Dokumentation bereitgestellt und ein Slack-Kanal geschaffen, in dem man Hilfe bekommen konnte.
-
Viele Engineers sorgten sich darum, wie stark On-Call ihr Leben beeinflussen würde. Wenn man wenig Erfahrung hat, kann es schwierig sein, den Alltag während des On-Call-Dienstes anzupassen. Deshalb wurden Tipps und Tricks von On-Call-Expert:innen gesammelt und Maßnahmen eingeführt, etwa dass jemand anderes einspringen kann, wenn ein Alarm verpasst wird. Das ist vor allem eine Frage der Gewöhnung, daher wird man sich eher durch wiederholte On-Call-Erfahrung mit der Zeit wohler fühlen als allein durch Training.
-
Da viele Angst hatten, On-Call nicht gut zu bewältigen, versucht man ein Gefühl von Sicherheit zu vermitteln: Fehler zu machen ist in Ordnung, und Störungen lassen sich selbst bei bester Arbeit nicht vollständig vermeiden.
-
Je nach Produkt gibt es unterschiedliche Schweregrade, daher müssen manche Teams innerhalb von 5 Minuten reagieren, während andere Themen auch am nächsten Tag bearbeitet werden können. Manche halten das für unfair, aber letztlich haben Engineers einfach unterschiedliche Interessengebiete.
-
Während diese Veränderungen eingeführt werden, können die Teams nicht viel Zeit darauf verwenden, die On-Call-Erfahrung zu verbessern. Wenn On-Call nicht richtig funktioniert, muss der On-Call-Prozess verbessert werden. Den Teams wurde vermittelt, dass etwa 20 % für den Abbau technischer Schulden und etwa 20 % für die Verbesserung der On-Call-Erfahrung verwendet werden sollten, und dafür ist eine langfristige Perspektive der Führung nötig.
4 Kommentare
Ich weiß ungefähr nicht, was mit On-Call gemeint ist ... Geht es vielleicht um Supportanfragen? Es ist vermutlich nicht so wie bei uns in Korea die telefonische Kundenbetreuung ...
Bei uns im Unternehmen bedeutet On-Call in der Regel, etwa eine Woche lang alle zwei Monate auch außerhalb der Arbeitszeit in Echtzeit auf Systemstörungen zu reagieren. Häufig wird dafür eine App namens PagerDuty verwendet: Wenn eine Störung mit hoher Severity auftritt – zum Beispiel wenn sich Dead Letters ansammeln oder die API-Failure-Rate einen bestimmten Schwellenwert überschreitet – kommt sofort ein Alarm aufs Handy, und man verbindet sich über den Firmenlaptop, prüft die Logs und ergreift die nötigen Maßnahmen.
Man kann es sich wie Bereitschaftsdienst vorstellen.
Fühlt sich ungefähr wie Bereitschafts- oder Wochenvertretung an. Die Störungsbehebung wird reihum übernommen..