Das Wichtigste in Kürze
- Ausfallsicherheit entsteht nicht nur durch Ersatzhardware. Jeder Vorgang braucht einen gespeicherten Stand.
- Nach einem Fehler setzt die Bearbeitung an der letzten sicheren Stelle fort.
- Wirkende Schritte dürfen bei einem Neustart nicht doppelt ausgeführt werden.
- Für wichtige Zeiträume bleibt ein einfacher manueller Weg erhalten.
- Eine Datensicherung zählt erst, wenn die Wiederherstellung getestet wurde.
Die Liste der Dinge, die ausfallen können, ist lang, und die Wirklichkeit ergänzt sie zuverlässig. Hardware kann defekt sein. Ein Modellupdate kann scheitern. Die Warenwirtschaft kann wegen Wartung nicht antworten. In einem unserer Projekte war es ein einzelnes PDF — ein schief eingescanntes Bestellfax, gespeichert als eine einzige riesige Bilddatei —, das die Dokumentverarbeitung zum Stehen brachte. Kein Ereignis davon war vorhersehbar. Dass eines davon eintritt, war es schon.
Das Ziel kann deshalb nicht lauten, jeden Fehler unmöglich zu machen. Das Ziel lautet: Ein einzelner Fehler darf keinen Auftrag verschwinden lassen und den ganzen Betrieb nicht anhalten.
Im Projekt haben wir daher keinen langen Ablauf gebaut, der nur von Anfang bis Ende funktioniert. Jeder Vorgang besitzt einen gespeicherten Stand. Die Verarbeitung kann stoppen, geprüft werden und später weiterlaufen.
Ein belastbarer Prozess kann scheitern, ohne die Kontrolle zu verlieren.
Der Vorgang bleibt der feste Anker
Jeder Vorgang durchläuft benannte Zustände: eingegangen, wenn Original und Vorgangsnummer gesichert sind; gelesen, wenn die Bestelldaten vorliegen; geprüft, wenn Material und Termin geklärt sind; freigegeben, wenn wirkende Schritte starten dürfen. Dieser Status steht nicht nur im Arbeitsspeicher eines Programms. Er wird dauerhaft gespeichert. Nach einem Neustart weiß die Lösung deshalb, welche Schritte bereits abgeschlossen sind — und muss nicht raten.
Sichern, fortsetzen, nicht doppelt buchen
Der erste Grundsatz: Jeder Eingang wird sofort gesichert. Nachricht, Anhänge und Vorgangsnummer werden gespeichert, bevor die eigentliche Bearbeitung beginnt. Fällt die Verarbeitung später aus, bleibt der Auftrag erhalten — er wartet, statt zu verschwinden. Nach jedem wichtigen Schritt schreibt die Anwendung zusätzlich einen sicheren Stand: nach dem Lesen, nach der fachlichen Prüfung, vor jeder wirkenden Aktion. Sie muss darum nie den ganzen Ablauf wiederholen, nur den letzten Schritt.
Offene Arbeiten stehen in einer Warteschlange, die einen Neustart überlebt. Ein freier Teil der Anwendung nimmt sich den nächsten Auftrag; bleibt ein Schritt hängen, wird der Vorgang nicht vergessen, sondern bleibt sichtbar liegen. Das unauffällige Vergessen ist bei Softwarefehlern die teuerste Variante — es fällt erst auf, wenn der Kunde anruft.
Heikel sind die Schritte, die nach außen wirken. Vor dem Anlegen eines Auftrags, dem Reservieren einer Nummer oder dem Versand einer Nachricht prüft die Lösung deshalb, ob diese Wirkung bereits eingetreten ist. Ein Neustart erzeugt dann keine Doppelbuchung, und der Kunde bekommt eine Auftragsbestätigung statt drei.
Abhängigkeiten einzeln im Blick, Ersatzweg in Reichweite
Modell, Datenbank, Mailserver und Fachsysteme werden getrennt überwacht. So wird sichtbar, ob nur ein einzelner Dienst fehlt oder die ganze Plattform betroffen ist. Als die Warenwirtschaft des Kunden einmal für eine nächtliche Wartung offline ging, zeigte die Übersicht am Morgen genau das: ein Dienst fehlte, alles andere lief, die betroffenen Vorgänge standen ordentlich vor dem Prüfschritt. Niemand musste suchen, was los war.
Für längere Ausfälle bleibt ein einfacher Ersatzweg erhalten. Mitarbeitende sehen Originaldokument, bisherige Prüfergebnisse und offene Punkte und können den Vorgang manuell weiterführen. Später übernimmt die Anwendung wieder den gespeicherten Stand. Der Ersatzweg ist bewusst schlicht gehalten — eine Notlösung, die selbst erklärungsbedürftig ist, ist keine.
Was bei verschiedenen Ausfällen geschieht
| Ausfall | Automatische Reaktion | Betrieblicher Weg |
|---|---|---|
| Sprachmodell antwortet nicht | Der Vorgang bleibt vor dem Modellschritt stehen. | Später erneut versuchen oder Dokument manuell lesen. |
| Warenwirtschaft ist nicht erreichbar | Keine Bestandsaussage wird erfunden. | Offener Prüfpunkt bleibt sichtbar. |
| Ein PDF blockiert die Verarbeitung | Nur dieser Vorgang wird angehalten. | Datei prüfen oder Daten manuell erfassen. |
| Server startet neu | Offene Aufgaben bleiben erhalten. | Bearbeitung setzt am letzten sicheren Stand fort. |
| Neue Modellversion ist fehlerhaft | Der Betrieb wechselt auf die vorige geprüfte Fassung. | Update wird zurückgenommen und untersucht. |
| Gesamte Plattform fällt länger aus | Neue Eingänge werden gesichert. | Wichtige Fälle laufen im manuellen Modus weiter. |
Was zuerst wieder laufen muss
Nicht jeder Teil der Plattform ist gleich wichtig. Für den Betrieb haben wir eine klare Reihenfolge:
- Neue Bestellungen dürfen nicht verloren gehen.
- Offene Vorgänge und Originaldokumente müssen sichtbar sein.
- Manuelle Bearbeitung muss möglich bleiben.
- Automatische Prüfungen kommen danach zurück.
- Komfortfunktionen und ausführliche Auswertungen folgen zuletzt.
Diese Reihenfolge verhindert, dass eine technisch vollständige Wiederherstellung wichtiger wird als der eigentliche Geschäftsbetrieb.
Datensicherung mit klaren Zielen
Für jede wichtige Datenart ist festgelegt, wie viel Verlust vertretbar ist und wie schnell sie wieder verfügbar sein muss. Die Fachbegriffe dafür lauten RPO und RTO — der maximal hinnehmbare Datenverlust und die maximal hinnehmbare Ausfallzeit. Wichtiger als die Abkürzungen sind die konkreten Aussagen dahinter:
- Eingegangene Bestellungen dürfen nicht verloren gehen.
- Der zuletzt bestätigte Stand eines Vorgangs muss wiederherstellbar sein.
- Der manuelle Betrieb muss innerhalb eines festgelegten Zeitfensters möglich sein.
- Die automatische Verarbeitung darf später zurückkehren.
Ein Backup ohne Rückspiel ist allerdings nur eine Hoffnung. Die Datei kann vorhanden und trotzdem unbrauchbar sein — Passwörter fehlen, Versionen passen nicht zusammen, die Anleitung ist veraltet. Bei unserer ersten Wiederherstellungsübung lag der Schlüssel für die Sicherung ausgerechnet in einem System, das erst aus eben dieser Sicherung wiederherzustellen gewesen wäre. Seitdem liegt er auch woanders, und die Übung findet in festen Abständen auf einer getrennten Umgebung statt: Datensicherungen, Konfiguration und Modellstände werden nicht nur erstellt, sondern tatsächlich zurückgespielt.
Störungen werden geplant, nicht improvisiert
Für häufige Fehler gibt es kurze Arbeitsanweisungen: Woran ist der Fehler zu erkennen? Wer entscheidet? Welche Schritte sind sicher? Wann wird auf den manuellen Weg gewechselt? Wie kommt der Vorgang später zurück in den normalen Ablauf?
Diese Hinweise liegen dort, wo sie bei einer Störung erreichbar sind. Eine Anleitung nur im ausgefallenen System hat begrenzten Unterhaltungswert.
Prüffragen vor dem Betrieb
- Ist jede eingegangene Bestellung sofort gesichert?
- Hat jeder Vorgang einen dauerhaft gespeicherten Stand?
- Können Schritte ohne Doppelwirkung neu gestartet werden?
- Ist für jedes wichtige Fachsystem ein Fehlerzustand vorgesehen?
- Gibt es einen verständlichen manuellen Ersatzweg?
- Sind Modell, Konfiguration und Daten gemeinsam wiederherstellbar?
- Wurde ein kompletter Wiederanlauf praktisch getestet?
Fazit
Ausfallsicherheit ist kein zweiter Server neben dem ersten. Sie steckt im Aufbau des Prozesses: Originale sichern, Zustände speichern, Wiederholungen beherrschen und einen einfachen Ersatzweg erhalten — und all das gelegentlich üben, bevor es der Ernstfall tut.
Dann bleibt ein technischer Ausfall ein technisches Problem. Er wird nicht automatisch zum verlorenen Auftrag.
Quellen und weiterführende Hinweise
Auch der Ersatzweg gehört zur Lösung
Ein produktiver KI-Prozess braucht einen sicheren Zustand, klare Zuständigkeiten und einen geübten Wiederanlauf.
Anwendungsfall besprechen