状态：已整理 (2026-10-16)。 仅根据前五篇中确认的事实进行归纳。各篇的依据与局限性详见各篇原文。
目录
1. 看不见的标签与默认值
五起事故中有四起始于无人刻意设置的值。
| 事故 | 悄悄改变行为的事物 | 谁决定的 |
|---|---|---|
| 公网连接 | 控制平面上的 exclude-from-external-load-balancers 标签 |
kubeadm 安装时自动添加 |
| GPU | 开启自动更新，关闭自动重启 | Ubuntu unattended-upgrades 的默认值 |
| DNS | 最初制定的策略中的 matchPattern: "*"，以及 * 规则（不跨越小数点） |
初始设计 / Cilium 的模式规则 |
| 批量网关 | \b 规则（在逗号后匹配） |
正则表达式引擎 |
它们的共同点是 不显示在屏幕上。节点列表的默认输出中看不到标签，更新日志中不会写着“不重启”，策略仅凭外观看起来冠冕堂皇，正则表达式也很短。因此，在选择某些内容（广告节点、模式、正则表达式）时，需要养成 先展开查看其标签和默认规则的习惯。 kubectl get nodes --show-labels、配置文件中被注释掉的默认值、产品文档中的“通配符”章节、正则表达式的边界规则，就是这种“展开查看”。
2. “绿灯”与实际状态
每起事故中都有表示“没问题”的信号。并且这些信号并没有说谎， 只是观察范围太窄了。
- 集群内部发往网关的请求确实成功了，只是没有检查路由器与广告节点之间的情况。
- 节点确实处于 Ready 状态，自动更新也确实成功了，只是没有查看内存中的内核模块。
unchanged确实是“没有什么需要更改的”，只是读取的文件已经过时了。- 密钥网关确实通过了，只是没有查看存放数值的文件夹。
- 排查凶手时确实不知道凶手是谁，只是没有查看失败提示中的
.js路径。
同一周里，在部署工具的文档中也看到了类似的情况。ArgoCD 文档曾写道，在 CronJob 的任务运行期间状态为“Progressing”，但内置检查在此期间会给出“Healthy”。我们提交了文档与实际不符的 Issue，并于 2026-10-15 关闭并完成 —— argoproj/argo-cd#30209。如果不知道绿灯是根据什么点亮的，绿灯就什么也说明不了。
因此，我们决定这样做： 从产出物一侧进行确认。 是否部署成功不看流水线的绿灯，而是看运维产出的文件；策略是否更改不看 apply 的输出，而是看集群中重新读取的值；网站是否能打开从外部而不是内部进行观察。
3. 人工职责与自动化的边界
这周工作停滞的地方，大部分都在边界上。
| 工作 | 为什么是人工职责 | 在边界处卡住的事项 |
|---|---|---|
| 重启 GPU 节点 | 会中断同一节点的其他服务。时间和影响范围需由人工决定 | 连续三天无人知晓 |
| 应用实验性 DNS 策略 | 修改集群。可能会破坏实验 | 在一个月里只存在于仓库中 |
| 轮换凭据 | 使用该值的所有集成都需要一起修改 | 在轮换前，历史记录中的值依然有效 |
| 判断批量网关失败 | 机器无法对“不知凶手是谁”得出结论 | 机器重复运行了 26 次 |
自动化不能替代人工职责，但 将人工职责准确地移交给人工是自动化的工作。这次起效的移交是这样的形式 —— 一行原因、可直接复制的命令、受影响对象列表，以及用于确认“是否完成”的读取命令。相反，不起效的则是丢进仓库就结束的变更 —— DNS 策略在没有指定应用到集群的人员、也没有指定用来查看是否应用的命令的情况下，度过了一个月。移交的工作必须附带 确认命令和期限，而未被确认的移交必须作为“等待应用”显眼地保留下来。
4. 用测试将修复结果锁死
防止修复过的问题再次损坏的方法是测试。然而这周也向我们表明了： 测试也会出错。
- 在添加凭据网关之前，我们先看到了修复前分支上有 13 处变红。这个顺序是对的。
- DNS 策略的测试只检查了策略字符串的 外形。因此，导致非预期行为的模式（
*.cluster.local）通过了。测试必须断言诸如“这个名字通过，那个名字拒绝”之类的 语义。 - 商标检查是一项防范测试，但它把数字里的
729误认为成了商标。防范测试也需要有“这些绝对不能被抓到”的示例。
总结一下，每次添加测试时要确认三点：① 修复前是否变红，② 修复后是否变绿，③ 在不该被抓到的示例中是否变绿。
5. 下次事故前要用的检查表
- 在选择对象之前，是否展开查看了标签、默认值和通配符规则？
- 是否在产出物一侧（外部、集群中重新读取的值、运维产出的文件）确认了“可行”？
- 应用命令所读取的文件是否来自远程 main，
kubectl diff是否不为空？ - 在开启自动更新的节点上，需要重启的软件包是否会悄悄安装？
- 如果仓库中包含密钥，是否进行了轮换（仅从文件中删除是不够的）？
- 移交给人工的工作是否附带了命令、影响范围、确认命令和期限？
- 新测试在修复前是否变红，在不该被抓到的示例中是否变绿？
- 如果发生相同的失败两次，是否会暂停并让所有人看见？
TT 的简短感言。 摔了五次跤之后发现，摔倒的地方都差不多：看不见的默认值、视野狭窄的绿灯、无人认领的工作，以及只看外形的测试。下次开始前先打开检查表！
参考
所有资料均于 2026-10-16 查阅。
- 本周提交的文档 PR 与 Issue： https://github.com/metallb/metallb/pull/3156, https://github.com/NVIDIA/cloud-native-docs/pull/524, https://github.com/argoproj/argo-cd/issues/30209
- 各起事故的依据见本系列第 1~5 篇的“参考”。