一、实验背景与目的
在云原生时代，架构的健康度直接决定了业务的稳定性与用户体验。腾讯云智能顾问（CloudQ）是一款 ITOM 领域的智能运维工具，能够从卓越运营、安全性、可靠性、性能效率、成本优化五大支柱对云上架构进行全面评估。
本次实验的目的是：在真实运行的 SH-WEB 博客服务中，依次注入 3 个不同架构层次的故障，从两个维度验证 CloudQ 的故障发现能力：
- 架构评估维度：通过 Well-Architected 五大支柱评估，检测资源健康度变化和风险项增减
- 日志分析维度：通过 CLS（腾讯云日志服务）日志检索，直接从日志中定位故障根因
这不仅是对 CloudQ 双重检测能力的一次实战检验，也是故障注入（Chaos Engineering）在云上运维中的最佳实践演示。
二、SH-WEB 架构概览
被测试的 SH-WEB 博客服务是一个典型的三层 Web 应用。经过三轮故障注入实验和后续的架构治理优化，当前架构已完成如下演进：
当前架构组件：
| 组件 | 当前方案 | 演进说明 |
|---|---|---|
| CLB | 负载均衡 → AS 伸缩组 | 后端关联 AS 伸缩组，支持竞价实例自动扩缩容 |
| CVM | 竞价实例（AS 管理） | 从包年包月改为竞价实例，成本降低 60%-80% |
| Nginx + Node.js | 无状态应用 | 配置环境变量化，支持弹性伸缩 |
| 数据库 | TDSQL-C Serverless | 从 CDB MySQL 迁移至 TDSQL-C Serverless，低负载自动暂停 |
| Redis | 单节点 256MB | 保持不变，用于文章列表/详情缓存 |
| 静态资源 | COS 对象存储（公有读） | 从本地磁盘迁移至 COS，消除多实例图片同步问题 |
架构组件与日志对应关系：
| 组件 | 角色 | CLS 日志主题 | 日志内容 |
|---|---|---|---|
| CLB | 负载均衡 | clb_topic | 访问日志（状态码、延迟、后端健康） |
| Nginx + Node.js | 反向代理 + 应用 | shweb | Nginx error log、应用 ERROR 日志 |
| TDSQL-C MySQL | 数据库 | cloud_sh_cdb_topic | 慢查询日志、系统操作日志 |
| Redis | 缓存 | shweb（应用日志中体现） | Redis 连接错误通过应用日志记录 |
三、CloudQ 双重检测能力
CloudQ 对 SH-WEB 架构的检测能力覆盖两个互补维度：
3.1 架构评估（Well-Architected）
通过智能顾问 TSA 对云资源进行五大支柱评估：
- 卓越运营：运维自动化、监控覆盖度
- 安全性：访问控制、数据保护
- 可靠性：高可用、容灾备份、健康检查
- 性能效率：资源利用率、响应延迟
- 成本优化：资源配置合理性
3.2 日志分析（CLS）
通过腾讯云日志服务（CLS）进行实时日志检索与分析：
- 关键词搜索：搜索 ERROR、timeout、connection refused 等异常关键词
- 时间范围过滤：精确到分钟级别的时间窗口查询
- 智能分析：对日志内容进行语义理解，给出排查建议
- 上下文还原：查看异常日志的前后上下文，还原问题现场
验证发现 SH-WEB 已配置了完整的日志采集链路，CloudQ 可以直接查询以下 6 个日志主题：
| 日志主题 | 来源 | 保留天数 | 实验用途 |
|---|---|---|---|
shweb | 用户自建（LogListener） | 30 天 | Nginx + 应用 ERROR 日志 |
cloud_sh_cdb_topic | TencentDB-MySQL | 30 天 | CDB 慢查询日志 |
clb_topic | CLB（负载均衡） | 7 天 | CLB 访问日志（状态码、延迟） |
loglistener_business | CLS LogListener | 7 天 | 采集器业务日志 |
loglistener_alarm | CLS LogListener | 7 天 | 采集器告警日志 |
loglistener_status | CLS LogListener | 7 天 | 采集器状态日志 |
四、基线评估
在注入任何故障之前，首先建立健康基线：
4.1 架构评估基线
- 使用 CloudQ 运行 SH-WEB 架构评估，记录五大支柱的健康评分
- 记录当前风险项数量作为对比基准
4.2 日志基线
- CloudQ 搜索
shweb主题中的 ERROR 日志 → 基线状态（已发现 1 条 Nginx upstream 偶发连接异常） - CloudQ 搜索
cloud_sh_cdb_topic慢查询日志 → 基线状态（无慢查询，数据库运行健康） - CloudQ 搜索
clb_topic异常状态码 → 基线状态（待记录）
4.3 服务基线
- 确认服务运行正常：
curl http://localhost/health返回{"status":"ok"} - 记录首页响应时间（正常应 < 200ms）
五、故障一：Redis 缓存层 — 连接地址错误
5.1 故障描述
将 Redis 连接地址从正确的 172.17.0.14 修改为不存在的 172.17.0.199，模拟缓存服务不可达的场景。这是生产环境中常见的配置错误，可能发生在环境迁移、配置变更等操作后。
5.2 预期影响
| 维度 | 影响 |
|---|---|
| 响应时间 | 每次请求增加数秒（连接超时等待） |
| 错误日志 | 大量 Redis connection error: connect ECONNREFUSED |
| 数据库负载 | 所有请求直接穿透到 MySQL，查询量翻倍 |
| 影响范围 | 所有使用缓存的路由（首页、文章详情） |
5.3 CloudQ 检测方案
架构评估维度：可靠性 + 性能效率支柱评分下降
日志分析维度：shweb 主题中出现大量 ECONNREFUSED、Redis 连接错误
六、故障二：CDB 数据库层 — 无限制全表查询
6.1 故障描述
移除文章列表查询中的 LIMIT/OFFSET 分页限制，并额外查询包含完整 HTML 的 content 字段。模拟开发中常见的 SQL 查询未加限制的问题。
6.2 预期影响
| 维度 | 影响 |
|---|---|
| 查询性能 | 全表扫描 + 大字段传输，查询耗时显著增加 |
| 网络 I/O | MySQL 到应用的数据传输量暴增 |
| 内存使用 | Node.js 持有大量文章内容，内存占用上升 |
| 用户体验 | 分页失效，首页加载缓慢 |
6.3 CloudQ 检测方案
架构评估维度：性能效率 + 成本优化支柱评分下降
日志分析维度：cloud_sh_cdb_topic 出现慢查询记录
→ 详见 实验报告（二）：CDB 数据库层慢查询
七、故障三：应用层 — 事件循环阻塞
7.1 故障描述
在 /health 健康检查端点中注入一个同步阻塞循环，使每次健康检查耗时 5 秒。由于 Node.js 是单线程模型，健康检查阻塞期间所有其他请求都将被挂起。
7.2 预期影响
| 维度 | 影响 |
|---|---|
| 健康检查 | CLB 探测超时，后端可能被标记为不健康 |
| 全局影响 | 所有路由在健康检查执行期间被阻塞 5 秒 |
| 可用性 | 服务间歇性不可用，用户体验严重劣化 |
| 影响范围 | 所有路由（全局性影响） |
7.3 CloudQ 检测方案
架构评估维度：可靠性 + 性能效率支柱评分下降
日志分析维度：clb_topic 健康检查超时，shweb upstream timeout
→ 详见 实验报告（三）：应用层事件循环阻塞
八、三轮故障对比分析
| 对比维度 | 故障一（Redis） | 故障二（MySQL） | 故障三（App） |
|---|---|---|---|
| 故障层次 | 缓存层 | 数据库层 | 应用层 |
| 主要影响支柱 | 可靠性 + 性能 | 性能 + 成本 | 可靠性 + 性能 |
| 架构评估检测 | ✔ Redis 连接异常 | ✔ 慢查询风险 | ✔ 单点故障 |
| 日志分析检测 | ✔ ECONNREFUSED | ✔ 全表扫描 | ✔ 健康检查超时 |
| 服务中断 | 降级运行 | 性能劣化 | 间歇性中断 |
九、实验后架构演进
三轮故障注入实验验证了 CloudQ 的双重检测能力后，我们基于实验发现的架构薄弱点进行了一系列优化改造：
9.1 数据库层：CDB → TDSQL-C Serverless
| 对比项 | 改造前（CDB） | 改造后（TDSQL-C Serverless） |
|---|---|---|
| 计费模式 | 包年包月 ~180 元/月 | 按量 Serverless ~10-30 元/月 |
| 扩缩容 | 手动调整规格 | 自动弹性伸缩，低负载自动暂停 |
| 运维成本 | 需关注磁盘/内存/连接数 | 全托管，免运维 |
9.2 静态资源：本地磁盘 → COS 对象存储
| 对比项 | 改造前 | 改造后 |
|---|---|---|
| 存储位置 | CVM 本地磁盘 + MySQL BLOB | COS 对象存储（公有读） |
| 多实例一致性 | 需手动同步或 DB 回源 | 所有实例访问同一 COS URL，天然一致 |
| CDN 友好 | 图片请求经过 CLB → CVM | 浏览器直接从 COS 拉取，不占用 CVM 带宽 |
9.3 应用层：无状态化 + 环境变量
- 配置外置：数据库、Redis、COS 等连接信息改为环境变量读取，通过
.env文件或 AS UserData 注入 - 无状态设计：去除本地文件依赖，新实例拉起即可服务，支持随时扩缩
- 启动脚本：
startup.sh用于 AS UserData，新实例自动启动 Nginx + Node.js 应用
9.4 计算层：包年包月 → 竞价实例 + AS 伸缩组
| 对比项 | 改造前 | 改造后 |
|---|---|---|
| 实例类型 | 2x S5.MEDIUM2 包年包月 | 竞价实例（AS 伸缩组管理） |
| 月成本 | ~400 元/月 | ~80-160 元/月（2-4 折） |
| 弹性能力 | 固定 2 台 | 1-4 台自动扩缩（CPU > 70% 扩容，< 30% 缩容） |
| 容灾 | 一台故障手动处理 | AS 自动替换不健康实例 |
9.5 总体成本对比
| 资源 | 改造前 | 改造后 | 节省 |
|---|---|---|---|
| CVM | ~400 元 | ~80-160 元 | 60-80% |
| 数据库 | ~180 元 | ~10-30 元 | 83-94% |
| COS | - | < 1 元 | - |
| 合计 | ~580 元/月 | ~90-190 元/月 | 67-84% |
十、总结
通过本次 CloudQ 架构治理实战，我们完成了从发现问题到解决问题的完整闭环：
- 故障注入（Chaos Engineering）：分别在缓存层、数据库层、应用层注入 3 种典型故障
- CloudQ 双重检测：验证了架构评估（Well-Architected）和日志分析（CLS）两个维度的故障发现能力
- 架构治理：基于实验发现的薄弱点，完成了数据库、静态资源、应用层、计算层的全面优化
- 成本优化：月成本从 ~580 元降至 ~90-190 元，节省 67%-84%
实践启示：CloudQ 不仅能在故障发生时快速定位问题，更重要的是通过持续的架构评估，在问题变成事故之前提前发现风险。结合故障注入验证和架构治理优化，可以形成"发现→验证→治理"的良性循环，持续提升云上架构的健康度。