Incident-Management und operativer Zyklus

1. Was ist ein Incident in der Welt der ChatGPT‑Apps

Im klassischen Web ist ein Incident meist so etwas wie „Server ist down“, „500er‑Fehler sind stark angestiegen“, „die Latenz hat sich verdoppelt“. Die formale ITIL‑Definition: Ein Incident ist eine ungeplante Unterbrechung eines Services oder eine Verschlechterung seiner Qualität.

In der Welt der ChatGPT‑Apps und bei GiftGenius ist das Bild komplexer. Es kommt eine Modelle‑Schicht hinzu, die:

• das benötigte Tool nicht aufruft, obwohl alles verfügbar ist;
• ein Tool mit falschen Parametern aufruft;
• Ergebnisse „halluziniert“ und dabei Ihren MCP ignoriert.

Daher kann ein Incident nicht nur ein HTTP 500 sein, sondern auch der Fall, dass alle Backend‑Metriken grün sind, Nutzende aber massenhaft klagen: „Der Bot ist lahm und zeigt keine Geschenke“ – weil das Modell aufgehört hat, suggest_gifts aufzurufen oder Argumente verwechselt. Das ist ein Qualitäts‑Incident (Quality incident).

Es ist hilfreich, Incidents nach Kategorien zu denken:

Ein Incident liegt vor, wenn eine Ist‑Metrik außerhalb des vorher vereinbarten SLO liegt. Zum Beispiel:

• vereinbart: p95 der Geschenkeauswahl < 4 Sekunden. Jetzt sind es 9 Sekunden;
• wir wollen, dass 99% der Checkouts pro Woche erfolgreich sind, jetzt sind es 94%;
• wir erwarten, dass das Modell in Kauf‑Szenarien nahezu immer create_checkout_session aufruft, sehen in den Logs aber einen sprunghaften Anstieg der „Auslassungen“.

Wichtig: Ein Incident ist nicht „jemand hat im Chat gemeckert“. Eine Beschwerde ist ein Trigger, aber die Entscheidung „ja, das ist ein Incident“ treffen wir anhand von SLO/SLI und Dashboards.

2. Wie SLO/SLI zu Incidents werden

Im Modul zur Observability haben Sie bereits die Schlüsselmetriken definiert: Latenz, Availability, Error‑Rate, Checkout‑Erfolg. Jetzt nutzen wir sie als „Türsteher“.

Das einfachste Szenario: Wir haben ein SLO für checkout_success_rate. Wir führen strukturierte Ereignis‑Logs:

// Beispiel eines Checkout-Logevents im MCP-Server
logger.info({
  event: 'checkout_result',
  request_id,
  user_id,
  checkout_session_id,
  status: 'success', // oder 'failed'
  error_code: null,
});

Darauf baut man eine Metrik: Anteil von status = "success" unter allen checkout_result der letzten N Minuten/Stunden. Wenn dieser Anteil unter den Schwellenwert fällt (z. B. 95% über 10 Minuten), sendet das Monitoring einen Alert in den On‑Call‑Kanal. Das ist die Incident‑Detektion: Das SLI liegt außerhalb des SLO.

Genauso können Alerts feuern bei:

• Anstieg der error_rate der Tools suggest_gifts, search_products;
• Anstieg der p95/p99‑Latenz;
• anomalem Rückgang der Anzahl workflow_completed (Menschen schließen den Flow nicht ab);
• anomalem Anstieg der LLM‑Kosten ohne Traffic‑Zuwachs (ökonomischer Incident).

All das ist nur möglich, weil wir strukturiert loggen und nicht in die Logs schreiben „irgendwas ist mit dem Checkout wieder kaputt“. Sind Metriken und Alerts eingerichtet, können wir bemerken, dass etwas schief läuft. Nächste Frage: Was passiert nach der Detektion, wer reagiert wie?

3. Lebenszyklus eines Incidents: von Detektion bis Post‑mortem

Damit man nicht im Dauerfeuer lebt, ist es hilfreich, einen Standard‑Pipeline für Incidents zu beschreiben. Viele SRE‑Teams formalisieren sie als Kette:

flowchart TD
    D["Detection (Erkennung)"] --> T["Triage (Schweregradbewertung)"]
    T --> M["Mitigation (schnelle Eindämmung)"]
    M --> R["Resolution (endgültige Behebung)"]
    R --> P["Post-mortem (Analyse und Verbesserungen)"]

