Piattaforma
Doctor: l'AI SRE in sola lettura per le tue app live
Quando qualcosa si rompe in produzione, Doctor indaga come farebbe un site reliability engineer — e ti consegna la diagnosi e una correzione abbozzata invece di una pagina di log.
Doctor è l'AI site reliability engineer in sola lettura di Ciao. Sonda l'applicazione live, il DNS e la CDN, diagnostica la causa radice degli incidenti e abbozza la correzione. A differenza degli agenti a cui viene dato accesso in scrittura alla produzione, Doctor è in sola lettura per progettazione — può guardare tutto e non cambiare nulla, così la diagnosi è veloce, continua e sicura da eseguire contro sistemi reali.
Pubblicato 2026-07-03 · Ultimo aggiornamento 2026-07-03
La produzione si rompe; l'esperienza scarseggia
Ogni applicazione prima o poi ha il suo brutto pomeriggio: il sito è giù, il checkout dà errore, il login fallisce per un cliente e nessuno sa perché. La risposta tradizionale è un site reliability engineer che scava tra log, record DNS e comportamento della CDN finché non emerge una storia. La maggior parte dei team che costruisce con l'AI non ha quella persona — e non dovrebbe doverla assumere solo per tenere in vita un portale.
Doctor è l'AI SRE in sola lettura di Ciao. Sonda l'applicazione live, il DNS e la CDN, diagnostica la causa radice e abbozza la correzione. Sola lettura è la decisione di design che conta: Doctor può guardare tutto e non cambiare nulla.
Come funziona una diagnosi
Una diagnosi segue lo stesso percorso che prenderebbe un SRE esperto — solo immediatamente, e a verbale.
1. Qualcosa sembra non andare
Un controllo di produzione fallisce, un indicatore di salute diventa rosso in Conductor, oppure un umano chiede a Doctor di indagare un sintomo.
2. Doctor sonda l'app live
Richiede route reali, esercita il flusso che fallisce e legge risposte ed errori nel modo in cui li incontrerebbe il browser di un utente.
3. Poi il percorso per raggiungerla
Vengono sondati anche la risoluzione DNS, lo stato dei certificati e il comportamento della CDN, perché "l'app è giù" spesso significa in realtà "la strada verso l'app è giù".
4. Il contesto si unisce alle prove
Deploy recenti, modifiche alla configurazione e la cronologia dei controlli restringono quando si è rotto e cosa è cambiato intorno a quel momento.
5. Una causa radice, in linguaggio semplice
L'output è una diagnosi, non un dump di log: cosa si è rotto, dove e perché — con le prove allegate.
6. Una correzione abbozzata, dalla porta principale
Doctor abbozza la correzione, e viene rilasciata come qualsiasi altra modifica: tramite Builder, revisione Guardrails dove le policy lo richiedono, e gate QA. La diagnosi è immediata; il cambiamento resta governato.
Perché la sola lettura è importante
Dare a un'AI accesso in scrittura alla produzione è una decisione che la maggior parte dei team di sicurezza non prenderà — e Ciao non lo chiede loro. L'autorità di Doctor è investigativa. Questo lo rende sicuro da eseguire continuamente contro sistemi reali e sicuro da portare in ambienti regolamentati: il raggio d'azione di una diagnosi sbagliata è una frase sbagliata, non una modifica sbagliata.
Mantiene anche gli incentivi onesti. La correzione che Doctor abbozza deve superare la stessa revisione e lo stesso test di qualsiasi modifica umana, così la velocità non compra mai una scorciatoia intorno alla governance.
C'è anche un effetto di flotta. Poiché sondare è sicuro, Doctor non deve aspettare che un umano sospetti qualcosa — i controlli di produzione e gli indicatori di salute gli consegnano sintomi continuamente, su ogni progetto in Conductor. L'indagine che una volta iniziava quando qualcuno si lamentava ora inizia quando fallisce il primo controllo.
Chi usa Doctor
Doctor cambia l'esperienza degli incidenti per chiunque ne abbia mai posseduto uno.
- Founder e operatori — La persona che ha costruito l'app con Ciao raramente è la persona che può eseguire il debug del DNS a mezzanotte. Doctor è l'investigatore che non devono diventare.
- Agenzie — Con una flotta di applicazioni clienti in Conductor, Doctor è il primo a rispondere — la diagnosi è spesso pronta prima che il cliente noti il sintomo.
- Team IT e di piattaforma — Il triage arriva pre-investigato: le escalation arrivano con una causa radice e prove invece di un ticket vago.
- Ingegneri — Sono ancora loro a decidere — semplicemente partono da una diagnosi invece che da un grep.
Note di sicurezza e governance
- ✓ Doctor è in sola lettura per progettazione — non può modificare l'applicazione, i suoi dati o la sua infrastruttura.
- ✓ Le sonde coprono l'applicazione live, il DNS e la CDN.
- ✓ Le correzioni abbozzate vengono rilasciate tramite revisione Guardrails e gate QA come qualsiasi altra modifica.
- ✓ Le indagini e i risultati vengono registrati nel registro di controllo append-only.
- ✓ Doctor lavora insieme a SysOps, che gestisce rollback e riconciliazione come operazioni registrate.
Sintomo per sintomo
Sintomi diversi, stesso metodo: sondare, correlare, spiegare.
| Sintomo | Cosa esamina Doctor | Forma tipica della diagnosi |
|---|---|---|
| Sito irraggiungibile | Risoluzione DNS, certificati, stato della CDN, salute dell'origine | Dove muore la richiesta nel suo percorso verso l'app |
| Un flusso che fallisce | La route, le sue chiamate al backend, modifiche recenti a quell'area | La modifica o la dipendenza che ha rotto il flusso |
| Pagine lente | Tempistiche di risposta su route e asset, comportamento della CDN | Quale livello sta aggiungendo il tempo |
| Errori dopo un deploy | Il diff del deploy, i controlli falliti, gli errori runtime | Se correggere in avanti o affidare a SysOps un rollback |
Domande frequenti
Doctor può apportare modifiche alla produzione?
No. Doctor è in sola lettura per progettazione. Diagnostica e abbozza correzioni, e quelle correzioni vengono applicate attraverso la pipeline governata normale — revisione, gate QA, poi pubblicazione. La separazione è deliberata: l'indagine non dovrebbe mai modificare ciò che sta indagando.
Cosa può effettivamente vedere Doctor?
Il comportamento dell'applicazione live — route, risposte, errori — più DNS, certificati e comportamento della CDN, e la storia stessa del progetto: deploy, modifiche alla configurazione e risultati dei controlli. Quella combinazione di solito basta per individuare una causa radice.
Come diventa reale la correzione abbozzata?
Entra nel ciclo come qualsiasi modifica: su un branch, tramite revisione Guardrails dove le policy lo richiedono, tramite smoke gate QA, poi pubblicazione. Se tornare indietro è più veloce che correggere in avanti, Doctor lo dice e SysOps esegue il rollback come operazione registrata.
Doctor sostituisce un turno di reperibilità?
Fa il lavoro investigativo e consegna agli umani una diagnosi invece di log grezzi. Qualcuno decide e approva ancora — quella persona semplicemente parte molto più avanti, e per molti team questo cambia cosa deve essere la reperibilità.
Doctor è incluso, o un componente aggiuntivo?
Ogni workspace Ciao include l'organizzazione software AI — CTO, Doctor, analista QA, ingegnere Security, Coder e operatore SysOps. Per i programmi di produzione, che partono da 10.000 USD all'anno, prenota una demo e guarda una diagnosi dal vivo su un incidente reale.