11. Verfügbarkeit im Betrieb

Verfügbarkeit im Betrieb

Der letzte fachliche Baustein des Schwerpunkts. Ihr System liefert kontrolliert aus und zeigt seinen Zustand. Es fehlt die Frage, was passiert, wenn etwas kaputtgeht: ob es das übersteht, wie schnell es zurückkommt und ob überhaupt jemand weiß, was dann zu tun ist.

Der Leitsatz dieser zwei Wochen ist unbequem und stimmt trotzdem: Was nicht geübt wurde, funktioniert im Ernstfall nicht. Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung. Ein Notfallplan, den niemand gelesen hat, ist ein Dokument. Deshalb wird in diesem Kapitel alles einmal ausgelöst.

Ziele in Zahlen

Was Verfügbarkeit kostet

Zielwert	Ausfall im Monat	Was dafür nötig ist
99 %	rund 7 Stunden	ein Server, Sicherungen, jemand, der werktags hinsieht
99,9 %	rund 43 Minuten	Redundanz, automatischer Wiederanlauf, Bereitschaft
99,99 %	rund 4 Minuten	mehrere Standorte, Rund-um-die-Uhr-Bereitschaft

Jede zusätzliche Neun kostet ungefähr das Zehnfache. Für ein Schulprojekt auf einem VPS mit einer Person, die abends Zeit hat, ist 99 Prozent während der Nutzungszeiten ein anspruchsvolles und redliches Ziel. Alles darüber zu behaupten, ohne die Voraussetzungen zu haben, fällt in der Prüfung sofort auf.

Zielwert und Fehlerbudget

Ein SLO ist der selbst gesetzte Zielwert, gemessen an einem Indikator, etwa dem Anteil erfolgreicher Anfragen. Die Differenz zu 100 Prozent ist Ihr Fehlerbudget: Bei 99,5 Prozent im Monat sind das rund dreieinhalb Stunden, in denen es schlecht laufen darf.

Der Nutzen dieser Rechnung liegt in der Entscheidung, die daraus folgt. Ist das Budget noch voll, kann zügig ausgeliefert werden. Ist es aufgebraucht, geht Stabilität vor neuen Funktionen. Damit ist die Diskussion „schnell oder sicher” keine Frage der Lautstärke mehr, sondern eine Zahl.

Schnell zurück statt nie kaputt

Die Ausfallzeit ergibt sich aus Häufigkeit mal Dauer. An der Häufigkeit lässt sich mit viel Aufwand etwas verbessern; an der Dauer meist mit wenig. Ein Rollback, das drei Minuten dauert, ist mehr wert als der Vorsatz, keine Fehler zu machen.

Ihre Dauer setzt sich aus drei Teilen zusammen: bemerken (Kapitel 10), entscheiden (Notfallplan, weiter unten), beheben (Kapitel 9). Messen Sie alle drei einmal, dann kennen Sie Ihre tatsächliche Erholungszeit.

Und jetzt kommen die Zahlen aus Kapitel 1 zurück: RPO und RTO, also zulässiger Datenverlust und zulässige Ausfalldauer. Diese Woche wird geprüft, ob Sie sie einhalten können.

Gesundheitsprüfungen

Lebendigkeit und Bereitschaft

Prüfung	Frage	Reaktion bei Fehlschlag
Lebendigkeit	Läuft der Prozess überhaupt noch?	neu starten
Bereitschaft	Kann er gerade Anfragen bedienen?	keinen Verkehr schicken

Der Unterschied ist im Betrieb wichtig. Eine Anwendung, die gerade startet oder deren Datenbank kurz weg ist, lebt, ist aber nicht bereit. Wer beides vermischt, startet einen gesunden Prozess neu, weil die Datenbank hakt, und macht damit alles schlimmer.

src/app/api/health/ready/route.ts

export async function GET() {
  try {
    await Promise.race([
      db.$queryRaw`SELECT 1`,
      new Promise((_, reject) => setTimeout(() => reject(new Error("too slow")), 2000)),
    ]);
    return Response.json({ status: "ready" });
  } catch {
    return Response.json({ status: "not ready" }, { status: 503 });
  }
}

