Playbook3 Abschnitte · 2 Min. LesezeitVon Dezső Mező · Veröffentlicht 3. Oktober 2026.mdMonitoringOpsUptime
Die meisten Monitoring-Setups scheitern sozial, bevor sie technisch scheitern: Die Metriken existieren, die Dashboards sind hübsch, und der Ausfall wird trotzdem vom Kunden entdeckt, weil der Alarm in einen Kanal ging, den um 21 Uhr niemand liest. Das ist das minimale Setup, das funktioniert — drei Teile, alle langweilig.
01Von außen proben, für die echte Antwort
Ein externer Dienst ruft die echten Seiten ab und prüft den echten Inhalt — nicht 'Port offen', sondern 'der Checkout liefert 200 und enthält das Wort bezahlen'. Interne Health-Checks fangen tote Prozesse; externe Probes fangen tote Zertifikate, totes DNS und tote Upstreams — das meiste, was wirklich stirbt.
02Ein Alarmweg, den jemand besitzt
Alarme gehen in einen Kanal, den eine benannte Person liest — eine Telefon-Benachrichtigung, kein geteiltes Postfach — mit Ruhezeiten-Logik, die bei den wichtigen Endpunkten trotzdem piept. Ein Alarm, den jeder ignorieren kann, ist einer, den jeder ignoriert.
03Das Runbook ist geschrieben, bevor es gebraucht wird
Zu jedem Alarm eine Seite: was zuerst prüfen und wie 'behoben' aussieht — denn wer es um zwei Uhr nachts liest, bist du selbst ohne Schlaf. Das Runbook in jemandes Kopf ist ein terminierter Single Point of Failure.
Was bleibt
- Externe Probes prüfen Inhalt, nicht nur Ports.
- Ein Alarmweg, ein benannter Besitzer, echte Benachrichtigungen.
- Das Runbook zur Build-Zeit schreiben, nicht um zwei Uhr nachts.
- Alarm-Müdigkeit ist ein Bug — jeder Alarm muss actionable sein.
Mehr aus dem Lab
Alle Beiträge ansehen
Ein Backup, das du nie zurückspielst, ist eine Geschichte
Was Custom Software wirklich kostet
Custom oder von der Stange — der ehrliche Test
Die ersten neunzig Tage eines Retainers, wie er wirklich läuft
Sollen wir das an Ihrem System ansehen?Gespräch beginnen
