• 导航

上线发布规范

前端杂烩 2023-11-26 23 次浏览

一、背景和定义

后台服务场景复杂,微服务的广泛使用,调用量不断增大,调用关系越来越复杂,强弱依赖的问题也导致故障的发生频次和影响更加难以控制。
上线发布作为日常高频动作,参与人员多,出错概率大, 据统计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依次确认同意后,操作上线