Incident-Plan: was tun, wenn das Produkt ausfällt
Irgendwann steht dein Produkt still: ein Deploy geht schief, eine Datenbank antwortet nicht mehr, ein externer Dienst fällt weg. Wer in diesem Moment erst überlegt, wer was tun darf, verliert Zeit und Vertrauen. Ein Incident-Plan ist die kurze Antwort darauf, die du vorher schreibst statt mittendrin. Dieser Artikel zeigt dir die fünf Schritte erkennen, eindämmen, kommunizieren, beheben, lernen und macht sie für kleine Teams praktikabel.
Warum auch ein kleines Produkt einen Incident-Plan braucht
Ein Incident ist jeder Moment, in dem dein Produkt nicht mehr so funktioniert, wie deine Nutzer es erwarten: die App lädt nicht, das Login dreht sich, eine Bestellung läuft ins Leere. Ob das ein kompletter Ausfall ist oder nur eine Funktion, die hängt, spielt für den Betroffenen kaum eine Rolle. Für ihn ist gerade etwas kaputt.
Viele kleine Teams denken, ein Plan für solche Fälle sei etwas für Konzerne mit Bereitschaftsdienst und eigenem Operations-Team. Das Gegenteil stimmt. Je kleiner das Team, desto teurer ist die Minute, in der jemand erst nachdenkt, wer eigentlich Zugriff auf den Server hat und wo die Logs liegen. Ein Incident-Plan ist im Kern eine vorbereitete Entscheidung: Du legst in Ruhe fest, was unter Stress passieren soll, damit niemand unter Druck improvisieren muss.
Wir betreiben mit Wortfreunde und Reazon eigene Produkte, nicht nur fremde. Das heisst, wir sind selbst die, die nachts das Telefon in der Hand halten, wenn etwas klemmt. Das schärft den Blick: Ein Plan, den man nur einmal geschrieben und dann nie gebraucht hat, ist trotzdem die Stunde Arbeit wert gewesen. Denn der eine Fall, in dem du ihn brauchst, kommt zur ungünstigsten Zeit.
Die fünf Schritte: erkennen, eindämmen, kommunizieren, beheben, lernen
Ein Incident hat einen Lebenszyklus, und der ist bei einer Drei-Personen-Firma nicht anders als bei einem grossen Anbieter, nur kürzer. Diese fünf Phasen geben dir ein Gerüst, an dem du dich entlanghangeln kannst, auch wenn der Adrenalinspiegel hoch ist.
Erkennen heisst, überhaupt zu merken, dass etwas nicht stimmt, idealerweise bevor der erste Nutzer eine Mail schreibt. Eindämmen bedeutet, den Schaden zu begrenzen, oft bevor die eigentliche Ursache klar ist. Kommunizieren läuft parallel zu allem: Betroffene wollen wissen, dass du es weisst und dran bist. Beheben ist die technische Reparatur. Lernen kommt danach, wenn die Köpfe wieder kühl sind, und sorgt dafür, dass derselbe Fehler nicht dreimal passiert.
Die Reihenfolge ist kein Dogma. In der Praxis greifen die Schritte ineinander, du kommunizierst, während du eindämmst, und behebst, während du schon die Notizen für die Nachbereitung sammelst. Wichtig ist, dass keiner der fünf vergessen geht. Der, der am häufigsten unter den Tisch fällt, ist der letzte.
Wer macht was: Rollen statt Heldentum
Unter Stress ist die teuerste Frage die nach der Zuständigkeit. Drei wahre Geschichten in einem: Zwei Leute editieren gleichzeitig dieselbe Konfiguration, ein Dritter startet den Dienst neu, während der Erste noch debuggt, und niemand schreibt den Kunden. Das passiert nicht aus Unfähigkeit, sondern weil Rollen fehlen.
Du brauchst keine Organigramme. Für den Anfang reichen zwei Rollen. Der Incident-Lead trifft Entscheidungen und behält den Überblick, er tippt nicht selbst, sondern koordiniert. Der Operator packt an der Technik an. Bei einem Einzelkämpfer fallen beide Rollen zusammen, dann ist die wichtigste Disziplin, zwischen Denken und Tun bewusst umzuschalten und nicht beides gleichzeitig halb zu machen.
Sobald ihr zu zweit oder zu dritt seid, lohnt sich eine dritte Rolle: jemand, der kommuniziert, also den Statustext schreibt und Anfragen beantwortet, damit der Operator in Ruhe arbeiten kann. Halte fest, wer diese Rollen im Ernstfall übernimmt und wer einspringt, wenn die erste Person im Urlaub oder im Zug ohne Empfang ist. Eine Rolle ohne benannte Vertretung ist im Notfall keine Rolle.
Das Runbook: die Schritte, die du nicht auswendig können willst
Ein Runbook ist eine schlichte Sammlung von Anleitungen für wiederkehrende Situationen. Kein Roman, eher eine Checkliste, die ein müder Mensch um drei Uhr nachts noch versteht. Es beantwortet die Fragen, die du im Ernstfall nicht googeln willst: Wo logge ich mich ein? Wie sehe ich, ob die Datenbank lebt? Wie starte ich den Dienst sauber neu? Wie spiele ich das letzte Backup zurück?
Fang mit den zwei oder drei Szenarien an, die am wahrscheinlichsten sind. Bei den meisten Produkten sind das ein hängender Anwendungsserver, eine überlastete oder nicht erreichbare Datenbank und ein ausgefallener externer Dienst, etwa der Zahlungsanbieter oder der Mailversand. Für jedes Szenario notierst du, woran du es erkennst und welche konkreten Befehle oder Klicks es entschärfen.
Ein gutes Runbook hat zwei Eigenschaften, die oft fehlen. Es liegt dort, wo du im Ernstfall hinkommst, also nicht ausschliesslich in dem System, das gerade ausgefallen sein könnte. Und es ist getestet: Du hast den Backup-Restore mindestens einmal geübt, statt nur zu hoffen, dass er klappt. Wer Monitoring, Backups und Alerting als Minimum ernst nimmt, hat hier schon die halbe Arbeit gemacht, mehr dazu im Artikel über das Minimum an Betriebsabsicherung. Der Restore, den niemand je ausprobiert hat, ist kein Backup, sondern eine Hoffnung.
Statuskommunikation: was, wann und wie offen
Die Technik ist oft das kleinere Problem. Den meisten Schaden richtet das Schweigen an. Ein Nutzer, der eine halbe Stunde gegen eine tote App klickt und nichts hört, fühlt sich im Stich gelassen. Derselbe Nutzer, der nach fünf Minuten eine Zeile liest, dass ihr das Problem kennt und daran arbeitet, bleibt erstaunlich geduldig.
Deine Statuskommunikation braucht drei Antworten: Was ist betroffen, seit wann arbeitet ihr daran, und wann gibt es das nächste Update. Den genauen Lösungszeitpunkt kennst du meist nicht, und du sollst ihn auch nicht erfinden. Sag stattdessen verbindlich, wann das nächste Lebenszeichen kommt, etwa in dreissig Minuten, und halte das ein. Eine Statusseite oder ein klarer Kanal, den eure Nutzer kennen, ist Gold wert, weil er die Support-Mails bündelt und du nicht zwanzigmal dasselbe tippst.
Formuliere nüchtern und klar, ohne Schuldzuweisungen und ohne Beschönigung. Wenn Daten betroffen sein könnten, sag das, sobald du es sicher weisst, nicht früher und nicht später. Diese Haltung ist nicht nur Anstand, sie ist Risikomanagement: Vertrauen, das im Incident hält, spart dir die Kündigungswelle danach.
Nachbereitung: aus einem Ausfall einen Schutz machen
Wenn das Produkt wieder läuft, ist die Versuchung gross, einfach erleichtert weiterzumachen. Genau hier entscheidet sich, ob der Ausfall dich klüger macht oder ob er in einem halben Jahr wiederkommt. Die Nachbereitung, oft Post-Mortem genannt, ist ein kurzes Dokument: Was ist passiert, wann, was hat geholfen, was hat aufgehalten, und welche zwei oder drei konkreten Massnahmen verhindern die Wiederholung.
Der entscheidende Punkt: Die Nachbereitung sucht keine Schuldigen, sie sucht Ursachen. Wenn jemand einen falschen Befehl abgesetzt hat, ist die spannende Frage nicht, wer geschlampt hat, sondern warum es so leicht war, den Fehler zu machen, und wie man ihn unmöglicher macht. Ein System, in dem ein einzelner Tippfehler die Produktion kippt, ist das eigentliche Problem, nicht die Person, die ihn getippt hat.
Aus den Massnahmen werden Aufgaben mit Verantwortlichen, sonst bleibt es Papier. Vielleicht fehlt ein Alert, der euch früher gewarnt hätte. Vielleicht war der Restore zu langsam, weil ihn niemand geübt hatte. Vielleicht braucht ihr eine Statusseite, die ihr im Ausfall vermisst habt. Jeder Incident, sauber nachbereitet, macht den nächsten weniger wahrscheinlich oder zumindest weniger schmerzhaft.
Wann ein voller Incident-Plan zu viel des Guten ist
Nicht jedes Projekt braucht den ganzen Apparat von Tag eins an. Wenn du an einem Prototyp arbeitest, den eine Handvoll Tester benutzt, und ein Ausfall niemandem wehtut, dann ist ein dreistündiger Workshop über Eskalationsketten verschwendete Zeit. In dieser Phase reicht ein Notizzettel: Wo logge ich mich ein, wie starte ich neu, wen rufe ich an. Mehr Plan als Risiko wäre hier Theaterdonner.
Die Schwelle, ab der sich der volle Plan lohnt, ist nicht die Nutzerzahl allein, sondern die Frage, was ein Ausfall kostet. Sobald echte Kunden echtes Geld bezahlen, sobald ein stiller Datenverlust unbemerkbar wäre oder ein längerer Ausfall einen Vertrag gefährdet, kippt die Rechnung. Das deckt sich mit der Logik aus unserem Artikel dazu, warum Betrieb ab Tag eins produktionsreif sein sollte: Die Frage ist nicht ob, sondern ab wann.
Und es gibt den umgekehrten Weg. Wenn du merkst, dass dich der Betrieb und die Bereitschaft mehr Nerven kosten, als dir lieb ist, musst du das nicht allein stemmen. Genau dafür gibt es Produkt-Betrieb als Leistung: jemand, der das Monitoring aufsetzt, das Runbook pflegt und im Ernstfall mit anpackt, während du dich um dein Geschäft kümmerst. Ob du das selbst aufbaust oder abgibst, hängt davon ab, wie nah dein eigenes Team an der Technik dranbleiben will.
Den Plan schreiben, bevor du ihn brauchst
Der beste Zeitpunkt für deinen ersten Incident-Plan ist ein ruhiger Nachmittag, an dem nichts brennt. Setz dich eine Stunde hin, schreib die zwei wahrscheinlichsten Ausfallszenarien auf, leg die Rollen fest, notiere die Zugänge und einen Satz, den du im Ernstfall an deine Nutzer schicken würdest. Das ist kein perfektes Dokument, und es soll auch keines sein. Es ist die Version, die du in drei Monaten nach dem ersten echten Vorfall überarbeitest.
Ein Incident-Plan altert mit dem Produkt. Neue Funktionen bringen neue Bruchstellen, ein gewechselter Hoster verschiebt die Zugänge, ein zusätzlicher externer Dienst öffnet eine neue Fehlerquelle. Schau ihn ein- oder zweimal im Jahr an und nach jedem grösseren Vorfall. So bleibt er das, was er sein soll: die kurze, klare Antwort auf die Frage, die irgendwann kommt, nämlich was zu tun ist, wenn das Produkt gerade nicht tut, was es soll.