上线发布规范
一、背景和定义
后台服务场景复杂，微服务的广泛使用，调用量不断增大，调用关系越来越复杂，强弱依赖的问题也导致故障的发生频次和影响更加难以控制。
上线发布作为日常高频动作，参与人员多，出错概率大，据统计80%的线上故障均和线上变更有关，规范的上线发布规范可以避免低级错误，减少故障发生。
影响线上服务运行的研发人员操作，均定义为【上线发布】，包括功能迭代的plus的发布、线上配置的修改、数据库的修改，技术后台操作等。
上线发布的项目 | 适用的规范 |
|---|---|
PLUS的发布 | 此上线发布规范的所有规则都需要遵守 |
配置修改 | |
数据库修改 | 发布红线、上线窗口、上线周知、紧急上线申请 |
二、上线发布红线
对线上发布始终保持敬畏之心，下列为严禁项
- 上线前，代码未经过团队内review
- 上线前，使用非master分支发布
- 上线前，上线方案不具备回滚性
- 上线前，未经过测试直接发布线上
- 上线前，未周知关键干系方
- 上线前，未申请或不在规定时间内发布
- 上线前，未经审批，直接对线上数据或配置变更
- 上线中，未灰度发布，或灰度时间低于10分钟
- 上线后，未进行线上验证
- 上线后，未进行有效的线上服务稳定性观察
- 上线后，留观时间低于30分钟
良好的底线意识是一个RD专业性的体现，对于触犯发布红线的，建议团队在绩效评定中予以负向考虑。
三、上线时间窗口
正常上线时间窗口 | 原则及说明 |
|---|---|
针对各业务特点，各团队可根据业务高峰期设定正常上线窗口。下面是建议的上线时间窗口： | |
• 周一至周四 | |
• 14~17点（17点前必须发完） | |
• 20点以后 | |
• （建议）每个服务每个时间段只有一次上线 | • 上线时间避开业务高峰期 |
• 上线时间要在正常工作时间 | |
• 周五及周末禁止上线，特殊情况下请走审批流程 | |
• 系统静默期间（重大节假日前三天，春节，国庆。普通假日前一天）禁止上线 | |
• 上线的功能为关键核心服务，且影响重大的，建议晚上8点以后上线 |
各系统负责人可根据各自系统特性及业务场景进行严格的调整。本着避免犯错的出发点，需要在plus发布系统里面开启发布禁止时间。
四、上线流程规范
上线必须使用MCM系统申请上线与审批、Plus系统进行实际灰度、观察服务稳定后、全量发布。
在功能开发、自测完成以后，走以下流程进行上线操作：
1、上线前准备
检查的checklist：（如不涉及，直接勾选完成）
上线前Checklist
- 与QA沟通后：需要QA测试的，回归测试/用例测试完成；需RD自测的，自测完成
- Code Review，指定的Approver均已通过（有多名Approver时，需要全部通过）
- 确定表结构变更、索引变更均已上线
- 确定上线内容对已有的缓存内容是否产生影响；如果有，要有保证数据一致性的方案
- 确定对于新域名已经申请完毕并解析配置上线成功
- 如对性能有影响的变更，确保压测报告已产出
- 确定给出了上线方案；多方协作时，要给出协作上线的顺序和步骤
- 确定给出了上线回滚方案；
- 已经大象群通知到受影响的业务方，并确认相关人员已经收到通知
- 已合并至master分支，准备发布
2、上线申请
在变更系统操作，发起上线申请。审核人通过后，可进行灰度发布。
有几个方面需要注意：
- 尽量选择在公司上线，且要保证上线观察（raptor和db、tair监控）30分钟后再离岗。
- 尽量选在有多名组内rd(>=2)都在岗的时间上线，防止出问题时，人手不足。
3、上线周知
上线申请通过后，即可开始准备上线发布。正式操作之前，首先需要在大象群里周知。
事项 | 说明 | 举例 |
|---|---|---|
周知范围 | 包括但不限于以下大象群，尽可能周知到需要知晓本次上线的范围： | |
• 服务上线周知群 大象 | ||
• 业务方相关的 大象 | ||
周知内容模板 | 【上线标题】：简要概述上线内容 | |
【上线内容】：业务名-上线内容说明 | ||
【测试验收】：测试验收结果，需要说明验收人及验收结果；自测通过写“RD自测通过”；QA测试通过写“QA测试通过；” | ||
【上线时间】：预估上线时间； | ||
【影响范围】：此次上线影响的范围或内容；如果直接或间接影响客户端，则以客户端角度阐述，比如“影响首页金刚区、顶通”、“影响登录/注册功能”；如果不影响客户端，则以服务角度阐述，比如“影响所有调用用户中心的服务” | ||
【联系人】 本次变更的负责人 | ||
【变更状态】 清晰描述当前变更的进展（包含但不限于 变更中/变更完成），同一个变更在状态变化是需要第一时间同步 | ||
【上线标题】：丛林金刚-共用位置需求 | ||
【上线内容】：丛林金刚-大交通及金融共用位置需求上线 | ||
【测试验收】：QA测试通过 | ||
【上线时间】：2019-01-03 15:30~16:30 | ||
【影响范围】：影响首页金刚区展示 | ||
【联系人】 小小 | ||
【变更状态】 变更中/变更完成 |
模版的要素：
1）需要有标题和内容，确保清晰的描述功能相关情况；
2）需要有测试验收情况和上线影响的说明；3）需要有上线时间说明，并在时间内完成上线动作；
4）需要有本次上线的负责人，确保异常发生时可以找到负责人解决问题；
5）需要有变更状态，清晰描述变更的进展；
4、灰度确认
建议发布工具（PLUS等）灰度第一批的默认时间调整为10分钟且第一批灰度观察时间不低于10分钟。
审批通过后，灰度发布时观察各项业务指标正常后，完成灰度确认环节。
如有异常，直接回滚，进行回滚相关操作。
灰度前注意检查集群是否配置独立liteSet，如有，考虑是否针对独立 liteSet单独灰度，以确保灰度能覆盖所有场景。
灰度确认
- 跟进QA、PM线上回归情况，没有测试资源介入的要自测回归。
- 确认性能、稳定性是否符合预期。
- 观察raptor、cat的服务抖动、db耗时变化、服务响应时间等情况。
- 检查线上日志是否有异常日志。
5、全量发布
灰度确认无问题后，即可开始全量发布。
灰度无问题，不代表全量发布无问题。要继续观察指标及异常情况。
6、上线确认
全量发布并确认无问题后，需要通知干系方开始全量发布操作。
对于同时部署双城（北京、上海）或多城的服务，应两个城市并行进行灰度，不可将两个城市的机器统一到同一个灰度发布任务中。
7、上线回滚
上线失败，立刻回滚，禁止重复在线修复问题！
- 发布过程遇到问题，立刻回滚！并在相关群里周知！（后端服务上线周知大象群、业务方相关的大象群，乃至电话通知等）；
- 技术主R在48小时内完成问题总结，并按照影响大小确定范围（小组内、大组内、所有受影响的人）组织复盘；
五、紧急上线流程
由于线上问题修复、紧急需求等，要在上线窗口外的时间上线，须走紧急上线申请流程。
PM、QA及RD，充分沟通后确认需要申请紧急上线时，走以下流程：
- PM、运营或RD整理紧急上线的必要理由，需要说明：
- 为什么紧急、为什么需要非正常时间上线（为什么不能安排在正常上线窗口）
- RD评估上线风险，包括：
- 上线如果出现问题，风险有多大，会造成什么样的损失
- PM或运营（修复线上问题时，则为RD）综合以上内容，发送紧急上线申请邮件或大象完成相关确认动作
- 抄送PM对应的产品Leader、运营对应的运营Leader、RD对应的研发Leader，及其他相关干系人
- 邮件中需明确表示：确认风险已知，并承担风险后果
- 产品Leader或运营Leader&研发Leader依次确认同意后，操作上线