不可变基础设施
§1摘要与结论
部署完成后的基础设施（服务器、网络设备、运行实例）不再被就地修改，任何变更都通过创建新版本并替换实例实现，从而把运行环境的实际状态锚定在经测试的制品上。
别名：immutable infrastructure、不可变服务器、immutable server、配置漂移防治 | 英文：Immutable Infrastructure | 类型：方法原则 / concept
§2局部关系图
§3原理 · 为什么
就地运维的隐患在于，环境会随时间累积无数未受控的小改动，逐渐偏离最初经过测试的状态。这种偏离通常不可见、不可复现，直到某次事故才暴露，而那时根因往往已经无法追溯。不可变基础设施的根本主张是：运行环境应当是可被替换的制品，而不是需要反复修补的活体。一旦部署完成就不再登录修改，所有变更先落到基础镜像或定义文件、经过测试，再以新实例替换旧实例。由此，环境的实际状态始终等于某个已知制品的状态，隐藏状态被消除，故障可复现、差异可审计、误操作或恶意改动难以长期潜伏。它把运维中大量依赖个人经验的修补动作，转化为可版本化、可评审、可重放的构建与替换动作，也让安全核查有了确定的比对基准。本质上，这是把『配置环境』转化为『交付制品』，让环境与代码一样进入受控的工程流程，从而以确定性和可审计性替代对个人谨慎的依赖。
§4机制 · 如何运作
从受测的固定镜像启动实例之后，不再运行配置管理工具对其做增量修改，因为那等于在运行环境里引入未经完整测试的变更。修复与升级先修改基础镜像并走测试流程，再滚动产出携带该变更的新实例，同时淘汰不含该变更的旧实例。需要跨实例保留的可变部分被外置：持久化数据放到共享存储或托管服务，运行实例本身尽量保持无状态，使得任意实例都可以被安全丢弃和重建。强制手段可以是自动化流程定期以受测状态覆盖未授权的改动，也可以是系统自身拒绝变更。也使环境的历史清晰可查，也让任何一次变更都有据可回溯与复现，从而在故障发生前就能识别出环境之间的差异。不可变性的强制力还体现在：它把『服务器当前是什么状态』这一原本模糊的问题，转化为『正在运行哪个受测制品』这一可精确回答的问题。当出现未授权改动时，可用自动化以受测状态覆盖，或由系统本身拒绝变更，使漂移无法长期存活。实例应尽量无状态，可跨实例保留的部分交给共享存储或托管服务，这样任意实例都能被安全丢弃并按需重建，重建过程也因此成为可反复验证而非偶发的操作。
§5工程 · 怎么落地
工程上应把实例当作一次性资源：重建优于修补，替换优于登录修复。把服务器与运行实例的定义纳入版本控制，变更走代码评审与自动化测试，使环境的演化像应用代码一样被管理。实例之间的差异应尽量少，且只来自其外部元数据或集中注册信息，避免每台实例都有自己的特殊状态。区分运行时无需保留的数据（如日志外送）与必须持久化的数据，后者用共享存储或托管服务承接。把从零重建作为常态演练，使重建路径始终可用；对遗留的手工运维环境，逐步以受测镜像替换而非原地改造，避免一次性推倒带来的风险。同时应把重建所依赖的镜像、依赖与配置一并版本化，确保重建过程本身也确定可复现。此外，可借助周期性重建或主动破坏实例的方式持续检验系统在无状态下能否自愈。围绕重建还应建立可运维的保障：明确实例从镜像到可服务的启动路径并尽量缩短，使替换足够快以支撑频繁发布；把需要保留的状态与可丢弃的状态清楚切开，避免重建时误删数据；为镜像与依赖保留可追溯的版本标识，使任意历史实例都能被复现。
§6权衡卡
重建与替换会带来成本与复杂度：实例启动时间、镜像存储、构建流水线能力都构成门槛；有状态数据无法随实例丢弃，必须外置，增加了架构约束与改造成本。
对遗留系统与手工运维环境，切换到不可变模型的迁移成本很高，往往只能渐进推进。
反例之一是只在部署那一刻不可变、之后仍以运维登录热修，于是重新陷入配置漂移；反例之二是把需要持久的数据留在实例本地，导致替换即丢失；反例之三是把镜像做得过大过杂，使每次重建都昂贵缓慢，最终团队因成本而放弃重建。
- 另一个张力是速度：安全补丁与工具升级需要显式重建镜像，若惰性积累则会延迟修复。
- 因此不可变原则必须与状态外置、瘦镜像和重建演练配套，否则只是形式上的不可变，实际仍会退化为手工维护的活体。
- 此外，不可变并不等于拒绝变更，而是要求变更走受控路径：安全补丁、依赖升级与配置调整都必须以新制品形式进入并接受测试，若缺少推动升级的节奏，缺陷修复会被拖延。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8信源与核验
核验结论：术语 Immutable Server 由 ThoughtWorks 的 Ben Butler-Cole 命名；Netflix 是该模式最早的实践者之一（AMI/Aminator），并非命名者 [WEB-034]
§9原始关系清单
展开：本节点的全部原始关系边（2 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 促成 | → ESS-J-04 | 部署即变更管理 E-523 | 不可变与可追溯制品使部署成为受控变更 |
| 前置依赖 | ← ESS-J-01 | 构建发布运行分离 E-522 | 运行阶段无变更入口是基础设施不可变的基础 |
附对照资源 · 12factor 子库
| 12factor 节点 | 关系 | 对照说明 |
|---|---|---|
| 进程 app-processes | 跨体系对照 | 无状态进程即以可替换的实例承载运行，对应不可变基础设施与容错 |
| 可处置性 app-disposability | 跨体系对照 | 快速启动与优雅终止服务容错；进程视为可丢弃的不可变实例 |
| 启动/暂停/恢复 ag-pause | 跨体系对照 | 启动/暂停/恢复的生命周期管理对应容错与可替换实例 |
| 无状态 Reducer ag-reducer | 跨体系对照 | 无状态 reducer 以不可变演算（state,event)→state 保持单一事实源 |
| 生命周期与可处置性 t-disposable | 跨体系对照 | 进程可处置与 Agent 可暂停恢复本质同源，指向容错与不可变实例 |
| 12factor.net 站点源码 tool-app-site | 案例印证 | 12factor.net 站点自身是 App 原则的参考实现（不可变静态构建）与文档化载体 |