Sehen wir uns die Phasen am Beispiel GiftGenius an.

Detection — wie erkennen, dass es ernst ist

Die Erkennung kann automatisch oder manuell erfolgen.

Automatisch – Alerts aus dem Monitoring nach SLO/SLI:

• PagerDuty / Opsgenie / E‑Mail / Slack‑Bot meldet: SEV‑1: checkout_success_rate < 60% über 10 Minuten;
• Alert zur Latenz: p95(suggest_gifts) > 10 s;
• Kosten‑Anomalie: „LLM‑Kosten haben sich bei gleicher Anzahl workflow_completed verdoppelt“.

Manuelle Detektion – wenn beim Support (oder direkt bei Ihnen per Telegram) eine Flut an Meldungen eingeht „Zahlung klappt nicht“, „das Widget lädt endlos“. Manchmal weist das früher auf ein Problem hin, als das Monitoring es bemerkt.

Praktische Folgerung: Auch ohne perfektes Monitoring sollten Sie Massenbeschwerden immer durch die Metriken‑Brille betrachten: „Welche Metrik steckt dahinter und wie messen wir sie?“

Triage — Klassifikation und Priorisierung

Nach der Detektion sind zwei Fragen zu beantworten: Wie schlimm ist es und wer rennt zum Fixen los.

Eine einfache Schweregrad‑Skala ist hilfreich:

• SEV‑1: kritisch – Nutzende können nicht kaufen, die App funktioniert im Kernpfad nicht (z. B. Checkout=0 bei Live‑Traffic).
• SEV‑2: ernst, aber mit Degradation – ein Teil der Nutzenden kann den Flow nicht abschließen, die Latenz ist stark erhöht, aber nicht „auf null“.
• SEV‑3: minore Bugs – eines der Zusatz‑Tools fällt gelegentlich aus, nur ein Edge‑Case ist betroffen.

Für GiftGenius sind Commerce‑Incidents fast immer SEV‑1: Wenn Geldflüsse stehen, ist das nicht nur ein technisches Problem, sondern unmittelbarer Schaden bei Umsatz und Vertrauen.

In diesem Schritt wird der On‑Call bestimmt (oder Sie selbst, wenn das Team aus einer Person besteht) und entschieden: „Ja, das ist ein offizieller Incident SEV‑1, wir arbeiten nach Runbook N“ (Runbook — das ist eine vorab beschriebene Schritt‑für‑Schritt‑Anleitung; die Struktur besprechen wir in einem separaten Abschnitt).

Mitigation — das „Bluten“ stoppen

Mitigation bedeutet nicht, die tiefe Ursache zu finden, sondern schnelle Maßnahmen, um das Leid der Nutzenden zu verringern. Beispiele:

• Rollback des letzten Releases von MCP/Agents/ACP;
• Abschalten des problematischen Feature Flags;
• GiftGenius in einen „Viewer‑Modus“ schalten: Empfehlungen anzeigen, aber keinen Kauf ermöglichen;
• temporäre Lastsenkung (Rate Limiting) oder Abschalten schwerer Tools.

Typisches Beispiel für Code zum „Degradationsmodus“ in unserem MCP:

// Pseudo-Code: globales Flag, das sich schnell umschalten lässt
let checkoutDisabled = false;

export function setCheckoutDisabled(value: boolean) {
  checkoutDisabled = value;
}

export async function createCheckoutSession(args: CheckoutArgs) {
  if (checkoutDisabled) {
    // Wir teilen dem Modell mit, dass der Kauf vorübergehend nicht verfügbar ist
    return {
      error: 'checkout_temporarily_disabled',
      message: 'Die Zahlung ist vorübergehend nicht verfügbar, zeige dem Nutzer eine Erklärung.',
    };
  }

  // normale Logik zum Erstellen der Session
}

Im Feature‑Flag‑System können Sie setCheckoutDisabled(true) als Teil der Mitigation auslösen: Nutzende bekommen zumindest keine 500er und hängenden Zahlungen, sondern eine ehrliche Meldung.

Resolution — endgültige Behebung

Wenn die „Blutung gestoppt“ ist, bleibt Zeit, die Ursache zu finden und zu beheben:

• Bug im MCP/ACP‑Code;
• Problem bei einem Drittanbieter (Stripe, Payment‑Gateway);
• Limits beim OpenAI‑API (429, Überlastung);
• kaputter Prompt oder ein gewechseltes Modell, das das Tool nicht mehr aufruft.

