一、故障排查方法论：从现象到根因的5步排查法
做SRE这些年，我最大的体会是——故障排查不是玄学，是科学。
很多人遇到线上问题就慌了，东看看西看看，最后靠运气解决问题。说实话，我刚入行时也这样。有一次日志系统突然延迟飙升，我折腾了整整一个通宵，最后发现只是磁盘IO被打满了。嗯，从那以后，我总结了一套自己的排查方法。
今天要聊的，就是这套「从现象到根因的5步排查法」。说白了，就是让你遇到问题时，能像老司机一样，有条不紊地找到问题根源。
1.1 五步排查法详解
我个人习惯把这五步记成：看、定、猜、验、修。好记，也好用。
- 看（观察现象）：收集所有能收集到的信息
- 定（定义问题）：把模糊的抱怨变成可量化的指标
- 猜（提出假设）：基于经验列出可能的根因
- 验（验证假设）：用数据说话，别靠感觉
- 修（修复验证）：修复后确认问题真的解决了
核心原则：每一步都要有数据支撑，不要凭感觉做决策。
我在项目中遇到过很多次，明明问题已经解决了，但监控图上还是异常。为什么？因为修复动作本身可能引入了新问题。所以第五步「修」之后，一定要持续观察一段时间。
1.2 实战案例：日志延迟飙升
举个例子。有一次线上告警说「日志写入延迟超过5秒」。我们来看看怎么用五步法排查。
第一步：看
- 延迟从3秒飙到了15秒
- CPU使用率80%
- 磁盘IO等待时间升高
- 网络带宽正常
第二步：定
- 问题定义：日志写入P99延迟从3秒升至15秒，持续超过10分钟
- 影响范围：影响了3个核心业务模块的日志采集
第三步：猜
- 假设1：磁盘IO达到瓶颈
- 假设2：日志队列堆积导致背压
- 假设3：网络抖动导致写入失败重试
第四步：验
- 检查磁盘IO：iostat显示磁盘利用率已达95%
- 检查日志队列：队列长度从1000涨到了50000
- 检查网络：延迟正常，排除网络问题
第五步：修
- 临时方案：扩容日志写入节点，增加并行度
- 长期方案：优化日志写入逻辑，增加缓冲机制
- 验证：修复后观察30分钟，P99延迟降至2秒
避坑指南：我曾经犯过一个错误——修复后只看了一眼监控就下线了。结果第二天发现，修复方案虽然解决了延迟问题，但导致了日志丢失。所以修复后一定要做完整的回归验证。
二、如何定义SLA与SLO
聊完排查方法，咱们来说说SLA和SLO。这两个概念，说白了就是你和用户之间的「契约」。
很多团队一上来就拍脑袋定SLA，比如「我们保证99.9%可用性」。但你想想看，这个数字是怎么来的？有没有数据支撑？
2.1 SLA vs SLO vs SLI
先理清三个概念：
| 术语 | 全称 | 含义 | 举例 |
|---|---|---|---|
| SLI | Service Level Indicator | 你实际测量的指标 | 日志写入延迟P99 = 3秒 |
| SLO | Service Level Objective | 你给自己定的目标 | P99延迟 ≤ 5秒，99.9%的时间 |
| SLA | Service Level Agreement | 你向用户承诺的底线 | P99延迟 ≤ 10秒，否则赔偿 |
我见过最典型的错误是：SLA定得太高，结果天天赔钱。或者SLO定得太低，用户天天投诉。
2.2 如何科学定义SLO
我个人习惯用「三个数据点」来定SLO：
- 历史数据：过去30天的P99、P95、P50指标
- 用户感知：用户能接受的延迟上限是多少
- 成本考量：要达到这个SLO，需要多少资源
黄金法则：SLO要比SLA严格，给自己留出缓冲空间。
比如：SLO定99.9%，SLA就定99.5%。这样即使偶尔超出SLO，也不会触发SLA赔偿。
2.3 日志系统的SLO定义示例
拿我们的低延迟日志系统来说，我建议这样定义：
# 日志写入SLO
- SLI: 日志写入端到端延迟（从产生到可查询）
- SLO: P99 ≤ 5秒，99.9%的时间满足
- 测量窗口: 滚动30天
# 日志查询SLO
- SLI: 日志查询响应时间
- SLO: P99 ≤ 2秒，99.5%的时间满足
- 测量窗口: 滚动7天
# 日志持久化SLO
- SLI: 日志写入后不丢失的概率
- SLO: 99.999%的日志持久化成功
- 测量窗口: 滚动30天
注意：SLO不是一成不变的。随着业务增长，SLO需要定期review和调整。我每季度都会做一次SLO复盘，看看哪些指标需要收紧，哪些可以放松。
2.4 故障排查中的SLO应用
回到故障排查的场景。当你收到告警时，第一件事不是修，而是判断：这个故障是否触发了SLO？
如果触发了SLO，那就是P0级故障，需要立即响应。如果没触发，可以按常规流程处理。
我曾经遇到一个案例：日志延迟从3秒涨到8秒，团队立刻拉群开会。结果一查，SLO定的是10秒，根本没超。白白浪费了大家的时间。
所以，SLO不仅是给用户的承诺，也是给团队的「定心丸」。知道底线在哪里，就不会过度反应。
三、知识体系总览
最后，我用一张图来总结本章的核心内容。这张图展示了从故障发生到根因修复的完整链路，以及SLO在其中扮演的角色。
这张图把今天讲的内容串起来了。左边是五步排查法的流程，右边是SLO体系。中间用反馈循环连接——排查过程中，SLO是你的判断依据；修复之后，SLI是你的验证工具。
我的建议：把这五步法打印出来贴在工位上。遇到故障时，按步骤来，别跳步。我见过太多人直接从第一步跳到第五步，结果修了半天发现修错了地方。
好了，这一章就聊到这里。记住：故障排查不是靠运气，是靠方法。SLO不是摆设，是你的护身符。下次遇到线上问题，试试这五步法，你会发现——原来排查也可以这么从容。