---
title: TrueWatch AIOps实践(2)
tags: 
author: [李小飛](https://docswell.com/user/4681711)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/47MYRNQP7W.jpg?width=480
description: TrueWatch AIOps实践(2) by 李小飛
published: July 24, 26
canonical: https://docswell.com/s/4681711/Z1QWYV-2026-07-24-112123
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/47MYRNQP7W.jpg)

TrueWatch AIOps 实践
Harlon · SA Manager · 2026.07

# Page. 2

![Page Image](https://bcdn.docswell.com/page/P7R9RD8YE9.jpg)

TrueWatch 简介
面向 AWS 与 AI 时代的统一可观测平台
全球化布局
覆盖全球主要区域，助力客户全球业务稳定高效运行
北京
上海
杭州
成都
台北
广州
深圳
马尼拉
新加坡 (总部)
雅加达
产品与 AWS 生态
统一观测 Metrics / Logs / Traces / RUM
支持 AWS 生态与云原生场景
可通过 AWS Marketplace 交付
与 50+ AWS 服务深度集成
全球服务能力
覆盖全球主要区域节点
多区域高可用架构
服务全球客户与出海业务
7×24 全球技术支持
安全与合规
重点支持 SOC 2 Type II
支持 ISO 27001 / ISO 9001
数据加密、访问控制与审计
满足企业级安全与合规要求
核心价值
统一采集、分析与可视化
AI 辅助分析与根因定位
Agent 推动自动化处置
提升运维效率与业务可靠性
AWS 生态合作伙伴
AWS Marketplace Partner of the Year (GCR)
AICPA SOC
SOC 2 Type II
ISO 27001
ISO 9001

# Page. 3

![Page Image](https://bcdn.docswell.com/page/PJXQR1847X.jpg)

AIOps 的行业认知演进
从“算法辅助运维”，走向“可观测平台化”，并进一步演进为 GenAI / Agent 驱动的自主运维闭环
1 2016 - 2020
算法探索与单点应用
从硬编码规则，走向单点算法尝试
告警降噪、动态阈值、
异常检测
时间序列预测
(如 ARIMA 等)
多为单点探索，局部
AI 学件 (算法模块)
数据孤岛严重，算法黑盒，
可解释性差，信任度低
主要痛点
各工具各自为战，缺乏一上下文
模型效果受限，泛化能力差
大部分决策仍需人工确认
2 2021 - 2023
全栈可观测与平台化
从单点工具，走向统一可观测平台
Metrics / Logs / Traces
统一采集与关联
OpenTelemetry、eBPF
实现全链路、无侵入采集
Observe -> Engage -> Act
形成闭环
根因分析 (RCA)、事件联动、
自动化编排与执行
有效缩短 MTTR，向事前
预防运维演进
核心价值
系统可见性全面提升
根因定位更准确
自动化响应缩短故障恢复时间
运维模式从被动响应 -> 主动预防
3 2024 - 至今 (当前 2026 年)
大模型与 Agentic AIOps
从人机协作，走向自主运维
自然语言交互:
Chat2Query / Chat2SQL /
Chat2PromQL
AI Copilot 辅助分析、解释告警、
生成排查建议
AI Agent 自主调用工具、
编排任务、执行修复动作
监控对象扩展到 LLM / Agent:
Token、调用链、工具执行、
成本与安全风险 (GenAIOps)
核心价值
提升运维效率与体验
复杂问题自主诊断与处置
保障 AI 应用稳定与安全
推动运维走向智能自治
AIOps 的本质变化 -> 算法处理告警
解决单点问题 -> 可观测数据理解系统
建立统一上下文与闭环 -> 用 AI / Agent 推动运维闭环
实现自主感知、分析与行动

# Page. 4

![Page Image](https://bcdn.docswell.com/page/3JK9R2KPJD.jpg)

AIOps 正在走向 AgenticOps
从“更好的告警和仪表盘”到“自主理解、决策与执行”，实现运维的智能闭环
AIOps 与 AgenticOps 对比
传统 AIOps
AgenticOps
自动化能力
告警与建议，需要人工跟进
AI Agent 自主推理、规划与执行
工作方式
静态规则、固定流程
自适应流程，端到端任务执行
推理能力
发现异常，分析依赖人工
多步推理，实时权衡与决策
运行规模
受人工与周期限制
7x24 持续运行，机器级响应
角色身份
无持久身份，功能割裂
有角色、有职责、可协同
安全治理
依赖现有系统控制
策略、权限、审计全链路保障
协作方式
多工具切换，人工串联
人与 Agent 在统一工作区协同
运维价值
提升检测效率与可视化
推动自主处置与闭环优化
AIOps 帮助我们更早看到问题，AgenticOps 帮助我们更快解决问题。

# Page. 5

![Page Image](https://bcdn.docswell.com/page/LE3W84Z4E5.jpg)

AIOps 的前提，是统一的可观测数据底座
没有统一数据、统一上下文和统一语义，AIOps 只能做“局部分析”，很难完成准确的根因定位和行动闭环
统一采集·统一关联·统一语义
用户体验
RUM
应用与链路
Traces / APM
日志与事件
Logs / Events
基础设施
Metrics
云与容器
K8s / Cloud
变更与配置
Change / Config
统一可观测数据平台
统一时间轴 | 全局关联 | 高性能存储 | 自助查询
端到端上下文
串联依赖关系与资源
快速定位根因
多维关联，锁定根因
统一业务语义
系统、服务、业务、SLO
开放与集成
API / MCP / 工具生态
VS
传统割裂监控
统一可观测平台
指标、日志、链路、事件分散
全域数据统一采集与关联
告警很多，但不知道主因
聚合问题，识别核心故障
只能看到局部系统状态
还原端到端业务链路
依赖人工经验排查
基于上下文辅助根因分析
AI 只能总结单点信息
Agent 可理解系统关系
并执行动作
AIOps 不是简单在监控工具上叠加 AI，而是需要建立在完整、可信、关联的可观测数据之上。
为 AI 提供完整上下文，帮助其判断影响范围、识别核心问题、定位根因，
并进一步推动 Runbook、API 或 Agent 行动闭环。
看得全
数据完整
看得懂
上下文与语义统一
判得准
精准定位根因
行动快
自动化闭环
数据不统一，AI 只能“猜”；
上下文统一，AIOps 才能“判断与行动”。
数据连接 -> 上下文关联 -> 根因定位 -> 方案建议 -> 自动处置 -> 效果验证

# Page. 6

![Page Image](https://bcdn.docswell.com/page/8EDKMQR57G.jpg)

TrueWatch：面向 AI 时代的统一可观测平台
统一采集、统一存储、统一分析与统一行动，支撑开发、运维、安全与业务场景
软件交付与优化
后端应用性能观测
Web / App 性能观测
CI/CD 可观测
日志分析
持续性能优化
可观测性与安全
基础设施监控
应用性能监控
日志与指标
变更观测
AI Agent 可观测
安全分析
数字化业务分析与服务管理
用户行为分析
用户会话回放
业务数据集成
On-call
事件 / 错误 / 故障管理
Toby AI
AI 驱动的智能观测
与自动化行动
Toby AI Agent Team | AI SRE Agent | AI DevOps Agent | AI Security Agent | AI Test Agent
Toby AI Copilot | Vibe Dashboard | 解析日志 | 洞察指标 | 穿透链路 | 告警分析
统一的可观测性数据湖 GuanceDB 3.0
统一存储与查询，支撑高性能分析体验
30X
查询性能提升
60%
存储成本降低
统一的全域数据采集器 DataKit
低成本接入，一键开启可观测性体验
650+
集成开箱即用
100%
兼容开源生态

# Page. 7

![Page Image](https://bcdn.docswell.com/page/V7PKRLWDJ8.jpg)

统一采集 AWS 与应用全栈数据
从云资源到应用与用户体验，统一接入同一个可观测平台
AWS 与应用侧数据来源
AWS 云资源
EC2 / ECS / EKS
Lambda
RDS / ElastiCache
ALB / NLB
CloudWatch 指标
应用与用户数据
应用日志
APM 链路
前端与用户体验
变更与事件
业务访问数据
TrueWatch 统一接入
统一采集
统一标签
统一时间轴
统一关联
DataKit / OpenTelemetry / RUM / Cloud API
统一接入后形成的观测视角
技术视角
云资源状态
主机与容器指标
应用服务性能
请求链路与错误
日志与事件
业务视角
用户访问体验
影响范围分析
发布与配置变更
统一分析与可视化
AIOps 上下文支撑
TrueWatch 将 AWS 云资源、应用、日志、链路与用户体验统一采集到同一个平台，形成完整上下文，为分析、定位与 AIOps 提供一致的数据底座。
统一采集 -> 统一关联 -> 统一分析 -> 统一可视化

# Page. 8

![Page Image](https://bcdn.docswell.com/page/2JVVRQ8GJQ.jpg)

端到端统一的上下文还原完整问题现场
围绕一次业务请求，将指标、日志、链路、事件、资源与变更统一关联，帮助快速定位根因、识别影响范围并还原问题全貌
端到端业务链路
用户访问 -> 前端 / APP -> API 网关 -> 应用服务 -> 数据库 / 中间件 -> 云资源 / K8s
异常节点
响应慢 / 错误率高
user_id /
session_id
trace_id /
span_id
service /
endpoint
sql /
cache key
host / pod /
container
全链路追踪
从用户入口到后端资源
请求路径完整可见
异常节点快速发现
多维数据关联
Metrics / Logs / Traces / Events
变更与配置统一纳入
业务与技术视角联动
根因与影响分析
识别故障源头
分析上下游依赖
评估用户与服务影响范围
问题现场还原
还原故障发生前后状态
保留时间线与上下文
支持 Runbook / API / Agent 闭环动作
看得全
端到端链路可见
连得上
数据与上下文统一
判得准
精准定位根因
影响清
快速识别影响范围
行动快
支持自动化闭环

# Page. 9

![Page Image](https://bcdn.docswell.com/page/5EGLMWZDJL.jpg)

TrueWatch AIOps 能力全景图
从数据统一到智能运维闭环，构建面向业务健康的智能运维体系
5 行动层
处置建议、Runbook、
通知、工单、自动化
处置建议 Runbook 通知 工单 自动化
推动问题闭环
4 分析层
数据分析、根因分析、
影响面分析
数据分析 根因分析 影响面分析
快速定位问题
3 SLO 层
以业务目标定义服务健康状态
SLO / 目标
识别核心问题
2 上下文语义层
服务、资源、链路、
业务、变更关联
服务拓扑 依赖关系 业务上下文 变更关联
还原完整问题现场
1 数据层
指标、日志、链路、事件、
用户体验、云资源
指标 日志 链路 事件 用户体验 云资源
建立统一数据基础
核心价值
从单点检测走向业务健康管理
围绕根因分析与影响面展开
让 AI 从发现问题走向推动闭环
典型能力
异常发现与告警聚合
SLO 与服务健康评估
根因分析与影响范围判断
自动化处置联动
闭环路径
发现 -> 分析 -> 判断 -> 行动 -> 优化
TrueWatch AIOps 的重点不是单点检测，而是围绕业务健康、根因分析和行动闭环展开。

# Page. 10

![Page Image](https://bcdn.docswell.com/page/4JQYR3LX7P.jpg)

AIOps 的第一步：识别核心问题
先治理告警，再从故障事件、算法异常与 SLO 异常中识别真正重要入口
先做告警治理
原始问题信号
阈值告警
算法异常告警
无固定阈值 / 动态基线 / 突变检测
告警治理
去重降噪
分组聚合
优先级
补充上下文
高质量问题入口
A. 故障事件
时间窗 / 同服务 /
同系统聚合
事件同时包含阈值告警
与算法异常信号
B. SLO 异常
可用性 / 错误率 /
延迟 / 成功率
识别核心问题
判断真正影响
业务的问题
阈值告警仍有价值
保留关键资源与核心服务告警
明确风险边界，避免漏报
作为问题发现的基础信号
不要把所有告警直接交给 AI
AIOps 的两个有效入口
从事件识别故障
聚合零散告警与算法异常
结合链路 / 拓扑 / 业务关系
形成协同处理的故障事件
从告警沉淀 SLO
梳理核心服务健康目标
用 SLO 判断是否影响业务
再下钻日志、链路与资源
最佳实践不是简单减少告警数量，而是把阈值告警、
算法异常与 SLO 异常治理为高质量问题入口，
让 AIOps 从真正重要的问题开始分析。
发现信号 -> 聚合事件 -> 判断影响 -> 推动闭环

# Page. 11

![Page Image](https://bcdn.docswell.com/page/K74W81D2E1.jpg)

AIOps 的第二步：根因分析和影响面分析
从故障事件或 SLO 异常出发，基于统一上下文解释为什么发生、影响哪里、下一步做什么
统一上下文分析
指标 日志 链路 资源 变更 拓扑
故障事件 / SLO 异常
AI 分析引擎
还原问题现场
时间线 / 关联关系 / 异常变化
推断可能根因
错误日志 / 调用异常 / 资源瓶颈
判断影响范围
服务 / 用户 / 地域 / 环境
完整上下文
高置信根因
明确影响范围
统一上下文分析
关联指标、日志、链路、资源、
变更与拓扑，还原完整问题现场
AI 推断可能根因
对比异常时间线、调用路径、
错误日志和资源瓶颈，识别
最可能线索
影响面分析
明确受影响的服务、接口、
用户、地区、环境与业务流程
处置建议生成
输出现象总结、分析依据、
建议动作与下一步排查路径
输出结果
根因线索排序
业务影响等级
推荐查询与 Dashboard
Runbook / 工单 / 自动化建议
根因分析不是解释单条告警，而是基于统一上下文，
把技术异常转化为可判断、可排序、可行动的问题结论。
发现问题 -> 分析定位 -> 影响判断 -> 推动处置

# Page. 12

![Page Image](https://bcdn.docswell.com/page/LJ1Y2GZKEG.jpg)

AIOps 的第三步：故障自动处置执行
从固定 Workflow 到 Agent 驱动的故障自愈，让系统具备理解、规划、执行与验证能力
Agent 驱动的故障自愈流程
1 理解上下文
故障事件 / SLO 异常 /
根因线索 / 影响范围
2 规划路径
拆解诊断与恢复步骤，
判断自动执行或人工确认
3 调用工具
Runbook / API / CLI /
MCP / 工单 / 通知
4 验证恢复
观察 SLO、指标、日志、
链路，未恢复则调整或升级
传统 Workflow 的局限
流程固定，难覆盖复杂场景
依赖预设条件，输入变化失效
执行失败后多转人工
Agent 自愈的关键机制
目标驱动，多步推理
工具调用，受控执行
权限、审批、审计全链路
人在回路，可验证可回退
Agent 不是替代 Workflow，而是负责理解、规划和决策；
由 Runbook、API 与工具可靠执行，并通过验证形成闭环。

# Page. 13

![Page Image](https://bcdn.docswell.com/page/GJWGRK9P72.jpg)

AIOps 的第四步：故障复盘与经验沉淀
让每一次故障处理都沉淀为知识、规则与 Agent 记忆，持续提升下一次智能运维效率
自动复盘故障过程
还原故障时间线
整理异常现象、根因、影响范围
记录处置动作与恢复结果
沉淀可复用知识
形成故障案例与 FAQ
沉淀知识库、Runbook、最佳实践
降低重复排障成本
形成 Agent 记忆
还原似故障的判断依据
沉淀异动动作与无效尝试
提升后续处置准确率
反哺监控与自愈策略
优化阈值与 SLO
优化聚合与根因分析逻辑
调整自动处置边界
从一次故障到持续进化
1 故障恢复 -> 2 自动复盘 -> 3 知识沉淀 -> 4 Agent 记忆 -> 5 策略优化
下一次更快处置
识别更快 -> 分析更准 -> 处置更稳 -> 组织经验可复用
AIOps 的长期价值，不只是更快恢复一次故障，而是让每一次故障都成为系统与组织持续进化的素材。
一次故障形成一份经验，一份经验优化一套策略，
一套策略提升下一次智能处置
时间线复盘 -> 知识沉淀 -> 策略优化 -> 持续进化

# Page. 14

![Page Image](https://bcdn.docswell.com/page/4EZLRZ9673.jpg)

TrueWatch AIOps 产品化能力：从辅助分析到自动执行
基于统一可观测数据平台，让 Toby AI Copilot 辅助人分析，让 Toby Agent Teams 推动诊断、处置与闭环执行
Toby AI Copilot
辅助人分析与决策
智能问答
数据查询与分析
异常解释与根因辅助
操作建议生成
帮助用户更快理解系统状态、定位异常并生成下一步建议
Toby Agent Teams
自动诊断与处置闭环
异常分析
智能诊断
根因定位
自动处理
角色定义
任务编排
工具调用 / API / Runbook
推动问题从发现、分析走向执行与闭环
统一可观测数据底座
Metrics | Logs | Traces | Events | Resources | RUM
统一采集、存储、关联与查询全域可观测数据，为 AI 分析和 Agent 执行提供完整上下文。
完整上下文 | 统一分析入口 | 支撑行动闭环
TrueWatch AIOps 的核心价值，是让可观测平台从“人看数据”升级为“AI 辅助分析 + Agent 自动执行”。

# Page. 15

![Page Image](https://bcdn.docswell.com/page/Y76WRZKL7V.jpg)

TrueWatch AIOps 在电商和游戏场景下的具体案例
以支付 / 充值 / 道具购买接口 5xx 为例，展示如何通过统一上下文快速进入问题分析
典型业务场景
电商场景
用户支付下单时，订单接口
5xx 升高，出现支付失败、
订单未完成、收入转化受影响
游戏场景
玩家充值或购买道具时，
接口 5xx 升高，出现充值失败、
道具不到账、用户体验与流水受影响
共同特征：核心交易链路异常，直接影响收入与用户体验
统一采集的上下文数据
RUM
失效用户、页面访问、地区设备、会话回放
APM
接口链路、错误 Span、服务依赖、慢请求
Logs
应用报错、超时日志、数据库 / 缓存异常
Metrics
5xx 错误率、延迟、资源负载、连接池 / 队列状态
RUM 用户访问上下文
定位失败会话、页面行为与 5xx 请求，看到用户侧发生了什么
APM 链路与服务上下文
查看错误链路，服务依赖与主机指标，看到系统侧卡在哪里
先把用户体验、接口链路、日志和指标统一连接起来，AIOps 才能从“接口报错”进一步判断“影响谁、卡在哪里、可能为什么”。
用户侧可见 | 系统侧可见 | 问题上下文完整

# Page. 16

![Page Image](https://bcdn.docswell.com/page/G75M8WPM74.jpg)

TrueWatch AIOps 在电商和游戏场景下的具体案例
故障识别与 Copilot 辅助排查
5xx Error
Alert /
故障事件
Copilot
快速分析
定位可疑根因
Copilot 初步结论
自动汇总异常时间、受影响接口与服务
关联 SLO、故障事件、链路与依赖拓扑
给出优先排查方向：order-service、payment-service、Redis / 下游依赖
SLO 与业务看板：发现服务健康异常，并触发 AI 分析建议
Toby AI
Toby Agent Teams
发现以下服务的 SLO 存在异常
SLO
80.0% 基准 order-service 上游依赖 0.44830 -> 需
18请求 /P90 延迟异常，常见链路错误监控
告警
UPDATE demo, order-o SLO 1 根问题: 0.44830 -> 常
设置超标后，错误关注 根因排查逻辑
可能原因与根因分析
基于当前的链路拓扑和指标分析：
可能的根因:
你的当前是: order-service 支付 503 错误，导致
notco, 链路异常，请看链路拓扑，请看排查建议
故障中心 + Toby AI：结合链路拓扑、关键 span、错误分布，快速缩小排查范围
Toby AI
Toby Agent Teams
根因候选清单
payment-service
inventory-service
order-service
redis
mysql
关键 span 耗时贡献
api/orders (POST (api/orders) 69.20ms
order-service (POST (api/orders) 45.60ms
payment-service (Checkout) 68.76ms
redis 8.76ms
downstream-service (GET (inventory) 70ms
从异常发现到辅助分析，TrueWatch AIOps 帮助团队更快看见问题、理解影响并收敛根因方向。

# Page. 17

![Page Image](https://bcdn.docswell.com/page/9J29KQ6RER.jpg)

TrueWatch AIOps 在电商和游戏场景下的具体案例
Agent Teams 深度分析与故障笔记沉淀
Toby Agent Teams：像 SRE 一样分析
Agent Workspace
Observability Navigator
Online
+ New Task
My Tasks
In progress · 07/18 14:55
Task Insight
Timeline
List
7/18
Evidence 收到 3 条关联告警: gateway-
service 延迟 2.94%，order-
service 错误率 2.9%，mall-demo
后端 HTTP 错误率 2.9%，均超过
阈值 1%。
Analysis gateway-service 和 order-service
同一时间段
(rut_0e27893 已经持续 45 分钟，表现同
是同一故障导致多个服务
(rut_a7bfb770f2646774b4fb2833a27
cac895e)、说明问题同时影响网关和
订单服务
自动生成故障笔记
故障根因分析 - mall-h5 503 错误
故障概览
产品 mall-demo 的服务 mall-h5 接口 /api/orders 在 2026-07-18 14:05 UTC 期间 HTTP 503 错误率
率达到 **100%**，触发 fatal (致命) 级别故障，共产生 55 条错误 trace，故障持续约 40 分钟。
字段 值
故障 ID event-1bfd9606483045caafa76b7005fbcbe5
故障 ID event-4e1d388461034247fac53a02cb5477d9
状态/等级 fatal (致命)
服务 mall-h5
接口 /api/orders
HTTP 状态码 503
错误率 100.0% (检测窗口 300 秒内 Result=1.0)
产品 mall-demo
故障开始时间 2026-07-18 13:25:00 UTC
故障持续时长 2400 秒 (40 分钟)
监控规则 HTTP 状态码 503 error rate for endpoint /api/orders of service mall-h5 in product mall-demo ha
01
接收故障事件
多源事件聚合
02
拆解分析任务
多 Agent 协同拆解
03
调用工具验证
链路/日志/指标/拓扑
04
输出根因结论
形成证据链
故障时间线
还原事件全貌
根因判断
关键证据支撑
影响范围
受影响服务/接口
处置建议/Runbook
修复建议与验证步骤
沉淀与复用
知识库与记忆更新
多 Agent 协同告警、链路、日志、指标与拓扑，形成证据链
从 Agent 深度分析到故障笔记沉淀，TrueWatch AIOps 将一次故障转化为下一次更快识别、更准分析、更稳处置的经验。

# Page. 18

![Page Image](https://bcdn.docswell.com/page/DEY4NW95JM.jpg)

如何开通使用 TrueWatch？
支持 SaaS 与托管版两种开通方式，并可通过 AWS Marketplace 完成订阅与支付
SaaS 版：开箱即用
无需自建平台，注册后即可开始使用
统一接入 AWS 与应用全栈观测数据
平台自动升级与弹性扩展
适合快速上线与全球化业务
快速开通
免运维
按量付费
托管版：部署在自有云环境
平台部署在企业自己的 AWS 环境中
数据、网络与权限边界更可控
由 TrueWatch 提供托管运维服务
满足安全、合规与数据留存要求
自有环境
安全可控
托管运维
两种模式均支持通过 AWS Marketplace 订阅与支付
按需选择 SaaS 或托管版，均可通过 AWS Marketplace 快速开通 TrueWatch。

# Page. 19

![Page Image](https://bcdn.docswell.com/page/VJNYX9L478.jpg)

OBSERVABILITY &
AIOPs IMMERSION DAY
从演讲到动手实践
TrueWatch AIOps 实践 · Tokyo AWS Office
15:50-16:50 Builder Session: 观测云 (TrueWatch) AIOps 实践
扫码加入交流群
日本 TrueWatch AI Agent &
可观测交流群
HANDS-ON WORKSHOP
TrueWatch AIOps 实践
01 EKS 部署商城 Demo 应用
02 采集全量观测数据与上下文
03 触发故障并完成故障定位
04 使用 AI 辅助分析故障
05 Agent 协同诊断问题
扫码进入 Workshop
Access Code: 82f1-0d62bd-5d
https://catalog.us-east-1.prod.workshops.aws/
join?access-code=82f1-0d62bd-5d
2026.07.19 · 中文 Workshop · 亚马逊云科技 UserGroup-Tokyo

# Page. 20

![Page Image](https://bcdn.docswell.com/page/YE9P8244J3.jpg)

谢谢！
AIOps 让可观测更智能，让运维更高效
了解更多
加入交流群