团队在云上做事，多数时候盯的是前面：新功能什么时候上，流量能不能扛住，接下来要不要扩容。真出了问题，线索往往在身后。这里说的“阿里云后视镜”，就是借助操作审计、日志服务和云监控留下的历史记录，回头看系统之前发生过什么。与其凭印象猜，先看记录通常更快，也更不容易走偏。
为什么云上要留一面后视镜
云资源变化很快。扩容、缩容、改配置、调权限，每天都可能发生，而且很多操作不在同一个人手里。一个数据库连接数突然飙升，原因可能是上周发布时连接池参数改了，也可能是某个定时任务跑飞了。没有历史记录的时候，排查只能靠同事的回忆和群聊里的截图，慢不说，还容易漏掉关键节点。
阿里云的几项基础能力正好能把“过去”存下来。操作审计记录账号在控制台和 API 上做过的操作，日志服务负责集中收集应用和中间件日志，云监控保留指标的历史曲线。三者放在一起看，才算有一面像样的后视镜。单独拿出任何一项，都只能看到局部。
一个复盘案例
下面是一个示意性的案例，用来说明这套思路怎么落地。假设某电商团队在大促次日发现，订单服务偶尔超时，但监控大盘上 CPU 和内存都没有明显峰值。扩容的念头很自然，团队却先没动手，而是按时间顺序往回看。
- 在操作审计里按时间段筛选，发现大促前两小时有一次安全组规则的批量修改，由某个自动化脚本触发。
- 在日志服务里按请求链路检索超时记录，超时集中在访问某个内部接口的时段，而这个接口的调用方，正是被修改规则影响的服务。
- 回到云监控，对比规则变更前后的网络指标，丢包率在变更后明显上升。
原因最后落在脚本上：批量更新规则时，它误删了一条放行内网段的记录，部分请求只能走更慢的回退路径。团队修好脚本，又给关键安全组变更加上了审批和灰度步骤。整个排查用了不到一小时，每一步都有记录可查，复盘会上也没人再争“是不是那次发布的问题”。这类争论既耗时间又难有定论，后视镜的价值很大一部分就在这里。
把后视镜用得顺手
后视镜要真有用，得提前准备几件事。这些事都不复杂，但晚做的话，出事那天就补不回来了。
- 操作审计保持长期开启，并把日志投递到独立的存储里。否则账号被误操作，或者有人清理日志时，最需要的那段记录可能正好没了。
- 关键业务统一日志格式，至少带上请求 ID 和服务名。没有这两个字段，跨服务串联请求基本靠猜。
- 给核心指标设置合理的保留周期。大促、月结这类周期性事件需要回看整段历史，但无关紧要的明细没必要长期留存，存储费用也会跟着涨。
- 把常用的排查路径沉淀成查询模板，比如“按时间查审计”“按请求 ID 查链路”。下次出事时直接套用，不用每次从头摸索。
后视镜替代不了前挡风玻璃
回溯只能解释已经发生的事，擅长回答“发生了什么”和“为什么会这样”。它代替不了事前的容量规划、灰度发布和故障演练。稳妥的做法是两边都做：前面的路靠预案和测试铺平，后面的镜子靠审计和日志校准。出了问题，两边的信息能互相印证，判断就不容易跑偏。
如果你的团队已经在用阿里云，可以先花一个小时检查基础配置：审计是否开着，日志有没有统一格式，指标保留周期是否合适。这些设置在出事之前做好，排查时才用得上。
