Läuft die Website noch? Uptime-Monitoring und Vorfälle
Wie schnell ein Unternehmen merkt, dass die eigene Seite ausgefallen ist: Uptime-Monitoring, Alarmkette und eine Nachbesprechung, die gelesen wird.
rabbitclip-TeamVeröffentlicht: 4 Min. Lesezeit
Kurz gesagt
Uptime-Monitoring ist eine externe Prüfung, die nach Zeitplan läuft und aufzeichnet, ob eine Website oder App tatsächlich antwortet. Eine einfache Prüfung schaut nur, ob die Startseite lädt; eine zuverlässigere Einrichtung testet eine echte Transaktion, Kasse, Login, ein Formular, im selben Zeitplan. Der Sinn ist, einen Ausfall zu bemerken, bevor es die Kundschaft tut, und das funktioniert nur, wenn ein Alarm vorab definiert ist: wen er erreicht, über welchen Kanal, innerhalb welcher Zeit.
Wenn die Kassenseite eines Berufsbekleidungsherstellers an einem Sonntagmorgen anfängt, Fehler zu werfen, kann das stundenlang unbemerkt bleiben, wenn eine Kundenbeschwerde das erste Anzeichen ist. Eine Prüfung, die den Bezahlvorgang selbst überwacht, erkennt denselben Fehler innerhalb von Minuten und benachrichtigt die richtige Person; der Unterschied liegt zwischen einem stundenlangen Verlust und wenigen Minuten Reaktion.
Was misst Uptime-Monitoring tatsächlich?
Uptime-Monitoring ist die Aufzeichnung, ob ein Server oder eine Seite, abgefragt von einem externen Kontrollpunkt nach Zeitplan, meist alle ein bis fünf Minuten, überhaupt antwortet. Die Antwort muss sowohl existieren als auch den erwarteten Inhalt tragen, den richtigen Statuscode, einen bestimmten Text auf der Seite; dass der Server bloß erreichbar ist, reicht allein nicht, die Seite muss tatsächlich funktionieren.
Diese Art der Prüfung erkennt zuverlässig einen Server, der ganz ausgefallen ist oder nicht mehr antwortet, fängt aber nicht immer eine Verlangsamung, einen Teilfehler oder ein Problem ab, das nur in einem Browser auftritt. Deshalb steht Uptime-Monitoring neben Fehlerverfolgung und Performance-Monitoring, nicht an deren Stelle.
Welche Prüfung erkennt welches Problem?
Verschiedene Prüfungsarten decken unterschiedliche Risiken ab; eine zu wählen macht die anderen nicht überflüssig.
- Ping-/HTTP-Prüfung: ob der Server überhaupt antwortet, innerhalb von Sekunden
- Inhaltsprüfung: ob die Seite korrekt geladen hat, anhand eines bestimmten Textes oder Statuscodes
- synthetische Prüfung: ob ein mehrstufiger Vorgang wie Kasse, Login oder Formularabsendung durchgängig funktioniert
- SSL-Zertifikatsprüfung: wie nah das Zertifikat am Ablauf ist
Wie wird eine Alarmkette aufgebaut?
Ein Alarm, der niemanden erreicht, oder der alle gleichzeitig erreicht, sodass niemand Verantwortung übernimmt, ist der Punkt, an dem Monitoring in der Praxis am häufigsten versagt. Eine gestufte Eskalation senkt dieses Risiko.
- erste Erkennung: die automatische Prüfung bestätigt den Fehler über 2-3 aufeinanderfolgende Versuche, damit ein einzelner Netzwerkaussetzer nicht mit einem Ausfall verwechselt wird
- 0-5 Minuten: eine sofortige Benachrichtigung an die zuständige Person, in-App oder per E-Mail
- 5-15 Minuten: bleibt eine Reaktion aus, folgen SMS oder ein Anruf, und eine zweite Person wird benachrichtigt
- nach 15 Minuten: eine Führungskraft übernimmt, die Status-Seite wird aktualisiert
Was passiert während eines Ausfalls?
Die erste Aufgabe, sobald ein Ausfall erkannt wird, ist nicht die Behebung, sondern das Verstehen des Ausmaßes: ist die ganze Seite down oder nur ein Teil, wie viele Nutzer sind betroffen, wann hat es angefangen. Ohne diese Information riskiert eine Reaktion, das Falsche zu reparieren und die eigentliche Ursache zu übersehen.
Eine öffentliche Status-Seite zahlt sich an diesem Punkt aus; sie erlaubt dem Support, jede Kundschaft auf eine einzige aktuelle Seite zu verweisen, statt jeder einzeln zu antworten. Die Seite muss bis zum Ende des Ausfalls aktuell gehalten und danach geschlossen werden.
Warum die Nachbesprechung nie übersprungen werden sollte
Ist ein Ausfall behoben, wird eine kurze Nachbesprechung geschrieben: was passiert ist, wann es bemerkt wurde, wie lange die Behebung dauerte, was sich ändert, damit es nicht wieder passiert. Das Dokument existiert, um eine Wiederholung zu verhindern, nicht um Schuld zuzuweisen.
Fällt das Buchungssystem einer Spa-Kette zweimal hintereinander aus demselben Grund aus, ist das Problem nicht technisch, sondern prozessual; was die erste Nachbesprechung als Maßnahme forderte, wurde nie wirklich umgesetzt. Ein zweiter Ausfall aus demselben Grund verdient mehr Ernsthaftigkeit, nicht weniger.
Häufige Fehler
Uptime-Monitoring kann zu einem Werkzeug werden, das einmal eingerichtet und dann vergessen wird; das passiert fast so oft wie die Ausfälle, die es eigentlich erkennen soll.
- nur die Startseite überwachen, während Kasse oder Login unbeobachtet bleiben
- Alarme nur an eine einzige Person senden, sodass niemand bemerkt, dass sie abwesend ist
- zu selten prüfen, etwa alle dreißig Minuten, und kurze Ausfälle ganz übersehen
- direkt zur nächsten Krise übergehen, ohne eine Nachbesprechung zu machen
Uptime-Monitoring verhindert keinen Ausfall; es sorgt dafür, dass er vor der Kundschaft bemerkt und geordnet gehandhabt wird. Eine gut aufgebaute Alarmkette und die Gewohnheit einer kurzen Nachbesprechung verkürzen, wie lange der nächste dauert. Ein Erstgespräch mit rabbitclip ist ein guter Ort, um Ihre aktuelle Monitoring-Einrichtung gemeinsam durchzugehen.
Häufige Fragen
Lässt sich Uptime-Monitoring mit kostenlosen Werkzeugen umsetzen?
Ja, für eine einfache Ping-/HTTP-Prüfung reichen viele kostenlose Stufen. Synthetisches Monitoring und häufigere Prüfungen liegen meist hinter einer kostenpflichtigen Stufe.
Wie oft sollten Prüfungen laufen?
Ein bis fünf Minuten sind für kritische Seiten üblich. Häufigere Prüfungen erkennen Probleme früher, belasten aber auch den Server zusätzlich.
Braucht jede Seite eine Status-Seite?
Für Seiten mit hoher Kundeninteraktion und für E-Commerce lohnt sie sich. Eine wenig frequentierte Präsenzseite kann darauf verzichten.
Geht es bei einer Nachbesprechung um Schuldzuweisung?
Nein. Der Sinn ist, eine Wiederholung zu verhindern; die Nachbesprechung betrachtet den Prozess und das System, nicht eine Person.
