网络值班手册：SOP 与容量复盘
把前面所有知识固化成别人也能照着执行的流程，这才是工程师的产出物。
学完这节你能做到
- 写出一份别人能照着执行的网络故障处置 SOP
- 主持一次不追责的网络故障复盘
- 建立变更前的检查清单与回滚方案
前面 49 节的落点在这里
前面所有内容教的是你怎么查网络问题。这一节讲怎么把它变成团队的能力。
区别很实际：你会查，意味着你半夜必须被叫起来。 写成别人能执行的流程，才算真正解决了问题。
工程师的最终产出物不是"我修好了"，而是下一个人也能修好。
SOP 长什么样
一份能用的 SOP 有三个特征：能照着敲、有判断分支、有升级出口。
以「重传率告警」为例：
告警：TCP 重传率 > 1% 持续 5 分钟，节点 node-17
① 确认范围（2 分钟）
- 只有这个节点，还是同机架/同交换机都有？
看板：按节点的重传率热图
- 只有这个节点 → 走 ② 单机路径
- 一片节点 → 走 ③ 网络路径，并升级到网络组
② 单机路径
ethtool -S <dev> | grep -E 'missed|no_buffer|crc'
nstat -az | grep -iE 'retrans|timeout|overflow'
→ rx_missed 增长 = CPU 侧跟不上，查队列数与亲和性
→ rx_crc_errors 增长 = 物理层，报修光模块/线缆
→ ListenOverflows = 应用消费不过来，找业务方
③ 网络路径
- 同交换机的多个节点都有 → 交换机上行拥塞或链路故障
- 升级给网络组，附上：受影响节点列表、开始时间、重传率曲线截图
④ 升级条件（满足任一）
- 30 分钟内无定位
- 涉及硬件报修
- 影响面扩大到多个机架
很多人写的 SOP 是一串命令。这不够——值班的人不知道看到什么该怎么走。
真正有用的部分是那些 → 箭头：看到 A 就做 B。
把你脑子里的判断过程写出来，SOP 才能替代你。
一个检验方法：让一个没查过这类问题的同事照着走一遍。 他卡住的每个地方，就是 SOP 缺的判断分支。
分层排障：先便宜的，后贵的
工具是有成本的，按成本从低到高用：
| 层级 | 手段 | 成本 | 什么时候用 |
|---|---|---|---|
| 1 | 看板 | 几乎为零 | 永远先看，一眼定范围 |
| 2 | 计数器（ethtool -S、nstat） | 低 | 定层 |
| 3 | 路径工具（mtr、ss、ip） | 低 | 定位具体跳数/连接 |
| 4 | 抓包 | 中（有性能影响） | 前三层定不了性质时 |
| 5 | eBPF 追踪 | 较高（要会写） | 内核内部行为 |
| 6 | 复现实验 | 高（要资源） | 性能类问题的最终手段 |
最常见的错误是直接跳到第 4 层。 故障时第一反应抓包， 结果抓了 10GB 包，问题其实在看板上一眼就能看出是某台交换机上行满了。
顺序反过来的代价：抓包本身也可能加重故障（L4 观测那节
提过要给 tcpdump 加资源上限）。
变更管理：网络故障的一半来自变更
统计上，绝大多数"突发"网络故障都能追到一次变更： 策略改动、路由调整、固件升级、MTU 修改、扩容加节点。
所以排障的第 0 步不是敲命令，而是问变更：
# 有变更记录系统就查系统；没有就先查这些
kubectl get events -A --sort-by=.lastTimestamp | tail -30
journalctl --since '2 hours ago' | grep -iE 'link|bond|network'
git log --since='1 day ago' --oneline # 网络配置仓库这一步平均能省掉一半的排障时间。
变更清单要覆盖三件事：
| 阶段 | 必须有 |
|---|---|
| 变更前 | 影响面评估、回滚方案、当前状态快照 |
| 变更中 | 分批（先一台）、每批后验证、双人在场 |
| 变更后 | 观察窗口、关键指标对比、变更记录归档 |
「当前状态快照」很容易被跳过，但它是回滚的前提：
# 改之前先存一份，回滚时才有依据
ip addr show > /tmp/before-ip.txt
ip route show table all > /tmp/before-route.txt
iptables-save > /tmp/before-iptables.txt
ethtool -S bond0 > /tmp/before-counters.txt最常见的假回滚方案就是这四个字。它在两种情况下会失效：
- 改了才发现不可逆：固件降级不一定支持、conntrack 表清空后连接已断
- 回滚本身有影响：改回 MTU 会让已建立的连接再次中断
所以回滚方案要写具体：执行什么命令、需要多久、会不会再断一次业务。 如果答案是"不确定"，那就不该在业务高峰做这次变更。
复盘：不追责，但要有改进项
复盘的目的是让这类故障不再发生，不是找出谁的错。 一旦变成追责，下次就没人愿意如实说时间线了——而时间线是复盘最有价值的部分。
一份复盘包含四块：
① 时间线（客观事实，不带评价）
14:02 变更：更新 NetworkPolicy
14:07 监控：策略拒绝速率突增 8 倍
14:19 用户报障（比监控晚 12 分钟 ← 这是个改进点）
14:31 定位：新策略缺少 DNS 出向规则
14:35 回滚，恢复
② 影响面
持续 33 分钟，影响 X 个服务，Y% 请求失败
③ 根因（技术层面，往下追到能被修的那层）
直接原因：策略未放通 53/udp
深层原因：策略变更没有 CI 检查，也没有先在预发布验证
④ 改进项（必须有责任人与时间点）
- 策略变更加 CI：校验 DNS 出向规则 @someone 两周内
- 策略拒绝速率突增配告警（现在只有看板） @someone 本周
- 值班 SOP 加一条「先问变更」 @someone 本周
判断改进项好不好，看它能不能被验证完成：
| 写法 | 问题 |
|---|---|
| ❌ 加强变更评审意识 | 无法验证是否做到 |
| ❌ 提高监控覆盖率 | 覆盖什么？多少算够？ |
| ✅ 策略变更 CI 增加 DNS 规则校验 | 能验证：CI 里有没有这条 |
| ✅ 拒绝速率突增配告警，阈值 3× | 能验证：告警规则存在且测过 |
上面那条「用户报障比监控晚 12 分钟」也是典型改进点—— 监控发现得比用户晚，等于没有监控。
容量复盘：两种"用尽"要提前量
容量问题的特点是到了才发现，而那时来不及。 两种资源必须定期盘：
| 资源 | 用尽的表现 | 提前量 | 怎么盘 |
|---|---|---|---|
| 交换机端口 | 新机器上不了架 | 至少一个采购周期（数月） | 按机架统计已用/总数 |
| IP 地址 | Pod 起不来、ContainerCreating | 一个季度 | 按网段统计分配率 |
| conntrack 表 | 新连接随机失败 | 实时告警即可 | 水位监控 |
| 上行带宽 | 高峰丢包、重传上升 | 一个季度 | 峰值利用率趋势 |
# Pod 网段的分配率（简化算法：已分配 Pod 数 / 网段容量）
kubectl get pods -A -o wide --no-headers | awk '{print $7}' | grep -c '^10\.'
# 每个节点的 Pod 数上限与当前值
kubectl get nodes -o custom-columns=\
'NAME:.metadata.name,MAX:.status.allocatable.pods'IP 规划那节 说过：Pod 网段的 nodeCIDRMaskSize
决定了每节点能起多少 Pod，而这个值改不了——改就要重建集群。
所以容量复盘要盯的不是"现在还剩多少"，而是按当前增速什么时候用完：
当前分配率 62%，季度增长 11% → 约三个季度后触顶
→ 现在就该规划第二个网段/第二个集群，而不是等到 95%
端口同理：等到机柜插满才去采购，交货周期就成了业务瓶颈。
值班交接：三句话
交接不需要长文档，但这三项不能少：
| 项 | 例子 |
|---|---|
| 未闭环的事 | node-17 光模块已报修，备件明天到，暂时摘流量 |
| 待观察的事 | 昨天调了 bond1 的队列亲和性，重传率在降，继续看 |
| 今天的变更窗口 | 20:00 交换机固件升级，网络组主导，我们只需盯监控 |
「未闭环」这一项最重要——它是唯一会被漏掉的信息。 告警和看板下一班能自己看到，只有"我知道但还没记录"的事会丢。
检查点
一份 SOP 里最有价值的部分是什么？
收到网络故障告警后，第 0 步应该做什么？
容量复盘时，Pod 网段该盯哪个数字？
这节课的落点
- 工程师的产出物不是"我修好了"，而是下一个人也能修好
- SOP 的价值在判断分支（看到 A 做 B）与升级出口，不在命令列表
- 排障按成本从低到高：看板 → 计数器 → 路径工具 → 抓包 → eBPF → 复现
- 第 0 步是问变更——大多数突发故障都能追到一次变更，这一步省一半时间
- 变更三件套：影响面评估、回滚方案、状态快照；回滚方案不能写"改回去"
- 复盘不追责，但必须有能被验证完成的改进项与责任人
- 「监控发现得比用户晚」本身就是一个改进项
- 容量复盘盯触顶时间而不是剩余量；端口要留采购周期，IP 网段掩码改不了
- 交接必说未闭环的事——那是唯一会丢的信息