Zur Resolution gehören üblicherweise:

• Fix (Patch/Rollback/Konfiguration);
• Deployment auf Staging, danach auf Production;
• Überprüfung aller SLI/SLO;
• Zurückschalten der Flags in den Normalzustand.

Post‑mortem — aus Fehlern lernen

Nach einem Incident, insbesondere SEV‑1/SEV‑2, wird ein Post‑mortem erstellt: ein Dokument, in dem Sie ehrlich beantworten:

• was passiert ist (Fakten und Zeitlinie);
• wie es bemerkt wurde;
• wie reagiert wurde;
• was gut funktionierte und was nicht;
• welche Änderungen Sie vornehmen, damit es sich nicht wiederholt.

Ein Post‑mortem dient nicht der Schuldsuche, sondern der Verbesserung von System und Prozess. Auf seiner Basis aktualisiert man Runbooks, Alerts, manchmal sogar die Architektur.

4. Rollen und Verantwortlichkeiten: selbst wenn Sie „allein auf weiter Flur“ sind

Damit die oben beschriebene Incident‑Pipeline im echten Leben funktioniert, ist es wichtig, im Vorhinein zu klären, wer während des Feuers wofür entscheidet. Selbst wenn Ihr Team in einen Aufzug passt, lohnt es sich, die Rollen bei Incidents zu formalisieren. Das reduziert Chaos.

Typischerweise unterscheidet man:

• On‑Call‑Ingenieur — dem als erstem der Alert zugeht und der technische Maßnahmen zur Stabilisierung trifft (Rollback, Feature Flags, temporäre Platzhalter).
• Incident Commander — die Person, die den Prozess führt: Timeline festhält, Entscheidungen zur Priorisierung trifft, darauf achtet, dass das Team fokussiert bleibt. Im Mikro‑Team ist das dieselbe Person wie der On‑Call, nur mit „anderem Hut“.
• Kommunikation — verantwortlich für die Kommunikation mit Nutzenden und Business‑Stakeholdern: Nachrichten in Slack, auf der Status‑Seite, in der App‑UI (Widget/Chat), im ChatGPT‑Store.
• Scribe — protokolliert wichtige Schritte und Fakten; anhand dieses Protokolls wird das Post‑mortem geschrieben.

Im Ein‑Personen‑Team sind alle vier Rollen Sie selbst; hilfreich ist das bewusste Umschalten: „Jetzt bin ich Ingenieur und fixe“, „jetzt kommuniziere ich“, „jetzt schreibe ich die Timeline auf“.

5. Runbook: Verfassung statt Gedächtnis

Ein Runbook ist ein Dokument, das Schritt für Schritt beschreibt, was bei einem konkreten Incident‑Typ zu tun ist: welche Grafiken anzusehen sind, welche Knöpfe zu drücken sind, worauf man verzichten kann. Es reduziert Improvisation und Stress deutlich.

Struktur eines Runbooks

In der Regel enthält ein Runbook:

1. Eine kurze Beschreibung des Incidents und wie er detektiert wird. Beispiel: „Anstieg der ACP‑Checkout‑Fehler > 5% über 5 Minuten“ oder „Error talking to app für >20% der Anfragen“.
2. Scope — wen betrifft das Problem: gesamter Traffic, nur eine Region, nur ein bestimmtes Tool.
3. Wo nachsehen: Links zu Dashboards (SLO für Checkout, MCP‑Error‑Rate, Logs nach tool_name = create_checkout_session), zum MCP Inspector usw.
4. Schnelle Mitigation‑Schritte: „Stripe‑Status prüfen“, „letztes ACP‑Release zurückrollen“, „Empfehlungsmodus ohne Kauf aktivieren“.
5. Schritte zur endgültigen Analyse und zum Fix.
6. Was im Ergebnis zu aktualisieren ist: Alerts, Code, Dokumentation.

Mini‑Beispiel eines Runbooks für GiftGenius (Checkout fällt aus)

Wir beschreiben es als strukturierte Daten, näher am Code:

type Severity = 'SEV-1' | 'SEV-2' | 'SEV-3';

interface RunbookStep {
  title: string;
  description: string;
}

interface Runbook {
  id: string;
  title: string;
  severity: Severity;
  detection: string;
  steps: RunbookStep[];
}