Ein Endpunkt, der immer 200 zurückgibt, prüft nichts. Er prüft, ob der Webserver antwortet, und das ist genau der Teil, der selten kaputt ist.

Die Prüfung darf den Ausfall nicht auslösen

Verlockend, aber falsch: in der Bereitschaftsprüfung auch die fremden Dienste aus Kapitel 3 abfragen. Wenn der Zahlungsdienst eine Stunde steht, meldet Ihre Anwendung „nicht bereit”, der Proxy nimmt sie aus dem Verkehr, und aus einer eingeschränkten Funktion wird ein Totalausfall.

Prüfen Sie nur, was Sie zum Bedienen einer Anfrage zwingend brauchen, typischerweise die eigene Datenbank. Der Zustand fremder Dienste gehört auf das Dashboard, nicht in die Bereitschaftsprüfung.

Neustart, Start und Ende

Drei Einstellungen, die zusammengehören: eine Neustartregel im Container, damit ein abgestürzter Prozess von selbst wiederkommt; eine Startprüfung, damit ein langsam startender Dienst nicht sofort als tot gilt; und ein elegantes Herunterfahren, damit beim Ausrollen keine Anfrage mitten im Vorgang abgeschnitten wird. Beim Signal zum Beenden nimmt die Anwendung keine neuen Anfragen mehr an, arbeitet die laufenden fertig, schließt den Verbindungspool und geht dann.

Ausfälle abfedern

Zählen Sie zuerst auf, was bei Ihnen allein steht. Auf einem VPS ist das eine kurze und ernüchternde Liste.

Einzelne Fehlerquelle	Wirkung	Was machbar ist
Der eine Server	alles weg	Sicherung außer Haus, Wiederaufbauanleitung, gemessene Aufbauzeit
Die eine Datenbank	alles weg	Sicherung, kurze RPO, geübte Rückspielung
Die eine Platte	alles weg	Sicherung an einem zweiten Ort
Ein fremder Dienst	eine Funktion weg	verschlechterter Betrieb aus Kapitel 3
DNS und Domain	nicht erreichbar, trotz laufendem System	Verlängerung automatisieren, Ablaufdatum in den Kalender
TLS-Zertifikat	Browser verweigert	automatische Erneuerung überwachen
Die eine Person mit den Zugängen	niemand kommt hinein	Zugänge im Team, im Passwortspeicher

Die letzten drei Zeilen sind die, die in der Praxis am häufigsten zuschlagen und am billigsten zu verhindern sind.

Wenn es doch trifft, sagen Sie es den Leuten. Eine Wartungsseite über den Reverse Proxy mit einem Satz dazu, was los ist und wann es weitergeht, ist besser als eine Fehlermeldung des Browsers, und deutlich besser als eine Seite, die scheinbar lädt. Kurz, klar und ohne Beschönigung: Was geht nicht, seit wann, was tun wir, wann kommt die nächste Meldung.

Backup und Wiederherstellung

Was gesichert wird

Was	Wie oft	Anmerkung
Datenbank	täglich, besser stündlich	pg_dump reicht in dieser Größenordnung
Hochgeladene Dateien	täglich	ohne sie sind die Datensätze wertlos
CMS-Inhalte und Medien	täglich	eigene Datenbank, eigenes Volumen
Konfiguration	bei Änderung	im Repository, damit ohnehin versioniert
Geheimnisse	bei Änderung	getrennt vom Rest, im Passwortspeicher

Die 3-2-1-Regel: drei Kopien, auf zwei verschiedenen Medien, eine davon außer Haus. Für Ihr Projekt heißt das mindestens: die Daten auf dem Server, eine Sicherung auf dem Server, eine Kopie an einem anderen Ort. Eine Sicherung, die auf derselben Platte liegt wie die Daten, ist gegen genau ein Szenario wirksam, nämlich das versehentliche Löschen.

#!/bin/sh
set -eu
STAMP=$(date +%Y%m%d-%H%M)

