Monitoring, Backups, Alerting: das Minimum für ein KMU-Produkt

Monitoring, Backups und Alerting: drei Schichten, ein Ziel

Wenn ein Produkt online geht, verschiebt sich die Frage. Vorher ging es darum, ob die Software funktioniert. Danach geht es darum, ob sie weiter funktioniert, auch wenn niemand hinschaut. Dafür gibt es drei Schichten: Monitoring, Backups und Alerting. Sie klingen technisch, und genau deshalb landen sie oft auf dem Stapel machen wir später. Später heisst im Schadensfall, und dann ist es zu spät.

Jede der drei beantwortet eine andere Frage. Monitoring: läuft mein System gerade so, wie es soll? Backups: bekomme ich meine Daten zurück, wenn etwas kaputtgeht? Alerting: werde ich rechtzeitig geweckt, bevor ein Kunde es merkt? Erst zusammen ergeben sie einen Betrieb, dem du trauen kannst. Fehlt eine, hat das Konstrukt ein Loch, durch das im falschen Moment alles fällt.

Ich nehme jeden Begriff einzeln auseinander, baue daraus ein kleines Minimum-Setup und spiele am Schluss durch, was bei jeder fehlenden Schicht konkret schiefgeht. Wer ein eigenes SaaS für ein KMU betreibt, kommt an diesen drei Themen ohnehin nicht vorbei.

Monitoring: sehen, was das System gerade tut

Monitoring heisst, dass du laufend misst, wie es deinem System geht, und diese Werte sichtbar machst. Ohne Monitoring ist dein Produkt eine Blackbox. Du weisst, dass es läuft, aber nicht, wie es ihm dabei geht. Mit Monitoring bekommst du Instrumente, so wie ein Auto Tacho, Tankanzeige und Temperaturanzeige hat.

Gemessen wird auf zwei Ebenen. Die Infrastruktur ist die eine: Läuft der Server? Wie voll sind Arbeitsspeicher und Festplatte? Wie stark hängt die CPU? Antwortet die Datenbank noch? Die Anwendung ist die andere: Wie schnell beantwortet die Software Anfragen, wie viele davon enden im Fehler, funktioniert der Login, geht die Bezahlung durch? Die erste Ebene sagt dir, ob die Maschine läuft. Die zweite sagt dir, ob die Maschine das Richtige tut. Beide brauchst du, denn ein Server kann tadellos laufen, während der Checkout seit zwei Stunden jede Zahlung verweigert.

Ein zentraler Baustein ist der Health-Check: ein kleiner Endpunkt in deinem System, der auf Anfrage meldet, ob die wichtigen Teile erreichbar sind. Datenbank verbunden, externe Dienste erreichbar, Speicher frei. Ein Dienst von aussen ruft diesen Endpunkt im Minutentakt auf. Antwortet er nicht oder meldet ein Problem, weisst du es sofort.

Ein Punkt, der gern verschwimmt: Monitoring misst und zeigt, mehr nicht. Es weckt dich nicht. Ein Dashboard voller schöner Kurven, das niemand anschaut, hilft dir um drei Uhr nachts genau gar nicht, wenn die Datenbank vollläuft. Das Wecken ist Sache des Alertings, zu dem ich gleich komme. Monitoring liefert die Wahrheit, Alerting bringt sie zu dir.

Backups: der Weg zurück, wenn Daten weg sind

Backups sind Kopien deiner Daten an einem anderen Ort, damit du sie nach einem Verlust wiederherstellen kannst. Klingt banal, ist aber die Schicht, die am häufigsten nur halb gemacht wird. Daten verschwinden nämlich selten durch einen Hardware-Defekt. Häufiger löscht ein fehlerhaftes Update die falsche Tabelle, klickt jemand versehentlich auf Delete oder verschlüsselt ein Angreifer deine Datenbank. In all diesen Fällen ist das Backup der einzige Weg zurück.

Drei Eigenschaften machen ein Backup brauchbar. Automatisch, denn ein Backup, das jemand von Hand anstossen muss, wird genau dann vergessen, wenn es zählt. Regelmässig, denn wie oft du sicherst, bestimmt, wie viel Arbeit im Ernstfall verloren ist: sicherst du einmal täglich, kann im schlimmsten Fall ein ganzer Tag fehlen. Und getrennt aufbewahrt, denn ein Backup auf demselben Server, der kaputtgeht, ist kein Backup. Es gehört an einen anderen Ort, idealerweise zu einem anderen Anbieter oder zumindest in eine andere Region.

Dann kommt der Schritt, den fast alle überspringen: Wiederherstellen testen. Ein Backup, das du nie zurückgespielt hast, ist eine Hoffnung, kein Plan. Datenformate ändern sich, Dateien sind unvollständig, im Wiederherstellungsprozess steckt ein Schritt, den keiner mehr kennt. Das merkst du nur, wenn du es ausprobierst, bevor du es brauchst. Trag dir einen festen Termin ein, an dem du die Wiederherstellung in einer Testumgebung durchspielst.