export const checkoutFailureRunbook: Runbook = {
  id: 'rb-checkout-failure',
  title: 'Anstieg der Checkout‑Fehler in GiftGenius',
  severity: 'SEV-1',
  detection: 'Alert: checkout_success_rate < 60% über 10 Minuten',
  steps: [
    {
      title: 'Externe Status prüfen',
      description: 'Stripe‑Status und ACP‑Backend prüfen und sicherstellen, dass es keinen globalen Outage gibt.',
    },
    {
      title: 'Jüngste Releases prüfen',
      description: 'Prüfen, ob es in den letzten 30 Minuten Deploys von MCP/ACP gab. Bei Bedarf zurückrollen.',
    },
  ],
};

In einem realen Runbook fügen Sie mehr Schritte hinzu: Read‑only‑Feature‑Flag aktivieren, Banner im Widget anzeigen, Logs für das Post‑mortem sammeln.

Beispieltext für das Widget bei einem Commerce‑Incident

Im Runbook ist es nützlich, vorab den Text für Nutzende zu formulieren. Im GiftGenius‑Widget könnte man anzeigen:

„Derzeit haben wir vorübergehende technische Probleme mit der Zahlung. Sie können Ihre favorisierten Geschenkideen trotzdem speichern; den Kauf schließen wir etwas später ab.“

Solchen Text kann man anschließend in einen UI‑Zustand einbauen:

// Pseudocode für den Widget-Zustand
const [checkoutAvailable, setCheckoutAvailable] = useState(true);

if (!checkoutAvailable) {
  return (
    <Alert>
      Die Zahlung ist vorübergehend nicht verfügbar. Sie können Geschenkideen weiterhin ansehen und speichern.
    </Alert>
  );
}

6. Praxis bei GiftGenius: Code rund um Incidents

Damit das Thema nicht nur organisatorisch bleibt, betrachten wir ein paar Code‑Snippets, die direkt im Incident‑Management helfen.

Health‑Check‑Endpoint für MCP/Backend

Ein einfaches, aber wichtiges Werkzeug ist der Health‑Check. In Next.js 16 lässt er sich über einen Route Handler bauen:

// app/api/health/route.ts
import { NextRequest, NextResponse } from 'next/server';

export function GET(_req: NextRequest) {
  // Man kann DB-, Queue-Checks usw. hinzufügen.
  return NextResponse.json({
    status: 'ok',
    mcp: 'healthy',
    timestamp: new Date().toISOString(),
  });
}

Das Monitoring fragt /api/health periodisch ab. Wenn statt 200 OK Timeouts oder 5xx zurückkommen, ist das ein klarer Hinweis auf einen Availability‑Incident (MCP ist nicht erreichbar).

Klassifizierung des Incidents anhand von Metriken

Auf der Seite des Analytics‑Dienstes oder eines Admin‑Backendskripts kann man eine einfache Logik zur Schweregrad‑Bestimmung halten:

type Severity = 'SEV-1' | 'SEV-2' | 'SEV-3';

interface IncidentContext {
  checkoutSuccessRate: number; // 0..1
  giftSearchErrorRate: number; // 0..1
  p95GiftSearchMs: number;
}

export function classifyIncident(ctx: IncidentContext): Severity | null {
  if (ctx.checkoutSuccessRate < 0.6) return 'SEV-1'; // Geldflüsse stehen still
  if (ctx.giftSearchErrorRate > 0.3 || ctx.p95GiftSearchMs > 8000) return 'SEV-2';
  return null; // noch kein Incident
}

Solch ein Snippet kann per Cron laufen oder vom Monitoring getriggert werden: Bei Rückgabe von SEV‑1 wird automatisch ein Incident in Ihrem System erzeugt und eine On‑Call‑Benachrichtigung verschickt.

Logging der Schlüssereignisse eines Incidents

Incidents sind nicht nur Metriken, sondern auch Ereignisse: wann ein Incident erstellt, mitigiert, geschlossen wurde. Es ist praktisch, das in separaten Logs zu halten.

function logIncidentEvent(event: {
  incidentId: string;
  type: 'created' | 'mitigated' | 'resolved';
  severity: Severity;
  requestId?: string;
  message: string;
}) {
  logger.warn({
    level: 'WARN',
    service: 'incident-manager',
    ...event,
    timestamp: new Date().toISOString(),
  });
}

