研发流程——变更流程管控

什么是变更？

狭义：根据需求、问题修复而创建的研发、联调、上线并引起线上变化的过程。
广义：对实际线上系统的任何变动、操作。比如：

1. 线上数据订正
2. 线上配置调整
3. 线上开关调整

我们理解变更有几个需要去考虑的点：
1）约束对线上的影响
2）以同等要求看待发布与线上变更
3）明确避免非管控的线上调整
4）最大程度提升线上的稳定性

研发变更和线上变更同等重要，但是他们之间又有一些很显著的差异：

研发变更

1. 周期性并计划性发布
2. 标准化流程与人员保障
3. 通常代码发布的过程
4. 确定性回滚方案

线上变更

1. 突然性和非计划性
2. 不在研发流程当中
3. 非代码发布性
4. 回滚不确定性

对于某些线上变更反而需要比研发变更要求更严格去关注，也就意味着它存在一定的风险，我们可以根据变更的一些行为和特点把它分成不同的风险级别。

• 高风险：可能会影响线上核心功能甚至导致故障
  对于高风险我们需要非常严格谨慎的操作，甚至需要把预案和回滚方案明确好。
• 中风险：可能会影响线上功能并且产生线上问题，进一步引发故障
• 低风险：常规性影响，一般不会导致问题发生。

所以将变更的风险进行分级有助于我们针对不同类型的操作、不同类型的变更进行相关流程的定制，从而进行风险的管控。

风险管控

这里我们就需要明确在变更前后到底有哪些行为是我们先要设定好、先要做好准备从而最大程度上降低风险。

变更前

1. 评估影响范围
2. 设定变更执行方案与计划
3. 设计相关预案
4. 明确预案、回滚执行的条件与时机。
5. 明确预案、回滚执行的方案与步骤

变更中

1. 做好充分的测试
2. 严格按照方案执行

变更后

1. 做好变更的验收
2. 进行持续监控
3. 一旦出现问题，进行预案与回滚的执行

相关人员

在管控相关过程中，我们还需要触达相关的人员，因为每一个变更都会牵扯的不同的人。
每件事情都是由变更需求方提出明确的需求后，都会有明确的开发方（架构师/项目经理/TL）去指定这个功能该谁开发，开发完成后由相关的变更执行人进行执行，最后由相关的验收方，他们会对整体的结果和功能看看是否达到预期。
当然，在变更执行过程中，可能还会有相关的变更审批人以及变更的受影响方。

所以从总体来看，变更包括我们整体对研发体系的支撑，因为它是整个研发体系里的源头，以及它是我们能够对线上产品不断优化和迭代的基础。同时它也是风险最大的环节。接近 40% 以上的线上问题都是由变更引起的。因此我们需要在变更中最大程度的把控和降低风险。
最终去明确出我们变更的流程，他需要严格的审批来确保我们所有的行为是在被监管范围下。
以及我们需要有一个明确的预设流程，来保证我们整体的行为是可控的。
当然上面所有的一切，都要确定我们没有触犯研发红线。
针对研发红线我们去细分的话，可以分为：

1. 未审批的线上修改
2. 管控期间的未审批发布
3. 越过流程直接操作
4. 未灰度的高危变更

这些都属于常规的红线范围，当然还会有很多，一个合适的红线是需要取决当前公司的规章制度、研发流程、员工水平以及线上产品的成熟度去综合制定的。