Für die Planung helfen zwei Begriffe. Der RPO (Recovery Point Objective) sagt, wie viel Datenverlust du verkraftest, also wie alt das letzte Backup höchstens sein darf. Die RTO (Recovery Time Objective) sagt, wie lange die Wiederherstellung dauern darf, bis das System wieder läuft. Beide hängen am Geschäft: Ein internes Tool verträgt einen Tag Ausfall, eine Kassensoftware am Samstag nicht eine Stunde. Diese zwei Zahlen bestimmen, wie aufwendig dein Backup-Setup sein muss, und damit, was es kostet.

Alerting: rechtzeitig geweckt werden

Alerting macht aus den Daten des Monitorings eine Nachricht an einen Menschen, sobald etwas Wichtiges passiert. Monitoring sieht das Problem, Alerting sorgt dafür, dass du davon erfährst, ohne ständig auf ein Dashboard zu starren. Ohne Alerting nützt dir das beste Monitoring nur, wenn zufällig jemand hinschaut.

Die Kunst liegt nicht darin, viele Meldungen zu verschicken, sondern die richtigen. Hier lauert die grösste Falle: Alarm-Müdigkeit. Feuert ein System bei jeder Kleinigkeit, lernt das Team innerhalb von Tagen, die Meldungen wegzuwischen. Und wenn dann der echte Alarm kommt, geht er im Rauschen unter. Gutes Alerting meldet selten, aber wenn es meldet, dann zu Recht.

Deshalb trennst du nach Dringlichkeit. Ein vollgelaufener Speicher, eine nicht erreichbare Datenbank, eine Fehlerrate, die durch die Decke geht: Das muss jemanden sofort erreichen, notfalls per Anruf oder Push. Eine Festplatte, die in zwei Wochen voll sein wird, ist wichtig, aber sie kann warten und gehört in einen Kanal, den du am nächsten Werktag liest. Diese Trennung zwischen wecke mich jetzt und sag es mir später entscheidet, ob ein Team dem Alerting auf Dauer traut.

Zwei Begriffe noch. Ein Schwellenwert legt fest, ab wann ein Zustand als Problem gilt, etwa Speicherauslastung über 90 Prozent. Eskalation beschreibt, was passiert, wenn der erste Empfänger nicht reagiert: nach einer Weile geht die Meldung an die nächste Person. Für ein kleines KMU-Produkt reicht oft eine einzige Person mit Telefon. Der Gedanke dahinter, dass eine Meldung nicht einfach versickern darf, gilt trotzdem.

Ein Minimum-Setup, das an einem Tag steht

Du brauchst kein grosses System, um diese drei Schichten abzudecken. Für ein typisches KMU-Produkt mit einem Server und einer Datenbank reicht ein überschaubares Setup.

Fürs Monitoring baust du einen Health-Check-Endpunkt in deine Anwendung, der prüft, ob Datenbank und die wichtigsten externen Dienste antworten. Davor hängst du einen günstigen externen Uptime-Dienst, der diesen Endpunkt und die öffentliche Startseite im Minutentakt von aussen aufruft. Auf dem Server läuft zusätzlich ein schlanker Agent, der CPU, Arbeitsspeicher und Festplatte erfasst. Damit hast du beide Ebenen abgedeckt.

Für die Backups aktivierst du auf der Datenbank ein automatisches tägliches Backup. Viele gehostete Datenbanken bringen das mit, du musst es nur einschalten und kontrollieren. Die Kopien landen in getrenntem Speicher bei einem anderen Anbieter oder in einer anderen Region. Du legst eine Aufbewahrungsdauer fest, etwa die letzten dreissig Tage, und du blockst dir einen wiederkehrenden Termin, an dem du die Wiederherstellung in einer Testumgebung einmal durchspielst.

Fürs Alerting verbindest du Uptime-Dienst und Server-Monitoring mit einem Kanal, den du wirklich liest. Kritisches wie ein nicht erreichbares System geht per Push oder SMS direkt an dich. Weniger Dringendes wie eine fast volle Festplatte geht in einen separaten Kanal, etwa eine eigene Mailadresse oder einen Chat-Raum. Setz die Schwellenwerte am Anfang lieber unempfindlich und schärf sie nach, sonst züchtest du dir die Alarm-Müdigkeit selbst heran.

Dieses Setup ist bewusst klein. Es nutzt fertige Dienste statt selbst betriebener Werkzeuge, und das ist für ein KMU der richtige Weg. Wächst das Produkt, wächst das Setup mit. Entscheidend ist, dass alle drei Schichten von Tag eins an da sind, nicht dass sie perfekt sind.

Wann weniger reicht und wann nicht

Muss das wirklich jedes Produkt in voller Tiefe haben? Nein. Wie tief du gehst, hängt davon ab, was ein Ausfall kostet und wie viele Leute betroffen sind.

