Monitoring ist wie Rasen mähen

1. Monitoring ist wie Rasen mähen – warum man nie fertig ist

Ist das Monitoring erst einmal aufgesetzt und eingeschwungen, ist die Freude groß: Alle wichtigen Metriken auf dem Dashboard, keine offenen Alerts. Arbeit erledigt.

Leider ist es nicht so einfach. Ein Monitoring lebt davon, dauerhaft gepflegt zu werden. Neue Systeme kommen dazu, die Last verändert sich, neue Versionen werden deployt, Alerts wollen nachjustiert werden. Und die anfangs gute Alert-Moral bröckelt, weil gerade ein neuer Kunde onboarded oder ein wichtiges Feature gebaut wird.

Es ist wie beim Rasen: Nur weil man einmal gemäht hat, bleibt er nicht für immer kurz. Zwei Wochen nicht gemäht, und das Unkraut wächst. Nach einem Monat verholzt es, nach einem halben Jahr steht dort ein kleiner Wald. Was anfangs eine Fingerübung war, wird zum Kraftakt, der sich immer schwerer einplanen lässt – also macht es niemand.

Deshalb: dranbleiben. Monitoring aktuell halten, regelmäßig aufräumen, Auffälligkeiten nachgehen. Und wenn es doch einmal verwildert ist (das passiert jedem), nicht resignieren, sondern den Rhythmus wieder aufnehmen.

2. Der “Broken Windows”-Effekt – warum Kleinigkeiten zählen

Eine saubere Straße, ein Fenster geht kaputt, niemand repariert es. Andere sehen das kaputte Fenster und kümmern sich auch weniger. Weitere Fenster gehen zu Bruch – am Ende stehen verfallene Häuser und brennende Autos.

Im Betrieb sind die zerbrochenen Fenster die kleinen Dinge: ein Alert, den alle ignorieren. Pods, die „halt manchmal“ neu starten. Speicher, der dauerhaft am Limit läuft. Fehler im Log, die „schon immer da waren“. Werden die kleinen Dinge erst einmal hingenommen, kann man sie irgendwann nicht mehr von den großen unterscheiden. Und plötzlich verbringt man mehr Zeit damit, das System am Laufen zu halten, als es weiterzuentwickeln.

3. Der Schmetterlingseffekt – jede Kleinigkeit ist ein Geschenk

Ein Beispiel, das ich so oder so ähnlich schon mehrfach erlebt habe: 30 Pods laufen, ab und zu startet einer ohne erkennbaren Grund neu. Der Service läuft ja weiter, also kümmert sich niemand darum. Dann kommt Last, und die Plattform steht plötzlich komplett. Unter Stress wird neu gestartet, hoch- und runterskaliert – und die eigentliche Ursache wird wieder nicht gefunden.

Die seltenen Neustarts waren der Flügelschlag des Schmetterlings: ein frühes Signal für ein tieferliegendes Problem. Ich sehe solche kleinen Auffälligkeiten deshalb als Geschenk. Man bekommt einen Hinweis, dass etwas nicht stimmt, und hat noch die Ruhe, der Ursache in aller Gründlichkeit nachzugehen. Später, mitten im Incident, hat man diese Ruhe nicht mehr.

4. Der Junge, der „Wolf!“ rief – jede Benachrichtigung muss zählen

Ein Hirtenjunge ruft zum Spaß „Wolf! Wolf!“ und amüsiert sich, wenn die Dorfbewohner angerannt kommen. Als eines Tages wirklich ein Wolf auftaucht, glaubt ihm niemand mehr.

Der Hirtenjunge ist das Monitoring. Wenn Alerts kommen, bei denen es heißt „den kann man ignorieren“, werden irgendwann alle Alerts ignoriert – bis die Kunden anfangen zu rufen. Meine Faustregeln:

• Alerts sofort beheben. Geht das nicht schnell, den Alert bewusst stummschalten (Downtime/Acknowledge) und ein Ticket daran hängen.
• Nur benachrichtigen, was sofortiges Handeln erfordert. Alles andere gehört aufs Dashboard, nicht in den Chat-Kanal oder auf den Pager. Sonst stumpft man gegen das ständige „Ping! Ping! Ping!“ ab – und der Wolf freut sich über ein Festmahl.

Fazit

Ein gutes Monitoring ist kein Projekt mit Enddatum, sondern eine Gewohnheit. Regelmäßig mähen, kaputte Fenster reparieren, auf die kleinen Flügelschläge achten und nur „Wolf!“ rufen, wenn wirklich einer da ist. Dann wird aus dem ständigen Gefühl, dass gleich etwas Schlimmes passiert, eine Plattform, bei der ein Ausfall wieder die Überraschung ist – und nicht der Normalfall.