大多数的事故来源于变更,这句话并不是妄言,而且确实是具有统计学意义的。在持续集成的过程中,一次发布对应的是一系列的变更,而变更意味着从一个已经稳定的状态切换到一个仅预期稳定的状态,这就导致了线上风险实际是在降低的。为了防止最终的发布的效果与预期不符,造成事故产生,除了对变更内容做业务功能上的测试之外,还需要考虑很多事情,比如分析变更影响到了哪些上下游业务跟服务性能,变更的时间是不是业务的高峰期,变更的行为是不是有更多的相关人员感知。充分考虑了这些因素,每一次变更发布才可以尽可能不产生事故或者事故的影响面被控制住。
对于一个业务而言,发布变更的方式有多种。占大部分的是代码变更,一个新业务的开发,老缺陷的bugfix,或是底层的技术优化,都需要代码变更来直接体现;其次是服务配置的变更,比如遇到特定feature关停或开放的场景,或是调整缓存/DB的容量,抑或是满足业务代码变更的需要,都需要通过配置变更的方式来体现。除这两个大头之外,数据变更也同样是占据一定比例的变更方式。数据变更主要场景有如下几块: