Monitoring auf Geschäftsergebnisse: grüne Dashboards, leere Kasse

Jedes Plattform-Team kennt den Moment: CPU bei 30 Prozent, keine Fehler im Log, alle Dashboards grün, und seit zwei Stunden kann kein Kunde bezahlen. Klassisches Monitoring beobachtet die Maschinen. Das Geschäft muss aber wissen, ob Menschen tun können, wofür sie gekommen sind: buchen, bezahlen, sich anmelden. So richte ich Monitoring ein, das auf Ergebnisse schaut, Probleme von aussen erkennt, bevor Kunden sie melden, und ruhig genug bleibt, dass die Leute die Alerts noch lesen.

Dominik Heinrich

8. November 202610 Min. Lesezeit

1. Symptome beobachten, nicht Maschinen

Das SRE-Buch von Google ordnet Monitoring entlang zweier Fragen: Was ist kaputt, und warum. Das "Was" ist ein Symptom, das ein Nutzer spürt: eine Seite, die nicht lädt, eine Zahlung, die scheitert, eine Buchung, die nie ankommt. Das "Warum" ist eine Ursache: eine volle Festplatte, eine langsame Abfrage, ein abgelaufenes Zertifikat. Symptome verdienen Alerts, weil sie immer zählen; Ursachen gehören auf Dashboards, auf die man schaut, wenn ein Symptom anschlägt.

Das Prometheus-Projekt rät dasselbe: auf Symptome alarmieren, Alerting einfach halten und Alarme vermeiden, bei denen es nichts zu tun gibt. Ein CPU-Alert um 3 Uhr nachts für eine Maschine, die ausgelastet ist, aber jeden Kunden bedient, ist das Gegenteil, und er bringt Leuten bei, den Pager zu ignorieren.

2. Die Kundenwege benennen und ihnen Ziele geben

Mit drei bis fünf Kundenwegen beginnen, die das Geschäft tragen, und jeden aus Kundensicht beschreiben: einen Aufenthalt suchen und buchen, bezahlen, die Bestätigung erhalten, sich für einen Kurs anmelden. Für jeden einen Indikator wählen, der sagt, ob es geklappt hat, etwa den Anteil begonnener Buchungen, die abgeschlossen werden, oder den Anteil erfolgreicher Zahlungen, und mit dem Fachverantwortlichen ein Ziel vereinbaren.

Ein Ziel von 99,5 Prozent erfolgreichen Buchungen pro Tag definiert zugleich ein Fehlerbudget: die 0,5 Prozent, die verloren gehen dürfen, bevor das Geschäft Schaden nimmt. Das SRE-Buch nutzt dieses Budget, um Zuverlässigkeitsarbeit gegen neue Features abzuwägen. In der Praxis gibt es jedem Alert eine klare Schwelle und jeder Release-Diskussion eine Zahl.

Monitoring auf Geschäftsergebnisse: synthetische Checks alle 10 Minuten, stündlich ein Gang durch den Buchungs-Funnel und täglich eine Testzahlung laufen von aussen; in der Kubernetes-Plattform speisen Anwendungsmetriken, Geschäftsereignisse und Watchdogs gegen die Quelle der Wahrheit Prometheus und Loki; Grafana zeigt SLOs pro Kundenweg, Alertmanager alarmiert auf Symptome und Fehlerbudget-Verbrauch, eröffnet einen deduplizierten GitHub-Issue pro Ausfall und meldet sich im Team-Chat mit Runbook-Link. — Monitoring auf Ergebnisse: von aussen prüfen, mit der Quelle der Wahrheit vergleichen, auf Kundenwege alarmieren, ein ruhiger Issue pro Ausfall.

3. Von aussen prüfen, wie ein Kunde

Metriken aus der Plattform sehen keinen kaputten DNS-Eintrag, kein abgelaufenes Zertifikat und kein CDN, das eine alte Seite ausliefert. Synthetische Checks schon: kleine Skripte, die von aussen laufen und tun, was ein Kunde tut. Auf einer Plattform, die ich betreibe, prüfen sie die wichtigen Seiten alle 10 Minuten, gehen jede Stunde einmal durch den Buchungs-Funnel und machen jeden Tag eine echte Testzahlung. Als der Anbieter des Hostel-Systems seine API ohne Vorwarnung änderte, schlugen die Probes an, und Aufenthalte waren am selben Tag wieder buchbar.

Diese Website hat dasselbe im Kleinen: Ein geplanter Workflow ruft einmal pro Stunde die wichtigsten Seiten, jeden Artikel, den KI-Guide, jeden PDF-Leitfaden, die Sitemap und den Buchungslink auf, und ein Fehler landet in meinem Postfach.

yaml

# GitHub Actions: a synthetic check that fails (and emails the owner) when a vital page breaks
on:
  schedule:
    - cron: "*/10 * * * *"
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - run: |
          for path in / /book /checkout; do
            code=$(curl -s -o /dev/null -L --max-time 20 -w '%{http_code}' "https://www.example.com$path")
            [ "$code" = "200" ] || { echo "FAIL $path -> $code"; exit 1; }
          done

Tipp aus der Praxis

