192 lines
13 KiB
Markdown
192 lines
13 KiB
Markdown
# 发布管理
|
||
|
||
|
||
|
||
## 目的
|
||
|
||
为了对公司的发布管理进行规范化、统一化管理，减少发布风险，提高发布效率
|
||
|
||
## 正文
|
||
### 1. 职责分工
|
||
#### 1.1 发布管理流程负责人
|
||
主要职责：
|
||
|
||
确保本流程的设计、实施、回顾和改进；
|
||
负责本流程及附件文档的更新维护；
|
||
回顾流程执行情况，反映存在问题，提出改进建议，制定改进计划。
|
||
#### 1.2 研发负责人
|
||
主要职责：
|
||
|
||
完成系统开发、通过上线所需测试、准备发布所需交付物后提交发布申请；
|
||
参与发布评审，对本次发布内容、升级操作等做说明，对关联系统及受影响系统的发布风险做揭示；
|
||
对用户验证不通过的版本，组织修订；
|
||
在正式发布前（包括灰度发布）应提前将本次版本发布计划发送系统运维负责人做好评估及发布准备。
|
||
#### 1.3 运维组负责人
|
||
主要职责：担任发布评审，按发布评审表内容评审发布风险。审批本组相关系统的发布申请，审批时主要关注点为：
|
||
|
||
发布时间是否合适；
|
||
确认是否有完整、可行的升级、回滚方案；
|
||
发布操作手册是否根据本次版本变化内容进行更新。
|
||
#### 1.4 发布评审组
|
||
系统运维负责人根据发布评审管理要求《评审人员对照表》确定参与评审人员，其主要职责是：
|
||
|
||
按《发布评审表》内容识别发布可能带来的影响、存在的风险；
|
||
确认本次发布的执行计划及执行时间安排；
|
||
确认回退计划是否正确有效；
|
||
批准发布的执行
|
||
#### 1.5 系统运维负责人
|
||
主要职责：
|
||
|
||
根据每次版本变化特性，负责编写发布操作手册；
|
||
检查确认研发提交的文档是否满足发布要求、填写的申请信息是否与实际一致。
|
||
负责系统的发布执行，发布验证（包括用户实时验证结果确认）、发布完成通知、发布排期、发送发布前、后通知。
|
||
负责生产环境配置文件准备。
|
||
发布评审组成人员，参与发布评审。
|
||
版本发布前根据实际情况更新发布操作手册。
|
||
更新发布验证指引及发布完成后确认需要更新的相关文档（如服务目录、运维手册、应急预案、系统清单、监控、配置管理信息等）并组织更新。
|
||
对于失败的发布进行总结并跟进改进措施。
|
||
#### 1.6 数据库组负责人
|
||
如涉及数据库脚本变更，检查研发提交的脚本，评估脚本的风险。
|
||
#### 1.7 产品经理
|
||
组织用户进行测试，反馈验证结果并确认是否需要进行生产环境发布实时验证；
|
||
对于需要参与发布实时验证的，组织用户进行验证，并反馈验证结果。
|
||
### 2. 管理内容
|
||
#### 2.1 发布管理范围
|
||
涉及应用包更新、数据结构修改的应用系统更新遵循本管理流程；
|
||
只需进行应用类配置文件修改但不涉及应用包更新的遵循变更管理要求。
|
||
对于临时脚本的执行只涉及纯数据修改（不涉及数据结构修改）的遵循“数据修改类服务请求”的管理要求；
|
||
#### 2.2 发布来源
|
||
应用系统的版本发布主要来源于用户需求（含运维优化）和软件缺陷修复所产生。
|
||
#### 2.3 紧急发布管理要求
|
||
发布根据执行发布的时间紧迫性分为常规发布和紧急发布。原则上，符合以下情形才允许走紧急发布：紧急版本不受发布窗口限制
|
||
|
||
软件缺陷已经影响业务，只有通过修复版本才能恢复业务。
|
||
紧急安全漏洞需要，只有通过修复版本才能修复的。
|
||
其它无法满足常规版本发布条件的。
|
||
紧急发布审批：紧急发布需经过运维负责人、产品技术负责人审批通过（明确业务影响，把控业务风险），并知会CTO后方可发布，同步知会到相应业务部门。
|
||
|
||
高峰期所有发布都为紧急发布，必须CTO审批，并知会运维总监和运维经理，抄送相关方。
|
||
|
||
高峰期的版本发布审批流程：
|
||
|
||
系统所属研发负责人发送邮件申请，主送技术负责人和系统所属业务部门/技术负责人（总监及以上），抄送相关方。
|
||
系统所属业务部门/项目负责人明确业务影响，把控业务风险，进行审批。
|
||
技术负责人就技术与业务综合影响进行复批后，版本发布才允以执行。
|
||
以上信息，请各业务部门负责人同步知会到相应业务部门/技术负责人。
|
||
2.4 发布评审管理要求
|
||
对于常规的发布评审，发布评审的管理细则如下：
|
||
|
||
发布评审范围：
|
||
|
||
所有A类系统发布需要评审，BC类发布，涉及到如下场景的，需要评审
|
||
|
||
需要系统协同发布的
|
||
涉及大批量数据更新、删除或插入
|
||
版本有接口变更
|
||
版本有架构变更（含系统底层基础架构调整，包括但不限于数据库切换、应用主机切换等）
|
||
涉及功能推广及运营活动的（包含但不限于各大节庆日活动如双11，特色经济业务高峰等）
|
||
其他存在应用性能风险的配置调整（如涉及带宽流量的静态文件更换，包含但不限于系统扩容、域名调整等）
|
||
|
||
|
||
发布评审内容：
|
||
|
||
由运维组长组织发布评审，评审内容参照附件《发布评审表》,评审参与人参照发布评审参与人管理要求，评审通过后方可执行发布。
|
||
|
||
运维人员在收到版本计划时，可以根据本次版本的新特性内容，提前识别相关风险。如架构变更的影响、接口调整/变更的影响范围及验证需要、关联系统发布的联调与排期准备等信息。
|
||
|
||
发布评审参与人管理要求：
|
||
|
||
评审项|评审参与人
|
||
---|---
|
||
配置文件|系统运维负责人、研发人员
|
||
脚本|系统运维负责人、DBA（如有需要）
|
||
架构变更|系统运维负责人、研发人员
|
||
数据结构修改|系统运维负责人、研发人员
|
||
接口变更/调整|系统运维负责人、研发人员
|
||
涉及外围系统（关联系统发布）|系统运维负责人、研发人员、外围系统研发及运维负责人
|
||
|
||
#### 2.5 发布窗口
|
||
与用户约定的应用系统正常发布时间。原则上：
|
||
|
||
发布日期（窗口）：待定；每个系统具体发布日期原则上按项目计划执行，特殊情形变动项目计划，研发需提前1个工作日邮件知会系统运维负责人。
|
||
发布频率：初期不做限制，后期每个系统每周建议1次发布，每个月最多允许发布4次。
|
||
对于紧急缺陷修复引发的紧急发布不受上述发布频率和窗口的限制。
|
||
|
||
#### 2.6 发布申请要求
|
||
对于常规发布，原则上需在发布前一个工作日提交申请，如特殊情况，至少提前4个工作小时提交申请；
|
||
节假日后第一个工作日12:00前发布的版本，需在本次节假日的最后一天12:00前提交发布申请（如周一上午12:00前发布，需在星期天12:00前提交发布申请；如10月8日上午12:00前发布，则需在10月7日12:00前提交发布申请）；
|
||
紧急发布申请时间不受限制，根据实际情况，流程审批通过后执行发布。
|
||
|
||
#### 2.7 版本发布与基础架构变更冲突处理机制
|
||
先来优先处理原则：谁先发布正式具体计划（原则上：版本发布以项目计划中确定的发布时间为准；变更以申请中填写的“计划变更时间”为准），谁优先处理（以运维中心判定为准）；
|
||
基础架构变更与版本发布间隔时间建议在1天（含1天）以上；
|
||
若发布和变更时间存在冲突（如均要求在同一天）时，则由系统负责人反馈至对应研发负责人、运维人员所在部门负责人沟通决定。
|
||
|
||
#### 2.8 发布执行中出现异常时的处理机制
|
||
30分钟内未有效解决，发布人员应立即联系研发负责人协助处理；
|
||
升级给研发负责人后，发布人员应根据系统维护窗口和发布、回退执行时长及时执行回退。
|
||
|
||
#### 2.9 发布审批
|
||
|
||
|
||
为提高发布审批的效率、减少审批节点，在审批环节，针对部分角色采用“知会”的方式。详细要求如下：
|
||
|
||
发布类型|研发负责人|产品经理|运维经理/组长|DBA组长|运维部负责人|产品总监|CTO
|
||
---|---|---|---|---|---|---|---
|
||
常规发布|线上审批|线上审批|线上审批|如涉及（线下审批）|——|知会|——
|
||
紧急发布|线上审批|线上审批|线上审批|如涉及（线下审批）|邮件审批|知会|邮件审批
|
||
|
||
|
||
注：封版期所有发布都为紧急发布，按高峰期紧急版本管理要求执行。
|
||
|
||
#### 2.10 发布失败的定义（适用于生产环境）
|
||
符合以下任一条件，则定义为发布失败：
|
||
|
||
执行过程中出现问题导致必须回退或在计划发布窗口内无法完成发布；
|
||
版本发布完成后未实现预期效果，如：此版本新特性未实现；
|
||
发布完成后(1个工作日内发现)系统核心功能不可用或性能下降引发P1/P2类事件，导致必须回滚或需立刻升级版本修复。
|
||
对于失败的发布紧急修复的要求：
|
||
|
||
发布失败后优先考虑恢复业务，默认采用回滚的方式，待查明原因及解决措施后，经过测试、代码审核，重新按照发布流程规范申请发布
|
||
失败的发布如因业务要求或紧急情况，需要立刻发布新版本修复的，技术总监和产品总监批准后执行。
|
||
|
||
#### 2.11 发布总结和回顾
|
||
针对失败的发布，系统负责人应在发布完成后1-3个工作日内组织相关人员分析根本原因，识别改进机会，由运维经理/组长审核，并根据需要提交问题进行跟进；
|
||
发布管理流程负责人应定期对发布执行整体情况进行回顾，以识别发布管理流程执行中的改进计划，并组织改进。
|
||
|
||
### 3. 系统发布流程
|
||
#### 3.1 流程概况
|
||
|
||
| 流程名称 | 【系统发布流程】 | 流程编号 | x |
|
||
| ---- | ---- | ---- | ---- |
|
||
| 责任部门 | | 责任岗位 | |
|
||
| 流程目的 | 规范生产环境发布审批、执行、验证、总结等管理要求。 | | |
|
||
| 流程客户 | 某某业务 | | |
|
||
| 输入流程 | | 输出流程 | |
|
||
| 流程起点 | 交付物检查通过 | 流程终点 | 系统关单 |
|
||
|
||
#### 3.2 流程图
|
||
#### 3.3 流程说明
|
||
|
||
| 活动编号 | 活动名称 | 时效要求（选填） | 活动说明 | 输入信息 | 输出信息 | 执行角色 | 执行系统 |
|
||
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|
||
| 1 | 交付物检查及发布评审通过 | / | 系统负责人及DBA相关人员确认交付物及发布申请信息。 | 各发布交付物 | / | 系统负责人 | |
|
||
| 2 | 紧急发布 | / | 系统根据研发经理申请填写的信息判断是否为紧急发布：1、 如果为紧急发布，则进入步骤03；2、 如果为常规发布，则进入02步骤 | / | / | / | |
|
||
| 3 | 研发审批通过 | / | 研发/产品审批是否有必要：1、 如审批同意，则进入04步骤；2、 如审批不通过，则结束流程 | / | / | 研发负责人/产品经理 | |
|
||
| 4 | 产品负责人审批 | | 针对紧急发布，研产品负责人审批是否有必要：1、 如审批同意，则进入04步骤；2、 如审批不通过，则结束流程 | / | / | 产品负责人 | |
|
||
| 5 | 运维审批通过 | / | 运维经理组织对组内发布进行评审，并根据评审结果审核发布。主要根据发布可能造成的业务影响审核发布时间是否合适：1、 如审核通过，则进入05步骤；2、 如审核不通过，则结束流程 | / | / | 运维经理/组长 | |
|
||
| 6 | 发送发布通知 | / | 运维经理在审批通过后，发送发布通知，提醒发布人员和产品经理等相关人员做好发布准备 | / | 发布通知 | 系统运维负责人 | |
|
||
| 7 | 执行生产环境发布 | / | 部署人员在收到发布通知并确认用户测试通过后，根据计划的发布时间执行生产环境的发布，发布过程需要执行的主要工作参考《发布过程执行指引》 | / | / | 发布人员/系统运维负责人 | |
|
||
| 8 | 发布验证 | / | 发布完成后，根据《发布过程执行指引》中的验证要求进行验证，初步验证通过后通知用户进行验证 | / | / | 发布人员/系统运维负责人 | |
|
||
| 9 | 测试人员/用户验证 | / | 对于用户选择参与发布实时验证的，产品经理组织相关人员对新特性、主要业务流程进行实时验证，并将结果反馈给发布人员 | / | / | 关键用户/测试人员 | |
|
||
| 10 | 发布成功 | / | 发布人员/系统运维负责人根据验证结果判定发布是否成功：1、 如果成功，发送发布完成通知后结束流程；2、 如不通过，则进入12步骤 | / | 发布完成通知 | 发布人员/系统运维负责人 | |
|
||
| 11 | 执行回退 | / | 对于失败的发布，发布人员/系统运维负责人根据实际情况执行回退，并在回退完成后发送发布完成通知 | / | | 发布人员/系统运维负责人 | |
|
||
| 12 | 发布总结 | 1-3个工作日 | 系统运维负责人在发布完成3个工作日内负责组织相关人员分析失败的原因，识别改进的计划，在系统中进行登记并根据需要提交问题进行跟进，发布流程结束 | / | | 系统运维负责人 | |
|
||
| 13 | 发布后的信息更新 | | 在发布完成后，及时更新相关信息 | | | 系统运维负责人 | |
|
||
|
||
|
||
|
||
|
||
|
||
|