平台
Doctor:面向线上应用的只读 AI SRE
当生产环境出现问题时,Doctor 会像一名站点可靠性工程师一样展开调查——交给你的是诊断结果与一份草拟好的修复方案,而不是一页日志。
Doctor 是 Ciao 的只读 AI 站点可靠性工程师。它探测线上应用、DNS 与 CDN,诊断事故的根本原因并草拟修复方案。与被赋予生产环境写权限的智能体不同,Doctor 在设计上就是只读的——它能查看一切,却不能改动任何东西,因此诊断可以又快又持续,并且可以放心地针对真实系统运行。
发布日期 2026-07-03 · 最近更新 2026-07-03
生产环境会出问题;专业能力却很稀缺
每一个应用早晚都会遇到那个糟糕的下午:网站宕机、结账报错、某位客户登录失败,却没人知道原因。传统的应对方式是找一名站点可靠性工程师,翻查日志、DNS 记录与 CDN 行为,直到理出一条头绪。大多数用 AI 构建产品的团队并没有这样的人——也不应该为了让一个门户网站正常运转,而不得不去雇一个。
Doctor 是 Ciao 的只读 AI SRE。它探测线上应用、DNS 与 CDN,诊断根本原因并草拟修复方案。只读,是这里真正重要的设计决策:Doctor 能查看一切,却不能改动任何东西。
一次诊断是如何进行的
诊断遵循的路径,与一名经验丰富的 SRE 会走的路径相同——只是它立即进行,并且留有记录。
1. 某些地方看起来不对劲
一项生产环境检查失败了、Conductor 中的一盏健康指示灯变红了,或者有人请 Doctor 去调查某个症状。
2. Doctor 探测线上应用
它请求真实的路由、演练失败的流程,并像用户的浏览器那样去读取响应和错误。
3. 然后是通往应用的路径
DNS 解析、证书状态与 CDN 行为也会被探测,因为“应用宕机了”背后往往真正的问题是“通往应用的路径断了”。
4. 上下文加入证据
近期的部署、配置变更与检查历史,能缩小问题发生的时间范围,并明确当时周围到底发生了什么改动。
5. 用简明语言给出根本原因
输出的是一份诊断,而不是一堆日志转储:哪里坏了、在哪个位置、为什么——并附带证据。
6. 草拟好的修复方案,走正门发布
Doctor 会草拟修复方案,并按照每一次变更本该走的方式发布:通过 Builder、按政策要求经过 Guardrails 审核、通过 QA 关卡。诊断是即时的;变更依然受到治理。
为什么只读很重要
把生产环境的写权限交给一个 AI,是大多数安全团队不会做的决定——Ciao 也没有要求他们这么做。Doctor 的权限仅限于调查。这让它可以放心地针对真实系统持续运行,也可以放心地被引入受监管环境:一次错误诊断的影响范围,是一句错误的话,而不是一次错误的变更。
这也让激励机制保持诚实。Doctor 草拟的修复方案必须经过与任何人工变更相同的审核和测试,速度永远不能换取绕过治理的捷径。
这里还有一层 Fleet 效应。因为探测是安全的,Doctor 不需要等人先怀疑出了问题——生产环境检查和健康指示灯会持续把症状交给它,覆盖 Conductor 中的每一个项目。过去要等有人抱怨才开始的调查,现在从第一项检查失败的那一刻起就已经开始。
谁在使用 Doctor
Doctor 改变了每一个曾经承担过事故处理的人的体验。
- 创始人与业务负责人 — 用 Ciao 搭建应用的人,很少也是那个能在半夜排查 DNS 问题的人。Doctor 就是他们不必去成为的那名调查员。
- 代理机构 — 在 Conductor 中管理一支客户应用 Fleet 时,Doctor 是第一响应者——诊断往往在客户注意到症状之前就已完成。
- IT 与平台团队 — 分诊工作提前完成了调查:升级的问题会带着根本原因和证据抵达,而不是一张模糊的工单。
- 工程师 — 最终决定依然由他们来做——只是他们的起点变成了一份诊断,而不是一次 grep 搜索。
安全与治理说明
- ✓ Doctor 在设计上是只读的——它无法修改应用、应用的数据或基础设施。
- ✓ 探测覆盖线上应用、DNS 与 CDN。
- ✓ 草拟好的修复方案会像其他任何变更一样,经过 Guardrails 审核与 QA 关卡再发布。
- ✓ 调查与发现会被记录进只增不减的审计日志。
- ✓ Doctor 与 SysOps 协同工作,后者以有记录的操作方式处理回滚与协调工作。
逐个症状来看
不同的症状,相同的方法:探测、关联、解释。
| 症状 | Doctor 检查的内容 | 典型的诊断形态 |
|---|---|---|
| 网站无法访问 | DNS 解析、证书、CDN 状态、源站健康状况 | 请求在通往应用的路上死在了哪里 |
| 某个流程失败 | 该路由、其后端调用、该区域近期的变更 | 是哪次变更或依赖破坏了该流程 |
| 页面变慢 | 跨路由与资源的响应时间、CDN 行为 | 是哪一层增加了耗时 |
| 部署后出现错误 | 部署差异、失败的检查项、运行时错误 | 该向前修复,还是交给 SysOps 回滚 |
常见问题
Doctor 能对生产环境做出改动吗?
不能。Doctor 在设计上是只读的。它负责诊断并草拟修复方案,而这些修复方案会通过正常的受治理流水线来应用——审核、QA 关卡,然后发布。这种分离是刻意为之的:调查不应该改动被调查的对象。
Doctor 实际上能看到什么?
线上应用的行为——路由、响应、错误——再加上 DNS、证书与 CDN 行为,以及项目自身的历史:部署、配置变更与检查结果。这些信息组合起来,通常足以定位根本原因。
草拟的修复方案是如何变成真正的修复的?
它会像任何变更一样进入闭环:在一个分支上,按政策要求经过 Guardrails 审核,通过 QA 冒烟测试关卡,然后发布。如果回滚比向前修复更快,Doctor 会明确说明,并由 SysOps 以有记录的操作方式执行回滚。
Doctor 能取代值班轮换制度吗?
它完成了调查的体力活,交给人类的是一份诊断,而不是原始日志。仍然由人来做决定并批准——只是这个人的起点大大提前了,对许多团队来说,这改变了值班本身应有的样子。
Doctor 是包含在内的,还是一项附加服务?
每一个 Ciao 工作区都包含这套 AI 软件组织——CTO、Doctor、QA 分析师、安全工程师、Coder 与 SysOps 运维。对于起价为每年 10,000 美元的生产项目,预约一次演示,看一看它在真实事故上的实时诊断。