Plataforma
Doctor: o SRE de IA apenas de leitura para as suas apps ao vivo
Quando algo quebra em produção, o Doctor investiga como um engenheiro de fiabilidade de sistemas — e entrega-lhe o diagnóstico e uma correção elaborada em vez de uma página de registos.
O Doctor é o engenheiro de fiabilidade de sistemas com IA, apenas de leitura, do Ciao. Sonda a aplicação ao vivo, o DNS e a CDN, diagnostica a causa raiz de incidentes e elabora a correção. Ao contrário de agentes com acesso de escrita à produção, o Doctor é apenas de leitura por design — pode olhar para tudo e não mudar nada, para que o diagnóstico seja rápido, contínuo e seguro para executar contra sistemas reais.
Publicado 2026-07-03 · Última atualização 2026-07-03
A produção quebra; a experiência é escassa
Toda a aplicação acaba por ter a tarde má: o site está em baixo, o checkout dá erro, o login falha para um cliente e ninguém sabe porquê. A resposta tradicional é um engenheiro de fiabilidade de sistemas que vasculha registos, registos DNS e comportamento da CDN até surgir uma explicação. A maioria das equipas que constroem com IA não tem essa pessoa — e não deveria precisar de contratar uma só para manter um portal vivo.
O Doctor é o SRE de IA apenas de leitura do Ciao. Sonda a aplicação ao vivo, o DNS e a CDN, diagnostica a causa raiz e elabora a correção. Apenas de leitura é a decisão de design que importa: o Doctor pode olhar para tudo e não mudar nada.
Como corre um diagnóstico
Um diagnóstico segue o mesmo caminho que um SRE experiente seguiria — apenas de imediato, e em registo.
1. Algo parece errado
Uma verificação de produção falha, uma luz de estado fica vermelha no Conductor, ou um humano pede ao Doctor para investigar um sintoma.
2. O Doctor sonda a app ao vivo
Pede rotas reais, exercita o fluxo a falhar e lê respostas e erros da forma como o navegador de um utilizador os encontraria.
3. Depois o caminho até lá
A resolução DNS, o estado do certificado e o comportamento da CDN também são sondados, porque "a app está em baixo" é frequentemente, na realidade, "a rota até à app está em baixo".
4. O contexto junta-se à evidência
Deploys recentes, alterações de configuração e o histórico de verificações delimitam quando quebrou e o que mudou à volta desse momento.
5. Uma causa raiz, em linguagem simples
O resultado é um diagnóstico, não um despejo de registos: o que quebrou, onde, e porquê — com a evidência anexada.
6. Uma correção elaborada, pela porta da frente
O Doctor elabora a correção, e ela é lançada da mesma forma que qualquer alteração: através do Builder, revisão do Guardrails onde as políticas o exigem, e gates de QA. O diagnóstico é imediato; a alteração continua governada.
Porque é que ser apenas de leitura importa
Dar a uma IA acesso de escrita à produção é uma decisão que a maioria das equipas de segurança não vai tomar — e o Ciao não lhes pede que o façam. A autoridade do Doctor é investigativa. Isso torna-o seguro para executar continuamente contra sistemas reais e seguro para levar para ambientes regulados: o raio de impacto de um diagnóstico errado é uma frase errada, não uma alteração errada.
Também mantém os incentivos honestos. A correção que o Doctor elabora tem de sobreviver à mesma revisão e testes que qualquer alteração humana, para que a velocidade nunca compre um atalho à volta da governança.
Há também um efeito de frota. Como sondar é seguro, o Doctor não precisa de esperar que um humano suspeite de algo — as verificações de produção e as luzes de estado entregam-lhe sintomas continuamente, em todos os projetos no Conductor. A investigação que costumava começar quando alguém se queixava agora começa quando a primeira verificação falha.
Quem usa o Doctor
O Doctor muda a experiência de incidentes para todos os que já tiveram um.
- Fundadores e operadores — A pessoa que construiu a app com o Ciao raramente é a pessoa que consegue depurar DNS à meia-noite. O Doctor é o investigador que não precisam de se tornar.
- Agências — Com uma frota de aplicações de clientes no Conductor, o Doctor é o primeiro a responder — o diagnóstico está frequentemente feito antes de o cliente notar o sintoma.
- Equipas de TI e de plataforma — A triagem chega pré-investigada: as escaladas vêm com uma causa raiz e evidência em vez de um ticket vago.
- Engenheiros — Continuam a tomar a decisão — apenas começam a partir de um diagnóstico em vez de a partir de um grep.
Notas de segurança e governança
- ✓ O Doctor é apenas de leitura por design — não pode modificar a aplicação, os seus dados ou a sua infraestrutura.
- ✓ As sondagens cobrem a aplicação ao vivo, o DNS e a CDN.
- ✓ As correções elaboradas são lançadas através de revisão do Guardrails e gates de QA como qualquer outra alteração.
- ✓ As investigações e resultados são registados no registo de auditoria apenas de acréscimo.
- ✓ O Doctor trabalha ao lado do SysOps, que trata do rollback e reconciliação como operações registadas.
Sintoma a sintoma
Sintomas diferentes, o mesmo método: sondar, correlacionar, explicar.
| Sintoma | O que o Doctor examina | Forma típica do diagnóstico |
|---|---|---|
| Site inacessível | Resolução DNS, certificados, estado da CDN, saúde da origem | Onde o pedido morre no caminho até à app |
| Um fluxo a falhar | A rota, as suas chamadas ao backend, alterações recentes nessa área | A alteração ou dependência que quebrou o fluxo |
| Páginas lentas | Tempo de resposta em rotas e ativos, comportamento da CDN | Qual camada está a acrescentar o tempo |
| Erros depois de um deploy | O diff do deploy, verificações a falhar, erros de runtime | Se corrigir para a frente ou entregar ao SysOps um rollback |
Perguntas frequentes
O Doctor pode fazer alterações à produção?
Não. O Doctor é apenas de leitura por design. Diagnostica e elabora correções, e essas correções são aplicadas através do pipeline governado normal — revisão, gates de QA, depois publicação. A separação é deliberada: a investigação nunca deve alterar aquilo que está a ser investigado.
O que é que o Doctor consegue realmente ver?
O comportamento da aplicação ao vivo — rotas, respostas, erros — mais o DNS, os certificados e o comportamento da CDN, e o próprio histórico do projeto: deploys, alterações de configuração e resultados de verificações. Essa combinação é normalmente suficiente para localizar uma causa raiz.
Como é que a correção elaborada se torna uma correção real?
Entra no ciclo como qualquer alteração: num branch, através de revisão do Guardrails onde as políticas o exigem, através de smoke gates de QA, depois publicação. Se reverter for mais rápido do que corrigir para a frente, o Doctor diz-o e o SysOps executa o rollback como uma operação registada.
O Doctor substitui uma escala de prevenção?
Faz o trabalho de investigação e entrega aos humanos um diagnóstico em vez de registos brutos. Alguém continua a decidir e a aprovar — essa pessoa apenas começa muito mais adiantada, e para muitas equipas isso muda o que a prevenção precisa de ser.
O Doctor está incluído, ou é um extra?
Todos os workspaces Ciao incluem a organização de software com IA — CTO, Doctor, analista de QA, engenheiro de Segurança, Coder e operador SysOps. Para programas de produção, que começam em 10.000 USD por ano, marque uma demonstração e veja um diagnóstico ao vivo num incidente real.