Wenn ein Monitoring-System nicht mehr überwacht, sondern überwältigt – wie Airbnb mit einem klassischen Infrastrukturproblem kämpfte, das am Ende eine Kulturfrage war.
Airbnb baut sein Alert-System neu auf – und stolpert dabei über ein Kulturproblem
Airbnb hat sein internes Monitoring- und Alerting-System grundlegend überarbeitet. Der Umbau offenbarte dabei nicht nur technische Schwachstellen, sondern auch tief verwurzelte organisatorische Gewohnheiten, die einem funktionierenden On-Call-Betrieb im Weg standen.
Zu viele Alerts, zu wenig Signal
Das Ausgangsproblem war ein klassisches: Im Laufe der Jahre hatte sich bei Airbnb eine große Menge an Monitoring-Regeln angesammelt, die kaum noch gepflegt wurden. Alerts feuerten zu häufig, zu unspezifisch oder zum falschen Zeitpunkt – ein Zustand, den Ingenieure in der Branche als „Alert Fatigue” bezeichnen. Teams ignorierten Benachrichtigungen zunehmend, weil der Signal-Rausch-Abstand zu schlecht geworden war.
Die Folge: Kritische Ereignisse gingen im Rauschen unter, On-Call-Schichten wurden zur Belastung, und das Vertrauen in das gesamte Monitoring-System erodierte.
Airbnb erkannte, dass eine technische Lösung allein nicht ausreichen würde.
Technische Neuausrichtung: Weniger, aber bessere Alerts
Auf der technischen Seite setzte Airbnb auf eine stärkere Priorisierung und Klassifizierung von Alerts nach tatsächlicher Geschäftsrelevanz. Statt jede Systemanomalie direkt zu eskalieren, wurden Schwellenwerte und Eskalationspfade systematisch überprüft und angepasst. Dabei orientierte sich das Team konsequenter an Service Level Objectives (SLOs) – messbaren Zielvorgaben für Verfügbarkeit und Performance aus Nutzersicht.
Alerts, die keinem klar definierten SLO zugeordnet werden konnten, wurden entweder überarbeitet oder deaktiviert. Das Ergebnis: eine deutlich schlankere Alerting-Landschaft, in der jede Benachrichtigung eine konkrete Handlungsanweisung nach sich ziehen sollte.
Das eigentliche Problem: Teamkultur und Ownership
Der schwierigere Teil war kultureller Natur. Alerts existieren nicht im Vakuum – sie gehören Teams, und Teams müssen Verantwortung für ihre Qualität übernehmen. Bei Airbnb zeigte sich, dass diese Ownership oft unklar oder schlicht nicht vorhanden war. Alerts wurden angelegt, aber selten überprüft. Wer einen Alert erstellt hatte, war nach Teamwechseln oder Reorganisationen häufig nicht mehr greifbar.
Das Unternehmen reagierte mit verbindlicheren Prozessen:
- Jeder Alert muss einem Team zugeordnet sein, das auch für seine Pflege verantwortlich ist
- Regelmäßige Reviews wurden eingeführt, um veraltete oder ineffektive Regeln zu identifizieren
- On-Call-Schichten wurden kulturell neu bewertet – nicht als notwendiges Übel, sondern als integraler Teil des Softwarebetriebs
„Tooling und Infrastruktur skalieren schnell – organisatorische Klarheit hält nicht Schritt.”
Lessons Learned: Technik folgt Prozess
Airbnbs Erfahrung zeigt ein Muster, das in wachsenden Technologieunternehmen häufig auftritt. Ein ausgereiftes Monitoring-System lässt sich nicht allein durch bessere Software erreichen – es erfordert:
- klare Zuständigkeiten
- regelmäßige Überprüfungszyklen
- eine Unternehmenskultur, die technische Schulden im Betrieb ebenso ernst nimmt wie solche im Code
Für Unternehmen, die eigene Observability-Strategien aufbauen oder modernisieren, liefert der Airbnb-Fall einen nüchternen Hinweis: Bevor neue Monitoring-Werkzeuge eingeführt werden, lohnt ein Blick auf die bestehende Alert-Hygiene. Ungepflegte Benachrichtigungsregeln sind in vielen Organisationen ein stilles Produktivitätsproblem – und eines, das sich mit klarer Ownership-Struktur und regelmäßigen Reviews vergleichsweise kosteneffizient adressieren lässt, ohne umfangreiche Tooling-Investitionen.
Quelle: InfoQ
