线上事故很多时候，系统本身并没有真的崩，问题出在没人及时知道。CPU 长时间顶满、磁盘写满导致数据库写不进去、月底账单超出预算，这些情况如果没有提前提醒，往往要等用户投诉才发现，修起来代价就大了。阿里云预警要做的，就是把这些风险变成提前能看到的信号。
为什么要单独配预警
云资源的优势是弹性和按需付费，但变化也快。一台 ECS 今天负载正常，业务涨一波，下周可能就贴着瓶颈跑。靠人工定期登录控制台查看，既费时间，也容易漏。预警配好之后，系统替你盯着关键指标，异常时直接通知负责人。
预警并非越多越好。阈值设得太低，每天几十条短信，最后大家都习惯性划走；设得太高，等于没设。比较靠谱的做法是三件事同时满足：指标和业务挂钩，阈值有历史数据做依据，通知能落到对的人手上。
常见的三类预警
日常使用阿里云，优先配置的大致可以分为三类。
- 资源类：ECS 的 CPU 使用率、内存、磁盘空间、网络带宽。最基础，也最常出问题。
- 服务类：RDS 连接数、慢查询数量、SLB 后端服务器健康状态、Redis 内存占用。这些直接关系到业务能不能正常使用。
- 费用类：账户余额不足、月度消费超预算、某类资源计费异常增长。容易被忽略，但一旦漏掉，影响往往不小。
配置阿里云预警的五个步骤
以下以云监控（CloudMonitor）为例，思路基本适用于大多数场景。
- 先列出关键资源。把生产环境里真正影响业务的东西挑出来，比如核心网关、订单数据库、文件存储。第一轮不必全部覆盖，先保住最重要的几项。
- 设置联系人和联系组。在云监控里维护联系人，按职责分组：运维组收基础设施告警，业务开发组收应用层告警。否则所有消息都打给同一个人，很快就没人看了。
- 创建规则并设定阈值。比如 CPU 使用率连续 5 分钟超过 80% 触发，磁盘使用率超过 85% 触发。阈值尽量参考历史峰值，别凭感觉定一个数。
- 选择通知渠道。紧急事件走短信，日常提醒走钉钉或企业微信机器人，周报类汇总走邮件。如果已有自建运维平台，可以通过 Webhook 接入。
- 每月复盘一次。查看告警记录，算一下误报和漏报。某条规则一个月响了几十次却没有真实问题，就该调阈值或时间窗口。
案例一：磁盘预警救了一次数据库
某电商团队的订单服务跑在一台 ECS 上，数据库和日志写在同一块系统盘。最初只配了 CPU 和内存预警，没有磁盘预警。一个周末，业务量上涨，加上日志没有轮转，磁盘使用率两天内从 60% 一路涨到 100%，MySQL 无法写入，服务停了。
复盘后，团队在云监控里补上磁盘使用率预警，阈值设为 80%，又加了一条增长速率规则：一小时内增长超过 5% 就通知。之后遇到类似的日志异常，预警在使用率还没到 85% 时就响了。运维有足够时间清理日志、扩容，订单没有受影响。
磁盘这类指标只看绝对值，往往太晚。加一条增长速率，能更早察觉不对劲。
案例二：费用预警避免月底超支
一家中型 SaaS 公司的测试环境在迭代期间频繁创建资源，部分压测机器忘了释放。财务月底对账时才发现，当月费用比预算高出近三成。
之后团队在费用中心设置了月度预算提醒，分别在预算的 70%、90% 和 100% 三个节点通知项目负责人，同时给测试资源打标签，按项目统计消费。下一个月，消费到 90% 时系统就提前发了通知，团队及时释放了闲置实例，费用落在预算以内。
费用问题暴露得越早，留给处理的时间就越多。
几个容易踩的坑
第一，所有指标用同一个阈值。数据库和前端静态服务的合理水位不一样，要分开设。
第二，只配通知，不配处理流程。谁接、多久响应、响应不了怎么升级，提前约好。不然告警发出去，每个人都以为别人在处理。
第三，资源下线或更换后，旧规则没有清理。它会持续发无效通知，时间一长，团队对所有告警都会麻木。
阿里云预警本身不复杂，难的是长期维护。先从磁盘、CPU 和费用这三类最常见的风险做起，阈值别拍脑袋，通知对象定清楚，然后根据每月的告警记录慢慢调。