Beispiel beim Einschalten des „Read‑only“-Modus für GiftGenius:

setCheckoutDisabled(true);
logIncidentEvent({
  incidentId: 'inc-2025-11-21-001',
  type: 'mitigated',
  severity: 'SEV-1',
  message: 'Checkout disabled, app switched to recommendations-only mode',
});

Diese Events lassen sich anschließend leicht finden und mit Zeitreihen der Metriken korrelieren.

7. Betriebskalender: Leben nach „Hurra, alles gefixt“

Incident‑Management bedeutet nicht nur Brände zu löschen, sondern auch regelmäßige Prävention. In der SRE‑Praxis wird der operative Zyklus oft als Betriebskalender mit regelmäßigen SLO‑, Kosten‑ und Sicherheits‑Reviews beschrieben.

Man kann die Aktivitäten grob nach Periodizität gliedern.

Wöchentlich

Einmal pro Woche (oder alle zwei) lohnt es sich:

• die wichtigsten SLO zu prüfen: Latenz, Error‑Rate, Checkout‑Erfolg, Anteil der Incidents nach Kategorien;
• zu schauen, ob es Alerts gab, die „von selbst verstummt“ sind, und zu entscheiden, ob Schwellen gelockert/verschärft werden sollten;
• kurz mindestens einen Incident zu besprechen (auch SEV‑3) — das trainiert die Post‑mortem‑Muskeln.

Monatlich

Einmal pro Monat sollte man:

• einen Kosten‑Review machen (LLM, ACP/Stripe‑Gebühren, Infrastruktur) und ihn mit dem Umsatz verknüpfen — Anschluss an Themen 1–2 von Modul 19;
• Produktmetriken ansehen: Activation, Retention, Konversion workflow_completed → checkout_success — Verbindung zum Modul über Marketing und Wachstum;
• Security‑Logs auf Anomalien prüfen: ungewöhnliche Login‑Muster, Autorisierungsfehler, ungewöhnliche Peaks bei Anfragen (Brücke zum Sicherheitsmodul).

Quartalsweise

Einmal pro Quartal:

• Secrets rotieren: OpenAI‑API‑Keys, Stripe, OAuth‑Clients usw.;
• prüfen, ob SLO veraltet sind: Vielleicht ist die App gewachsen und p95 von 2 Sekunden statt 1 ist jetzt normal — oder umgekehrt, Sie können die Ziele verschärfen;
• Runbooks überprüfen: neue Incident‑Typen, aktualisierte Abhängigkeiten (SDK, MCP‑Spec usw.).

Den Kalender kann man einfach als Wiki‑Seite oder README im GiftGenius‑Repository führen: wichtig ist, dass er „lebt“ und aktualisiert wird.

8. Incidents, Geld und Produkt: warum Commerce‑Incidents die heißesten sind

Modul 19 dreht sich insgesamt um die Ökonomie und das „operative Leben“ der App; Incidents sind hier eng mit Geld verknüpft. Commerce‑Incidents — wenn der Checkout nicht durchgeht, Gelder blockiert werden oder doppelt abgebucht wird — haben fast immer höhere Priorität als etwa ein gelegentlicher Timeout bei der Geschenk‑Suche.

Die Gründe sind einfach:

• direkte Umsatzeinbußen im Moment des Vorfalls;
• Vertrauensverlust‑Risiko (eine Person, der Geld abgebucht wurde ohne Ware, kommt kaum zurück);
• potenzielle rechtliche und Reputationsfolgen.

Daher sollten Commerce‑Incidents in Ihrem Incident‑Katalog von GiftGenius klar als SEV‑1 markiert sein, mit strengen SLO zur Reaktionszeit (z. B. On‑Call‑Reaktion innerhalb von 15 Minuten, Mitigation innerhalb einer Stunde).

Ökonomische Anomalien (z. B. die LLM‑Kosten steigen stark ohne Umsatzwachstum) sind ebenfalls Incidents, in der Regel jedoch auf dem Niveau SEV‑2: Sie zerstören die UX nicht sofort, können aber die Marge auffressen, wenn man sie übersieht.

Produktseitig ist jeder große Incident ein Anlass zum Nachdenken:

• ist der Workflow zu komplex (vielleicht ist einfacher = zuverlässiger);
• sollte es einen Fallback‑Pfad geben: Wenn der MCP nicht antwortet, gibt das Modell zumindest Ratschläge ohne externe Daten;
• sollte der UX angepasst werden, um Probleme ehrlich zu kommunizieren statt sie zu verstecken.

