Plattform
Doctor: der Read-Only-KI-SRE für deine Live-Apps
Wenn in Produktion etwas kaputtgeht, ermittelt Doctor wie ein Site Reliability Engineer — und gibt dir die Diagnose und eine entworfene Korrektur statt einer Seite voller Logs.
Doctor ist Ciaos nur lesender KI-Site-Reliability-Engineer. Er prüft die Live-Anwendung, DNS und CDN, diagnostiziert die Grundursache von Vorfällen und entwirft die Korrektur. Anders als Agenten mit Schreibzugriff auf Produktion ist Doctor by Design nur lesend — er kann alles ansehen und nichts verändern, sodass Diagnose schnell, kontinuierlich und sicher gegen echte Systeme läuft.
Veröffentlicht 2026-07-03 · Zuletzt aktualisiert 2026-07-03
Produktion geht kaputt; Expertise ist knapp
Jede Anwendung hat irgendwann den schlechten Nachmittag: Die Seite ist down, Checkout wirft Fehler, Login schlägt für einen Kunden fehl, und niemand weiß warum. Die traditionelle Antwort ist ein Site Reliability Engineer, der sich durch Logs, DNS-Einträge und CDN-Verhalten gräbt, bis eine Geschichte entsteht. Die meisten Teams, die mit KI bauen, haben diese Person nicht — und sollten auch keine einstellen müssen, nur um ein Portal am Leben zu halten.
Doctor ist Ciaos nur lesender KI-SRE. Er prüft die Live-Anwendung, DNS und CDN, diagnostiziert die Grundursache und entwirft die Korrektur. Nur lesend ist die Design-Entscheidung, die zählt: Doctor kann alles ansehen und nichts verändern.
Wie eine Diagnose abläuft
Eine Diagnose folgt demselben Pfad, den ein erfahrener SRE nehmen würde — nur sofort, und aktenkundig.
1. Etwas sieht falsch aus
Eine Produktionsprüfung schlägt fehl, eine Zustandsampel wird in Conductor rot, oder ein Mensch bittet Doctor, ein Symptom zu untersuchen.
2. Doctor prüft die Live-App
Er fragt echte Routen ab, führt den fehlschlagenden Ablauf aus und liest Antworten und Fehler so, wie der Browser eines Nutzers ihnen begegnen würde.
3. Dann der Weg dorthin
DNS-Auflösung, Zertifikatsstatus und CDN-Verhalten werden ebenfalls geprüft, denn „die App ist down“ bedeutet oft eigentlich „der Weg zur App ist down“.
4. Kontext tritt den Beweisen bei
Kürzliche Deploys, Konfigurationsänderungen und Prüfungshistorie grenzen ein, wann es kaputtging und was sich rund um diesen Moment geändert hat.
5. Eine Grundursache, in einfacher Sprache
Die Ausgabe ist eine Diagnose, kein Log-Dump: was kaputtging, wo und warum — mit angehängten Beweisen.
6. Eine entworfene Korrektur, durch die Vordertür
Doctor entwirft die Korrektur, und sie wird so ausgeliefert, wie jede Änderung ausgeliefert wird: durch Builder, Guardrails-Prüfung, wo Richtlinien es verlangen, und QA-Gates. Diagnose ist sofort; Änderung bleibt kontrolliert.
Warum Read-Only wichtig ist
Einer KI Schreibzugriff auf Produktion zu geben, ist eine Entscheidung, die die meisten Sicherheitsteams nicht treffen werden — und Ciao bittet sie nicht darum. Doctors Befugnis ist ermittelnd. Das macht es sicher, kontinuierlich gegen echte Systeme zu laufen, und sicher, in regulierte Umgebungen zu bringen: Der Wirkungsradius einer falschen Diagnose ist ein falscher Satz, keine falsche Änderung.
Es hält auch die Anreize ehrlich. Die Korrektur, die Doctor entwirft, muss dieselbe Prüfung und dasselbe Testen wie jede menschliche Änderung überstehen, sodass Geschwindigkeit nie einen Umweg um Governance erkauft.
Es gibt auch einen Fleet-Effekt. Weil Proben sicher sind, muss Doctor nicht warten, bis ein Mensch etwas vermutet — Produktionsprüfungen und Zustandsampeln reichen ihm kontinuierlich Symptome, über jedes Projekt in Conductor hinweg. Die Ermittlung, die früher begann, wenn sich jemand beschwerte, beginnt jetzt, wenn die erste Prüfung fehlschlägt.
Wer Doctor nutzt
Doctor verändert die Vorfallserfahrung für jeden, der je einen besessen hat.
- Gründer und Operator — Die Person, die die App mit Ciao gebaut hat, ist selten die Person, die um Mitternacht DNS debuggen kann. Doctor ist der Ermittler, den sie nicht werden müssen.
- Agenturen — Mit einer Fleet von Kundenanwendungen in Conductor ist Doctor der First Responder — die Diagnose ist oft fertig, bevor der Kunde das Symptom bemerkt.
- IT- und Plattformteams — Triage kommt vor-ermittelt an: Eskalationen kommen mit einer Grundursache und Beweisen statt eines vagen Tickets.
- Ingenieure — Sie treffen weiterhin die Entscheidung — sie starten nur von einer Diagnose statt von grep.
Hinweise zu Sicherheit und Governance
- ✓ Doctor ist by Design nur lesend — er kann die Anwendung, ihre Daten oder ihre Infrastruktur nicht verändern.
- ✓ Proben decken die Live-Anwendung, DNS und CDN ab.
- ✓ Entworfene Korrekturen laufen wie jede andere Änderung durch Guardrails-Prüfung und QA-Gates.
- ✓ Ermittlungen und Befunde werden im unveränderlichen Audit-Protokoll erfasst.
- ✓ Doctor arbeitet neben SysOps, das Rollback und Abgleich als protokollierte Operationen abwickelt.
Symptom für Symptom
Unterschiedliche Symptome, dieselbe Methode: prüfen, korrelieren, erklären.
| Symptom | Was Doctor untersucht | Typische Form der Diagnose |
|---|---|---|
| Seite nicht erreichbar | DNS-Auflösung, Zertifikate, CDN-Status, Origin-Zustand | Wo die Anfrage auf dem Weg zur App stirbt |
| Ein Ablauf schlägt fehl | Die Route, ihre Backend-Aufrufe, kürzliche Änderungen an diesem Bereich | Die Änderung oder Abhängigkeit, die den Ablauf kaputtgemacht hat |
| Langsame Seiten | Antwortzeiten über Routen und Assets, CDN-Verhalten | Welche Schicht die Zeit hinzufügt |
| Fehler nach einem Deploy | Der Deploy-Diff, fehlgeschlagene Prüfungen, Laufzeitfehler | Ob man vorwärts korrigiert oder SysOps ein Rollback übergibt |
Häufig gestellte Fragen
Kann Doctor Änderungen an Produktion vornehmen?
Nein. Doctor ist by Design nur lesend. Er diagnostiziert und entwirft Korrekturen, und diese Korrekturen werden durch die normale kontrollierte Pipeline angewendet — Prüfung, QA-Gates, dann Veröffentlichung. Die Trennung ist bewusst: Ermittlung sollte nie das verändern, was untersucht wird.
Was kann Doctor tatsächlich sehen?
Das Verhalten der Live-Anwendung — Routen, Antworten, Fehler — plus DNS, Zertifikate und CDN-Verhalten, und die eigene Historie des Projekts: Deploys, Konfigurationsänderungen und Prüfungsergebnisse. Diese Kombination reicht meist aus, um eine Grundursache zu verorten.
Wie wird aus der entworfenen Korrektur eine echte Korrektur?
Sie tritt dem Kreislauf wie jede Änderung bei: auf einem Branch, durch Guardrails-Prüfung, wo Richtlinien es verlangen, durch QA-Smoke-Gates, dann Veröffentlichung. Wenn Rollback schneller ist als Vorwärtskorrektur, sagt Doctor das, und SysOps führt das Rollback als protokollierte Operation aus.
Ersetzt Doctor einen Bereitschaftsdienst?
Er erledigt die Ermittlungsarbeit und gibt Menschen eine Diagnose statt roher Logs. Jemand entscheidet und genehmigt weiterhin — diese Person startet nur viel weiter vorne, und für viele Teams verändert das, was Bereitschaftsdienst sein muss.
Ist Doctor inklusive, oder ein Add-on?
Jeder Ciao-Workspace beinhaltet die KI-Softwareorganisation — CTO, Doctor, QA-Analyst, Security-Engineer, Coder und SysOps-Operator. Für Produktionsprogramme, die bei 10.000 USD pro Jahr beginnen, buche eine Demo und sieh eine Live-Diagnose an einem echten Vorfall.