Krafton reduzierte Incidents um 77 % – ohne KI-Magie, nur durch Platform Engineering

Jeder On-Call-Engineer, der nachts um 3 Uhr ein Dashboard rot aufleuchten sah, kennt die Wahrheit, die auf Vendor-Keynotes niemand laut ausspricht: Der Unterschied zwischen einem fünfminütigen Ausfall und einem nationalen Nachrichtenereignis liegt fast nie am Tooling. Krafton, das Seouler Studio hinter PUBG: Battlegrounds, hat gerade den Beweis geliefert. Die Incident-Anzahl sank von 107 im Jahr 2024 auf bislang 24 im Jahr 2026, und die Mean Time to Repair kollabierte von 53,5 auf 10,3 Minuten. Das ist die Schlagzeile – und KI-Agenten hatten damit fast nichts zu tun.

Die Zahlen

Bleiben wir einen Moment bei Krafton, denn die Zahlen sind ungewöhnlich. Wie TechTarget aus Datadogs DASH-Breakout-Sessions vom 10. Juni berichtete, senkte Junghun Kims Team auch die Time-to-Detect von 8,8 Minuten auf 1,6 Minuten. Eine 5,5-fache Verbesserung bei der Erkennung, eine 5,2-fache Verbesserung bei der Behebung und eine 4,5-fache Reduzierung der rohen Incident-Anzahl. Bei einem Spiel mit Millionen gleichzeitiger Nutzer bedeutet jede dieser Minuten Umsatzverlust, Rückerstattungen und Schäden in sozialen Medien.

Zum Vergleich: Die SRE-Teams, mit denen ich auf europäischen iGaming-Plattformen gearbeitet habe, würden eine MTTD von unter zwei Minuten auf einem komplexen verteilten System als nahe an der praktischen Untergrenze betrachten. Man kann zwar schneller erkennen, aber nur indem man Responder mit False Positives überflutet. Dass Krafton 1,6 Minuten erreicht und dabei gleichzeitig die Gesamtzahl der Incidents reduziert, ist die schwierigere Leistung. Es bedeutet, dass ihre Signalqualität gleichzeitig mit ihrer Reaktionsgeschwindigkeit gestiegen ist.

Der MTTR-Wert verdient einen genaueren Blick. Von 53,5 auf 10,3 Minuten zu kommen ist die Art von Kurve, die man normalerweise nur sieht, wenn ein Team einen brüchigen Deployment-Prozess ersetzt. Neun Jahre der Verfeinerung, laut Kim, wobei der jüngste Schritt die Konsolidierung von fünf Observability-Tools in eines mit Datadog war. Fünf-zu-eins-Tool-Konsolidierungen sehen auf einer Folie sauber aus. Bei Produktions-Incidents, die ich erlebt habe, dauern sie meist zwölf bis achtzehn Monate und zerbrechen dabei einige Dashboards. Neun Jahre aufgebauter Kontext haben das hier erst möglich gemacht.

Dann ist da noch Getswish, der Betreiber der schwedischen Swish-Payment-App. Ein Ausfall im Jahr 2021 erreichte die nationale Presse, bevor der ausgelagerte IT-Dienstleister überhaupt davon wusste. Ende 2024 wurde ein vergleichbarer Incident intern innerhalb von fünf Stunden erkannt und behoben. Fünf Stunden sind im iGaming-Bereich keine Auszeichnung, aber für eine Zahlungsinfrastruktur, die drei Jahre zuvor noch auf einem ausgelagerten Betriebsvertrag lief, ist das eine strukturelle Veränderung dabei, wer den Schadensradius kontrolliert. Jonas Cronholm-Lundins Team erreichte dies durch eine Neuarchitektur der Code-Auslieferung auf GitOps-Basis und den Neuaufbau der Incident-Praxis nach Googles SRE-Buch. Keine Agenten. Keine Magie.

Was wirklich neu ist