Synthetischen Checks einen eigenen Testkunden geben und ihre Buchungen und Zahlungen markieren, damit sie nie in Umsatzberichten auftauchen oder das Team verwirren.

4. Watchdogs gegen die Quelle der Wahrheit

Manche Fehler zeigen sich erst, wenn zwei Systeme sich widersprechen. Ein Kunde hat bezahlt, aber es gibt keine Reservierung. Die Website hatte den ganzen Morgen Besucher, aber keine einzige Buchung. Ein Webhook kam an, aber die Bestellung wechselte nie den Status. Jeder dieser Fälle ist eine kurze Abfrage gegen die Datenbank oder den Zahlungsanbieter, alle paar Minuten ausgeführt, die immer leer sein sollte.

Diese Watchdogs sind die wertvollsten Prüfungen, die ich kenne, weil sie genau die Fehler fangen, die technische Metriken übersehen: Alles war schnell und gab 200 zurück, und das Ergebnis war trotzdem falsch. Das Resultat als Metrik exportieren, damit es alarmiert wie alles andere.

sql

-- Paid, but no reservation after 15 minutes: should always be empty
SELECT p.id, p.amount, p.created_at
FROM payments p
LEFT JOIN reservations r ON r.payment_id = p.id
WHERE p.status = 'succeeded'
  AND r.id IS NULL
  AND p.created_at < now() - interval '15 minutes';

5. Auf das Ziel alarmieren, nicht auf jedes Zucken

Die Indikatoren der Kundenwege in Prometheus zu Recording Rules machen und dann alarmieren, wenn sie lange genug unter das Ziel fallen, um eine Rolle zu spielen. Eine Mindestmenge an Verkehr verhindert Alerts in der Nacht, wenn zwei gescheiterte von drei Buchungen wie eine Katastrophe aussehen. Jeder Alert trägt eine Zusammenfassung in klaren Worten und einen Link zum Runbook, das sagt, was zuerst zu prüfen ist.

Auf der oben erwähnten Plattform laufen Prometheus, Grafana, Loki und Alertmanager mit 143 Alert-Regeln auf Kubernetes. Das klingt nach viel, aber die meisten speisen Dashboards und Tickets; nur jene, die an Kundenwege gebunden sind, wecken eine Person.

yaml

groups:
  - name: booking-slo
    rules:
      - record: booking:success_ratio:rate1h
        expr: |
          sum(rate(bookings_completed_total[1h]))
            / sum(rate(bookings_started_total[1h]))
      - alert: BookingSuccessBelowObjective
        expr: |
          booking:success_ratio:rate1h < 0.995
            and sum(rate(bookings_started_total[1h])) * 3600 > 20   # enough traffic to judge
        for: 15m
        labels:
          severity: page
        annotations:
          summary: "Fewer than 99.5% of started bookings complete"
          runbook_url: "https://runbooks.example.com/booking-success"

6. Ruhig genug halten, um gelesen zu werden

Ein Alerting-System stirbt an Lärm, lange bevor es an fehlender Abdeckung stirbt. Was sich für mich bewährt: ein GitHub-Issue pro Ausfall, automatisch eröffnet, wenn ein Check scheitert, und automatisch geschlossen, wenn er sich erholt, dedupliziert, damit ein flackernder Check denselben Issue aktualisiert statt zwanzig neue zu eröffnen, und stündliche Obergrenzen, damit ein Sturm den Team-Chat nicht flutet. Der Issue wird so ganz nebenbei zum Protokoll des Vorfalls, mit Zeitstempeln.

Einmal im Monat die Alerts durchgehen. Jeder Alert, der ausgelöst hat, ohne dass jemand handeln musste, ist ein Kandidat zum Löschen, zum Verschieben auf ein Dashboard oder zum Nachjustieren. Das Ziel: Jeder Alarm bedeutet etwas.

7. Jeden Release sich beweisen lassen

Der günstigste Vorfall ist der, den eine Release-Schranke stoppt. Zwei Schranken leisten den Grossteil: Datenbank-Migrationen laufen als Probedurchlauf gegen eine Kopie, bevor eine Änderung gemergt werden kann, und ein Smoke-Test läuft direkt nach jedem Deploy und färbt den Deploy rot, wenn ein wichtiger Pfad bricht. Beide nutzen dieselben Prüfungen wie das Monitoring, also scheitert eine kaputte Buchungsseite am Release, bevor ein Kunde sie je sieht.

Die Checkliste unten deckt diese Grundlagen ab, von Backups, die tatsächlich wiederhergestellt wurden, bis zu Geschäfts-Checks, die eine Person alarmieren. Jede Lücke, die sie zeigt, ist eine Stelle, an der Ihre Dashboards grün bleiben können, während das Geschäft es nicht ist.

Fazit
Beobachten, was Kunden tun, von aussen und gegen die Quelle der Wahrheit, nur auf die Kundenwege alarmieren, die Geld bringen, und es ruhig genug halten, dass jeder Alarm etwas bedeutet.

Echte Projekte dazu

Monitoring auf Geschäftsergebnisse, Backups jede Nacht geprüft

Selbst ausprobieren

Kosten der Log-Aufbewahrung

Das für Ihr Unternehmen? Sprechen wir mail@dominikheinrich.ch

Quellen und offizielle Leitfäden