Bei einem rein internen Tool, das ein paar Kollegen nutzen, darfst du beim Alerting abspecken. Ein Tagesausfall tut weh, aber er ruiniert nichts, also reicht oft eine Mailbenachrichtigung statt nachts klingelndem Telefon. Beim Backup darfst du dagegen nie sparen, egal wie klein das Produkt ist: Der Aufwand für ein automatisches tägliches Backup ist minimal, der Schaden ohne eines maximal. Umgekehrt rechtfertigt ein Produkt, an dem Umsatz oder ein gesetzlicher Auftrag hängt, mehr: häufigere Backups für einen kleineren RPO, echte Eskalationsketten, redundante Systeme. Den Aufwand bemisst du am Schaden, nicht am Gefühl.

Einen Fall gibt es, in dem du das alles nicht selbst stemmen solltest. Wenn niemand bei dir nachts ans Telefon geht, ist eine Alarmkette ohne Bereitschaft nur Theater. Dann brauchst du entweder jemanden, der die Bereitschaft übernimmt, oder eine Plattform, die das Meiste von sich aus abfängt. Lieber klein und wirklich abgedeckt als ein grosses Setup, auf das nachts keiner reagiert.

Was passiert, wenn eine Schicht fehlt

Am deutlichsten wird der Wert der drei Schichten, wenn du durchspielst, was ohne sie passiert. Jede Lücke hat ihr eigenes Schadensmuster.

Fehlt das Monitoring, fliegst du blind. Das System kann seit Stunden zäh sein, eine Teilfunktion kann ausgefallen sein, und du merkst nichts. Du erfährst von Problemen über den langsamsten und teuersten Kanal überhaupt: über Kunden, die sich beschweren oder still kündigen. Und wenn doch etwas auffällt, fehlen dir die Daten, um die Ursache zu finden. Du rätst, statt zu wissen.

Fehlen die Backups, wird ein einziger schlechter Tag existenzbedrohend. Gelöschte Tabelle, fehlerhaftes Update, Verschlüsselungsangriff: ohne Backup sind die Daten weg, und mit ihnen Vertrauen, Kunden und im schlimmsten Fall das Geschäft. Das ist die Schicht, deren Fehlen am seltensten auffällt und am härtesten zuschlägt, weil man es erst im Moment des Verlusts bemerkt. Ein nie getestetes Backup gehört in dieselbe Kategorie: Es fühlt sich sicher an, bis die Wiederherstellung im Ernstfall klemmt.

Fehlt das Alerting, hast du vielleicht sauberes Monitoring, aber niemand wird geweckt. Das Dashboard zeigt um zwei Uhr nachts brav die volllaufende Datenbank, und keiner sieht es. Um acht steht das Produkt, und der erste Hinweis ist wieder der verärgerte Kunde. Monitoring ohne Alerting ist eine Kamera, die aufzeichnet, aber keinen Alarm schlägt.

Das Muster ist jedes Mal dasselbe: Ohne diese Schichten rutscht der Moment, in dem du von einem Problem erfährst, nach hinten, und die Kosten der Behebung nach oben. Ein Problem, das du in Minuten bemerkst, kostet Minuten. Dasselbe Problem, das dir erst nach Tagen über Kundenbeschwerden auffällt, kostet Tage und dazu Vertrauen, das sich nicht zurückkaufen lässt. Das ist einer der Gründe, warum SaaS-Projekte scheitern: nicht am Code, sondern am fehlenden Betrieb danach.

Betrieb ist kein Nachgedanke

Die drei Schichten kosten Geld und Aufwand, das stimmt. Aber der Aufwand zahlt sich aus, weil er die teuren Fälle verhindert, bevor sie entstehen. Die Frage ist nie, ob etwas ausfällt, sondern wann, und ob du es vor oder nach deinen Kunden merkst.

Genau hier liegt ein Unterschied, den wir bei Wertstifter täglich leben. Wir bauen Produkte nicht nur, wir betreiben unsere eigenen, Wortfreunde und Reazon, mit denselben drei Schichten, die ich hier beschrieben habe. Das prägt, wie wir entwickeln: Monitoring, Backups und Alerting kommen bei uns nicht am Ende noch dazu, sie gehören von Anfang an dazu. Eine reine Agentur, die baut und dann übergibt, kennt diesen Schmerz oft nur aus der Theorie. Wer selbst um drei Uhr nachts geweckt wurde, baut danach anders.

Wenn du dein KMU-Produkt nicht selbst rund um die Uhr im Blick behalten willst oder kannst, ist das der Kern von Produkt-Betrieb: Wir richten diese Schichten ein, überwachen sie und reagieren, damit du dich um dein Geschäft kümmerst statt um Server. Das Minimum aus Monitoring, Backups und Alerting ist dabei kein Ziel, das du abhakst, sondern der Boden, auf dem ein Produkt überhaupt erst verlässlich laufen kann.