docker exec db pg_dump -U app werkstatt | gzip \
  | age -r "$BACKUP_RECIPIENT" > "/backup/db-$STAMP.sql.gz.age"

tar czf - /data/uploads \
  | age -r "$BACKUP_RECIPIENT" > "/backup/files-$STAMP.tar.gz.age"

rclone copy /backup remote:backup-werkstatt          # off-site
find /backup -mtime +30 -delete                      # retention

curl -fsS "$HEARTBEAT_URL"                           # report success

Zwei Zeilen daran verdienen Aufmerksamkeit. Die Sicherung ist verschlüsselt, weil sie personenbezogene Daten enthält und außer Haus wandert; der private Schlüssel liegt nicht auf demselben Server, sonst ist die Verschlüsselung folgenlos. Und die letzte Zeile meldet den Erfolg an einen Dienst, der Alarm schlägt, wenn die Meldung ausbleibt. Eine Sicherung, die seit sechs Wochen scheitert, ist der Normalfall, wenn niemand sie überwacht.

Wiederherstellung üben

1. Testumgebung leeren. Keine Rückspielung in Produktion zum Üben, keine Ausnahme.

2. Uhr starten und die Sicherung von außer Haus holen, nicht die lokale Kopie. Genau dieser Schritt ist im Ernstfall der langsame.

3. Entschlüsseln und einspielen, Datenbank und Dateien.

4. Prüfen: Anmeldung, ein Datensatz von gestern, ein hochgeladenes Bild, Anzahl der Zeilen in den Haupttabellen.

5. Uhr stoppen. Diese Zahl ist Ihre RTO. Der Zeitpunkt der Sicherung gegenüber dem Ausfall ist Ihre RPO.

6. Protokoll schreiben in docs/betrieb.md: Datum, Dauer je Schritt, Auffälligkeiten, was beim nächsten Mal schneller geht.

Vergleichen Sie die beiden Zahlen mit den Zielen aus Kapitel 1. Wenn Sie dort vier Stunden versprochen haben und die Übung sieben ergibt, ist das ein Ergebnis: Entweder die Sicherung wird häufiger und der Ablauf schlanker, oder das Ziel wird korrigiert. Beides ist zulässig, das Ignorieren nicht.

Verhalten unter Last

Der Lasttest aus der 4. Klasse kommt wieder, jetzt gegen ein System, das echte Daten hat. Deshalb mit Sicherheitsnetz:

• Im Team angekündigt, außerhalb der Nutzungszeiten.
• Mit Abbruchkriterium: Fehlerrate über zehn Prozent oder p95 über fünf Sekunden, dann Stopp.
• Mit Blick auf das Dashboard aus Kapitel 10, während der Test läuft.
• Mit dem Wissen um die eigene Ratenbegrenzung, sonst messen Sie diese statt der Anwendung.

Interessant ist nicht der Bestwert, sondern der Sättigungspunkt: die Zahl gleichzeitiger Benutzer, ab der die Antwortzeit steigt, ohne dass der Durchsatz mitwächst. Und die Anschlussfrage, was zuerst nachgibt: CPU, Arbeitsspeicher, Datenbankverbindungen oder eine einzelne Abfrage.

Daraus folgt der Überlastschutz. Ein System, das unter Last komplett stehen bleibt, ist schlechter als eines, das einen Teil der Anfragen sofort abweist. Die Werkzeuge dafür kennen Sie: Ratenbegrenzung am Rand, Obergrenzen für teure Endpunkte, begrenzte Warteschlangen, und im Notfall Lastabwurf mit 429 statt einer Zeitüberschreitung für alle. Langsam und teilweise schlägt vollständig ausgefallen.

Angriffe im Betrieb

Eine Web Application Firewall sitzt vor Ihrer Anwendung und filtert Anfragen nach Regeln, üblicherweise nach dem OWASP Core Rule Set. Was sie leistet: Sie hält massenhafte Standardangriffe ab, fängt bekannte Angriffsmuster ab und verschafft Ihnen Zeit, wenn eine Lücke in einer Abhängigkeit bekannt wird, bevor Sie ausliefern können.

