云监控 + 告警实战：千里达票务系统 7×24 稳定运行保障
节假日景区系统最怕"无声故障"：凌晨 2 点数据库连接池打满，早上开园才发现，游客已经排队。千里达票务系统基于阿里云云监控构建了"指标采集 + 告警通知 + 事件闭环"的运维体系，本文分享落地实践。
一、业务场景与挑战
- 7×24 无人值守：夜间运维人员不常驻，故障发现依赖监控告警；
- 多景区差异：各景区业务量不同，需要按景区设置不同的告警阈值；
- 告警要能落地：告警发出后必须有人响应，否则等于没有。
二、方案设计
| 层级 | 方案 |
|---|---|
| 基础监控 | ECS、RDS、Redis、SLB 云产品指标自动上报 |
| 应用监控 | 自定义指标（QPS、错误率、P99 延迟）通过 API 上报 |
| 告警通道 | 钉钉机器人 + 短信 + 电话（严重级别） |
| 值班闭环 | 告警 → 响应 → 处置 → 复盘记录 |
三、关键实现
3.1 自定义指标上报（Python 示例）
from aliyun_python_sdk_cms.request.v20190101 import PutCustomMetricRequest
request = PutCustomMetricRequest()
request.set_MetricList([
{
"metricName": "ticket_order_p99", "value": "180", "dimensions": "{\"scene\":\"SC1001\"}"}
])
client.do_action_with_exception(request)
3.2 告警规则示例
- ECS CPU > 85% 持续 5 分钟 → 钉钉告警；
- RDS 连接数 > 80% 持续 3 分钟 → 短信告警；
- 接口错误率 > 2% 持续 5 分钟 → 电话告警（节假日自动升级）。
3.3 告警升级机制
非工作时间，普通告警延迟 15 分钟未确认自动升级为电话告警；重大故障直接电话 + 短信双通道。
四、踩坑复盘
- 告警风暴：一次 RDS 故障触发 50 条关联告警，值班群被刷屏。解决：告警收敛（主故障 + 抑制关联告警）+ 分组通知；
- 阈值拍脑袋：CPU 阈值设 90%，实际业务在 70% 时已卡顿。解决：基于压测数据反向设定阈值，预留 30% 冗余；
- 告警无人响应：凌晨告警发出去没人处理。解决：建立值班表 + 告警升级机制 + 次日复盘；
- 监控盲区：只监控云产品，业务层错误发现滞后。解决：补齐自定义指标，把订单失败率、支付成功率纳入监控。
五、效果与总结
监控体系上线后，重大故障平均发现时间从"开园后游客反馈"缩短到"3 分钟内自动告警"。对千里达票务系统而言，云监控不只是看板，而是一套可执行的事件闭环：发现、通知、响应、复盘。稳定的告警体系，是支撑景区 7×24 运营的基础设施。
