#240 Dead Man's Switch für dein Alerting

Wer überwacht eigentlich dein Monitoring System? – Dead Man's Switch für dein Alerting.

Im Engineering-Kiosk-Adventskalender 2025 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb weniger Minuten über ein interessantes Tech-Thema.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Anregungen, Gedanken, Themen und Wünsche

Dein Feedback zählt! Erreiche uns über einen der folgenden Kanäle …

EngKiosk Community: https://engineeringkiosk.dev/join-discord
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
Instagram: https://www.instagram.com/engineeringkiosk/

Unterstütze den Engineering Kiosk

Wenn du uns etwas Gutes tun möchtest … Kaffee schmeckt uns immer

Buy us a coffee: https://engineeringkiosk.dev/kaffee

Sprungmarken

(00:00:00) Deadman Switch

Hosts

Wolfgang Gassler (https://gassler.dev)
Andy Grunwald (https://andygrunwald.com/)

Community

Diskutiere mit uns und vielen anderen Tech-Spezialist⋅innen in unserer Engineering Kiosk Community unter https://engineeringkiosk.dev/join-discord

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:03 - 00:00:26)

Willkommen zum Engineering Kiosk Adventkalender oder für unsere deutschen Hörer Adventskalender. So viel Zeit muss hier noch sein, vor allem in dieser ruhigen Adventszeit. Da haben wir Zeit für Wissen Sinnvolles, aber auch weniger Sinnvolles. Und was sich Andi für dieses Türchen ausgedacht hat, mit welchem Wissen er jetzt um die Ecke biegen wird, das hört ihr gleich. Also zurücklehnen, Lauscher auf und los geht's.

Andy Grunwald (00:00:27 - 00:18:47)

Die meisten von uns arbeiten an irgendeiner Art von Applikation und hoffentlich läuft deine Applikation und macht eigentlich auch das, was es tun soll. Und das ist ein ziemlich gutes Gefühl. Doch woher weißt du denn das so genau? Woher weißt du genau, dass deine App genau das tut, was es soll? Wahrscheinlich warst du gerade mal drauf und hast die App benutzt. Geil. Und dann gehst du schlafen. Doch woher weißt du denn am nächsten Morgen, dass es genau das tut, was es tun soll? Wahrscheinlich hast du dann ein Monitoring System. Monitoring ist wichtig, wissen wir irgendwie alle. Und wenn man richtig gut ist im Bereich Hochverfügbarkeit und keine Bugs hat, bekommt man auch keine Alerts oder beziehungsweise Notifications. Das ist ein richtig gutes Gefühl. Doch zu welchem Zeitpunkt weiß ich eigentlich, dass meine App eigentlich super stabil ist oder einfach nur das Monitoring System kaputt ist? Denn wenn das Monitoring System kaputt ist, dann ist man blind. Und dann könnte man auch sagen, ich glaube, meine App funktioniert. Also ist die Wer überwacht eigentlich den Überwacher? Oder auf Englisch who is watching the washer? Also ist die Wer überwacht eigentlich das Monitoring System? Dass das Monitoring System selbst nicht ausfällt? Wer überwacht die Überwacher? Who is watching the watcher? Das ist eine klassische Frage, die viele ops, DevOps und SRE Teams plagt. Die Lösung ist relativ einfach, nennt sich Deadman Switch. Was ist ein Deadman Switch? Ein Deadman Switch ist ein Konzept, das verhindert, wenn man blind wird, wenn der Wächter einschläft. Also eigentlich ein unabhängiger Wächtermechanismus, der das Monitoring System selbst überwacht. Manche Leute kennen das auch unter Todmannschalter, Totmann Einrichtungen, Bewegungslosmelder oder Todmannwarner. Die ganze Sache ist kein neues Konzept bzw. Kommt nicht aus der IT, sondern eher aus der Technik und Ingenieurswelt. Da ist es eher ein Schalter oder ein Mechanismus, der automatisch eine Aktion auslöst, wenn eine Person ausfällt bzw. Es überprüft, ob ein Mensch anwesend und handlungsfähig ist und löst andernfalls ein Signal oder eine Schalthandlung aus. Das habt ihr vielleicht schon mal gesehen, wenn ihr in die Bahn eingestiegen seid. Die Lokführer müssen da in der Regel regelmäßig ein Pedal oder Handtaster gedrückt halten, denn wenn der Fahrer dieses Pedal oder den Handtaster loslässt, zum Beispiel wenn er ohnmächtig wird, bremst der Zug automatisch. Ein ähnliches Konzept gibt es bei Baumaschinen wie bei Bagger und Rasenmäher. Da müsst ihr in der Regel als Bediener einen Hebel oder einen Griff gedrückt halten, denn wenn der losgelassen wird, stoppt die Maschine sofort, um Unfälle zu vermeiden. Zumindest habe ich einen Benzinrasenmäher, wenn man den so schiebt, dann muss ich immer so einen Haken festhalten und wenn ich den loslasse, hört er halt sofort auf. Bei Schiffen und Motorbooten gibt es eine sogenannte Notausleine. Da trägt der Fahrer eine Leine, die dann so mehr oder weniger mit dem Motor verbunden ist und wenn er dann über Bord fällt, geht der Motor sofort aus, dass das Boot halt nicht weiterfährt. Die Feuerwehr hat ein ähnliches Konzept. Oft haben ziemlich viele Feuerwehrmänner so einen Bewegungsmelder an ihrer Ausrüstung und und wenn man sich nicht bewegt, reagiert das Gerät, dann muss man das einmal manuell bestätigen. Das nennt man auch Quittierung des Voralarms. Und wenn man sich halt länger nicht bewegt und diesen Voralarm nicht quittiert, dann geht der Todbandschalter halt los, weil du dich halt nicht mehr bewegst. Das Militär macht ein anderes System oder ein anderes Konzept, nennt sich in der Regel so Heartbeat. Da passiert so man meldet sich immer wieder bei der Zentrale in einem bestimmten Intervall, aber da komme ich gleich noch drauf. Im Endeffekt dieser Deadman Switch oder Todmannschalter dient der Arbeitssicherheit an Einzelarbeitsplätzen oder an gefährlichen Maschinen. Die ganze Sache ist nicht neu, habe ich initial erwähnt. Der Begriff taucht ein tausend neun hundert zehn das erste Mal auf und ein tausend neun hundert zwei und zwanzig in einer Patentschrift. Im Zweiten Weltkrieg wurde der Begriff dann in den USA auch mal in einem Handbuch der US Luftstreitkräfte von ein tausend neun hundert vierzig gefunden. Dort beschrieb ein Abwehrstandschalter explizit als Deadman Switch. Leider ging es, glaube ich, im Zweiten Weltkrieg dann wirklich um tote Menschen. Die Wortherkunft ist auch ganz interessant und zwar im englischsprachigen Technikraum sprach man früher eher von einer Hold to run Device. Ihr erinnert euch, man muss einen Schalter drücken, um die Bahn zu fahren. Hold to run Device. Vermutlich wurde der Todmannschalter bzw. Auf Englisch Deadman Switch dann durch deutsche Ingenieure bzw. Deutsche Schriften vermittelt und dann, ich sag mal, eingeenglischt naja, zurück zum Monitoring, zurück zur Technik, zurück zur Softwareentwicklung. Was heißt das jetzt eigentlich fürs Monitoring? Solange das Monitoring System lebt, sendet es regelmäßig ein Lebenszeichen, so ähnlich wie bei der Feuerwehr. Wenn die Signale ausbleiben, schlägt der Deadman Switch Alarm. Man kehrt also die eigentliche Logik um. Nicht das Auslösen eines Signals erzeugt den Alarm, sondern das Ausbleiben des Signals löst den Alarm aus. Also wir halten nicht kontinuierlich was gedrückt, sondern wir senden kontinuierlich ein Heartbeat. Heartbeats selbst finden auch eigentlich Anwendungen in der Hochverfügbarkeit. Beispiel, wenn du einen Datenbank Cluster hast. Die Cluster senden in der Regel Regel Heartbeats zueinander, um zu sagen, hey, ich bin noch da und hatte ich ja gerade schon mal erwähnt, im militärischen Bereich wird die ganze Sache auch genutzt. Wie implementiert man jetzt einen solchen Deadman Switch? Also wie überwacht man den Überwacher? Dazu mache ich einen ganz kurzen Exkurs. Wie ist eigentlich ein Monitoring System aufgebaut? In der Regel hat ein Monitoring System zwei Komponenten. Auf der einen Seite hast du irgendetwas, was deine Applikation überwacht. Der fragt deine Applikation die ganze Zeit, hey, lebst du noch und wie geht's dir denn? Was hast du für eine Ziele CPU und so weiter. Und diese Daten werden dann in der Regel in einer Zeitreihen Datenbank, in einer Time Series Datenbank gespeichert. In dieser Komponente definiert man oft auch Regeln, wie zum Beispiel, wenn die CPU über sechzig Prozent für ein Intervall von fünf Minuten ist, dann sende mal eine Notification. Eine zweite Komponente ist dann meist die Alerting Komponente. Diese Alerting Komponente nimmt dann in der Regel das Resultat einer solchen Regel, diese CPU Regel, von der ich gerade besprochen habe, entgegen und sendet diese dann an dein Handy, SMS, ruft dich an, an pagerduty oder an deinen Slack oder ähnliches. Natürlich müssen das nicht zwei getrennte Komponenten sein, das entspricht doch jedoch eigentlich dem generellen Aufbau. Kann auch alles in einer Komponente sein, wenn man das jetzt mal auf Cloud Native Infrastruktur übertragen würde, würde man sagen okay, du hast einen Prometheus, der überwacht deine Applikation, nimmt sich die ganzen Metriken, speichert die in der Zeitreihen Datenbank und führt auch diese Regeln aus, wenn meine CPU für ein Zeitinterv von fünf Minuten über sechzig Prozent ist und so weiter. Und wenn das der Fall ist, dann sagt okay, sende eine Notification. Und diese Notification würde man zum Beispiel an einen Alert Manager senden. So baut man zum Beispiel ein Monitoring System auf. Kannst du natürlich auch alles implementieren, Nagios und Zynga und wie sie alle heißen können, das aber auch alles. Kommen wir mal zu der Implementierung eines Deadman Switches, hatte ich gerade schon kurz erwähnt. Wir wenden das Heartbeat Prinzip an. Wir implementieren also eine Regel, die immer true ist. Das bedeutet, wir implementieren einen Alert, der immer feuert. Der Alarm muss immer laufen, wie zum Beispiel null null. Sowas kann man zum Beispiel in einer Alerting Regel definieren und die feuert halt immer. Die feuert konstant. Diese Alerting Regel nennt man Watchdog Alert Regel. Das Alerting System nimmt dann das Resultat und Ah, okay, ich muss jetzt irgendwen informieren, zum Beispiel Slack oder ähnliches. Und das Alerting System leitet diesen Alert dann weiter, diesen Heartbeat dann weiter, am besten an eine unabhängige Stelle. Warum, sage ich euch gleich. Die dritte unabhängige Stelle sagt okay, ich muss immer ein Signal von meinem Alert Manager bekommen. Und wenn ich die dritte unabhängige Stelle nimmt dann dieses Heartbeat Signal entgegen und okay, einmal pro Minute muss ich hier ein Hard Beat Signal bekommen und wenn ich das für dreimal in Folge nicht bekomme, löse ich ein Signal aus. Die ganze Sache klingt unglaublich simpel, doch wie es meist so mit einfachen Dingen ist, ist es doch deutlich schwieriger als gedacht. Fangen wir mal an. Und ich hatte gerade gesagt, eine dritte unabhängige Stelle sollte auch dabei sein. Und da kommen wir mal zu dem ersten Fehler, der oft gemacht Wohin geht denn deine Heartbeat Benachrichtigung? Ich hatte gerade gesagt, du hast ein System, was deine App überwacht, das evaluiert diese Alerting Regel, sendet das an das Alert System weiter und das Alertsystem muss es dann an eine dritte Stelle weiterleiten. Wenn die dritte Stelle eine selbstgeschriebene Komponente ist, die auf demselben Server wie dein Alerting Stack läuft, Schwierig. Denn was passiert, wenn der Server von deinem Alerting Stack runterfällt? Dann funktioniert auch dein Heartbeat System nicht mehr. Am besten ist es, wenn du das Signal aus deiner eigenen Infrastruktur rausroutest auf einen anderen Infrastruktur Stack. Das kann zum Beispiel, wenn du jetzt auf Google Cloud host, kann das sein, dass du eine Server bei AWS oder bei Hetzner hast. Eine gute Anwendung ist auch irgendein Software as a Service, wie zum Beispiel Pager Duty. Es gibt sowas wie Dead Man Snitch, das ist speziell ein Service für sowas oder obsgeny über Heartbeat. Du kannst natürlich auch alles selbst bauen. In den Shownotes habe ich dir mal zum Beispiel ein Hacker News Thread verlinkt. How to do simple Heartbeat Monitoring mit zwei und achtzig Kommentaren. Die Leute sind oft sehr kreativ. Hol dir doch da mal ein bisschen Inspiration. Warum ist es jetzt wichtig, dass diese Komponente, diese Komponente, die dein Heartbeat überwacht, außerhalb deiner Infrastruktur ist, Die soll natürlich auch funktionieren. Wenn all deine Hauptsysteme down sind, entkoppelt die so weit wie möglich. Leg die bitte auch nicht auf einen Server daneben oder in ein anderes Rack oder wo auch immer. Pack es wirklich komplett woanders hin am besten, was wirklich ein hundert Prozent unabhängig von deiner Infrastruktur ist. Ein zweiter häufiger Fehler Was macht man eigentlich, wenn der Deadman Switch triggert? Was passiert eigentlich, wenn das Heartbeat Monitoring System Hey Jung, dein Monitoring ist tot, denn dieser Alarm selbst enthält halt sehr wenig Details und jetzt bin ich on Call und auf einmal kriege ich einen ganz neuen Alarm, den habe ich noch nie gesehen. Dann Alerting System ist down, da stelle ich mir erstmal die oh fuck, was mache ich denn jetzt? Also am besten definiere mal ein Runbook oder setze einen Link in diesen Alert, der zu einem Runbook führt. Am besten auf eine Wiki Seite oder ähnliches, wo dort dann ein paar Instruktionen stehen, wie man denn prüft, ob dein Alerting System noch online ist, welche Komponente kaputt ist und so weiter und so fort. Ein weiterer Fehler, der sehr, sehr oft gemacht wird, sind falsche Intervalle und falsches Timing. Denn ihr könnt euch vorstellen, die Wahl des Heartbeat Intervall spielt eine große Rolle. Wenn ihr sagt, ihr sendet nur alle fünf oder zehn Minuten ein Heartbeat, dann könnte es sein, dass der Wiederholungszeitraum zu lang ist und man bemerkt einen Ausfall eventuell erst zu spät. Wenn ihr sagt zum Beispiel, sende ein Heartbeat alle fünf Minuten und ihr konfiguriert das Heartbeat Kontrollsystem, okay, vier Heartbeats müssen ausfallen, damit ich ein Alert sende. Dann bekommt ihr erst nach zwanzig Minuten mit, dass euer Alerting System down ist. Kann man machen, dann hat man sehr wahrscheinlich wenig False Positives. Wählt man den Intervall aber zu kurz, wie zum Beispiel alle zehn Sekunden oder alle fünf Sekunden, dann könnten natürlich auch kleinste Hiccups, wie zum Beispiel mal Netzwerk Blip oder irgendwie eine Serverkomponente wird neu gestartet, sofort einen Fehlalarm triggern. Meine Empfehlung Stimmt eure Intervalle und die Toleranz auf eure gewünschten Reaktionszeiten ab. Also wann müsst ihr am Rechner sein? Wann müsst ihr, nachdem ihr ein Alert bekommen habt, am Rechner sein und reagieren können? Die genauen Einstellungen hängen natürlich dann von euren eigenen SLO Zielsetzungen ab. Generell würde man sagen, je kritischer das Monitoring, desto schneller möchte man Ausfälle wissen oder über Ausfälle informiert werden. Ein guter Punkt ist, glaube ich so, wenn man sagt, okay, wenn fünf Minuten kein Ping da ist, wenn in den letzten fünf Minuten kein Heartbeat kam, dann sende ich mal ein Deadman Switch Alert. Damit könnt ihr mal kurz starten. Dann ein weiterer Fehler, der oft gemacht wird, ist ein Konfigurationsfehler. Manche Alerting Systeme, die senden den Alert einmal und dann nie wieder. Das ist natürlich jetzt in diesem Konzept fehl am Platz, denn euer Alert ist ja in diesem Fall jetzt ein Hard Beat. Das bedeutet, ihr müsst diesen Alert kontinuierlich senden. Ein Heartbeat ist nur wirksam, wenn er wirklich kontinuierlich gesendet wird. Zum Beispiel im Alert Manager würde man da den Repeat Intervall setzen und wirklich testet das, testet die Konfiguration, startet den Alert Manager einmal neu oder deaktiviert einmal die Heartbeat Route temporär, damit dieser Deadman Switch auch wirklich getriggert wird. Wenn ihr das nicht getestet habt, ist es für mich nicht existent und ich hoffe für euer Team auch nicht. Und eine weitere Fehlerquelle, über die viele Teams Stellt euch vor, ihr habt zwanzig Überwachungssysteme, ihr habt zwanzig Apps, vielleicht eine kleine Microservice Infrastruktur. Für jede dieser Microservice Apps habt ihr ein eigenes Überwachungssystem. Das bedeutet auch, ihr habt zwanzig Systeme, die unabhängig ein Hard Beat senden. Und was passiert jetzt, wenn ihr einen Single Point of Failure habt und ihr habt nur eine Alerting Komponente? Das bedeutet Ihr habt zwar zwanzig Überwachungskomponenten, zwanzig Prometheus, aber nur einen Alert Manager, der dafür zuständig ist, die Nachrichten weiterzuleiten. Wenn dann der Alert Manager down ist, wollt ihr dann zwanzig mal Heartbeat Failures bekommen, also zwanzig mal Deadman Switch Alerts Oder wollt ihr eine Catch All haben und Ah, das Alert Manager ist down, jetzt muss ich reagieren. Oder wollt ihr zwanzig haben? Das ist so eine Frage, die ihr euch auch stellen müsst. Die Lösung wäre, ihr könnt einen Catch All Heartbeat Alert definieren. Der sagt zwar dann, mit dem Monitoring ist etwas nicht in Ordnung und der ist viel, viel genereller, also ihr habt Informationsverlust. Dafür bekommt ihr aber halt keine zwanzig Deadman Switch Alerts, sondern nur einen. Ist halt so eine Art Trade Off, den ihr entscheiden müsst. Wenn ihr aber jetzt mal so ein Deadman Switch implementiert habt, gibt es noch zwei Best Practices. Macht regelmäßige Tests und Drills, also wirklich jeden Monat oder jedes Quartal. Lasst den Deadman Switch Alert einmal triggern, entweder indem ihr das Alert System einmal offline nehmt für einen gewissen Zeitintervall oder ihr deaktiviert die Heartbeat Deadman Switch Route. Testet es, denn ihr werdet an dem Alert System arbeiten. Da werden sich auch weitere Bugs einschleichen und sogenannte Regressions. Das bedeutet, Bugs, die ihr mal gefixt habt, werden wieder introduced. Testet es, weil nur wenn ihr das regelmäßig testet, könnt ihr wirklich sicher sein, dass die ganze Sache funktioniert. Eine andere Thematik ist auch die Optimierung über die Historie. Schaut euch mal an, wie oft eigentlich mal so ein Heartbeat Fehler bekommen habt oder so ein Deadman Switch Alert oder wann die mal außerhalb der Toleranz lagen. Da könnt ihr so ein bisschen die Konfiguration eurer Heartbeat Intervalle anpassen und natürlich aber auch über ein Audit Trail. Falls ihr mal einen größeren Ausfall hattet, wisst ihr, ah OK, da wurde dann auch wirklich ein Deadman zu ausgelöst. Also schaut zu, dass euer Heartbeat Kontrollsystem auch irgendeine Art Historie hat. Jetzt habe ich schon ziemlich viel über diese simple, aber doch komplizierte Lösung gesprochen und da stellt sich natürlich die Gibt es da nichts Einfaches? Kann ich nicht einfach ein zweites Monitoring System aufsetzen, was das erste Monitoring System überwacht? Die Antwort Klar kannst du aber die erste Frage Wer überwacht den Überwacher? Und wenn du diese jetzt mit mein zweites Monitoring System beantwortest, dann stellt sich für mich die Wer überwacht den Überwacher des Überwachers? Es ist halt ein Infinity Loop Problem, das sich halt nicht wirklich elegant lösen lässt, weil es halt eine endlos geschachtelte Monitoring Lösung wäre. Kannst du schon so machen. Und du sagst okay, wenn das eine Monitoring System sich mit dem anderen überwacht, ja, das reicht für mich, das ist völlig okay. Aber wenn du es richtig lösen möchtest, müsstest du halt eine Endlosrekursion, weil du den Überwacher des Überwachers überwachen müsstest und so weiter und so fort. Ein Deadman Switch durchbricht halt diesen Teufelskreis, indem er das Fehlen von Signalen nutzt, um Alarm zu schlagen, statt immer neue Überwachungssysteme in einer Kaskade aufzubauen. Eine andere alternative Lösung, die halt oft genannt wird, sind sogenannte Escalation Drills. Escalation Drills sind zum Beispiel, dass das Monitoring jeden Tag einen Alarm in einen Chat oder auf dein Mobiltelefon sendet, also sozusagen geplanter Testalarm, der halt regelmäßig ausgelöst wird. Und der Sinn ist auch klar, du willst die Alarmkette prüfen, quasi ein Probealarm fürs On Call Team. Kann man machen, kann man auch zusätzlich machen, ist vielleicht eine gute Sache. Aber wenn du das als Ersatz für einen Deadman Switch nutzen würdest, dann führt es halt über eine gewisse Zeit vielleicht zu einer Alerting Fatigue. Stellt euch vor, jeden Morgen kommt ein Test Alert in den Chat. In der ersten Woche oder in den ersten zwei Wochen schaut dann noch jeder drauf, aber irgendwann sagt man, ah, okay, da scrollt man einfach drüber nach der in der dritten oder vierten Woche. Und was passiert jetzt, wenn das Alerting System down ist? Dann kommt der Chat Alert nicht mehr. Und jetzt kommt es auf uns Menschen an zu wissen, Moment, jeden Morgen sollte hier nicht gerade Chat Alert sein und vielleicht war gerade Zeitumstellung und denkt ihr, ah ja, der kommt erst vielleicht in einer Stunde. In einer Stunde seid ihr schon wieder ganz tief in irgendeinem Problem und habt es wieder vergessen. Das zweite Problem ist natürlich, wenn das nur einmal pro Tag kommt oder vielleicht auch einmal pro Woche, je nachdem, was ihr für ein Zeitintervall habt, dann ist das natürlich nur eine Momentaufnahme. Stell dir vor, nach dem Escalation Drill, nach dem Testalarm Nach dem Probealarm fällt das Alerting System aus. Dann ist das Alerting System so lange ausgefallen, bis zum nächsten Escalation Drill, bis das mal jemandem auffällt. Ein Escalation Drill beantwortet also die Erreicht ein Alarm grundsätzlich die richtigen Leute, aber sie beantwortet nicht die Ist das Monitoring jetzt gerade noch intakt? Meines Erachtens nach sind Escalation Drills eine gute ergänzende Übung. Zum Beispiel einige Teams nutzen das auch, um einen Escalation Drill auf das Mobiltelefon des On Call Engineers zu senden, wenn die On Call Schicht beginnt. Damit kann man testen ist das Handy laut gestellt und so weiter und so fort. Es löst natürlich nicht alle Probleme, es ist aber besser als nichts. Zurück zum Deadman Switch. Also der Deadman Switch ist kein Allerheilmittel, aber ein wichtiger Baustein. Also ein Deadman Switch löst nicht alle Probleme. Zum Beispiel wird der Monitoring Ausfall an sich nicht verhindert. Er verhindert aber, dass du ihn nicht mitbekommst. Also ein Deadman Switch ist ein wichtiger Bestandteil der robusten Überwachung. Wenn du diese Episode hörst, mach doch mal ein Escalation Drill. Trigger doch mal deinen Deadman Switch. Schau doch mal, ob der noch funktioniert, wie er funktionieren soll. Und jetzt hoffe ich, dass dein Monitoring System über die Feiertage ruhig bleibt und wünsche dir eine frohe Weihnacht. Bis später. Tschüss.

Wolfi Gassler (00:18:49 - 00:19:03)

Das war das heutige Türchen im Engineering Kiosk Adventkalender. Ich hoffe, ihr konntet wieder etwas mitnehmen, zum Nachdenken schmunzeln oder auch direkt aus. Wenn euch die Episode gefallen hat, erzählt es gern weiter an Kolleg innen oder eure Lieblings Nerds. Abonniert den Podcast und eine Bewertung wär.

Andy Grunwald (00:19:03 - 00:19:04)

Natürlich auch super cool.

Wolfi Gassler (00:19:04 - 00:19:26)

Ihr kennt ja das ganze Spiel. Wenn ihr noch mehr Lust auf Austausch habt, kommt gerne in unserer Engineering Kiosk Discord Community vorbei. Dort tummeln sich Entwickler innen, Datenmenschen und auch alles andere, was Rang und Namen hat im Tech Universe. Für heute machen wir das Türchen mal wieder zu. Aber keine Sorge, das nächste wartet schon. Frohe Adventszeit in Zwischenzeit. Bleibt offen für Neues und bis zur nächsten Episode.