9. Mini‑Übungen (für die Selbstarbeit)

Auch wenn dies keine Übungsvorlesung ist, empfehle ich dringend, die folgenden Schritte in Ihrem GiftGenius wirklich durchzuführen:

1. Beschreiben Sie in einem Dokument mindestens zwei Runbooks:
   • „Massive Fehler bei der Zahlung (Checkout)“;
   • „MCP antwortet nicht / ChatGPT zeigt Error talking to app“.
2. Erstellen Sie einen Betriebskalender für einen Monat:
   • welche SLO Sie jede Woche ansehen werden;
   • welchen Kosten‑Review Sie am Monatsende machen;
   • welche Security‑Checks Sie aufnehmen (zumindest grundlegende).

Das dauert ein paar Stunden, verändert aber stark den Blick auf Ihre Anwendung: Sie ist nicht mehr nur Code, sondern ein lebendiger Service.

Typische Fehler im Incident‑Management für ChatGPT‑Apps

Fehler Nr. 1: „Ein Incident ist nur, wenn alles down ist“
Viele halten aus Gewohnheit nur den Totalausfall von MCP oder Datenbank für einen Incident. In AI‑Apps sind „weiche“ Qualitäts‑Incidents oft schmerzhafter: Das Modell ruft das benötigte Tool nicht mehr auf, der Checkout‑Flow wird verwirrend, Nutzende kommen nicht bis zum Ende, obwohl die HTTP‑Metriken grün sind. Wenn Sie solche Situationen nicht als Incidents zählen und nicht analysieren, wird die Qualität der App unbemerkt degradieren.

Fehler Nr. 2: Keine klaren SLO und Grenzen „normaler Arbeit“
Ohne formale SLO wird jede Diskussion über Incidents zu „mir kommt es langsam vor“ vs. „bei mir lokal ist es schnell“. Genau deshalb sind SLO die Basis des Incident‑Managements: Sie machen die Ernsthaftigkeit des Problems objektiv.

Fehler Nr. 3: Improvisation statt Runbooks
Das gängige Bild: Alert, alle springen panisch in die Produktion, jemand rollt ein Release zurück, jemand ändert Konfigurationen, nach einer Stunde „scheint gefixt“, aber niemand weiß, was genau geholfen hat. Ohne Runbooks ist jeder Incident ein Mini‑Chaos, und das Team lernt nicht. Schon ein einfaches Runbook für Checkout‑Incidents senkt den Stress spürbar.

Fehler Nr. 4: Kommunikation mit Nutzenden ignorieren
Manchmal reparieren Ingenieurinnen und Ingenieure das System im Stillen, während Nutzende nur den „Spinner“ und die Meldung „irgendetwas ist schiefgelaufen“ sehen. Für Commerce‑Szenarien ist das besonders toxisch: Menschen sorgen sich um Geld. Es ist wichtig, vorab Nachrichtenvorlagen im Widget, in der App‑Beschreibung und bei Bedarf in externen Kanälen zu haben, um das Problem ehrlich zu benennen und die erwartete Zeit bis zur Behebung anzugeben.

Fehler Nr. 5: „OpenAI ist schuld“ sagen, ohne den eigenen Teil zu prüfen
Es ist leicht, alles auf „OpenAI spinnt“ zu schieben, aber die Praxis zeigt: Selbst bei Upstream‑Problemen kann man auf der eigenen Seite viel tun — Timeouts und Fehler korrekt behandeln, auf einen Modus ohne MCP umschalten, die Zahl der Retry‑Versuche verringern, um die Lage nicht zu verschlimmern. Das Konzept der geteilten Verantwortung bedeutet, dass Sie für Ihren Teil der Kette verantwortlich sind, auch wenn ein Provider instabil ist.

Fehler Nr. 6: Keine Post‑mortems und kein Betriebskalender
Wenn ein Incident mit „na gut, weiter geht’s“ endet und keine Dokumente, Alerts und kein Code angepasst werden, ist das System zum Wiederholen derselben Fehler verdammt. Post‑mortems sowie regelmäßige Reviews von SLO, Kosten und Sicherheit sind keine Bürokratie, sondern eine Abmachung mit dem zukünftigen Ich und dem Team, damit GiftGenius in einem Jahr verlässlicher und nicht fragiler ist.