Datadog veröffentlichte bei DASH mehr als 100 Updates. Die zwei, für die Engineering-Leads wirklich die Release Notes lesen sollten, sind die Runtime Prioritization Engine mit Auto-Tagging für Sicherheitsschwachstellen und das Auto-Processing-Feature innerhalb von Observability Pipelines. Beides sind KI-gestützte Klassifikatoren, die auf Daten laufen, die man bereits hat. Krafton verwendet außerdem Datadogs MCP-Server und das neu veröffentlichte Pup CLI, um Coding-Agenten Zugang zu Incident-Kontext über Datadog, Kubernetes, Jira und Slack zu geben.

Dieses letzte Detail ist das eigentlich Neue. MCP plus CLI bedeutet, dass Agenten den Incident-Status aus vier maßgeblichen Quellen lesen können, ohne eine eigene Integrationsschicht. Für Teams, die die letzten zwei Jahre damit verbracht haben, Slack-Bots mit PagerDuty-Webhooks zusammenzuflicken, ist das ein bedeutsamer Grundbaustein. Es bleibt aber weiterhin rein unterstützend. Kim war eindeutig: quellenübergreifendes Debugging, Postmortem-Entwürfe, Runbook-Generierung, On-Call-Übergabedokumentation. Keines davon berührt die Produktion.

Kims Zitat zur Autonomie ist das, das man sich merken sollte. „Heute kann KI bei Incidents noch falsche Entscheidungen treffen, und wenn sie eine kritische Aktion ausführt, die schwer rückgängig zu machen ist, ist das Risiko für die Produktionszuverlässigkeit zu hoch." Das ist ein leitender Engineer bei einem Spieleunternehmen, der im Jahr 2026 erklärt, warum sein Team das Steuer noch nicht an einen Agenten übergeben hat. Es deckt sich fast Wort für Wort mit dem, was Platform-Leads bei Fintechs, mit denen ich gearbeitet habe, seit achtzehn Monaten intern sagen.

Getswishs Beitrag zum neuen Playbook ist struktureller Natur. Ihre Runbooks sind jetzt rund um den OODA-Loop organisiert, das Entscheidungsframework aus der Militärluftfahrt. Observe, Orient, Decide, Act. Der Sinn von OODA im Incident Response liegt darin, dass es einem Agenten – ob menschlich oder nicht – eine stabile Zerlegung gibt, in welchem Schritt man sich gerade befindet. Wenn man Teile des Loops irgendwann an Automatisierung übergeben möchte, ist ein explizit dokumentierter Loop die Voraussetzung. Cronholm-Lundins Formulierung war korrekt: Kuratierte Runbooks und Post-Mortems sind Trainingsdaten für jeden Agenten, den man als nächstes einsetzt.

Was für Engineering-Teams bereits eingepreist ist

Der Markt hat das Framing „KI-Assistent, nicht KI-Operator" bereits eingepreist. Jeder Platform-Vendor sagt es. Was noch nicht eingepreist ist, ist das Ausmaß der grundlegenden Arbeit, die geleistet werden muss, bevor die Unterstützung Früchte trägt.

Sieht man sich Krafton noch einmal an: neun Jahre der Prozessverfeinerung, eine Tool-Konsolidierung, in Code-Pfade eingebettete Ownership-Metadaten, Severity-Guardrails – und erst dann MCP plus Coding-Agenten obendrauf. Die Agenten sind die letzten 10 % des Stacks. Der Grund, warum sie Mehrwert erzeugen, liegt darin, dass die unteren 90 % sauber sind. Wenn Incidents bei einem immer noch von demjenigen triagiert werden, der in Slack am lautesten schreit, wird das Draufsetzen eines Agenten zu selbstsicher falschen Postmortems führen – nur schneller.