Was sie nicht leistet, steht schon in Kapitel 7: Gegen Logikfehler ist sie blind, weil eine Anfrage, die fremde Buchungen abruft, vollkommen normal aussieht.

Wer eine WAF einschaltet, tut das in zwei Schritten. Zuerst im Beobachtungsmodus, bei dem alles protokolliert und nichts blockiert wird, ein bis zwei Wochen lang. Dann sehen Sie sich die Treffer an und stellen fest, dass Ihr eigenes Formular für Maschinenbeschreibungen regelmäßig anschlägt. Erst wenn diese Falschmeldungen ausgeräumt sind, wird blockiert. Umgekehrt sperren Sie Ihre eigenen Benutzer aus und schalten die WAF nach zwei Tagen entnervt ab.

Dazu kommen Ratenbegrenzung am Reverse Proxy, einfache Bot-Abwehr und der Grundschutz gegen Überflutungsangriffe, den Ihr Anbieter oder ein vorgeschaltetes CDN mitbringt. Gegen einen ernsthaften verteilten Angriff kann ein einzelner VPS nichts ausrichten, und das gehört zu den Restrisiken, die Sie benennen.

Vorfälle

Der Notfallplan

Eine Seite, mehr nicht, aber sie beantwortet fünf Fragen:

1. Wer bemerkt es? Der Alarm aus Kapitel 10 und die Prüfung von außen.
2. Wer entscheidet? Eine namentlich genannte Person, mit Vertretung.
3. Wer informiert wen? Benutzer über die Statusseite, Betreuung, bei Datenpannen die Behörde binnen 72 Stunden (Kapitel 4).
4. Wo steht die Anleitung? Und zwar nicht nur in dem System, das gerade ausgefallen ist. Eine Kopie liegt außerhalb, notfalls ausgedruckt.
5. Was sind die ersten drei Schritte? Je Störungsart eine kurze Handlungsanweisung, verlinkt aus dem Alarm.

# Anleitung: Anwendung antwortet mit 5xx

1. Dashboard öffnen: Fehlerrate, p95, Sättigung, laufende Version
2. Letzte Auslieferung prüfen. Kurz davor? → Rollback (docs/betrieb.md)
3. Datenbank erreichbar? `docker exec db pg_isready`
4. Speicher und Platte: `free -h`, `df -h`
5. Wenn nichts greift: Wartungsseite aktivieren, Betreuung informieren
6. Nach Behebung: Rauchtest, Vorfall notieren

Nachbetrachtung ohne Schuld

Nach jedem Vorfall eine kurze Aufarbeitung, und zwar über das System und nicht über Personen. „Ein Klick hat Produktion gelöscht” ist keine Aussage über den Klickenden, sondern über ein System, in dem ein Klick Produktion löschen kann.

# Vorfall 2026-04-17: Anwendung 34 Minuten nicht erreichbar

Zeitleiste
  10:37  Release 1.4.2 ausgeliefert
  10:39  Alarm HoheFehlerrate
  10:44  Ursache gesucht, Dashboard zeigt Datenbankfehler
  10:58  Rollback auf 1.4.1 gestartet
  11:11  Rauchtest grün

Auswirkung   34 Minuten, alle Benutzer, keine Datenverluste
Ursache      Migration hat eine Spalte umbenannt, die die alte Version
             noch gelesen hat; beide Versionen liefen kurz gleichzeitig
Maßnahmen    1. Vier-Schritte-Verfahren verbindlich (Kapitel 9)  [Name, 24.04.]
             2. Prüfung in der Pipeline: verbietet DROP und RENAME [Name, 30.04.]
             3. Alarm auf Datenbankfehler ergänzt                 [Name, 20.04.]

Der Ertrag steht in der letzten Zeile: Aus jedem Vorfall wird ein Test, ein Alarm oder eine Regel. Ein Vorfall, nach dem sich nichts ändert, kommt wieder.

Häufige Stolperfallen

