变更恐惧症的根源：运行与变更被人为分离

传统IT把变更看作风险（”永远不碰运行中的系统”），发布要经数月多轮测试，升级技术却往往没有对应的”业务案例”——这逻辑像认为不换机油能省钱，直到发动机卡死为止。更根本的问题是，很多IT组织把”运行”（运营）和”变更”（开发）当作两个分开的职责，这暗示运行软件不等于变更，结果就是没人主动改动系统、系统必然老旧成为遗留物。害怕变更是有原因的：这些组织通常缺乏密切观察产品指标、并在出问题时快速部署修复的工具、流程和技能，因此只能选择在部署前尽量测试所有场景，然后多少”盲目”地上线并祈祷不出问题。讽刺的是，这样试图”省钱”的组织反而要花费超过一半的经费维护”运行”，因为不稳定、扩展性差、缺文档的遗留应用运营成本极高，真正用于支持业务变更的预算所剩无几。

结构图：

flowchart TB
  A["变更=风险,永远不碰运行系统"] --> B["运行(运营)与变更(开发)职责分开"]
  B --> C["没人主动改系统"]
  C --> D["系统变老旧,成为遗留物"]
  D --> E["运营成本畸高(不稳定/扩展差/缺文档)"]
  E --> F["超一半经费花在维护'运行'上"]
  F -.留给'变更'的预算所剩无几.-> A