Ein weiterer unterdiskutierter Punkt ist die Ökonomie der Datenhygiene. Bryan Pierson von US Bank erzählte bei DASH, dass nicht jedes Log einen First-Class-Platz in Datadogs Backend bekommt. Den Rest leiten sie aus Kostengründen für die Aufbewahrung über Observability Pipelines zu S3. Das ist die langweilige, richtige Antwort, die jeder CFO früher oder später verlangen wird. Observability-Rechnungen haben eine Art, von „handhabbar" auf „das Budget von zwei Engineers" zu steigen – von einem Quartal zum nächsten – und das gestaffelte Routing zu Object Storage ist der Standard-Ausweg. OpenTelemetry-Pipelines machen das portabel, wenn man die Option offen halten möchte.

Meine Einschätzung: Die agentischen Features werden in 18 Monaten zur Selbstverständlichkeit gehören, und niemand wird sich noch daran erinnern, welcher Vendor sie zuerst ausgeliefert hat. Was weiterhin eine Rolle spielen wird, ist, ob das Platform-Team das darunterliegende Fundament gebaut hat.

Die Gegenposition

Die kritische Lesart ist, dass Krafton und Getswish Survivorship Bias darstellen. Beide Unternehmen hatten das Budget, die Engineering-Kultur und im Fall von Krafton fast ein Jahrzehnt Vorlauf, um in diesen Zustand zu gelangen. Die meisten Teams, die die DASH-Zusammenfassung lesen, haben keine neun Jahre. Sie haben einen CFO, der fragt, warum die Observability-Rechnung jährlich um 40 % wächst, und einen CTO, der eine Agent-Demo gesehen hat und wissen möchte, wann Incidents sich von selbst beheben.

Für diese Teams könnte die ehrliche Antwort lauten, dass ein KI-Assistent auf einer mittelmäßigen Plattform immer noch besser ist als nichts. Eric Swanson, SRE bei MagicSchool AI in Denver, brachte die Befürchtung klar auf den Punkt: Entwickler, die die Log-Disziplin an Agenten auslagern, und Engineers, die die durch kritisches Denken geschärften Fähigkeiten abstumpfen. Er hat Recht, sich Sorgen zu machen. Aber die Gegenposition lautet, dass nicht jedes Unternehmen eine Incident-Plattform auf Krafton-Niveau aufbauen wird, und ein kompetenter Agenten-Boden den mittleren Operator mehr heben könnte, als er die Decke für die besten Operatoren senkt.

Die unbequeme Lesart: Die meisten Engineering-Organisationen werden das Plattform-Fundament überspringen, Agenten draufschrauben und es als erledigt betrachten. Die Vendors wissen das. Deshalb führt das Marketing mit Autonomie, und die Fallstudien führen mit Platform Engineering.

Wichtigste Erkenntnisse

• Die Plattform kommt zuerst. Kraftons 77-prozentige Incident-Reduzierung und die 5-fache MTTR-Verbesserung kamen aus neun Jahren Prozessarbeit – nicht aus nachträglich angeschraubten Agenten.
• MCP plus CLI ist der neue Integrations-Grundbaustein. Datadogs MCP-Server und Pup CLI ermöglichen Agenten den Zugriff auf Incident-Kontext über Observability, Kubernetes, Jira und Slack ohne maßgeschneiderte Verbindungsschichten. Ein Proof-of-Concept in diesem Quartal lohnt sich.
• Agenten auf der unterstützenden Seite halten. Postmortems, Runbooks, Übergabedokumente, quellenübergreifendes Debugging. Produktionsverändernde Aktionen bleiben so lange menschlich kontrolliert, bis Rollbacks günstig sind.
• Runbooks für Menschen und Agenten strukturieren. Getswishs OODA-Loop-Runbooks dienen gleichzeitig als Trainingsmaterial. Jetzt kuratieren, später ernten.
• Observability-Daten staffeln, bevor die Rechnung einen staffelt. US Bank leitet geringwertigere Logs über Observability Pipelines zu S3. Heute Standard-Praxis, keine Optimierung mehr.