在项目日常开发过程中，批量刷数也是有一定频率的变更场景之一，同时也是容易产生风险的一种变更操作。本文就来聊下，批量刷数的发布需要经历哪些流程，以及流程中每个环节中有什么风险点需要考虑。
首先需要了解批量刷数这个操作是个什么意义。无论是新增/删除一些数据也好，还是UPDATE某些已有线上数据也好，其背后要么对应着一个新业务开发，要么对应着一个bugfix。因此，批量刷数的本质其实就是一个业务需求，需要有完整的一套需求评审 -> 技术评审 -> 线下测试 -> 线上发布 -> 发布验证的过程。
第一个环节是需求评审。需求评审的主要的目的，一是为了做刷数的可行性评估，二是做刷数记录归档。
由于刷数的时间长&难以回滚的特性，不到万不得已的情况下，修复问题或是开发新需求，一般是不需要刷数操作的。如果需要做刷数操作，那么就需要提供需求背景信息，以及为什么一定需要刷数操作来达到需求目的，这样，从PM和TL角度，可以初步评估刷数的必要性，以及是否有更好的workaround。如果需要做刷数，那么这个需求就可以被归档到特定的业务模块里，以方便做进度跟踪和方案回溯。更甚者，如果需求管理平台自带流程管理和审批功能，那么在发布过程中，许多review跟审批操作都可以统一收敛到需求管理平台当中，这也是符合业务习惯的一种落地方式。
之后第二个环节便是技术评审。技术评审是整个批量刷数过程中最为重要的一环，因为在这一阶段，就必须考虑到整个刷数过程需要如何操作，上线分怎样的步骤，以及出现问题如何止损，刷数正确性如何验证。就规避风险而言，具体有需要考量以下点：
- 上下游关系：厘清刷数DB/服务涉及的上下游业务链路，尤其留意刷数操作触发下游数据同步/消费任务的场景时，引发过高并发/QPS的问题。除了确认上下游链路的完整性跟合理性外，还需要通过历史运行数据，估算一个合理的并发度。
- SQL影响面：DML场景下需要有EXPLAIN分析影响行数/命中索引情况，DDL场景下留意主从同步延迟给业务带来的影响。必要时，拉DBA做性能跟风险评估。
- 结果验证：在业务层面，需要如何验证刷数的效果，需要周知哪些负责人，如何确认数据有效性。这里尤其建议，测试/对账方案的评估过程，以及实际上线/刷数后验证的过程，强制QA介入，防止产生业务质量风险。
- 操作手法：刷数是一次性操作还是分批操作，选取的case覆盖哪些，分批和观察的节奏如何，如何验证刷数的正确性
- 过程监控：刷数期间，需要关注哪些业务和性能监控指标，监控告警需要知会到谁，级别如何
- 回滚止损：如果刷数操作不符合预期，怎样快速回滚，避免出错后因为缺失回滚方案导致二次犯错风险
技术评审之后是线下测试。线下测试最基础的保障是业务功能正常，但这里有一个风险是，线上刷数的量，相对于线下测试的量，实际是多得多的。像是SQL未命中索引、以及下游MQ堆积消费之类的操作，在线下测试时期，大概率没有办法暴露出来。而考虑到刷数需求的紧急程度，一般也很难紧急构造很重量级的数据跟上下文来还原线上场景。因此业务层面，规避这类风险的一个方法是，在技术评审环节去评估哪些问题是小数据量测试时无法暴露的，并在线下测试环节中给予一个复查checklist兜底。
线下测试完毕之后，就到了线上发布环节，这其中有几点需要考虑。首先是选择发布的时段，一般而言需要在上下游业务的非高峰期发布，以及非节假日发布，会比较保险。其次是发布的上线审批环节，除了选定合适的审批人操作外，操作的信息以及后续发布过程的信息，需要周知到上下游关联人。之后是发布的节奏，一般采取分批次发布的方式，比如先按业务用例最小集刷10个以内的数据量，然后刷20%左右，最后刷剩下80%。分批发布过程中，需要有足够的观察时间，防止发布过程中出现异常但来不及回滚。
线上发布的风险，除了来源于方案设计层面，操作层面的风险也不可避免。如果数据量大，刷数并发QPS过高，那么很容易引发下游的问题。因此建议每一批次发布操作实际发起时，有另一人知会或者review操作细节。如果出现不符合技术方案的操作，也可以及时阻止。同时，发布过程中的业务/性能监控信息，上下游/DBA负责人也有义务一起关注，要关注的信息点，也需要在发布前的方案里，做好详细分工。
线上发布过后，就是最终的测试验证跟对账了。这里尤其注意的是，验证和对账操作，在小批次发布的时候，就可以进行操作，或者是做成实时化巡检的形式，便于及时验证发布可靠性，也能够满足某些定时刷数任务的需求。
总的来说，刷数操作，从需求提出到发布完成，整个过程是非常紧凑跟紧张的。但最重要的一点，还是得保证刷数的稳定性，即便可能会有时间层面的损失。沉淀一套刷数流程SOP，归纳可能的风险点跟处理方案，能够有效提升刷数操作的规范性跟稳定性。以刷数流程为指导，同样也能保证发布的效率，也能规避到中途出现意外的情况下，不知如何处理，导致发布脏数据或者更大的事故影响。