一场故障，和17个浏览器标签页
凌晨两点十七分，值班群被一条告警炸醒：支付成功率跌了。
接下来的四十分钟，值班工程师先后打开告警平台、云监控、Prometheus、APM、CLS、RUM 和云拨测：每换一个控制台，就要重新设置时间范围、确认资源归属、重新拼接上下文。等第 17 个标签页打开时，最早看到的数据可能已经过期。
数据一点都不缺。缺的是那个把线索串起来的人。
过去，这件事主要依赖值班工程师对服务依赖、历史故障和处置流程的记忆。腾讯云可观测平台 AI 工作台希望把这段工作交给 AI：将告警、指标、日志、调用链、用户体验等能力封装成 Skill，按业务问题自动组织分析。
用户只需要问：
支付成功率下降了，请分析影响范围并找到可能的根因。
AI 会从业务问题出发，串联不同层面的证据；必要时，还可以接入代码平台、企业知识库或其他云厂商的能力。
原本分散的工具，由此变成可组合、可扩展的分析能力。
Skill 生态如何组织可观测能力
在 AI 工作台里，Skill 是数字分身可以调用的能力插件。它把产品接口、分析方法和领域经验封装在一起，让 AI 知道什么时候调用、需要哪些参数，以及如何解读结果。
换句话说：控制台是给人看的，Skill 是给 AI 用的。
从产品架构看，腾讯云可观测 Skill 生态包含四层：
- 场景入口：AI 探索页面提供告警历史分析、告警根因分析、应用异常分析、容器健康检查、日志波动分析、Dashboard 分析、前端异常排查和网络质量分析等场景，也支持自由提问并选择资源、告警历史、Dashboard 或资源地图作为上下文。
- AI 工作台与数字分身：数字分身承载身份定义、资源地图、Skill、MCP 和知识库，将业务问题翻译成具体的查询与分析动作。
- Skill 生态：平台内置 Skill 提供通用能力；Skill 广场和第三方 Skill 扩展行业、跨云和外部系统能力；企业也可以上传自研 Skill 或第三方官方安装包。
- 数据与系统：能力最终落到指标、日志、调用链、告警、用户体验、资源、代码平台和企业知识等数据上。
这套架构的价值，不是增加一个聊天入口，而是把专业能力变成 AI 可以稳定调用的标准单元。
- 单 Skill 场景：先把一个专业问题查清楚
问题边界清楚时，一个 Skill 就够了：
单 Skill 省掉的是学习成本：用户从 “我遇到了什么问题” 开始提问，不必先记住每个产品的查询语法。
AI工作台当前提供的内置Skill列表：
- 多 Skill 协同：把散落的证据串成故障链路
复杂故障往往跨越基础设施、容器、应用和用户体验层。AI 可以按“定位范围 → 跨层验证 → 影响确认 → 处置验证”的顺序协同多个 Skill。
以支付接口异常为例：
告警 Skill：识别首发告警、关联资源和分析时间范围；
云监控、Dashboard 与 Prometheus Skill：检查资源、工作负载和实例指标；
APM 与 CLS Skill：还原调用链，用日志验证候选根因；
RUM 与云拨测 Skill：确认用户影响，排除公网、DNS 和负载均衡等因素，并验证处置是否生效。
最终输出不应只是 “可能是数据库问题”，而应包含首发信号、异常指标、调用链、日志证据、影响范围、已排除因素、根因置信度和下一步动作。
能复核，是运维分析进入生产流程的前提。
- 有了平台内置 Skill，为什么还需要扩展能力
平台内置 Skill 覆盖可观测领域的通用查询与分析：告警、指标、调用链、日志、容器状态、用户影响和网络质量。
但运维问题经常还需要回答：
这些信息不一定存在于可观测数据中。扩展能力的作用，是把代码、其他云、企业知识和内部规则接入同一次分析，同时保留原有上下文。
这里的 “自定义” 首先指接入方式，不代表能力一定由企业自研：第三方官方 Skill 可以通过安装包上传，已上架能力也可以从 Skill 广场安装；只有企业专属系统和规则，才需要自行编写 Skill。
企业自研 Skill 通常需要补充三类信息：
- 系统：自建发布系统、CMDB、内部知识库的接口和查询范围；
- 语言：将“订单核心链路”“库存主集群”等内部称呼映射到具体资源；
- 规则：哪些操作只读、哪些需要审批、结果如何留痕。
内置 Skill 提供腾讯云可观测的通用证据，广场和第三方 Skill 扩展外部能力，自定义上传承载第三方官方安装包或企业自研能力。它们绑定到同一个数字分身后，就能在同一次会话里协同工作。
接下来用三个场景说明这条扩展链路：
-
联动代码平台：把运行时证据下钻到仓库、文件、函数和提交；
-
管理多云资源：统一巡检不同云上的健康状态和利用率；
-
对接知识库：把业务映射、历史经验和处置规则带回当前分析。
代码平台说明发生了什么变化，多云资源说明整体运行得怎么样，知识库补充团队过去如何判断和处理。
核心场景一：联动代码平台，把运行异常定位到代码
场景：五条告警同时响，但没有一条指向真正的原因
在一次真实分析中，资源地图为 Nebula，时间窗为 14:16–14:46。会话使用了告警、APM、Prometheus、CLS、RUM 等平台内置 Skill，并通过上传官方 Skill 安装包接入 GitHub 代码分析 Skillgithub-repo-analyzer。
用户只提出一个问题：
我的资源地图里出现了支付相关的告警，请从告警出发，逐层下钻找到真正的根因，并识别和排除不相关的干扰信号。
会话开始时有五条告警：
五条告警看起来像一场大面积故障，但没有一条直接告诉研发该改哪一行代码。
内置 Skill 先把范围收窄
前五个阶段由平台内置能力完成：
五个 Skill 跑完，结论已经收敛到：payment 在业务逻辑层面拒绝请求，基础设施正常，影响集中在/api/checkout。
从“哪个服务在报错”到“改哪一行”
研发接下来会追问：Invalid token是哪段校验逻辑判定的？为什么app.loyalty.level=gold被判无效？flagd 的告警是否与支付失败有关？
这些问题需要代码证据。若改为人工切换 GitHub，前面已经形成的时间窗、错误信息、服务范围和 flag 名称还要重新输入。
github-repo-analyzer接上后，前五个阶段的结论可以直接作为源码分析的输入：
第 6 步带来两个前面无法得到的答案：
- 从错误信息落到代码行：研发知道该检查哪个文件、哪个函数和哪个判断；
- 区分同时发生的异常：代码确认 flagd 与 payment 校验问题是独立路径，不能把重启 flagd 当作 payment 故障的修复方案。
结论不是“哪个服务挂了”，而是每个服务扮演什么角色
只有把源码证据补上，结论才从“高度疑似”变成可以写进故障报告的交叉验证结果。
案例会话结果：
案例中，AI 通过github-repo-analyzer将支付失败下钻到index.js:21的 token 校验逻辑。
小结：可观测证据 + 代码证据，结论才能落地
前五个 Skill 将范围从五条告警收窄到一个接口，代码分析 Skill 再把结论落到具体文件和代码行。前者回答“哪里异常”，后者回答“改哪里”。
核心场景二：统一管理和分析多云资源
场景：每朵云一个控制台，巡检靠手工拼
订单系统、大数据集群和不同地域节点可能分布在多朵云上，每朵云都有自己的控制台、指标口径和资源清单。
人工巡检通常要逐个查看告警和资源曲线，再手动汇总。这样不仅耗时，还容易遗漏长期低负载、持续高负载或配置异常的资源。
把不同云的监控数据接入 AI 工作台后，可以用同一句话完成统一巡检。
多云统一的不是“大盘”，而是口径
真正需要统一的是业务对象、时间窗口、指标口径、证据格式和结论口径：
一次巡检跑三件事：健康、利用率、成本优化
资源地图确定巡检范围，第三方云 Skill 查询各云资源，平台内置 Skill 汇总分析。用户可以这样提问：
对腾讯云和阿里云的云服务器和数据库资源做个整体的巡检：列出活跃告警和异常实例，分析资源利用率，标出长期低负载和持续饱和的资源，并给出配置调整建议。
AI 的动作顺序是：
-
确认巡检范围和各云对应的 Skill；
-
按统一时间窗口拉取告警、指标和资源状态；
-
输出分级健康清单；
-
对比各类资源的利用率，识别低负载和高负载对象；
-
汇总疑似闲置、超配或可合并资源。
这里的成本优化不是账单分析。当前能力边界内，AI 根据资源状态和利用率曲线识别浪费信号，给出优先处理方向和判断依据；具体节省金额、规格价格和账单核算仍由人工完成。
实战：一份真实的多云巡检报告
这次巡检覆盖腾讯云与阿里云的云服务器、数据库资源，由tcop-inspecting与alibabacloud-cms-manage协同完成。结果集中在三件事：5 个资源中 1 个需重点关注、CDB 内存持续高负载、1 台新建 ECS 疑似低负载。
| 报告模块 | 报告内容 |
|---|---|
| 总揽摘要 | |
| 分级健康情况 | |
| 详细利用率数据 | |
| 闲置资源识别与处置建议 | |
报告把健康分级、利用率和建议动作放在同一份清单里，避免在不同云控制台之间反复比对。需要注意的是，报告给出的是资源状态和调整方向，不包含具体节省金额。
小结：同一个问题入口，替代一串控制台
多云管理的重点，不是把所有云做成一张大盘，而是让不同云上的资源可以用同一套问题入口来巡检和分析。
安全边界
多云 Skill 的访问密钥应配置在数字分身的敏感环境变量中，权限默认只覆盖资源和监控数据读取。AI 负责分析和提出建议；涉及变配、缩容、重启或删除资源的动作，必须经过人工确认。
核心场景三：对接 ima 知识库，让企业经验参与排障
场景：实时数据告诉你哪里慢，企业知识告诉你该怎么判断
监控能说明当前发生了什么，但服务名、依赖关系、业务影响、处置顺序和审批边界，往往沉淀在企业自己的文档中：
- 服务与业务能力映射；
- 错误码和依赖说明；
- 应急预案与处置 SOP；
- 降级矩阵和历史复盘；
- 责任边界与审批规则。
通过 ima 知识库 Skill，AI 可以提取当前故障特征，检索相关文档，再回到实时数据验证，而不是直接照抄一条历史结论。
结果不是“搜到一篇文档”，而是完成一次验证；
可信的知识增强分析至少要说明：命中了哪些资料、当前故障与历史案例哪里相同、哪些结论已经被实时数据验证、建议适用的环境和版本是什么，以及哪些操作需要人工确认。
实战：同一故障，两种结论
这次对照实验的时间窗为 15:20–16:00。用户反馈首页和商品详情打开变慢、猜你喜欢加载很久、商品列表偶尔卡住，同时有人观察到“广告服务 CPU 很高”；加购、结账和支付正常。
两个会话使用相同的 APM、Prometheus 和 CLS 能力；其中一个额外接入 ima 知识库。知识库包含三篇文档：服务资源与业务能力映射、商品目录 PostgreSQL 依赖处置 SOP、商品浏览与推荐降级矩阵。
两边看到的实时现象一致：product-catalog 的 GetProduct 从 4ms 上升到 2200ms，sql.conn.query 从 0.89ms 上升到约 915ms；recommendation 和 frontend 同步变慢，购物车、支付和广告服务保持正常。
最终结论却不同：
| |
||
| | 未接知识库 | 接入ima知识库 |
|---|---|---|
| 最终根因 | “PostgreSQL 连接池耗尽”，将数据库实例当成根因 | “product-catalog 到共享 PostgreSQL 的网络访问路径异常”，数据库实例本身无异常 |
| 判定依据 | 看到 DB span 变慢，但未继续区分网络路径与数据库实例 | 依据约 915ms 的恒定延迟和正常的 PostgreSQL 服务端指标，按 SOP 归因为网络路径问题 |
| 处置建议 | 调大连接池、重启 Pod、入口限流 | 先推荐降级、缓存兜底和限制重试，再由网络/平台方恢复路径；禁止重启 PostgreSQL和盲目扩容 |
| 责任与影响边界 | 输出服务级受影响清单 | 说明商品浏览、详情和推荐受影响，结账被级联拖慢，购物车、支付和广告不受影响，并标注责任方与审批要求 |
未接知识库的会话并不是没有找到瓶颈：它识别了 sql.conn.query 延迟、排除了广告干扰，也确认购物车和支付正常。它缺少的是企业沉淀的判定规则：应用侧 DB span 变慢、数据库服务端指标正常时，应优先怀疑访问路径，而不是直接归因数据库实例。
知识库的增量也不止技术归因。它把技术资源翻译成业务影响和处置动作：商品目录异常首先影响商品浏览、详情和推荐；结账可能被级联拖慢，但购物车和支付保持独立；止血应先降级再修路径；不同动作分别由推荐、商品平台、网络或数据库团队负责，并遵守相应审批边界。
监控数据告诉 AI 哪个服务变慢；企业知识把服务名翻译成影响哪些业务、外部依赖归谁管、先降级还是先修路径，以及什么不能动。
ima 知识库 Skill 与平台知识库的区别
AI 工作台自带知识库适合沉淀与某个数字分身强绑定、需要在工作台内持续维护的资料；ima 知识库 Skill 适合连接企业已在 ima 中运营的知识资产，不必迁移原有文档和检索体系。
两种方式可以并存。无论选哪种，都要按用户、角色和项目校验访问权限，不要把密钥、账号和个人信息写进知识内容。
配置指引：把 Skill 接入 AI 工作台
先按能力来源选择获取方式，之后统一执行 “绑定分身 → 配置凭证 → 发起验证”：
第一步：准备 Skill
企业自定义 Skill 的入口文件是 SKILL.md，可以附带脚本、参考资料和模板：
my-skill/
├── SKILL.md
├── scripts/
└── references/
至少写清楚 Skill 的用途、触发条件、输入、输出证据、只读与审批边界，以及失败时的处理方式。鉴权只声明环境变量名称，真实密钥从运行环境读取，禁止写入安装包。
第三方 Skill 不需要重新编写：ima 知识库和 GitHub 代码分析等官方 Skill，获取安装包后进入第二步。
已经上架广场的 Skill，直接在广场搜索安装，当前广场已上架3个第三方Skill：alibabacloud-cms-manage、aws-observability、github-repo-analyzer。
第二步：上传并安装
适用于企业自定义 Skill 和第三方官方安装包：
-
进入AI 工作台 > 扩展中心 > Skill 技能；
-
点击“+ 自定义 Skill”；
-
上传包含 SKILL.md 的文件夹或 ZIP 包；
-
确认文件夹或 ZIP 不超过 200MB；
-
点击“确定”，等待安全检测；
-
安装成功后，在“自定义”分类中确认 Skill 可见。
平台会检查安装包结构和安全风险，检测记录可在“上传历史”中查看。通过 上传接入的 Skill 可以是企业自研能力，也可以是第三方Skill。
第三步：创建数字分身并绑定能力
-
进入数字分身 > 分身列表，新建数字分身；
-
填写身份定义和业务范围；
-
按需选择或创建资源地图；
-
在 “集成配置” 中添加 Skill、MCP 和知识库；
-
点击“创建并启用”。
资源地图按业务组织资源，而不是按产品堆叠。范围越准，数字分身遇到同名服务、测试资源和无关实例时越不容易误判。
按场景绑定最少的能力即可：
第四步：配置 Skill 凭证
环境变量在数字分身创建后配置：
-
打开数字分身详情；
-
进入集成配置并点击编辑；
-
添加 Skill 要求的 Key 和 Value；
-
Token、Secret、访问密钥等勾选“是否敏感”；
-
保存配置。
如果 Skill 声明了所需鉴权 Key，集成配置会提示还有哪些没配，需要按实际情况完成配置后才可以正常使用。
第五步：发起只读验证
-
在分身列表点击“发起对话”；
-
选择待验证的 Skill；
-
按需使用 @ 选择资源地图；
-
输入范围明确、风险较低的问题；
-
检查是否出现工具调用卡片和调用结果。
推荐先使用：
本次仅做只读验证。请使用已选择的 Skill 查询测试对象，返回调用步骤、数据来源和结果摘要。不要创建、修改、删除、发布、回滚或停用任何资源，也不要输出任何凭证明文。
只有出现真实的工具调用和结果，才说明 Skill 被正确触发。若只有文字回答没有调用卡片，应检查 Skill 绑定、会话选择、鉴权环境变量和 SKILL.md 的触发条件。
从一次对话走向持续运行
一次 RCA 会话往往已经形成了稳定步骤：查询告警、获取资源、检查指标、分析调用链和日志、确认用户影响、输出根因报告。
这套步骤可以保存为数字分身任务，补充任务目标、执行步骤、输出规范、异常兜底和验收标准。任务继承数字分身绑定的 Skill 和 MCP，还可以按需收窄能力范围。
工作面板支持查看任务日志、会话列表、任务列表和工作统计。研发和运维可以回看会话、手动触发任务、检查结果，并跟踪执行次数、成功率和趋势。
进一步配置定时触发或告警触发后，巡检和排查就能从“有人记得做”变成“到点自动执行”。
Skill 的价值不止于一次问答，它可以沉淀为可重复运行的运维流程。
结语
回到开头那 17 个标签页。它们不只是工具太多，更说明能力之间缺少连接：每个产品做好了自己的部分，但串联它们的工作仍依赖值班工程师的记忆和手速。
Skill 生态将这段连接工作沉淀下来：内置 Skill 提供标准化的可观测能力，第三方和广场 Skill 扩展外部系统，企业自定义 Skill 固化内部系统、语言和规则，AI 工作台负责在同一会话中组织它们并输出可复核的结论。
对企业来说，核心变化有三点：
- 降低对个人记忆的依赖：经验和流程沉淀为 Skill，团队可以复用同一套方法；
- 让结论可复核、可审计：每一步都有数据来源，写操作必须人工确认；
- 让能力持续沉淀：一次成功的排障或巡检可以保存为任务，定时或由告警自动触发。
可观测的终点从来不是“看得见”，而是看见之后，能有人或 AI 立即把它处理掉。
关于腾讯云可观测平台
腾讯云可观测平台（Tencent Cloud Observability Platform，TCOP）是集指标、链路、日志于一体的全栈智能观测平台。结合强大的可视化和告警能力，为您提供一体化、智能化监控解决方案。可以满足客户全链路、端到端的统一监控诉求，帮助用户提高运维排障效率，为业务的健康和稳定保驾护航：
-
Prometheus 监控：开箱即用的 Prometheus 托管服务；
-
应用性能监控 APM：支持无侵入式探针，零配置获得开箱即用的应用观测能力；
-
云拨测 CAT：利用分布于全球的监测网络，提供模拟终端用户体验的拨测服务；
-
前端性能监控 RUM：Web、小程序、APP等页面质量和性能监测；
-
终端性能监控 RUM Pro：专注为客户端应用Android、iOS、鸿蒙、Windows、Flutter 等提供全面的崩溃分析、性能监控、异常告警能力；
-
Grafana 可视化服务：提供免运维、免搭建的 Grafana 托管服务；
-
云压测 PTS：模拟海量用户的真实业务场景，全方位验证系统可用性和稳定性；
-
云监控 CM：腾讯云基础云产品资源的指标监控、Dashboard、以及告警功能；
-
......等等
