替换而非打补丁
核心规则很简单：实例一旦开始服务就不再被修改。所有变更都经构建流水线产出新镜像，编排器用新实例替换旧实例。由于同一版本的每个实例完全一致，两台声称版本相同的服务器实际上也相同。回滚意味着部署上一个镜像，而不是逆向执行一串手工修改。
commit -> 构建镜像 (tag: sha) -> 测试 -> 部署新实例 -> 排空旧实例
回滚：部署上一个镜像 tag何时使用
适用于无状态服务、自动伸缩组和容器平台等实例可丢弃的场景。当集群规模大、合规要求明确知道运行内容、或者配置漂移已导致事故时，价值最明显。对单台长期运行的数据库服务器，完全不可变并不现实，应把该思想应用到其周边的计算层。
权衡
镜像构建需要时间，必须依靠缓存才够快。有状态组件要谨慎处理：卷会保留而计算被替换。调试方式从登录改文件变为复现构建。团队还需要镜像扫描与保留策略，否则镜像仓库会变成垃圾场。
示例与常见误解
某团队发现生产环境缺少一张 CA 证书。他们没有把文件复制到二十台服务器，而是修改 Dockerfile、重新构建并滚动发布，修复因此可评审、可重复。常见误解是认为不可变性也适用于数据：数据库仍有状态，需要自己的迁移策略。相关概念包括基础设施即代码、蓝绿部署与滚动部署。