先把影响范围画出来

一句话总结

进行任何变更之前，都必须能在纸上画出谁会受到影响、什么会受到影响。如果画不出来，就说明还没有准备好执行这次变更。

为什么需要它

以“只改一行配置就行”开头，最后却让服务停止的事故之所以反复发生，是因为没有人确认这一行会触及什么。在陌生系统中尤其如此：系统对我们是新的，对客户却可能已经运行了十年，其间积累了许多从未被记录的依赖。

描绘影响范围的四个问题

1. 谁会调用这个组件（上游） 即使只修改一个配置文件，也必须知道哪些系统会向该进程发送请求。访问日志中的源 IP 分布、ss -tnp 显示的连接对端、以及防火墙规则，都是线索。

2. 它会调用什么（下游） 变更结果可能把负载集中到下游。延长超时就是典型例子：我们以为只是留出了更多余量，下游连接却会因此被占用更久。

3. 是否共享状态 要确认是否还有其他系统使用同一个数据库、文件系统或缓存。共享状态很少被画进架构图，事故却常常发生在这里。

4. 什么时候安全 要考虑批处理运行时间、截止日期、结算日。即使技术上安全，时间选错也会造成事故。这一点只有询问客户才能知道。

先写回滚方案

变更计划的第一行不应是变更内容，而应是如何回滚。

변경:   /etc/app/config.yml 의 pool_size 10 → 30
백업:   cp config.yml config.yml.2026-08-20
되돌림: cp config.yml.2026-08-20 config.yml && systemctl reload app
확인:   curl -s localhost:8080/healthz 가 200, 에러율 5분간 관찰
소요:   되돌림 2분

如果能够明确写出“回滚：2 分钟”，这次变更才可以执行；写不出来，就说明时机未到。

预先确定观察窗口

变更后要观察到什么时候，应提前决定。只看 5 分钟就离开，那么 10 分钟后发生的问题会被排除在原因候选之外；但也不可能无限期守着，因此应明确写成“观察 30 分钟，关注三个指标：错误率、延迟、队列长度”。

在实际项目中

• 延长超时后，下游数据库连接耗尽 → 没有观察下游。
• 夜间部署时，结算批处理恰好正在运行 → 没有询问时间窗口。
• 想回滚时，没人知道原始配置 → 修改前没有备份。

接下来的实验要做什么

你将接手一个既没有架构图、也没有 Wiki 的客户系统。手头只有两个配置文件、访问日志、轮转设置和 crontab。

需要从这些材料中亲自找出上游、下游、共享状态与批处理窗口，并制定一个把回滚方案写在最前面的变更计划。评分器会故意修改配置，再运行你的回滚脚本，确认是否恢复到原始状态。