On-Call bzw. Rufbereitschaft: Eine ewige Hass-Liebe?
Software-Engineers entwickeln die Applikationen. Doch wer maintained diese und bringt diese wieder zurück ins Leben, wenn die Applikationen mal abstürzen? Im klassischen Sinne sind das System-Administratoren. Und für die meisten in diesem Beruf gehört On-Call dazu. Doch ist dies auch im modernen Dev-Ops-Umfeld und in Voll-Autonomen Teams der Fall? Welche Herausforderungen gibt es beim On-Call? Sollten Software-Engineers genauso auf Rufbereitschaft sein? Wie sieht ein strukturierter On-Call-Prozess aus? Und was muss getan werden, um einen solchen zu etablieren? Und welche Modelle zur Bezahlung bzw. Kompensation gibt es, wenn man auch nach der Arbeit für seine App gerade steht?
All das und noch viel mehr gibt es in dieser Episode.
Bonus: Was Pager mit Tamagotchi zu tun haben und ob On-Call zu einer Handy-Phobie führt.
Schaut vorbei in unserer neuen Community: https://engineeringkiosk.dev/join-discord
Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners
Das schnelle Feedback zur Episode:
Links
- Engineering Kiosk #17 Was können wir beim Incident Management von der Feuerwehr lernen?: https://engineeringkiosk.dev/podcast/episode/17-was-k%C3%B6nnen-wir-beim-incident-management-von-der-feuerwehr-lernen/
- PagerDuty: https://www.pagerduty.com/
- OpsGenie: https://www.atlassian.com/de/software/opsgenie
- Being On-Call @ PagerDuty: https://response.pagerduty.com/oncall/being_oncall/
Sprungmarken
Hosts
- Wolfgang Gassler (https://mastodon.social/@woolf)
- Andy Grunwald (https://twitter.com/andygrunwald)
Feedback (gerne auch als Voice Message)
- EngKiosk Community: https://engineeringkiosk.dev/join-discord
- Email: stehtisch@engineeringkiosk.dev
- Mastodon: https://podcasts.social/@engkiosk
- Twitter: https://twitter.com/EngKiosk
- WhatsApp +49 15678 136776
Transkript
Andy Grunwald (00:00:03 - 00:00:16) 
All das macht dich zu einem deutlich besseren Software-Ingenieur. Und speziell, wenn du als Software-Ingenieur für die Software nachts aufstehen musst, die du selbst schreibst, lässt sich ganz anders darüber nachdenken, wie deine Software eigentlich auf die Nase fallen kann.
Wolfi Gassler (00:00:17 - 00:00:44)
Und damit willkommen zu einer neuen Episode im Engineering Kiosk zum Thema On-Call und Rufbereitschaft. Wir besprechen die rechtliche und organisatorische Seite, die technische Umsetzung und vor allem die psychologische Komponente. Denn die Frage ist ja, kann man On-Call auch nicht hassen? Oder macht es uns, wie Andi sagt, auch zu besseren EntwicklerInnen? Und braucht die Agentur von nebenan eigentlich eine Rufbereitschaft? Wie überzeugt man denn das Management? Und noch viele andere Tipps aus der Praxis.
Andy Grunwald (00:00:44 - 00:00:51)
Los geht's! Wie weit ist dein Handy aktuell von dir entfernt?
Wolfi Gassler (00:00:52 - 00:00:55)
Musst du das in Millimetern wissen oder in Armlänge?
Andy Grunwald (00:00:56 - 00:01:08)
In Armlänge? Also kommst du da jetzt gerade dran und hast du es sogar mit dem Bildschirm nach oben hingelegt. Also das bedeutet, wenn das jetzt aufleuchtet, wechselst du die Kopfrichtung und so weiter.
Wolfi Gassler (00:01:08 - 00:01:18)
Ich habe die volle Konzentration auf dich, Andi. Was denkst du? Natürlich, das liegt flach am Boden, ist leise gestellt, wie sowieso immer bei mir. Und meine Aufmerksamkeit gilt nur dir.
Andy Grunwald (00:01:19 - 00:01:20)
Aber es ist in Armlänge, oder?
Wolfi Gassler (00:01:20 - 00:01:21)
Es ist in Armlänge, natürlich.
Andy Grunwald (00:01:22 - 00:01:29)
Das bedeutet, wenn man da jetzt eine SMS hinschicken würde oder anrufen würde, dann könnte man dich, glaube ich, nicht erreichen. Also zumindest jetzt gerade nicht.
Wolfi Gassler (00:01:29 - 00:01:31)
Genau, wie es eigentlich immer ist bei mir.
Andy Grunwald (00:01:31 - 00:01:33)
Warst du schon mal auf Rufbereitschaft?
Wolfi Gassler (00:01:33 - 00:01:40)
Hallo, ich bin bei der Feuerwehr, ich bin immer auf Rufbereitschaft. Also bei einem Feuerwehreinsatz würde jetzt mein Pädscher neben mir läuten und vollen Radau machen.
Andy Grunwald (00:01:40 - 00:01:44)
Also hast du immer zwei Devices mit dir, dein Handy und dein Pager?
Wolfi Gassler (00:01:44 - 00:01:48)
Theoretisch, wenn ich in der Nähe bin, also nahe der Feuerwehr dann schon, ja.
Andy Grunwald (00:01:48 - 00:02:06)
Kannst du mir mal ganz kurz erklären, oder vielleicht auch Hörern, die noch nicht so alt sind, was ein Pager ist? Ist das sowas wie ein Tamagotchi? Okay, junge Hörer und Hörerinnen wissen auch nicht, was ein Tamagotchi ist, ne? Also, ich mein, erklär mal ganz kurz, was ein Pager ist und wie der kommuniziert. Welches Protokoll und so weiter. Läuft das auch über GSM?
Wolfi Gassler (00:02:06 - 00:02:24)
Ja, das ist ein eigenständiges Netz, bei uns in Österreich zumindest. Und ist einfach ein kleines Device, was mehr oder weniger SMS empfangen kann. Ist nichts anderes. Macht einen Lärm und zeigt dir eine Textnachricht an. Und läuft über ein eigenes Protokoll, eher niedrige Frequenz, dass es weniger Masten braucht.
Andy Grunwald (00:02:24 - 00:02:33)
Ich meine mich ... zu erinnern dass es auch firmen gibt die ihre klassische hochbereitschaft auch on call genannt auch über pager noch fahren.
Wolfi Gassler (00:02:33 - 00:02:48)
Ist natürlich nicht so dumm weil diese dinger sind super stabil stürzen nie ab brauchen extrem wenig strom mit mit einem akku der hält tagelang bis eine woche wie so ein altes klassisches nokia handy hält lang kann nicht viel aber kann ja textanzeigen.
Andy Grunwald (00:02:49 - 00:03:00)
Ich hab grad auch irgendwie an so Nokia 3310 oder so was oder 8210 irgendwie diese ganz kleinen Dinger gedacht, die irgendwie hast du einmal eingestöpselt, geladen und dann hast du irgendwie zwei Wochen ein Telefon gehabt.
Wolfi Gassler (00:03:00 - 00:03:20)
Aber die meisten Pager, die es heutzutage wahrscheinlich gibt, laufen trotzdem übers GSM-Netz vermute ich mal und sind einfach SMS-gesteuert. Früher hat es da ja so eigene Pager gegeben, bevor es Handys gab, die wieder über eine eigene Frequenz gelaufen sind. Und da hat man dann in der Telefonzelle so einen Service angerufen, hat ein Texttuch gegeben und dann hat der Freund diese Textnachricht bekommen. Aber das war vielleicht auch vor deiner Zeit.
Andy Grunwald (00:03:20 - 00:03:25)
Ich hatte noch nie einen Pager. Also ich hatte schon mal einen in der Hand, aber ich habe noch nie einen besessen oder aktiv genutzt.
Wolfi Gassler (00:03:26 - 00:03:30)
Aber hattest du keine Freunde mit Pager, die man dann irgendwie informiert hat über so eine Telefonhotline?
Andy Grunwald (00:03:31 - 00:03:47)
Also bei uns also ich meine mich erinnern zu können dass ich sag mal die generation über uns oder zwei generationen über uns zu meiner jugend irgendwie sowas hatte aber du weißt ja das waren die coolen und und da wollte man immer irgendwie mit interagieren aber hat man halt auch nicht.
Wolfi Gassler (00:03:47 - 00:04:17)
Zwei generationen über dir das heißt die die die alten danke. Zwei Generationen. Na, man hat früher einfach dann einen Monatsbeitrag gezahlt. Ich kann mich leider nicht mehr erinnern, wie viel das war. Und dann hat man Textnachrichten empfangen können. Das war vor der Handyzeit. Und wenn du was ausgemacht hast mit Freunden, dann hast du denen so eine Nachricht gesendet. Und wenn ich eine Nachricht senden wollte, habe ich bei einer Telefonhotline angerufen, mit einer netten Dame gesprochen, habe der den Text durchgesagt, die hat es abgedippt und hat dann diese SMS an diese Person gesendet.
Andy Grunwald (00:04:17 - 00:04:45)
So wie du das schon beschreibst, stell ich mir recht spaßig vor, weil eigentlich ist es ja nichts anderes, als wenn du wie bei AWS, Google Cloud Platform oder Azure, ein Ticket aufmachst. Weil wenn du bei Microsoft Azure ein Support-Ticket aufmachst, da kommt erst mal, vielen Dank, aber leider hast du keine Telefonnummer gesendet, ich würde gern mit dir darüber sprechen. Und das ist dann kein Microsofts Game. Also Azure versucht dich oft anzurufen, wohingegen du bei Amazon sehr wahrscheinlich ein Ticket sendest und dann musst du fünfmal hocheskalieren, bis du mal eine ordentliche Antwort kriegst.
Wolfi Gassler (00:04:45 - 00:04:57)
Ja, manchmal wäre ich froh, wenn ich irgendwen anrufen könnte und telefonieren könnte. Wenn man da teilweise in irgendwelchen Chatbots oder so gefangen hängt oder mit irgendwelchen First-Level-Supports fünf E-Mails austauschen muss.
Andy Grunwald (00:04:57 - 00:05:10)
Kommen wir mal zu dem Thema der heutigen Episode. Und deswegen habe ich nämlich auch gefragt, wo dein Handy ist und wie das da liegt. Und zwar geht es nämlich um On-Call-Rufbereitschaft und die Phobie und die Handyphobie.
Wolfi Gassler (00:05:11 - 00:05:12)
Was ist denn die Handyphobie?
Andy Grunwald (00:05:12 - 00:05:16)
Die Handyphobie ist ganz einfach, wenn man On-Call ist, dann hofft man einfach, dass es nicht klingelt.
Wolfi Gassler (00:05:17 - 00:05:21)
Aber wenn du eine Handyphobie hast, hast du ja Angst vorm Handy, dann sollte es aus Rechnen in Rufbereitschaft gehen.
Andy Grunwald (00:05:21 - 00:06:09)
Und immer wenn ich über das Thema On-Call beziehungsweise Rufbereitschaft spreche, dann schauen mich immer ganz viele Leute an, boah ne, weil ich treffe nämlich irgendwie immer nur Leute, die fragen sich, muss das sein und wie kann man On-Call nicht so beschissen machen? Dennoch ist das ein Riesenthema, besonders für aktuelle Applikationen, weil alle Applikationen werden irgendwie deutlich komplexer und haben fünf, sechs Engineering-Teams dahinter und Microservices und was weiß der Geier nicht. Und auch klassische Systemadministratoren haben Probleme beziehungsweise starke Herausforderungen, die ganze Sache online zu halten. Und deswegen haben wir mal gedacht, wir sprechen mal einfach darüber. Was ist das? Wer braucht das? Was für Herausforderungen gibt es denn im Rufbereitschaftsmodus? Wie setzt man das Ganze auf? Und wie wird man dann zum Beispiel die Rufbereitschaftsphobie einfach mal los?
Wolfi Gassler (00:06:09 - 00:06:17)
Also ich kenne durchaus Leute, die die Rufbereitschaft schätzen, weil es doch ein ordentlicher Teil von ihrem Gehalt ist, der dann nach oben geht.
Andy Grunwald (00:06:17 - 00:06:26)
Lass uns zum Bereich der Kompensation gleich kommen, weil ich kenne nämlich auch Leute, die sagen, das Geld ist zwar schön, aber den Stress, den du dir da ins Haus holst, der ist im Endeffekt nicht wert.
Wolfi Gassler (00:06:27 - 00:07:01)
Man merkt auf jeden Fall schon, dass das ein sehr ambivalentes Thema ist und eben nicht von jedem so geschätzt wird. Und ich habe ehrlich gesagt das erste Mal, wie ich damit Kontakt hatte, mit dieser ganzen Rufbereitschaft, auch persönlich eigentlich wenig Stress, weil ich das irgendwie schon seit jeher kenne, als Selbstständiger, als Feuerwehrmitglied. Da ist man irgendwie ständig mit dem in Kontakt. Und mir war das dann neu, dass das so viel Stress hervorruft. Und für ganz viele Leute ist das natürlich ein extremer Einschnitt in der Lebensfreiheit, wenn man das mal so sagen kann. Und darum soll es eben heute auch gehen.
Andy Grunwald (00:07:01 - 00:07:10)
Aber lasst uns mal bitte ganz vorne anfangen. Und zwar erklärt den Hörerinnen und Hörern noch mal bitte, was ist eigentlich On-Call- bzw. Rufbereitschaft und was bedeutet dies?
Wolfi Gassler (00:07:11 - 00:08:06)
Vermutlich gibt es gar nicht die Erklärung für das Ganze, weil es da natürlich ganz viele Formen gibt und es ist natürlich ein großer Unterschied, ob du jetzt lospringen musst, wie bei der Feuerwehr, wenn es irgendwo brennt und sofort dort sein musst, so schnell wie möglich, oder wenn da irgendwo mal die Festplatte voll läuft, dass du da innerhalb 1-2 Stunden reagieren musst. Also es sind schon ganz unterschiedliche die alle unter dem Schlagwort On-Call gesammelt werden. Also im Prinzip geht es einfach darum, dass man erreichbar ist für einen Schadensfall bei der Feuerwehr, für ein Ereignis in der Firma, für irgendein Problem, was auftritt bei einem Kunden, was es auch immer ist, dass man erreichbar ist für ein automatisches Service, das Alarm schlägt, für einen Kunden, der Alarm schlägt, auch da wieder ganz egal, was das ist, aber dass man einfach nur erreichbar ist und im Problemfall wenn man ein Ereignis hat, darauf reagieren kann, in welcher Zeit es dann auch immer ist.
Andy Grunwald (00:08:06 - 00:08:32)
Naja, in unserem Kontext ist es halt in der Regel, wenn irgendwie deine Applikation nicht mehr funktioniert oder die offline ist oder oder oder. Also das ist halt so in der Regel der klassische Anwendungsfall von Software-Engineers. Du sagtest gerade, wenn irgendwas in der Firma ist, wenn die Schließanlage vom Büro nicht mehr funktioniert, dann ist das jetzt für mich keine SMS auf mein On-Call-Handy wert. Also von daher denke ich schon, dass wir uns eher im Bereich Business-Applikation beschränken.
Wolfi Gassler (00:08:33 - 00:08:42)
Naja, wenn du in einem IT-Team sitzt, was verantwortlich ist für die Schließanlage und das ein großer Konzern ist mit Produktion oder sonst was, dann wirst du da auch eine Rufbereitschaft haben.
Andy Grunwald (00:08:42 - 00:08:49)
Ja, fair enough. Falls uns wer zuhört, der genau diesen Job hat, schreibt mir mal bitte eine E-Mail. Ich habe so viele Fragen.
Wolfi Gassler (00:08:49 - 00:09:03)
Ich glaube vor allem in kleineren IT-Teams ist es heutzutage sehr wohl der Fall, weil die sind einfach für alles verantwortlich und die werden einfach angerufen, egal ob das der Fall ist, wenn ein Drucker nicht funktioniert, wenn die Schließanlage nicht funktioniert oder wenn der Server down ist.
Andy Grunwald (00:09:03 - 00:09:23)
Dafür gibt es noch offiziell einen Begriff? Und zwar, bei uns ist Rufbereitschaft kompliziert. Geh doch mal zu kleinen Agenturen oder zu kleinen Firmen und frag mal, habt ihr Rufbereitschaft? Die werden Nein sagen, dann werden sie kurz nachdenken und sagen, scheiße, doch. Und dann fragst du, ist das denn bezahlt oder habt ihr Urlaubsausgleich dafür oder ähnliches? Und dann heißt es, ja, es ist kompliziert.
Wolfi Gassler (00:09:24 - 00:09:45)
Ich glaube, da braucht man gar nicht so klein sein. Also ich habe da auch schon sehr große Firmen erlebt, die genau mit diesem Konzept eigentlich sehr lange gefahren sind. Was ja auch vollkommen in Ordnung ist, wenn alle damit einverstanden sind. Aber worüber wir heute sprechen wollen, ist wirklich die strukturierte, organisierte On-Call-Bereitschaft, die auch vielleicht vertraglich festgelegt ist.
Andy Grunwald (00:09:45 - 00:10:13)
Unserer Perspektive nach gibt es bei der organisierten Rufbereitschaft eigentlich drei Bereiche, die man primär abdecken sollte auf der ersten stelle steht das rechtliche und das organisatorische also die kosten das management die zweite herausforderung wäre die psychische challenge also die leute an bord holen wie setzt man das ganze im team um und das dritte ist eher so die low hanging fruit beziehungsweise der punkt wo jeder daran denkt die technische umsetzung also das wirkliche alerting.
Wolfi Gassler (00:10:14 - 00:11:09)
Und man unterschätzt das Technische vielleicht immer, weil man sagt, okay, wir kennen das ja sowieso alle, Alerting, das ist alles leicht umgesetzt. Aber wenn man das Technische natürlich nicht sehr smooth umsetzt, dass alle da einen reibungslosen Ablauf, Alarmierung und so weiter haben, dann kann es natürlich auch einen extremen Overhead bedeuten oder einen Schmerz dann bei den Teammitgliedern, wenn sie on call sind. Also auch da wieder eine gute Umsetzung kann viel Schmerzen verhindern. Aber steigen wir mal in die rechtliche und organisatorische Challenge ein. Und da hast du ja schon erwähnt, das ganze Management von dem Ganzen. Und da spielt ja auch das Management an sich eine Rolle von der Firma. Und da war jetzt meine Frage, wer braucht denn überhaupt On-Call? Jetzt hast du die kleine Firma schon erwähnt, bei der das irgendwie so mitläuft. Aber wer braucht denn ein strukturiertes, organisiertes On-Call-System, wo man sich wirklich mal Gedanken drüber macht und nicht einfach, es funktioniert ja eh so irgendwie.
Andy Grunwald (00:11:09 - 00:11:47)
Meiner Meinung nach jede Firma, die jetzt bezogen auf unseren Job, auf Software Engineering, ein digitales Produkt als den Hauptanteil fürs Einkommen oder einen großen Teil des Firmeneinkommens abdeckt. Das bedeutet einen Online-Shop, eine Software-as-a-Service-Plattform, eine Webseite, eine iOS-App, gut, die iOS-App jetzt nicht selbst, aber das Backend dahinter, Cloud-Infrastruktur, oder oder oder also eigentlich und das muss nicht unbedingt direkter revenue sein das kann auch indirekter revenue sein damit meine ich zum beispiel die kompletten plattformen die innen dienstlern nutzen um mit den außen dienstlern zu kommunizieren.
Wolfi Gassler (00:11:48 - 00:12:00)
Und was ist jetzt wenn ich ein produzierendes gewerbe habe ich mache zum beispiel sparen platten was ist da mit den ganzen digitalen systeme die ich für die produktion brauche vom system über die steuerung meiner ganzen produktionslinie.
Andy Grunwald (00:12:01 - 00:12:39)
Ja, das fällt ja genau damit rein. Das habe ich ja gesagt, so nach dem Motto, nicht Direktrevenue, aber Indirektrevenue. Also du willst ja deine Sparenplatten verkaufen und irgendwie müssen die Sparenplatten hergestellt werden. So, und wenn du dann jetzt den 24-7-Betrieb davon hast, dann hast du da natürlich auch in irgendeiner Arbeitsrufbereitschaft werden. Bin ich mir jetzt nicht sicher, ob das dann nicht eher Ingenieure sind oder Software-Engineers, kenne ich mich jetzt nicht so aus. Aber eigentlich gibt es fast in jeder Firma diese Art von Rufbereitschaft. Und wir können uns jetzt hier, denke ich mal, getrost auf digitale Systeme spezialisieren oder vielleicht sogar auf Web-Systeme und Cloud-Native-Systeme, weil sonst kannst du dich aus dem Fenster lehnen und sagen, okay, jeder braucht Rufbereitschaft. Vielleicht ist das auch fast so, dass jeder Rufbereitschaft braucht, ja.
Wolfi Gassler (00:12:40 - 00:13:02)
Also ich glaube auch, dass eigentlich fast jeder Rufbereitschaft braucht. Die Frage ist immer, was sind dann die Reaktionszeiten und wie organisiert ist das Ganze und wie festgeschrieben ist das Ganze. Aber wenn wir jetzt schon sagen, jeder braucht Rufbereitschaft, wer ist denn jetzt auf Rufbereitschaft? Ist es Management auf Rufbereitschaft? Ist der klassische Admin auf Rufbereitschaft? Was sind denn die typischen Anwendungsfälle?
Andy Grunwald (00:13:02 - 00:13:36)
In den Firmen, in denen ich bisher gearbeitet habe, hat es immer so gestartet, dass die Systemadministratoren, also die Betriebsabteilung, die Operations immer ganz klassisch auf Rufbereitschaft sind. Und das hat auch am Anfang bzw. am Anfang der Firma immer sehr, sehr gut geklappt. Aber was man immer wieder gesehen hat, umso weiter die Entwicklung gegangen ist, umso mehr Leute eingestellt wurden, umso größer die Plattform wurde. desto herausfordernder wird der betrieb dieser plattform und irgendwann ging es sogar soweit dass systemadministratoren einfach nur noch neu starten konnten und nicht das wirkliche problem beheben konnten.
Wolfi Gassler (00:13:37 - 00:13:38)
Und wie hat sich das dann geändert?
Andy Grunwald (00:13:38 - 00:14:09)
Naja gut, irgendwann wurde halt mal der Bedarf größer von Leuten mit in die Rufbereitschaft zu holen, die sich dann wirklich damit auskennen, sogenannte Subject Matter Experts. Und die wurden dann vielleicht nicht als first in line eingesetzt, sondern du hattest dann immer noch die Systemadministratoren vorne dran, aber wenn ein Neustart nicht mehr geholfen hat, Dann wurden halt die Subject Matter Experts angerufen. Die waren dann halt jetzt nicht wirklich auf On-Call, sondern eher so, ja, Best Guess, wenn du so möchtest. Wenn jemand irgendwie auf einer Party war, dann war es halt schwierig, aber... Und.
Wolfi Gassler (00:14:09 - 00:14:15)
Das sind dann klassische Entwickler, wenn man jetzt von der Software spricht, wenn man jetzt irgendeine Web-Software, SaaS oder sonst irgendwas hat?
Andy Grunwald (00:14:15 - 00:14:21)
In der Regel waren das klassische Entwickler oder halt Leute aus dem weiteren Umfeld, die sich dann zum Beispiel mit einer speziellen Datenbanktechnologie gut auskannten.
Wolfi Gassler (00:14:22 - 00:14:45)
Das heißt, First Level sozusagen sind die klassischen Admins, die eine Checkliste haben, was sie machen können. Kann ich das Service neu starten? Ist irgendwo der Speicher einfach voll gelaufen? Muss ich irgendwo was hochskalieren? Oder nehme ich einfach mal die Daten auf, den aktuellen Stand? Was ist denn das Problem? Und die entscheiden dann und rufen im Falle zum Beispiel einen Entwickler an, wenn sie das Problem selbst nicht mehr lösen können.
Andy Grunwald (00:14:45 - 00:15:14)
Ja sowas bisher das war aber nicht wirklich organisatorisch geregelt ja also das bedeutet motivierende entwickler haben dann ihre handynummer auf basis von anfragen rausgegeben aber da war jetzt nicht wirklich was geregelt persönlich habe ich eine meinung dass entwickler und software engineers mit ein teil der rufbereitschaft sein sollen die ganze sache ist meines erachtens noch recht neu in deutschland und. schon sehr sehr weit verbreitet in Amerika. Mein Hauptgrund ist eigentlich immer, man wird dadurch ein besseres Software-Ingenieur.
Wolfi Gassler (00:15:14 - 00:15:27)
Aber heißt es dann, dass beide auf Rufbereitschaft sind und dann automatisch immer gepaged werden, wenn es ein Problem gibt, das heißt der Entwickler und der Admin oder die teilen sich die Arbeit, also wie läuft das dann in der Praxis ab?
Andy Grunwald (00:15:27 - 00:15:30)
Der Entwickler ist alleine auf Rufbereitschaft, also dann nicht beide.
Wolfi Gassler (00:15:30 - 00:15:36)
Das heißt, der Entwickler muss auch die ganzen Server-Dinge kennen, die Infrastruktur, wie er damit umgeht?
Andy Grunwald (00:15:36 - 00:17:31)
Kurze Antwort ja, längere Antwort, und genau das ist das, was ich meine, dass man dadurch ein besseres Software-Engineer wird. Als Software-Engineer fokussiert man sich in der Regel nur auf die Entwicklung seines Features, Fixing eines Bugs oder ähnliches. Vielleicht hat man noch einen Deploy-Knopf, aber wenn du mal ein bisschen links und rechts von deinem Entwickler-Dasein guckst, links wäre dann so die Ecke, du deployst eine neue Version und bist danach in der Lage, eure Datenbank zu fragen, wie wird eigentlich mein neues Feature genutzt, um die ersten KPIs zu kriegen und rechts, wie verhält sich eigentlich mein neues feature performance mäßig ist die cpu angestiegen wird mehr ramp verbraucht wie viel prozent der anfragen werden eigentlich erfolgreich beantwortet und so weiter das bedeutet man ist ein bisschen gezwungen links und rechts zu gucken und dadurch fängt man automatisch an sich mehr für die infrastruktur zu interessieren wie funktioniert eigentlich das monitoring Was passiert eigentlich bei einem Deployment? Welche Datenbank habe ich eigentlich hinten dran? Wird unsere Applikation aus mehreren Availability Zones oder sogar Regions, wenn man das zum Beispiel in der Cloud betreibt, ausgeliefert? Haben wir ein CDN? Wie viele Bilder werden im CDN eigentlich angefragt und laufen in 404, also File Not Found und so weiter und so fort? Umso mehr man auf diese Metriken guckt und umso mehr man versucht, eine Sinnhaftigkeit aus seiner Arbeit herauszuziehen und auch wirklich zu verstehen, was hab ich für einen Impact? Wow, ich hab grad ein Feature geschippt, was grad wirklich benutzt wird. Desto mehr wird die eigene Kreativität, gegebenenfalls mehr Metriken einzuführen, die interessante Fragen beantworten können. Und so fängst du halt an, wie mach ich eigentlich eine neue Metrik? Wie setz ich eigentlich einen Alert darauf auf? Und so weiter und so fort. Und all das, irgendwann beschäftigst du dich halt mit dem Architekturbild. Und genau das ist natürlich ein Prozess über Wochen, Monate, vielleicht sogar Jahre. Es ist jedoch so, all das macht dich zu einem deutlich besseren Software-Engineer. Und speziell, wenn du als Software-Engineer für die Software nachts aufstehen musst, die du selbst schreibst, lässt sich ganz anders darüber nachdenken, wie deine Software eigentlich auf die Nase fallen kann.
Wolfi Gassler (00:17:31 - 00:18:08)
Du hast schon extrem viele Positionen erwähnt, die on call sein sollten. Admins, Software Engineers, vielleicht ganz allgemein Subject Matters Experts. Da werden jetzt viele Leute nicht sehr glücklich sein, wenn du da alle erst ins Bett holst in der Nacht. Woher kommt denn so der Antrieb On-Call strukturierter zu machen oder überhaupt in einem ordentlichen Prozess aufzusetzen? Also wie du erwähnt hast in der Agentur, das funktioniert schon irgendwie so und jetzt einen richtig gut organisierten, niedergeschriebenen Prozess. Wie kommt man von dem einen Punkt zum anderen und wer treibt das an deiner Meinung nach oder auch deiner Erfahrung nach?
Andy Grunwald (00:18:09 - 00:19:07)
Naja, meine Erfahrung ist ganz einfach. Du bist in einer kleinen Firma und da sind Leute, die sind wirklich committed und die machen das alles mit und die übernehmen Verantwortung und wollen die Firma nach vorne boosten. Für die Leute, wenn man damit startet, sagen die Leute, ja komm, hier hast du meine private Handynummer, ruf mich einfach an, wenn was schief geht. Und irgendwann wird die ganze Sache vielleicht ein bisschen erfolgreicher, da kommen mehr Leute rein, da kommen mehr Leute rein. Und da sagt man immer so ganz schön, die ganze Sache muss ja irgendwie skalieren. Weil ich, ich habe ja meine Handynummer jetzt rausgegeben, irgendwann möchte ich halt auch mal in Urlaub fahren. Und irgendwann bin ich vielleicht mal in einer ganz anderen Zeitzone. Und vielleicht habe ich irgendwie meinen Laptop gar nicht dabei. Dann ist die große Frage, ja Moment mal, was ist denn, wenn ich jetzt drei oder vier Wochen im Urlaub bin und die Applikation fällt auf die Nase, wer macht das denn eigentlich? Dann stellt mal vielleicht diese Frage im Slack. Hey, möchtet ihr On-Call sein? Ich brauche eure Handynummer. Die erste Frage ist, ich arbeite hier 40 Stunden, dafür kriege ich ein ganz normales Gehalt. Was bekomme ich denn dafür? Weil nicht jeder ist so ambitioniert, besonders neue Leute, die jetzt gerade bei der Firma beigetreten sind und so weiter und so fort.
Wolfi Gassler (00:19:08 - 00:19:17)
Und dann wird dir das Management recht schnell sagen, warum sollen wir denn da Leuten irgendwas zahlen, das ist schwierig auch noch, in der Vergangenheit hat es doch auch funktioniert.
Andy Grunwald (00:19:17 - 00:20:08)
Wie sagtest du in der letzten Episode so schön, früher war alles besser, sogar die Zukunft, was? Es ist halt einfach nur so, du kannst halt nicht von jedem erwarten, dass jeder immer für eine Pizza arbeitet und speziell, Wenn es in die eigene Freizeit hineingeht, ist es einfach nur eine notwendige Sache, klare Erwartungshaltung zu setzen, nicht nur gegenüber den Arbeitnehmern, also wer ist wann wie auf Rufbereitschaft, sondern auch vielleicht Sicherheit für das Business und für die Arbeitgeber. Ein Vertrag ist ja immer für beide Seiten, weil wenn ich jetzt meine private Handynummer rausgebe, dann ist es ja mehr oder weniger Goodwill. Und was passiert, wenn ich einfach mal nicht an mein Handy gehe? Da kann mir ja auch keiner an die Karre pissen, oder? Dann ist die Applikation sehr wahrscheinlich für fünf, sechs Stunden down. Wir verlieren Millionen. Und was möchte der Arbeitgeber dann machen? Ja, ich habe ja meine private Handynummer herausgegeben, aber ich war ja nicht auf der Arbeit.
Wolfi Gassler (00:20:08 - 00:22:02)
Also ich glaube auch, dass das eigentlich auf drei Ebenen ganz schwierig ist. Auf der einen Seite natürlich den finanziellen Verlust, den du einfach hast, wenn du down bist, wenn deine Produktionslinie steht, was es dann auch immer ist und das kann man ja sehr einfach in Zahlen fassen. Das heißt, was kostet mich ein Produktionsstopp, eine Offline-App, die mir meinen ganzen Revenue bringt, was kostet mich das pro Minute, pro halbe Stunde, wie auch immer. Ist das relevant für mich? Wenn ich vielleicht eine Software habe, die nur am Tag genutzt wird, kann ich mir vielleicht in der Nacht wirklich das sparen, weil ich sage, da habe ich fast keine User. Dann steht das Ding bis um neun in der Früh. Kann ja auch eine Herangehensweise sein. Auf der zweiten Ebene ist es glaube ich ganz wichtig für die Fairness unter den MitarbeiterInnen zu sorgen. Weil ganz oft ist es ja so, dass im Endeffekt eine Person immer die ganze Rufbereitschaft macht, wenn das nicht organisiert ist. Weil das ist halt die nette Person, die immer erreichbar ist und die kann man immer anrufen und wenn es dann ein Problem gibt, wird man immer diese Person zuerst anrufen, weil da weiß man, dass die sich immer um alles kümmert, immer erreichbar ist und dann trifft es einfach eine Person. Das ist natürlich auch ein großes Problem. Und natürlich, wie du schon erwähnt hast, alleine, wenn man ständig angerufen wird, auch wenn man gar nicht ans Telefon geht, dann hast du einen extremen Stresslevel, weil du musst ja aktiv dich entscheiden, du gehst jetzt nicht dran, dir ist die Firma egal. Am nächsten Tag wird es heißen, wir waren down, was auch immer. Also das erzeugt überall einen extremen Stress. Und ich glaube, auch da muss man als Arbeitgeber oder Arbeitgeberin dafür sorgen, dass dieser Stress möglichst gering gehalten wird. Also der Stresslevel, die Fairness und der Kostenfaktor sind glaube ich die drei Punkte, die man unbedingt als Management beachten müsste und dann müsste das hoffentlich ein No-Brainer sein für das Management, da sinnvoll das System einzuführen. Dass es in der Realität meistens nicht so ist und dass das ganz viel Überzeugungskraft kostet, bis man da das Management überzeugt hat, Geld auszugeben, das wird halt dauern, aber umso besser man da vorbereitet ist, umso besser geht das natürlich.
Andy Grunwald (00:22:02 - 00:23:49)
Naja, du sprichst halt vom ganz klassischen Bassfaktor. Wie viele Leute müssen vom Bus erfasst werden, damit das Projekt in Schieflage gerät. Und in diesem Fall, in unserem Beispiel hier, ist der Bassfaktor 1. Was ist, wenn die Person krank wird und so weiter und so fort. Das passiert relativ schnell. Oder einfach nur in den Urlaub fährt. Die Situation, die ich beschrieben habe, das war jetzt keine fiktive Story, das war genau so bei Trivago am Anfang. Irgendwann habe ich mich halt immer hingesetzt, habe mich mit unserem Team unterhalten und dann haben wir mal einen strukturierten Vorschlag gemacht. Also wir haben alles aufgeschrieben, wir haben das aktuelle Szenario aufgeschrieben, ähnlich wie wir es gerade beschrieben haben. Wir haben beschrieben, wie wir es gerne machen würden, was wir dafür benötigen, wie wir es organisieren und das bedeutet eine kleine Rotation und dann was diese Leute dann auch für eine Art Kompensation bekommen. Und es war jetzt nicht so, als ich dieses Paper dann zum Management gegeben hab, dass die gesagt haben, hey, endlich, darauf haben wir jahrelang gewartet, lass uns bitte mehr Geld ausgeben. War jetzt nicht wirklich so. Und da ging's ein paar Runden Pingpong. Ende vom Lied war jedoch, dass es durchgegangen ist, weil wir dann ganz knallhart mit Zahlen gekommen sind, was bedeutet das, wenn wir einfach mal offline sind. Dann haben wir die Systemadministratoren mit noch reingenommen und die sagen, hey, das wäre für uns auch wirklich eine super Sache. Also wir haben wirklich dann holistisch die ganze Thematik betrachtet. Und Ende vom Lied war dann wirklich, dass wir damit gestartet sind, die ganze Sache aufzusetzen. Hat natürlich alles ein paar Wochen gedauert und ist auch nicht einfach, aber ich würde wirklich, wirklich empfehlen, weil du hattest gerade die Frage gestellt, wie kommt man jetzt von diesem, es ist kompliziert, zu etwas Strukturiertem. Hinsetzen, was aufschreiben, also wirklich alles verschriftlichen und dann mit eurer Vorgesetzten dann einmal durchsprechen. und Feedback einholen. Und meine Erfahrung ist auch, nicht technische Gründer haben eher Probleme für Rufbereitschaft Geld auszugeben als technische Gründer. Also ganz klar, man muss halt schon das Management überzeugen und man muss auch schon wirklich den Value zeigen.
Wolfi Gassler (00:23:50 - 00:23:57)
Und was waren da die größten Argumente, die du vom Management bekommen hast, gegen das Ganze systematisch aufzuziehen?
Andy Grunwald (00:23:57 - 00:24:37)
Eine Sache war, dass wir einen organisatorischen Wasserkopf draufgesetzt haben. Ja, man hat schon wieder Planung für etwas, was ja gar nicht so oft vorkommt. Eine andere Geschichte war, ja, aber was passiert denn, wenn wir jetzt zwei oder drei Wochen einfach mal gar keinen Ausfall haben, muss ich dann trotzdem zahlen? Weil dann zahle ich ja für nichts, weil es ist ja nichts passiert. Und da muss man sich dann halt hinstellen und sagen, Ja, aber was ist denn, wenn du einen Ausfall hast und der geht einfach vier Stunden lang? Dann hast du die letzten vier Wochen einfach mal ratzfatz in den Sand gesetzt, würde ich mal sagen. Es kommt natürlich immer ganz auf die Konstellation an. Wie viel Geld wird mit dieser Applikation gemacht? Wie lang kann die offline sein? Und so weiter und so fort. Es ist sehr kontextgetrieben, die ganze Thematik.
Wolfi Gassler (00:24:37 - 00:24:42)
Wie es so schön immer heißt, there is no glory for prevention. Das ist immer sehr schwer zu verstehen.
Andy Grunwald (00:24:43 - 00:24:50)
Also eigentlich muss das Management halt verstehen, dass die ganze Thematik für den sogenannten Katastrophenfall da ist, dass man aber dafür dann gut gewappnet ist.
Wolfi Gassler (00:24:51 - 00:25:23)
Jetzt hast du schon erwähnt, damals wie wir bei Trivago die Rufbereitschaft eingeführt haben, haben wir auch einen gewissen Betrag ausverhandelt, auch mit dem Team zusammen, was da Sinn machen könnte. Was sind denn die rechtlichen Rahmenbedingungen überhaupt in Deutschland? In Österreich ist es so, dass für Rufbereitschaft bezahlt werden muss. Das heißt, da gibt es einen eigenen Vertrag in dem Kollektivvertrag für IT zum Beispiel, dass man pro Stunde in Österreich 4,50 Euro zahlen muss, wenn man in Bereitschaft ist. Und natürlich, wenn man dann irgendwie ein Problem hat, zählt es sowieso immer als Arbeitszeit.
Andy Grunwald (00:25:23 - 00:26:13)
In Deutschland gibt es jetzt nicht diese 4,50 Euro mit einem Kollektivvertrag, weil in Deutschland wären das, glaube ich, die klassischen Gewerkschaften und die meisten ITler. Und ich glaube, dass die meisten ITler nicht in einer Gewerkschaft sind, außer sowas wie Verdi und IG Metall und allem drum und dran. Die haben natürlich eigene Tarifverträge. In Deutschland unterscheidest du eigentlich zwei Dinge, den Bereitschaftsdienst und dann die Rufbereitschaft. Und der Unterschied ist die Reaktionszeit. Die Reaktionszeit ist die Zeit, von der du die Eskalation oder den Alert bekommst, bis zu dem Zeitpunkt, wo du wirklich hands-on am Computer bist. Die Reaktionszeit sollte so bei 20 bis 30 Minuten liegen für eine klassische Rufbereitschaft. Alles was drunter liegt ist Bereitschaftsdienst und Bereitschaftsdienst müsste dann so gezahlt werden wie dein ganz normales Gehalt. Das ist zumindestens die Information, die ich von zwei unabhängigen Rechtsabteilungen mal bekommen habe.
Wolfi Gassler (00:26:13 - 00:26:56)
Was dann natürlich auch noch wichtig ist, ist, dass das Ganze natürlich Einfluss auf die Ruhezeiten hat, weil wir dafür nur eine maximale Anzahl von Arbeitszeit haben und man kann natürlich nicht 24 Stunden durcharbeiten. Also da ist dann schon ein ganz langer Rattenschwanz dran. In Österreich ist das sehr genau eben in diesen Kollektivverträgen geregelt, auch was das auf die Ruhezeiten für einen Einfluss hat. Aber wenn das natürlich in Deutschland dann als Arbeitszeit gilt, hast du natürlich auch die ganzen Probleme, die dann entstehen durch die Ruhezeiten und darum definieren eigentlich ganz viele Firmen diese 20 Minuten oder 25 Minuten, weil dadurch fällt man aus dem Ganzen raus und dann ist man in der klassischen Rufbereitschaft und muss unter Umständen auch gar nichts zahlen, was ich natürlich nicht empfehlen würde.
Andy Grunwald (00:26:56 - 00:27:18)
Genau. Öffnet natürlich auch das Tor zur Hölle theoretisch, weil du dann in der Bezahlung natürlich mehr oder weniger frei bist. Da gibt es verschiedene Modelle. Manche Leute zahlen einen Pauschalbetrag für die Zeit, die du auf Rufbereitschaft bist. Manche Leute unterscheiden zwischen Active und Passive. Passive ist die Zeit, wo nichts los ist. Active ist die Zeit, wo du Hands-on bist und ein Incident behandelst.
Wolfi Gassler (00:27:19 - 00:27:34)
Also da muss man dazu sagen, Active Passive ist sowieso rechtlich definiert. Also auch da bist du automatisch, wenn du in der Rufbereitschaft bist und ein Problem hast, das du bearbeiten musst, das ist immer Arbeitszeit. Also in Deutschland, Österreich und ich glaube, das ist wahrscheinlich überall so, weil da arbeitest du ja dann wirklich.
Andy Grunwald (00:27:34 - 00:28:29)
Es gibt auf jeden Fall dann noch so Sachen wie, wenn du hands-on bist, also aktiv, dass dann die Zeit für den Inzident mit einem Multiplikator versehen wird und das ist dann nochmal zusätzliche Freizeit, die auf dein Stundenkonto geht oder ähnliches, zusätzlich zu Geld. Da gibt es also ganz verschiedene Modelle und ich habe mich mit ein paar Leuten hier aus dem Bereich in Nordrhein-Westfalen unterhalten und da gab es wirklich von relativ wenig geld bis zu über 1000 euro pro woche bis am wochenende am samstag und sonntag kriegst du ein bisschen mehr also teilweise auch recht komplizierte modelle ja und dann kriegst du noch mal einen halben tag urlaub drauf und so weiter und sofort also da ist man dann in der gestaltung schon recht frei aber ihr merkt schon das geht dann alles komplett ins arbeitsrecht und noch mal kurz als disclaimer wir sind kein anwalt notar oder irgendwas das ist hier entertainment und wir stellen nur unsere eigene erfahrung.
Wolfi Gassler (00:28:29 - 00:29:50)
Dar Und wenn wir schon bei eigener Erfahrung sind, ich habe es am Anfang schon mal erwähnt, also für mich war das erste Mal, wie wir damals bei Trivago eben dieses große On-Call-System implementiert haben oder designt haben, war eben wirklich das Überraschende für mich, dass sehr viele Leute da einen sehr defensiven Zugang hatten. Wie gesagt, ich bin aus der Freelancing-Ecke gekommen, ich bin von der Universitätsseite gekommen, wo man sowieso Tag und Nacht arbeitet und irgendwie jeden erreichen kann. Ich komme von der Feuerwehr. Für mich war das irgendwie ganz normal und ich war auch gewöhnt, dass man einfach mal in der Nacht rausgeleitet wird und innerhalb von zwei, drei Minuten im Feuerwehrauto sitzt. Also für mich war das irgendwie ganz normal und das soll jetzt auf keinen Fall abwertend klingen, aber für mich war das einfach neu, dass Personen da große Schwierigkeiten gesehen haben, auch die vielleicht gar nicht da waren. Aber mit dem muss man sich befassen. Und das war für mich eben eigentlich ganz was Neues, dass man in einem Raum sitzt, diese Sachen bespricht und plötzlich sehr viel Gegenwind spürt. Und dem Gegenwind muss man auch richtig begegnen. Und ich glaube, da sind ja auch ernstzunehmende Probleme dabei. Aber man darf diese ganze psychologische Challenge, wie wir sie genannt haben, also dieser ganze Team Aspekt, den darf man auf keinen Fall vergessen und auch unterschätzen, weil wir sprechen da natürlich auch von Personen, die ihr Privatleben haben und ihr Privatleben opfern für die Firma. Und da muss man halt auch dementsprechend richtig umgehen und das auch wertschätzen.
Andy Grunwald (00:29:50 - 00:30:02)
Hast du jetzt ein bisschen kritisch formuliert. Privatleben opfern. Du tust ja gerade so, als hat man gar keine Zeit mehr. Also der Punkt ist, du wirst halt schon dafür entlohnt. Ja, also das ist die erste Baustelle und die zweite Baustelle ist?
Wolfi Gassler (00:30:02 - 00:30:29)
Das ist eben die Sache. Bei ganz vielen Firmen ist es so, dass du nicht entlohnt wirst, sondern es wird einfach vorausgesetzt und es ist vielleicht Teil des Vertrages, des All-in-Vertrages. Man hat es einfach immer so gemacht, dass man nur bezahlt wird, wenn es dann wirklich ein Inzident gibt. Also ich würde das auch gar nicht voraussetzen, dass das immer so ist, aber das ist eben auch ein Punkt. Es muss fair bezahlt sein. Wenn das wirklich ordentlich aufgesetzt wird, dann muss das mit fairen Stundensätzen einfach dementsprechend auch abgegolten werden.
Andy Grunwald (00:30:29 - 00:30:32)
Ja, aber speziell wenn es vorher im Vertrag drin stand, dann weißt du ja, was du unterzeichnet hast.
Wolfi Gassler (00:30:33 - 00:31:28)
Natürlich, aber auch wenn es dann darum geht in Bereitschaft zu gehen, dann opfere ich natürlich schon irgendwo meine private Zeit, weil ich kann natürlich weniger machen. Also es gibt natürlich sehr gechillte Leute, ein Freund von mir, der findet Bereitschaft extrem cool und ich bin mit dem auch Mountainbiken gewesen, der hat halt dann seinen Laptop hinten im Rucksack gehabt und eben Inzidenzfall hat er sich da halt einfach schön am Berg irgendwo hingesetzt mit seiner SIM-Karte und hat dann diesen Inzidenzfall gelöst. Am Laptop, das geht natürlich auch, aber es sehen schon viele als Einschränkung, dass sie weniger machen können. Und je nachdem wie gechillt du bist, gehst du natürlich mit so Sachen auch anders um. Und es stellen sich dann natürlich schon so Fragen und die habe ich auch oft gehört. Kann ich da noch ins Supermarkt gehen? Kann ich da noch überhaupt ins Kino gehen? Kann ich da eben Mountainbiken gehen? Was kann ich denn wirklich noch machen, wenn ich wirklich in Rufbereitschaft bin? Und viele hatten dann auch wirklich angst ich kann da nicht mehr einkaufen gehen ich kann diese die wohnung nicht mehr verlassen wenn ich in bereitschaft bin.
Andy Grunwald (00:31:28 - 00:31:35)
Wohnung verlassen ist vielleicht ein bisschen drastisch ins kino gehen ist immer so eine sache da da stimme ich dir schon zu.
Wolfi Gassler (00:31:35 - 00:32:19)
Also ich habe auch viele leute kennengelernt die die ins kino gegangen sind die haben, Das Handy mit, das vibriert, solange man Empfang hat im Kinosaal. Das ist ja heutzutage mit den ganzen Jamming-Signalen und so weiter auch nicht mehr so der Fall. Aber gehen wir mal davon aus, du hast Empfang. Im schlimmsten Fall gehst du halt aus dem Kino raus, aus dem Film und erledigst deinen Incident in der Lobby. Wo liegt das Problem? Also man muss das halt auch erklären, dass man diese 20 Minuten unter Umständen eben auch ausnutzen kann. Und gerade im Kino, wenn du ein Laptop mithast, du bist ja innerhalb fünf Minuten sofort online. Ist ja gar kein Problem. Also man muss, glaube ich, auch erklären, dass das jetzt kein Feuerwehrnotfall ist, kein Rettungsnotfall, wo man wirklich innerhalb von Minuten bereit sein muss und alles liegen und stehen lassen muss.
Andy Grunwald (00:32:20 - 00:32:24)
Reiche ich dann die kinokarte dann später als expenses wieder ein oder.
Wolfi Gassler (00:32:24 - 00:32:40)
Ich wollte jetzt sagen mit einem guten stundensatz hast du das sowieso locker herinnen aber wenn man sich anschaut was heutzutage kinokarten kosten mit 5d oder so wie du jetzt mal kürzlich erwähnt hast in der episode wenn man dann mehr als 20 euro los ist könnte das schon dann knapp werden ja vielleicht sollte man das einreichen.
Andy Grunwald (00:32:41 - 00:34:11)
Ich komme jetzt darüber wie der bad cop aber so ist das natürlich nicht. Ich bin da voll auf deiner Seite, dass man schon die Angst nehmen sollte und dass es nicht selbstverständlich ist. Natürlich ist es was anderes, wenn du es von Anfang an dem Vertrag unterschrieben hast. Weil da sage ich, es tut mir leid, du hast es unterschrieben und hoffentlich hast du den Vertrag durchgelesen. Es ist jedoch so, falls du in deiner Organisation aktuell nur die Ops-Abteilung, die Systemadministrator-Abteilung on Call hast und du möchtest anfangen, mehr und mehr Software-Engineers mit reinzunehmen, dass man da natürlich schon das Gespräch suchen sollte. Und auch ich hab da Erfahrungen gemacht, dass da ein bisschen Gegenwehr kam. Das Heftigste, was ich je gehört hab, ist, da hat sich jemand wirklich mit Händen und Füßen gewehrt und wurde auch recht angespannt und direkt laut und, ich nenn's mal, energetisch. Nein, ich geh nicht on Call. dies und das und kommt gar nicht in die tüte und dann habe ich einfach nur mal gefragt was ist denn der grund warum denn nicht und dann kam zurück ja ich habe ja familie. Dann habe ich gesagt ja moment mal und die kompletten systemadministratoren da drüben haben keine familie oder. Und dann war das Argument auch schon wieder kräftig. Was man halt schon sagen muss, es schränkt halt schon ein bisschen ein. Man muss halt schon konstant arbeitsfähig sein. Das bedeutet, ich kann jetzt nicht auf den Geburtstag gehen und mir den Helm zukleistern mit 35 Bier. Also das wird jetzt in der Regel nicht der Fall sein, weil du halt schon irgendwie in der Lage sein musst zu arbeiten. Das stimmt schon. Also es schränkt halt schon ein bisschen ein. Dafür wirst du aber auch auf der anderen Seite natürlich auch entlohnt.
Wolfi Gassler (00:34:11 - 00:34:12)
Im idealen Fall zumindest.
Andy Grunwald (00:34:13 - 00:34:33)
Ja, im idealen Fall natürlich. Aber wenn das nicht der Fall ist und ihr habt wirklich eine Herausforderung bei euch in der Firma, schreibt uns ruhig eine E-Mail und wir versuchen da ein paar Tipps noch auf euren speziellen Use Case irgendwie zu geben. Wir beide haben das schon mal ein paar mal gemacht und können da vielleicht ein bisschen Guidance geben. Auf jeden Fall ist es eine recht komplizierte Geschichte und es schränkt dein privates Leben ein, das stimmt schon.
Wolfi Gassler (00:34:34 - 00:34:50)
Wenn du jetzt sagst, es schränkt das Privatleben so ein, was ist deiner Erfahrung nach die beste Schichtlänge für On Call, weil du kannst ja das wöchentlich aufteilen, täglich aufteilen, Tag, Nacht aufteilen, stündlich aufteilen, was ist da deine Erfahrung diesbezüglich?
Andy Grunwald (00:34:50 - 00:35:54)
Für die Person, die die Compensation dann später ausrechnen muss, ist es natürlich wöchentlich, weil es dann recht einfach ist zu errechnen. Ich habe unterschiedliche Erfahrungen gemacht und zwar ist das wirklich von Person zu Person anders. Wir haben Leute, die waren super komfortabel damit eine ganze Woche zu nehmen oder teilweise sogar zwei Wochen. Wir haben Leute, die haben gerne nur zwei Tage am Stück gemacht. Bei Trivago haben wir das eine ganze Zeit lang in einem selbstorganisierten Team gemacht. Wir haben gesagt, okay, wir haben diesen Monat und der muss gefüllt werden. Reserviert euch einfach mal die Zeit und dann schauen wir, was drüber bleibt und dann holt ihr euch das. Und das hat ganz gut funktioniert. In der aktuellen Firma haben wir eine ganz klassische Rotation. Das bedeutet, wir benutzen einen Ops-Genie, da trägt man Leute ein mit einer definierten Schichtlänge und der teilt die dann ganz einfach ein und dann schauen die Leute, oh da bin ich im Urlaub, oh da habe ich eine Hochzeit und dann tauschen die Leute die einzelnen Schichten nochmal. Das müsst ihr für euch selbst unterscheiden, ob wöchentlich oder tägliche Wechsel oder alle zwei, drei, vier Tage. Das ist wirklich völlig unterschiedlich. Was wir jetzt in der aktuellen Firma haben, da haben wir den Luxus von Around the World. Das ist natürlich unglaublich klasse.
Wolfi Gassler (00:35:54 - 00:35:54)
Das heißt was?
Andy Grunwald (00:35:55 - 00:36:49)
Beim klassischen On-Call ist man in der Regel tagsüber und auch nachts dafür verantwortlich. Also ich liebe meinen Schlaf und ich glaube, viele Leute auch. Deswegen wollen die natürlich auch nicht nachts rausgeklingelt werden. Around the world bedeutet eigentlich, ich arbeite in einer Firma, wo ich Kollegen in Nordamerika habe und wo ich Kollegen in Asien und in Australien habe. Und das bedeutet, wenn ich schlafe oder zu spät abends, ist Nordamerika wach. Wenn ich schlafe, ist Australien wach. Und wenn ich aufstehe, geht Australien ins Bett. Das bedeutet, wir haben immer nur acht stunden schichten mit ganz klassischen handovers das bedeutet ich arbeite von 8 bis 16 uhr um 16 uhr übernimmt nordamerika die arbeiten von 16 bis 24 uhr und von 24 bis 8 morgens arbeitet in australien und somit haben wir keine nachtschicht und so läuft es auch am wochenende deswegen around the world ist natürlich das beste weil man hat kurze schichtzeiten immer nur wenn man tagsüber unterwegs ist das kannst du natürlich auch mit zwei aber.
Wolfi Gassler (00:36:49 - 00:36:52)
Das wochenende ist natürlich trotzdem dann außerhalb.
Andy Grunwald (00:36:52 - 00:36:58)
Der arbeitszeit Das Wochenende bleibt trotzdem so, aber wir haben trotzdem die Wochenenden auf acht Stunden Schichten aufgeteilt.
Wolfi Gassler (00:36:58 - 00:37:02)
Und ihr habt dann auch untertags immer die Schicht zugeteilt?
Andy Grunwald (00:37:02 - 00:37:03)
Ja.
Wolfi Gassler (00:37:03 - 00:37:08)
Also es gibt immer eine Person, die verantwortlich ist, die Notifications, die Alerts und so weiter abzuarbeiten?
Andy Grunwald (00:37:08 - 00:37:09)
Ja.
Wolfi Gassler (00:37:09 - 00:37:14)
Oder zumindest weiterzuleiten, wenn es nötig wäre. Aber dass es halt immer eine Person gibt, die verantwortlich ist.
Andy Grunwald (00:37:15 - 00:37:49)
Voraussetzung ist natürlich auch eine gewisse Mannstärke in Nordamerika und in Australien oder in Asien. Wenn du da nur eine Person sitzen hast, ist das auch doof, weil dann ist die Person halt immer on call. Kann halt auch nicht die Lösung sein. Aber sofern man weltweit aufgestellt ist oder vielleicht sogar nur mit zwei Locations in verschiedenen Zeitzonen, kann man vielleicht eine 12-Stunden-Schicht machen. ist immer noch deutlich besser als 24 stunden natürlich hat man vermehrte handovers das ist dann mehr oder weniger der nachteil aber auch wenn du einen ausfall hast der über einen tag anderthalb tage geht du musst ja trotzdem schlafen also handovers hast du ja trotzdem.
Wolfi Gassler (00:37:49 - 00:37:54)
Mit handover meinst du jetzt dass ein incident weitergegeben wird oder dass die schicht weitergegeben wird.
Andy Grunwald (00:37:54 - 00:38:31)
Ja, beides. Also auf der einen Seite, klar, wenn du ein Inzident hast, dann auf jeden Fall. Die Übergabe ist, okay, dieser Inzident ist passiert, wir haben das versucht, das hat nicht geklappt und hier sind wir jetzt. Wir würden die nächsten Aktionen empfehlen, A, B und C. Aber auch ganz normal die Schicht weitergeben. Hey, diese vier Services haben folgende Escalations geschmissen. Kann man dann sehr wahrscheinlich irgendwo nachgucken in irgendeinem Log. Alle sind resolved, happy shift. Also einfach nur mal ganz kurz einen kurzen Abriss davon geben, was ist eigentlich passiert, damit die Person, die die Schicht übernimmt, weiß, ah, wieso kommt denn dieser Service jetzt nochmal wieder? Ist da vielleicht nicht was krumm?
Wolfi Gassler (00:38:31 - 00:39:28)
Wer übrigens ganz allgemein mehr zum Incident Management wissen will, also wie geht man dann mit Incidents um, wenn man alerted worden ist, den können wir die Episode 17 empfehlen, wo wir einiges über Incident Management gemacht haben und auch Ähnlichkeiten zu Fireware und was man davon lernen kann. Aber bevor wir zur technischen Umsetzung von dem ganzen Alerting und so weiter gehen, hätte ich noch eine Frage an dich. Hast du auch Situationen schon mal erlebt, dass es irgendwie schwierig war, Leute zu bekommen, Leute zu rekrutieren für On-Call? Weil wenn du jetzt Around the World hast, wie du es erwähnt hast, in deiner aktuellen Firma, dann ist es natürlich wesentlich einfacher, weil das ist deren Arbeitszeit, die sitzen sowieso im Büro oder ist in ihrer Arbeitszeit, da ist natürlich leichter dann, Leute zu organisieren für diesen On-Call. Aber was ist, wenn jetzt Einfach die Leute sagen, ich möchte nicht, ich habe keine Zeit, das ist eigentlich nicht mein Thema, es ist zu schwierig für mich, ich kenne mir da zu wenig aus. Also wenn man einfach Schwierigkeiten hat, die Leute zu rekrutieren.
Andy Grunwald (00:39:28 - 00:39:32)
Wie ich vorhin schon erwähnt habe, niemand geht gern auf Encol, aber ja, also.
Wolfi Gassler (00:39:32 - 00:39:33)
Ich kenne schon Leute.
Andy Grunwald (00:39:33 - 00:41:06)
Habe ich noch nie getroffen mit denen würde ich echt gerne mal ein bierchen trinken gehen weil ich organisieren aber aber ja es ist eine herausforderung was wir bei was ich in einem meiner früheren teams gemacht habe ist ich habe mich vermehrt mit ein paar software engineers unterhalten und habe ganz einfach mal bland gefragt hey könnt ihr euch vorstellen auf rufbereitschaft zu gehen oder auf on call und dann haben wir da über mehrere ones einfach mal darüber gesprochen was hat das für vorteile was bedeutet das denn wirklich was hat das für nachteile und Dann habe ich mir die Ängste einfach mal angehört und habe, ich will nicht sagen, dagegen gearbeitet, sondern versucht, das ganze Setup so aufzustellen, dass die Ängste gar nicht mehr so berechtigt sind. Und was wir gemacht haben, ist, wir haben einen Software-Engineer genommen und haben so eine Art Operational Training gemacht. Und zwar war für eine gewisse Zeit dann dieser Software-Engineer mit einem erfahrenen auf Rufbereitschaft gleichzeitig. Wir hatten zwei Leute auf Rufbereitschaft. Immer, wenn ein Incident war, hat der neue Software-Ingenieur über die Schulter von dem erfahrenen Software-Ingenieur geguckt, okay, wie löst man jetzt diesen Ausfall, diese Eskalation. Nach ein paar Mal haben wir das einfach immer gewechselt. Wir haben Reverse Shattering betrieben. Primär während der Arbeitszeit. Immer, wenn wir einen Ausfall hatten, hat der neue Software-Ingenieur den Ausfall behoben und der erfahrene Software-Ingenieur hat ihm über die Schulter geguckt Einfach mal gefragt, im Moment, aber warum machst du das jetzt? Was wäre jetzt dein nächster Schritt? Also wirklich Reverse Shattering. Und so haben wir Stück für Stück den neuen Zofferingenieur, ich sag mal, die Angst genommen. Ja, all diese Ängste, von denen du gesprochen hast, ich kenn mich ja gar nicht aus, was muss ich denn hier machen und so weiter und so fort, kann ich überhaupt noch ins Kino gehen, wurden damit Stück für Stück genommen, weil die Person einfach deutlich sicherer wurde im Umgang mit der Produktionsinfrastruktur.
Wolfi Gassler (00:41:07 - 00:42:06)
Ich glaube überhaupt, dass das ganz wichtig ist, dass sich die Leute nicht alleingelassen fühlen und glauben, sie sind allein. Also einerseits, wenn man dann durch beginnt, wie du richtig gesagt hast, dass man das zu zweit macht oder auch vielleicht, wenn man on call mal initiiert in der Firma, dass man immer mit dem Zweierteam anfängt, damit sich die in irgendeiner Form helfen können. Aber auch wenn neue reinkommen, dass man da Zweierteams hat oder auch sonst, wenn man alleine offiziell ist on call, dass man da genau weiß, okay, es gibt eine Second Level Gruppe, die anpingen kann, die im Notfall auch verfügbar sind, wenn das Problem schwieriger wird. Also man ist nicht allein. Wenn was schwieriger wird, man muss nicht alles alleine lösen. Man kann da andere Leute dann mit reinholen ins Boot, die auch verfügbar sind. Und ich glaube, diese Probleme muss man wirklich möglichst früh adressieren. Weil wenn man dann mal eine extrem schlechte Erfahrung gemacht hat, dann ist das natürlich gestorben, das ganze Projekt. Und dann will niemand mehr on call machen. Also auch da beim Einstieg möglichst reibungslos wieder das Ganze probieren zu gestalten.
Andy Grunwald (00:42:07 - 00:43:05)
Wir sind aber immer wieder bei dieser Trainingssituation auf die Vorteile von Rufbereitschaft zurückgegangen. Und ich habe auch in den One-on-ones dann hinterher gefragt, okay, hast du denn das Gefühl, du bist jetzt ein besserer Software-Ingenieur oder erzähl mir doch mal, was hast du jetzt irgendwie im Bereich Monitoring gelernt und so weiter und so fort. Und da wurde natürlich recht klar, dass das wirklich ein Vorteil ist und dass du dadurch wirklich ein besseres Software-Ingenieur wirst. Und als die Person dann On-Call war, dann hatten wir so eine Art internen Influencer. Dann sind wir auf den nächsten Software-Engineer hinzugegangen. Und da haben wir eigentlich genau das gleiche gemacht. Ängste angehört, Ängste genommen, Shadowing und so weiter und so fort. Und das Tolle, weil wir jetzt einen Software-Engineer aus demselben Team im Boot hatten, hatte man natürlich so eine Art Verstärker. Und so hat sich das dann aufgebaut und da Mehr und mehr Software-Engineers gingen dann On-Call. Irgendwann wurden die Teams halt ein bisschen größer und da muss man dann gucken, okay, macht man jetzt nicht irgendwie spezielle On-Call-Teams für spezielle Services? Aber das ist dann eher abhängig von der Organisationsstruktur.
Wolfi Gassler (00:43:05 - 00:43:15)
Was hältst du eigentlich von Engineering-Manager als On-Call? Also würdest du Managern empfehlen, auch On-Call zu gehen? Weil die haben ja keine Ahnung, oder? Sind ja alle Manager.
Andy Grunwald (00:43:17 - 00:43:49)
Bin ich ein riesen fan von ja aber muss man natürlich gucken also ich finde finde super wenn engineering manager auch on call sind der grund ist ganz einfach die sind einfach näher am geschehen und wissen auch was was da wirklich los ist und ganz wichtig sie fühlen halt den schmerz also sie fühlen auch den schmerz von von individuell kontributieren Da muss man natürlich gucken, ist der Engineering-Manager auch fachlich unterwegs oder ist der Engineering-Manager in eurer Organisation wirklich nur ein People-Lead und ihr habt einen Tech-Lead, der dann fachlich unterwegs ist. Ja, das ist dann ein Unterschied, weil wenn du einen rein klassischen People-Lead als Engineering-Manager hast, den dann on-call zu setzen, könnte sogar gefährlich werden.
Wolfi Gassler (00:43:50 - 00:44:04)
Wobei ich natürlich das als Ausrede nicht gelten lassen würde, weil das ist so ein Klassiker, ja ich bin schon zu weit weg, ich mache ja fast nichts mehr hands on und ich kenne mich da nicht aus und die Manager reden sich dann gern raus, also die würde ich dann einfach verpflichten ganz hart.
Andy Grunwald (00:44:05 - 00:44:41)
Davon rede ich nicht. Ich meine einfach einen domänenfremden Manager. Nur weil du ein Software-Engineering-Team leitest, heißt das ja nicht, dass du Software-Engineering studiert haben musst. Oder Operations. Sondern du kannst ein klassischer People-Lead sein. Was ja völlig okay ist. Aber solche Leute würde ich dann nicht auf On-Call setzen. Aber wenn du ein Engineering-Manager bist oder eine Engineering-Managerin, die auch fachliche Expertise hat, ja bitte, das finde ich nur vorteilhaft. Man muss aber natürlich auch sagen, dass nicht jeder Alert, den du auf dein Handy kriegst, wirklich ein Alert ist, wo man sagen muss, oh, ich muss da jetzt ran. Denn speziell so Sachen wie zum Beispiel, die Festplatte ist zu 75% voll, ist.
Wolfi Gassler (00:44:41 - 00:44:44)
Ein Alert, der meiner Meinung nach gar nicht eigentlich auf dein Handy kommen sollte.
Andy Grunwald (00:44:45 - 00:44:57)
Das ist richtig, aber wir wissen ja alle, wie schwierig es ist, deine Alerts zu tweaken. Je nach Schreibgeschwindigkeit auf der Festplatte und je nach Größe der Festplatte kann es natürlich sein, ach, das ist ein Alert, den silenze ich jetzt und den löse ich erst morgen früh.
Wolfi Gassler (00:44:57 - 00:45:05)
Wie würdest du denn die Alerts auswählen, die wirklich critical sind? Also wie entscheidet man, was geht jetzt an die On-Call-Person in der Nacht und was nicht?
Andy Grunwald (00:45:06 - 00:45:56)
Eine gute Vorbereitung für das Alerting-System ist natürlich Pflicht für die ganze Thematik. Generell würde ich eigentlich die ganzen Alerts auf vier Level aufteilen. High, Medium, Low und Notice. Notice wäre dann zum Beispiel sowas wie ein Deployment war erfolgreich. Ja gut, dafür muss ich jetzt in der Nacht nicht aufgeweckt werden. Low wäre dann sowas wie, das SSL-Zertifikat läuft in einer Woche aus. Ja gut, dann habe ich eine Woche Zeit, die ganze Sache zu fixen. Medium wäre jetzt sowas wie, die Festplatte vom Produktions-Server läuft voll und in 48 Stunden sollte die voll sein. Da hat man ja so Estimations inzwischen. All diese Varianten gehen nicht aufs Handy. Was aufs Handy gehen soll, ist High bzw. Critical. Und das ist sowas wie, der Produktions-Service liefert nur noch 25% der Anfragen erfolgreich aus und 75% der Anfragen fehlen. So ein Ding würde ich mir schon aufs Handy schicken lassen.
Wolfi Gassler (00:45:56 - 00:46:08)
Und was macht man jetzt, wenn da ein Alert rausgesendet wird und keiner antwortet? Weil derjenige doch grad schläft und irgendwie so tief schläft. Ihr habt mal sogar einen Feuerwehrpatcher überschlafen, muss ich zugeben. Hab ich auch schon geschafft.
Andy Grunwald (00:46:08 - 00:46:35)
Die normalen Systeme haben dann so eine Second-Level-Thematik drin. Wenn deine Escalation, dein Alert, nicht innerhalb von fünf Minuten angenommen wurde, also acknowledged wurde, dann geht einfach die definierte Kette weiter. Und deswegen sollte man natürlich auch ein Second Level definiert haben. Und Second Level bedeutet einfach, ja dann wird die zweite Person halt einfach aus dem Bett geklingelt. Und wenn die nicht funktioniert, dann geht die Runde wieder auf den ersten und so weiter und so fort.
Wolfi Gassler (00:46:36 - 00:46:57)
Jetzt sind wir alle große Fans von Metricking und das Ganze zu begleiten, wenn man irgendwas Neues einführt, eine neue Software, was es aber immer ist. Was würdest denn du für Metricking vorschlagen, wenn es darum geht, On-Call zu monitoren? Zu sehen, ist On-Call erfolgreich, sind meine Teams erfolgreich, wenn es um On-Call geht? Was würdest du da für Metricking einführen?
Andy Grunwald (00:46:57 - 00:48:13)
Generell kriegt man aus dieser ganzen Rufbereitschaft natürlich eine ganze Menge verschiedener Datenpunkte. Wie viele Eskalations gingen außerhalb der Arbeitszeit los? In welche Zeit wurden diese Eskalations angenommen? Wie lange hat es gedauert, bis du alle Leute oder alle benötigten Ressourcen am Computer hattest, um arbeiten zu können? Und dann auch die Metrik Meantime to Recovery, also die Die Metrik nennt sich Meantime-to-Repair. Das bedeutet, wann kann ich mit dem Reparieren anfangen? Und dann gibt es noch Meantime-to-Recovery. Wie lange dauert es von dem Meantime-to-Repair, bis die ganze Sache gefixt wurde? Umso kleiner diese Zahlen sind, das bedeutet, umso schneller du dich von einem Ausfall wieder erholen kannst, umso besser ist natürlich die ganze Rufbereitschaft, deine Runbooks, dein Tooling, die Ausbildung deiner Leute und so weiter und so fort. Aber auch ganz klassisch, wer hat eigentlich unglaubliches Pech und hat immer diese schlimmen Wochen? Da kann man ja auch mal eine Analyse machen. Oder vielleicht kann man sogar sagen, wieso werden immer nur dienstags die Leute in der Nacht rausgeklingelt, aber nie mittwochs und donnerstags? Vielleicht hat man irgendwelche schlimmen Cronjobs laufen, die jeden Dienstag laufen. Diese ganzen Daten einfach mal zu visualisieren, vielleicht sogar ohne die spezifische Frage zu stellen, kann das schon hilfreich sein. Und wenn man als Bikeser dann schaut man da schon ein bisschen tiefer rein.
Wolfi Gassler (00:48:13 - 00:49:03)
Und eine Metrik, die dann natürlich drin versteckt ist, aber die für mich eigentlich eine der wichtigsten ist, ist einfach, wie oft wird das Team oder diese Leute im Team aufgeweckt, weil genau diese Metrik will ich eigentlich möglichst niedrig halten. Ich kann natürlich erreichen, indem ich alle Notifications abschalte ist natürlich jetzt nicht gerade die ideale Wahl um das Problem zu lösen aber es ist eben ein Unterschied ob jetzt bei einer Notification wirklich aufgeweckt werde oder nicht und gerade da kann man sehr viel tunen da kann man sehr viel automatisieren und am Ende steht meiner Meinung nach zumindest die Team Happiness immer im Vordergrund, Und das ist natürlich eine Metrik, die da extrem mit drauf einspielt und auch, ob sich dann Leute noch melden überhaupt für On Call und ob das belastend ist, ob die Person am nächsten Tag einfach müde ist nach so einer Schicht und so weiter. Also da hängt extrem viel dran. Darum ist das für mich einfach die Keymetrik schlechthin.
Andy Grunwald (00:49:04 - 00:49:40)
Generell sollte man bei diesen ganzen Metriken, auch beim Alerting, einfach nur konstant tunen, weil aus dem Stehgreif kriegt man ein gutes Alerting und keine false positives einfach nicht raus. Das ist einfach Erfahrung und da muss man dann einfach durch. Eine andere sinnvolle Thematik für das ganze Tunen ist, dass Feature-Flex beziehungsweise Controlled Deployments sehr, sehr, sehr hilfreich sein können. Stellt euch mal vor, ihr kriegt einen Alert in der Nacht, setzt euch an den Rechner, macht euer Dashboard auf und ihr merkt sofort, Der neue Algorithmus zur Produktsuche, der geht irgendwie schief. Und ihr habt diesen neuen Algorithmus einfach hinter einem Feature-Flag versteckt.
Wolfi Gassler (00:49:40 - 00:49:42)
Was ist denn ein Feature-Flag?
Andy Grunwald (00:49:42 - 00:51:05)
Ganz doof gesprochen ist ein Feature-Flag einfach nur eine If-Up-Frage. Wenn irgendeine Konfiguration auf True gesetzt ist, dann nehme den neuen Produkt-Such-Algorithmus und wenn nicht, nutze den alten. Das bedeutet, du kannst einfach on the fly verschiedene Features aktivieren oder deaktivieren. Und on the fly heißt natürlich im besten Fall, ohne die Applikation neu starten zu müssen oder ohne ein Deployment machen zu müssen. Das bedeutet, ihr habt entweder irgendeine REST-API, da könnt ihr den Curl-Request gegenschießen und somit aktiviert ihr oder deaktiviert ihr Features und die Applikation lädt sich dann intern neu. Wenn ihr sowas habt, dann ist es natürlich Gold wert. Ihr steht in der Nacht auf, seht, ah, das ist der neue Suchalgorithmus, den deaktiviere ich jetzt einfach mal, gehe wieder ins Bett und man schaut sich morgen an, was da eigentlich passiert ist. Neben dem Feature Flex gibt es natürlich auch solche Geschichten wie prozentualer Rollout von neuen Features. 5% aller User von eurer Applikation kriegen das neue Feature ausgespielt. Da dreht ihr den Threshold einfach später wieder auf 0, geht wieder ins Bett und behebt das morgen. Das sind so Thematiken, die können euch während der Rufbereitschaft enorm helfen und reduzieren natürlich auch sehr den Stress. Da muss man natürlich auch gucken, wo baut man Feature-Flags ein, wie maintaint man die und so weiter. Und das mit der EFAP-Frage, macht das bitte nicht genau so, sondern schafft euch da in irgendeiner Art ein Feature-Flag-Framework an, der vielleicht ein bisschen besser bestückt ist.
Wolfi Gassler (00:51:06 - 00:52:09)
Wenn man irgendein AP-Testing zum Beispiel macht, hat man üblicherweise sowieso so ein Framework, wo man gewisse Features ein- und ausschalten kann. Und das hilft dann natürlich beim On-Call genauso. Ganz allgemein muss man, glaube ich, auch definieren, wie denn ein Inzident behoben wird in der Nacht zum Beispiel. Also wie kritisch ist der? Muss ich den wirklich beheben? Kann der am nächsten Tag behoben werden? Kann ich nur irgendwas abschalten? Kann ich den Traffic umrouten? Was es da auch immer für Möglichkeiten gibt, Also man muss sich nicht als Entwickler in der Nacht hinsetzen und dann vier Stunden irgendwie programmieren, um einen Bug zu fixen, wenn der vielleicht nicht so schlimm ist oder wenn man bis zum nächsten Tag warten kann. Und das kommt natürlich auch erst mit der Zeit, aber umso besser man das im Vorhinein definiert und sich vielleicht im Team auch mal in einem Brainstorming am Anfang, wenn man dieses ganze Vehikel aufbaut, sich überlegt, was haben wir für Probleme, wie lösen wir diese Probleme? Gibt es unterschiedliche Kategorien von Problemen, von Inzidenz? Dann kann man dadurch durch das vorherige definieren und vielleicht dann auch irgendwelche Runbooks da wieder den Stress rausnehmen.
Andy Grunwald (00:52:09 - 00:52:16)
Primäre Erwartungshaltung sollte halt sein, die Blutung zu stoppen und den Service einfach am Fliegen zu halten, bis einfach mehr Leute wieder wach sind, genau.
Wolfi Gassler (00:52:16 - 00:53:01)
Oder eben wenn die Leute nicht wach sind und es ist kritisch, dass man eben diese Leute auch anpingen kann, dass man da irgendwie einen zweiten Alarm auslösen kann, Second Level Escalation hat, die Software supportet das üblicherweise, die man in den Bereichen verwendet. Aber man muss natürlich auch dann Leute in anderen Abteilungen, vielleicht sogar auf Product Ebene oder Management Ebene haben, die man dann im Notfall aus dem Bett holen kann. Also auch da wieder Stress rausnehmen, indem man das Angebot hat. Man kann andere Leute auch aus dem Bett holen und man ist nur die erste Person, die sich das Ganze anschaut. Aber wenn man nicht mehr weiter weiß, wird einfach weiter alarmiert. Jetzt, wenn wir schon bei Alarmierungstools sind, was sind deine Lieblingstalarmierungstools? Was würdest du empfehlen?
Andy Grunwald (00:53:01 - 00:53:20)
Ich habe sehr gute Erfahrungen mit ObsGenie gemacht, von Atlassian. Kann ich auch sehr empfehlen. Kann eigentlich fast alles, was es können muss. Ziemlich gehypt mit PagerDuty, hab ich aber leider noch nie mitgearbeitet. Preislich auch recht sportlich, hab ich mal gehört. Viele größere Firmen haben eh den Atlassian-Stack drin, da kann man auch mal eben ObsGenie noch dazunehmen, von daher.
Wolfi Gassler (00:53:21 - 00:54:02)
Der Nachteil bei diesen Systemen ist natürlich, dass sie nicht allzu billig sind. Diverse Monitoring Tools haben oft auch so abgespeckte Alarmierungstools dabei, die man unter Umständen auch verwenden kann. Also wenn man da vielleicht schon Lizenzen hat, kann man da damit etwas bauen. Man kann sich natürlich auch selber etwas bauen, ganz klassisch, wenn man Twilio verwendet, um SMS zu versenden oder irgendwelche Alarmierungs-Apps, da gibt es auch ganz viele, Wirepusher habe ich für so ein Mini-Projekt selber in Verwendung, das ist kostenlos. Wenn man dann natürlich was Großes aufbaut, würde ich schon auf die professionellen Tools gehen, aber wie gesagt, für die kleine Agentur oder für ein kleines Team kann man sich da natürlich auch einfach selber was aufbauen.
Andy Grunwald (00:54:02 - 00:54:21)
Ich bin großer Fan davon, dass die einzelnen Teams und dass du wirklich voll verantwortlich bist für deine Applikation und nicht nur die Applikation schreiben darfst und deployen darfst und dann den Stift fallen lässt. Ich bin Fan davon, dass du dann wirklich voll umfänglich für verantwortlich bist. Aber ich habe auch die Erfahrung gemacht, da ziehen ziemlich viele Leute die Grenze.
Wolfi Gassler (00:54:21 - 00:55:47)
Und meiner Meinung nach ist das genau der Knackpunkt an der ganzen Sache. Also auch wenn wir jetzt diese drei großen Bereiche, die rechtliche und organisatorische Seite, mit den ganzen Kosten, mit dem Management, wie ziehe ich denn das Ganze auf, natürlich habe, und auch die technische Umsetzung, wie mache ich das Alerting, wie teile ich die Leute ein. Das sind sicher zwei Punkte, die viel Zeit kosten und die man sich im Vorhinein überlegen muss. Aber die psychische Challenge, also wie kann ich die Leute dazu bringen, dass die Spaß haben an On Call, dass sie das gerne machen, dass das kein Albtraum für die wird. Das ist meiner Meinung nach die große Herausforderung und die Challenge und die spielt natürlich auf die anderen zwei Bereiche, auf die organisatorische und technische, mit ein, weil wenn die technische oder organisatorische Seite nicht gut umgesetzt ist, dann will natürlich erst recht niemand auf On Call gehen, aber man muss einfach den Leuten die Angst nehmen und wirklich den Einstieg so leicht wie möglich machen und wenn es dann, wie du gesagt hast, Ambassadors gibt, die das schon machen, die einfach davon erzählen können, dass es auch normale Arbeit ist, dass man da kein einzelner Hero ist, der in der Nacht alles alleine fixt, sondern dass man da halt einfach eine Person oder ein Zahnrad in einem gut geölten System oder Team ist und man dann auch zurückgreifen kann auf das Team, auf andere Spezialisten. Und dass das einfach ein weiterer Task ist im normalen Arbeitsleben. Dann hat man glaube ich gewonnen und genau da muss man hin. Also das sehe ich persönlich als die größte Challenge an, wenn es um On-Call geht.
Andy Grunwald (00:55:48 - 00:56:58)
Bin ich bei dir? Ich bin aber eher nicht so auf dem Happy Pass, wo du da in deiner esoterischen Welt mal bist, sondern eher so ein bisschen geerdet. Und zwar sag ich, jeder möchte immer selbst deployen können und komplett verantwortlich sein und ich denke halt, da gehört Oncall sein auch dabei. Das ist halt vielleicht nicht die schöne Seite, sondern eher die Seite in deinem schönen Garten hinter der Hecke, die keine Sonne kriegt. wo das Unkraut wächst, aber meines Erachtens nach kannst du dir nicht immer die Sonnenblumen picken hier und dann immer einen Walk in the Park haben. Also ich denke, du musst halt dann schon sagen, wenn du die komplette Flexibilität möchtest mit Deployen und allem drum und dran, dann musst du leider die hässliche Seite auch mitnehmen und dafür sorgen, dass die hässliche Seite halt auch schön wird. Das bedeutet ordentliches Software schreiben oder zumindest bereit sein, das zu lernen inklusive Ich nenne das jetzt mal Failure-first zu denken. Jeder im Web denkt immer Mobile-first. Site-Reliability-Engineers und DevOps und so weiter und so fort, die denken immer Failure-first. Weil wie Werner Vogels, CTO von Amazon oder CTO von AWS immer sagte, everything fails all the time. So bin ich eher halt geerdet. Deswegen, du kannst nicht Flexibilität haben, ohne den Schmerz mitzunehmen. Und ich bin kein Masochist oder Ähnliches.
Wolfi Gassler (00:56:59 - 00:57:41)
Vielleicht ist das auch meine Seite von der Freiwilligen Feuerwehr, wo die Leute einfach darauf warten, dass endlich ein Einsatz ist, dass sie endlich ein Feuer löschen können, wo es ja dann so weit geht, dass manche dann irgendwelche Feuer legen, damit sie solche Einsätze haben. Und wenn man dieses Gefühl vielleicht irgendwie transportieren kann in die Arbeitswelt, wo dann Leute Spaß haben am Incident Management, das würde ich gerne erreichen. Habe ich leider noch nie gesehen in dem Sinne. Aber vielleicht schafft man es irgendwie, einen ähnlichen Zustand zu erreichen, dass das eben auch positiver gesehen wird. Und man hat ja auch im Nachhinein, wenn man dann irgendwas fixen konnte, wenn man wirklich ein Problem beheben konnte in kurzer Zeit, hat man ja vielleicht auch ein gewisses Glücksgefühl, dass man da was Gutes machen hat können.
Andy Grunwald (00:57:42 - 00:57:53)
Ich tue mich schwer, das mit der Freiwilligen Feuerwehr zu vergleichen, weil du sagtest, die Freiwillige Feuerwehr ist, Achtung, freiwillig, und bei der Arbeit ist es halt nicht so. Von daher bin ich mir nicht sicher, wie gut der Vergleich so ist.
Wolfi Gassler (00:57:53 - 00:57:57)
Willst du mir jetzt sagen, dass du deine Arbeit nicht liebst und freiwillig machst?
Andy Grunwald (00:57:57 - 00:58:01)
Oh doch, ich rede ja nicht von mir, ich war ja jahrelang On-Call, jetzt gerade wenigstens nicht.
Wolfi Gassler (00:58:01 - 00:58:03)
Also es sind immer die anderen, ich verstehe das.
Andy Grunwald (00:58:03 - 00:58:20)
Nein, nein, nein, nein, nur wir haben ja auch über die Gegenwehr gesprochen, von daher, ich kann ja alle Seiten verstehen, aber ich denke auch, wir alle sind dafür verantwortlich On-Call besser zu machen und weniger beschissen, von daher. Wenn wir da alle an einem Strang ziehen, bin ich wieder voll dabei. Und das war der Streit zum Abschluss.
Wolfi Gassler (00:58:20 - 00:58:55)
Und falls ihr Kommentare oder Erfahrungen zu dem ganzen Themenbereich On Call habt, ihr kennt ja alle unsere Feedback Kanäle, die wir schon haben, aber wir haben jetzt einen neuen Feedback Kanal und zwar haben wir eine kleine, feine, Engineering-Kiosk-Community gegründet, einen kleinen Discord-Server. Den Link findet ihr natürlich wie immer in den Show Notes. Also schaut da gerne mal vorbei, da gibt es rege Diskussionen und wir freuen uns da natürlich auch Feedback zu bekommen, das vielleicht länger ist als die 160 Zeichen von dem Tweet oder keine Ahnung, was aktuell an Länge überhaupt erlaubt ist. Ändert sich ja auch täglich alles auf Twitter.
Andy Grunwald (00:58:55 - 00:59:26)
Wir hoffen, wir haben euch keine Angst vor der Rufbereitschaft gemacht, sondern haben euch eher ermutigt, das Thema doch mal organisiert und kontrolliert anzugehen. Ich bin gespannt, was ihr so zu erzählen habt, denn das ganze Thema ist natürlich so eine Herzensangelegenheit oder eine Hassangelegenheit. Man weiß es nicht. Hassliebe, ich weiß es auch nicht. Das ganze Thema sollte aber nicht negativ rüberkommen, sondern ich bin ein mega Fan von Rufbereitschaft. Ich denke, viel mehr Leute sollten es tun, weil dann zeigt man wirklich ihr Ownership. Deswegen entlasse ich euch jetzt mal von dieser Episode und wünsche euch noch einen schönen Tag. Bis später.
Wolfi Gassler (00:59:26 - 00:59:27)
Tschüss. Ciao.