软件生产变更管理初探
一、基本概念
1.1 定义
变更管理是指对人员、技术、设施资源、操作流程等永久性或暂时性的变换进行有计划的控制，以避免减轻对安全生产的影响，保障系统SLA指标运行。
1.2 目的
为了规范研发与运维人员对生产环境的操作，消除或减少由于变更而引起的潜在事故隐患，加强对变更过程有计划的控制，避免或减轻对企业安全生产的影响，结合公司生产实际情况，制定研发生产变更管理流程。
1.3 适用范围
技术研发：负责日常生产迭代和系统优化等变更操作。
技术运维：负责业务参数相关配置操作
二、现状分析
2.1 生产问题根因分布
故障整理平台统计集团全量生产故障根因归类
2021上半年部门故障根因归类
总结：根据对生产故障的分析可以看出，由生产变更操作造成的生产故障占集团的12.20%，占部门的9.52%。对于这个高占比的风险点有必要进行管理，降低其风险系数，提升安全生产质量。
2.2 生产变更操作方式分类
总结：
问题一：目前来看生产配置推送是最大的风险点，配置更改没有审核卡点，完全靠人员自觉性，这是十分危险的。任何一个极端的念头都有可能造成无法估量的生产故障，安全生产的一个核心原则就是不能相信人。同时配置推送也是制造生产故障成本最低的环节，值得关注。
问题二：online工单都是与运维团队的交互留痕，一个online工单无法体现出一次生产变更的整个生命周期。比如服务器缩容，当有online工单到组长审批时，实际开发人员已经完成了机器下线等生产操作，最后的online缩容工单只是为了让基础运维回收机器而已，对于服务器下线这个变更没有完整的闭环流程，操作过程黑盒，缺少监控验收手段。
问题三：预发环境和生产环境即使无法做到物理隔离，但也要做到完全的逻辑隔离，即可以避免生产操作影响，也可以避免一些生产脏数据的处理。目前缺失预发变更的管控能力，如果真的做好全面的逻辑隔离，其实倒也可以不进行管理。
2.3 生产变更场景分类跟踪
跟踪周期：2021/12/13 -- 2021/12/17【部分数据设计公司敏感系统，故模糊处理】
分析：
总结：
问题一：对于每周二、周四晚间统一变更的习俗是否合理，在此提出疑问。同行业中目前只有银行还保持夜间变更的流程，且对银行类系统来说是有必要的，而对我们来说是否有必要却是一个未知数。
问题二：以上的变更跟踪数据是人肉统计，对于团队(C3/C2)内的整体变更情况缺少跟踪管理的途径。
三、支付产品生产变更流程规范
3.1 变更原则
任何发布都需要通过测试验证（含测试允许的自测），有回滚计划和灰度环节。
上线代码必须经过非本人外的研发人员code review，核心系统可选择多人。
发布过程或者发布完成后，服务端和测试必先留观30分钟以上；相关核心服务发布需要持续关注30分钟以上（监控和舆情），并提前通知发布关联方或受影响方；
资金类关键业务点上线前必先验证及分版本监控；
核心和敏感服务的数据库变更务必选择和业务低峰时间操作；
禁止一切未经变更授权和一切变更方案外的操作，必须严格按照变更方案执行
禁止非变更窗口（周二、周四为变更窗口）执行变更（紧急变更需要向上申请报备）
备注：上线过程建议使用三屏无脑原则进行发布，研发人员打开发布屏、监控屏、回滚屏三屏，如有异常直接操作回滚 。
3.2 丰富技术设计方案
所有的研发需求变更都要有对应的研发卡片（研发人员直接在团队空间下创建即可）和技术方案，并应通过组内评审（每周三举行的设计方案评审）。
业务需求变更应在技术设计方案中体现，需要明确评估变更影响范围、变更时间、操作人和复核人。变更结束后需在设计方案中补充验证截图留痕。
todoList ：上线前的所有前置准备公司以及上线步骤。
checkList：上线后的对应验证步骤，需要留下验证痕迹（比如截图）。
最坏影响分析：每个变更都要考虑影响范围，并说明监控方式和应急处置手段。
3.3 配置变更
统一配置推送在不具备线上审核的情况下，必须双人复核（A：提交人 , B：推送人）,且配置推送后要持续留观30分钟。
3.4 online工单变更
在online工单没有明确实现自动化验证能力的情况下，需尽量实现人工验证覆盖。
四、All IN Online
按照传统的生产变更流程来说，每次生产变更都需要填写变更工单并通过评审，但考虑到我们迭代周期的紧凑性，详细的变更申请工单投入太大，整个变更流程过重，但为了对生产变更进行有效管理，还需通过简单的流程进行变更管理。综合以上两种情况，建议所有的生产变更都通过online来管理，在online上建立本部门的生产变更类型工单，根据不同的变更场景填写必要的变更要素，其本质为了多思考变更的影响，统一控制变更节奏，降低变更的影响范围。
具体执行工单模式可参考下表：
我们目前最缺少的其实是变更前的思考，要多想影响范围，考虑到回滚机制，即使是一个很小的常规变更，也要有思考、思考、思考的过程。