1. Sicherung vorhanden, nie zurückgespielt. Der klassische Totalverlust.
2. Sicherung auf derselben Platte wie die Daten.
3. Sicherung nicht überwacht. Sie scheitert seit Wochen still.
4. Verschlüsselte Sicherung, Schlüssel auf demselben Server.
5. Gesundheitsprüfung, die immer 200 liefert.
6. Fremde Dienste in der Bereitschaftsprüfung, und deren Ausfall wird zu Ihrem.
7. Lebendigkeit und Bereitschaft vermischt, und gesunde Prozesse werden neu gestartet.
8. Wiederherstellungsanleitung im ausgefallenen System.
9. Lasttest gegen Produktion ohne Ankündigung, Grenzen und Abbruchkriterium.
10. WAF sofort im Blockiermodus, danach ist sie zwei Tage später aus.
11. WAF eingeschaltet und Sicherheitsarbeit für erledigt erklärt.
12. Domain oder Zertifikat abgelaufen, obwohl das System lief.
13. Nach dem Vorfall aufatmen und nichts ändern.

Lernergebnisse

• Erklären: Verfügbarkeitsziele in Zahlen ausdrücken und begründen, was auf der eigenen Infrastruktur erreichbar ist.
• Anwenden: ein Fehlerbudget bestimmen und daraus eine Entscheidungsregel ableiten.
• Erklären: den Unterschied zwischen Lebendigkeit und Bereitschaft erklären und beides passend umsetzen.
• Beurteilen: entscheiden, welche Abhängigkeiten in eine Gesundheitsprüfung gehören und welche nicht.
• Analysieren: einzelne Fehlerquellen im eigenen Aufbau benennen und Gegenmaßnahmen bewerten.
• Anwenden: ein verschlüsseltes, überwachtes Backup mit Aufbewahrung und Kopie außer Haus einrichten.
• Anwenden: eine vollständige Wiederherstellung gegen die Uhr durchführen und gegen RPO und RTO prüfen.
• Analysieren: das Verhalten unter Last messen, den Sättigungspunkt bestimmen und den Engpass benennen.
• Anwenden: Überlastschutz umsetzen, damit Teilbetrieb statt Totalausfall entsteht.
• Beurteilen: Leistung und Grenzen einer WAF einschätzen und sie ohne Selbstausschluss in Betrieb nehmen.
• Erschaffen: einen Notfallplan mit Handlungsanweisungen erstellen und eine Nachbetrachtung schreiben, die Maßnahmen hervorbringt.

Arbeit am Jahresprojekt

• Gesundheitsprüfungen für Lebendigkeit und Bereitschaft, im Container und im Proxy verwendet, mit Nachweis, dass die Bereitschaft bei gestoppter Datenbank tatsächlich 503 liefert.
• Automatisches Backup von Datenbank, Dateien und CMS, verschlüsselt, mit Kopie außer Haus, Aufbewahrungsfrist und Überwachung.
• Ein Wiederherstellungsprotokoll: vollständige Rückspielung in die Testumgebung mit Zeiten je Schritt, verglichen mit RPO und RTO aus Kapitel 1.
• Lasttestbericht: Sättigungspunkt, Engpass, Gegenmaßnahme, Wiederholungsmessung.
• Überlastschutz aktiv, mindestens Ratenbegrenzung und Obergrenzen für teure Endpunkte.
• WAF oder gleichwertiger Schutz aktiv, mit Notiz zur Beobachtungsphase und den ausgeräumten Falschmeldungen.
• Notfallplan mit Zuständigkeiten und mindestens drei Handlungsanweisungen, außerhalb des Systems verfügbar.
• Eine Nachbetrachtung zu einem echten oder gestellten Vorfall, mit Maßnahmen und Verantwortlichen.

Passende Übungen

• Aufgabe - Wiederherstellung gegen die Uhr
• Aufgabe - Gesundheitsprüfung, die den Ausfall wirklich erkennt
• Aufgabe - Lasttest mit Sättigungspunkt
• Aufgabe - Vorfall simulieren und Nachbetrachtung schreiben