大多数的事故来源于变更，这句话并不是妄言，而且确实是具有统计学意义的。在持续集成的过程中，一次发布对应的是一系列的变更，而变更意味着从一个已经稳定的状态切换到一个仅预期稳定的状态，这就导致了线上风险实际是在降低的。为了防止最终的发布的效果与预期不符，造成事故产生，除了对变更内容做业务功能上的测试之外，还需要考虑很多事情，比如分析变更影响到了哪些上下游业务跟服务性能，变更的时间是不是业务的高峰期，变更的行为是不是有更多的相关人员感知。充分考虑了这些因素，每一次变更发布才可以尽可能不产生事故或者事故的影响面被控制住。
对于一个业务而言，发布变更的方式有多种。占大部分的是代码变更，一个新业务的开发，老缺陷的bugfix，或是底层的技术优化，都需要代码变更来直接体现；其次是服务配置的变更，比如遇到特定feature关停或开放的场景，或是调整缓存/DB的容量，抑或是满足业务代码变更的需要，都需要通过配置变更的方式来体现。除这两个大头之外，数据变更也同样是占据一定比例的变更方式。数据变更主要场景有如下几块：
- SQL发布：对DB既有数据做SQL变更
- 批量刷数：因新增/修复业务需要，对已有缓存/持久化数据直接做批量新增/修改/删除
- 数据同步：DB同步、异构数据迁移等行为
- 离线数据处理：以数仓存储数据为基础，运行数据同步/分析/生成任务，新增/修改/删除原有的持久化数据
相对于代码变更以及配置变更而言，数据变更的频率是相对较低，缺陷和事故的数量也不算挺多。但从缺陷/事故影响面的角度来看，数据类变更事故的影响是非常高的。数据类变更产生事故的形式是非常多样的，最典型的几种情况比如：
- SQL发布：DDL类语句造成主从同步延时影响DB可用性；UPDATE语句错误圈选数据导致出现预料之外的更新
- 批量刷数：刷数逻辑错误导致大面积脏数据；业务高峰期批量刷数导致DB负载过大；慢查询导致DB负载过大
- 数据同步：同步速率设置不合理导致写入侧DB压力或消息积压
- 离线数据处理：误操作数据处理任务导致数据重置
这些情况，除去SQL发布场景，其它场景变更的时间实际是非常长的。时间漫长，就意味着不仅变更量大，变更期间风险难以控制，且如果出了问题也难以回滚。再考虑变更行为，假设这类变更没有沉淀为需求的话，那么就很有可能出现在缺乏审核、周知跟测试/监控方案的情况下，做出量级较大的变更。也就是说一个产品可能不知不觉地，就出线上问题了，一回溯起来，才发现是私底下做了动作。
因此，管控数据类变更，也是做持续集成当中非常重要的一环，是必要的一个动作。除去开发者在风险意识层面做到谨慎发布外，如果一个业务体量够大，并且本身对线上稳定性有很高的要求，那么这类变更的流程规范是需要做起来的。而不是等到事故发生了，才去考虑这些东西。