第4章 变更管理

运维从诞生之初就和变更有很强的关联，过去所有的运维工程师谈到变更时都会说“变更是万恶之源”。在运维工程师看来，如果没有变更，线上就会少很多问题。导致变更的原因多种多样，但主要的类型有以下几个方面。

1.应用发布导致的变更

站在开发工程师的角度，因为产品迭代的开发压力，所以他们无时无刻都希望能快速地将自己的代码发布到线上生产环境。在传统运维模式下开发工程师认为只要代码开发完成，QA（Quality Assurance）软件质量测试确认，代码就可以直接发布了，如果出现问题也是运维工程师和QA的责任。运维工程师在这个过程中一般只扮演OP的角色，除非变更导致的故障太多，影响KPI时才会想到拒绝发布。发布变更经常让开发团队和运维团队形成意见冲突，有时候会闹得问题上升到需要一定级别的领导人拍板决策的地步，这种传统的变更决策机制很长一段时间内，在各个公司都存在过。这时候开发团队和运维团队对变更的目的从内心想法上还是基本一致的，稍微不一样的就是运维团队希望能控制变更导致的异常。

2.外部条件触发的变更

外部条件触发的变更一般是不可抗因素导致的变更，如一台服务器宕机、硬盘故障，或者是出现软件bug导致不得不执行重启回滚操作等。在这个方面开发团队和运维团队对变更的结果期望很多时候是相对一致的，都希望能正常执行变更，尽量减少对线上业务的影响。但在实际落地时，会发生针对故障场景，业务团队不太认可运维工程师给出的方案的情况。例如，服务器有 IO 硬件报错，运维团队可能给出的解决办法是：直接上一台新服务器重新部署应用后替换旧的问题节点。而业务团队可能会觉得重新部署应用太麻烦，希望能直接将旧服务器的硬盘插到新服务器上，不要重新部署。这样的案例可能有些人会认为过于夸张，但只要实际场景中业务团队的人员超过100人，这种案例肯定会发生，在开发团队和运维团队之间更多的是方案之争。

3.架构优化调整导致的变更

开发有代码重构，线上的业务在部署上有时也会面临重构的需求。例如，用Keepalived软件实现VIP（虚拟IP）方案时要换成服务发现和Apache Web服务器要换成Nginx等。有些操作是开发工程师发起的，有些操作则是运维工程师发起的。这类变更往往在执行时会有一定的争议，尤其当某个优化调整在另一方看来没有意义时争议会尤其明显。不知道大家是否经历过这样的场景，运维团队折腾半天想优化Nginx的配置，但变更要上线必须经过开发团队的测试确认，开发团队又忙于代码迭代，根本不想执行这样的变更。这种场景下开发团队和运维团队都可能有各自的变更诉求，相互依赖对方，但是又互相觉得对方的变更重要性不如当前在做的事情。

为了解决这些变更导致的开发团队和运维团队的争议，很多公司都会在内部引入变更管理流程。下面以发布变更为例，分析几种正在执行的变更管理机制。