发布管理规范指引_V1.3

发布管理规范指引_V1.3中国太平洋保险信息技术中⼼
发布管理规范指引发布管理功能区版本：1.3
2014/7/18
⽬录
⼀、定义： (4)
1、发布（同变更的区别） (4)
2、发布窗⼝ (4)
3、数据库DDL和DML (4)
4、发布停机时间窗⼝ (4)
5、预⽣产环境（同灾备环境的区别） (5)
6、上线和投产 (5)
7、堡垒机 (5)
8、特权账号平台 (6)
9、⾃动发布平台 (6)
10、版本库 (6)
11、发布信息平台 (6)
12、remedy平台 (6)
13、冻结期 (7)
14、发布计划 (7)
15、发布排期 (7)
16、技术验证和业务验证 (7)
⼆、相关分类和标准 (8)
1、发布的分类 (8)
2、窗⼝的分类 (9)
3、缺陷类紧急发布分级标准 (9)
4、签字件标准 (10)
三、格式要求 (11)
1、发布⼿册 (11)
2、版本库⽬录 (11)
3、发布通知 (12)
四、⾓⾊职责 (13)
1、发布⾓⾊按职能分类 (13)
2、开发负责⼈： (13)
3、测试负责⼈： (13)
4、维护负责⼈ (13)
5、发布规划负责⼈ (13)
6、发布协调员 (14)
3、DBA (14)
4、技术⽀持团队 (14)
5、业务验证代表 (14)
五、各主要环节 (15)
1、提供发布计划 (15)
2、发布版本交付 (15)
3、remedy评估和派单 (16)
4、发布评估和排期 (16)
5、预⽣产验证 (17)
6、预⽣产同步管理 /环境借⽤ (17)
7、发布过程实施 (18)
8、发布验证 (18)
9、结果通知 (18)
10、发布回顾 (19)
11、发布异常处理 (19)
六、时效要求 (20)
1、测试通过时效要求 (20)
2、发布材料评审时效要求 (21)
3、Remedy派单时效要求 (21)
⼀、定义：
1、发布（同变更的区别）
应⽤系统的发布，⼀般指应⽤程序的变动，可能包括程序⽂件的更新、数据库对象的调整、应⽤配置的变动、数据的更新等⼀系列动作。

不涉及到应⽤程序变更的平台软件、硬件等升级或替换，应按变更管理流程管控。

经开发、维护、数据库管理团队判定不会对应⽤系统功能/逻辑/数据产⽣影响的数据库对象调整也按变更管理流程管控。

发布和变更如何界定的标准：
对⽣产环境的变动，若对应⽤系统功能/逻辑/数据产⽣影响，则应通过发布流程管控，若⽆影响，可通过变更流程管控。

2、发布窗⼝
可默认安排发布的指定⽇期。

3、数据库DDL和DML
1、数据库DDL
数据定义语⾔DDL(Data Definition Language)，⽤来创建或改变数据库中的各种对象-----表、视图、索引、同义词、存储等，主要的命令有CREATE、ALTER、DROP等；
在实际发布中还包括⼀些对表进⾏赋权的grant命令，执⾏存储的exec命令等DCL语句。

2、数据库DML
数据操纵语⾔DML(Data Manipulation Language)，使⽤户能够查询数据库以及操作已有数据库中的数据的计算机语⾔。

具体是指是UPDATE、INSERT、DELETE等
4、发布停机时间窗⼝
指每个系统预先定义的可以进⾏停机发布的并且对⽤户没有影响或者影响最⼩的⼀个时间段。

各系统发布停机时间窗⼝信息及回退时间点要求,可在发布信息平台上查阅。

排期按照收集的各系统预定义的停机时间窗⼝进⾏安排，若需调整停机时间定义，需维护负责⼈以邮件形式通知发布管理团队。

若某次发布，停机时间⽆法按定义的窗⼝安排的，由发布管理团队在发布前召集开发、维护及发布操作团队进⾏评估。

5、预⽣产环境（同灾备环境的区别）
指⽤于在⽣产环境发布前对发布的部署过程、发布版本对环境的适应情况进⾏验证的环境，预⽣产环境具有数据同步程度⾼，应⽤节点拟真度⾼的特点（但性能配置差异较⼤），可在发布前检验和预防⽣产环境风险。

对于拥有灾备环境的系统，不再单独搭建预⽣产环境，在系统需要预⽣产验证前，切换为预⽣产环境使⽤，并且做数据库刷库，应⽤节点快照等准备。

对于没有灾备环境的系统，可以申请搭建专⽤的预⽣产环境。

6、上线和投产
上线：新系统可以正式投产⽣产运⾏前的⼀系列检查和审核动作。

系统上线后，原则上由应⽤负责⼈接收维护、由测试部负责测试、由发布规划负责⼈安排发布计划、由发布管理团队负责协调发布。

投产：应⽤系统的新增节点可以正式启⽤前的⼀系列检查和审核动作。

节点投产后，遵循⽣产⽹段的⽹络和安全策略，部署监控策略，CMDB更新策略等。

上线、投产由应⽤运⾏⽀持部发布管理功能区发起会签，相关部门功能区区长或指定负责⼈填写相关审核意见。

待全部通过后，系统或节点⽅可转为已上线/已投产状态。

上线由项⽬组提出申请，投产由项⽬组或维护负责⼈提出申请，将所有材料（见附件）提供给发布管理团队。

未投产通过的节点，进⾏⽹络隔离。

投产通过后，⽅可放开⽹络限制。

上线投产检查⽂档
清单.xlsx
参与审核⼈员通过会签平台签署意见，操作⽅法和检查要求详见附件。

上线投产会签说明.
pptx 上线投产各区合规性检查项清单.xlsx
7、堡垒机
由于⽹络限制，对⽣产环境或灾备环境（预⽣产环境）进⾏后台维护，需通过堡垒机的界⾯进⾏连接，其中登录堡垒机使⽤的是P13帐号，帐号及⾓⾊的申请通过IT热线进⾏申请。

8、特权账号平台
对⽣产环境⾼权限账号进⾏集中保管和密码控制的⼯具平台。

通过特权平台获取的帐号⼝令，并⾮长期有效，使⽤⼈须在规定时间内完成相应的⼯作，否则需在特权平台重新申请帐号⼝令。

9、⾃动发布平台
实现发布操作⾃动化的⼯具平台，其主要功能有：
1、通过⾃动发布平台配置应⽤发布的步骤
2、通过点击按钮做到⼀键发布的⽬的
3、对发布过程进⾏程序包的⾃动MD5码检查，确保版本⼀致
4、登录地址：http://10.190.34.174:8001/autodeploy/login.jsp
10、版本库
集中存放发布版本的⽂件服务器。

供开发团队上传版本，测试团队获取后进⾏测试的版本库为 10.191.18.23；
测试通过，并通过发布检查和审核的版本放置于10.191.17.59，发布操作员在此获取最终发布的内容和操作⼿册。

11、发布信息平台
发布管理功能区所搭建的供发布相关⼈员获取发布信息的平台。

这些信息主要包括：
发布计划清单
发布问题记录
发布过程信息
其他需公⽰的参考清单
访问地址：
http://10.192.36.145:8088/issueprj/login.do
12、remedy平台
Remedy平台是集中进⾏运维⼯单流程的⼯具平台。

在发布中的主要作⽤有：⽣成发布申请、进⾏发布评估和审批、分派发布变更、创建发布任务等。

Remedy平台确保了发布操作的合规性，是发布操作⼈员获取发布账号密码的凭证，记录了发布从申请到操作完成的⼀系列时间点，也是为发布后进⾏追溯和统计提供信息的平台。

13、冻结期
因⽉底业务结算、或特殊重⼤事项等原因须严格对⽣产环境的变更和发布进⾏控制的时期。

⼀般冻结期的定义为：每⽉26⽇～次⽉5⽇，其中年中为6⽉26⽇～7⽉10⽇，年末为12⽉21⽇～次年1⽉10⽇。

特殊冻结期如：⼗⼋⼤保障期，630保障期，亚新峰会保障期
具体要求应参照变更管理流程。

14、发布计划
指未来⼀定时间内的系统发布计划。

由发布规划负责⼈最终制定，并向发布管理功能区提供。

15、发布排期
由发布管理功能区和相关⼈员商定后，安排的发布操作时间表，并包含操作⼈员、验证⼈员、及其他配合⼈员的信息。

16、技术验证和业务验证
技术验证：发布操作结束后，由维护团队对系统发布后是否正常运⾏进⾏的验证动作。

业务验证：由业务代表在发布后，对系统的相关功能进⾏验证，检查所对应的需求是否正常，由需求提出⽅在提出需求时给予明确的验证要求。

如⽆特别情况，必须安排业务验证。

发布规划负责⼈，在向发布管理团队提供发布计划时，应同时提供相关的业务验证安排信息。

业务代表的确定⽅式如下：
由需求发起⼈在jira平台中填写是否需业务验证以及业务代表姓名的必填项。

后续可通过⼆部开发的发布管理平台获取业务代表信息。

对于⾮开发部门开发的系统由此系统的开发负责⼈提交业务代表信息⾄发布管理团队。

⼆、相关分类和标准
1、发布的分类
发布的类型，按发布⽅式分类共分为五类：常规发布、配合发布，专项发布，紧急发布，独⽴发布
常规发布：
在每⽉所属的常规窗⼝内安排的发布。

独⽴发布：
在所属独⽴窗⼝内安排的发布。

独⽴发布可默认关联发布的系统，采⽤⽩名单制，预先指定。

不可包含14个重点保障系统。

配合发布：
根据监管机构、⾏业协会要求进⾏应⽤调整
配合第三⽅平台调整，对接⼝应⽤进⾏调整
配合发布，仅需提供监管机构、⾏业协会、第三⽅正式函件或通知，⽆其他业务审核要求。

专项发布：
因某业务活动，新产品发布等专项⼯作提出的需求；
交付时间要求超过2周的；
紧急发布：
紧急发布按发布原因或性质可再细分为如下⼏类：
业务需求、缺陷修复、常规延期、部署问题、数据迁移、安全组件加固、热发布。

热发布：
指通过应⽤系统前台界⾯操作的⽅式完成业务功能或逻辑变化的⼀种操作⾏为。

具备热发布功能的模块通过预登记⽅式管理，由运维负责⼈负责。

登记时，对于已有功能，应核对功能上线时的测试是否完整。

若否，重新测试。

若为新功能，按正常发布流程发布后登记
热发布窗⼝暂定为每天的⾮⼯作时间，即：中午12：00-13：00 和 18:00后。

热发布单独设⽴指标，数据进⾏单独统计。

热发布评估要求：
业务⽅，窗⼝内发布-业务代表，⾮窗⼝内发布-业务⽅部总室，邮件即可，项⽬经理提供
开发负责⼈（Remedy平台），运维负责⼈（Remedy平台）
对于未完成⽬录登记的热发布申请，应按照业务需求类紧急发布进⾏申请与发布准备。

2、窗⼝的分类
常规窗⼝
指年初定义的某⼀类系统可以安排发布的固定时间点，每类系统每⽉⼀个常规窗⼝，如寿险常规发布窗⼝，产险常规发布窗⼝
独⽴窗⼝
对某个具体的系统，单独约定可安排发布的时间点，不限数量，但需事先确定。

独⽴窗⼝⽬前采⽤两种模式：
1、除每⽉常规窗⼝外，固定当⽉1天作为独⽴窗⼝。

适⽤于结佣类、结算类、传统互联⽹应⽤。

2、除常规窗⼝外，设置3个不固定窗⼝或每周设置⼀个固定窗⼝，适⽤于创新类应⽤、新互联⽹应⽤。

窗⼝外：指不在预定义的窗⼝内发布的情况。

3、缺陷类紧急发布分级标准
缺陷修复类紧急发布，按紧急程度划分为三级：⾼级，中级，低级，不同级别的缺陷类紧急发布的发布时间要求不同。

维护团队发现的缺陷，由维护团队进⾏评估定级，通过缺陷流程传递给开发。

开发团队发现的缺陷，由开发团队征询维护意见进⾏定级。

在提交发布申请时，开发⽅应提供本次发布所修复的缺陷描述，缺陷级别，维护负责⼈在remedy的评估意见中，应对级别是否正确给出意见。

不同级别的缺陷类紧急发布的发布时间要求见下表：
安全组件加固类紧急发布的时间要求，参照缺陷类，根据安全部提供的关于漏洞的说明和风险等级，具体时间要求为：
4、签字件标准
注意，签字形式不限于纸质，可采⽤其他可识别、可记录的⽅式，如邮件。

三、格式要求
1、发布⼿册
发布⼿册须按照发布⼿册模板的格式填写，对于新系统和尚未采⽤⼿册模板的系统，联系发布管理功能区进⾏⼿册模板的商定。

（模板在sftp:10.191.18.23 端⼝9999 ，⽤户名和密码请向发布管理功能区获取）
每次发布前，项⽬组除填写应⽤发布和数据库发布的内容外，必须填写发布基本信息、发布⽅案、以及应⽤和数据库操作的相应回退⽅案。

对发布当晚的关联变更，应通过发布⼝径，在发布⽅案中⼀并体现，由发布管理团队根据发布⽅案统⼀安排，避免发布和变更间的冲突。

开发团队须确保发布⽅案的完整性。

发布⼿册由开发团队提供，但⼿册中和⽣产环境相关的路径、IP地址、账号，维护团队应严格审核，以确保和⽣产环境⼀致。

发布⽅案的要求：项⽬组提交发布操作时，必须提供发布⽅案，⽅案中应写明与发布关联的变更内容，若本次发布的版本有⾮功能性⽅⾯的需求（如：监控、备份、容量、可⽤性等），必须在发布⽅案中⼀并说明。

回退⽅案的要求：回退⼿册的编写要尽量详尽、傻⽠化，强化实施操作步骤。

2、版本库⽬录
开发⽤于上传ftp版本库的⽬录如下：
IP：10.191.18.23 FTP协议：sftp 端⼝：9999
账号：默认⽤户名为系统英⽂简称，如产险2003版银保通系统，其⽤户名为PT03BAI。

帐号异常的处理⽅式：UC联系“服务导⼊值班员”检查，电话33965995。

由于涉及到⾃动打包及材料审核，ftp的发布材料放置必须按照以下规则：
发布材料上传后必须包含⽤于⽐对发布材料准确性的发布交付物清单，交付清单模板获取地址如下：
FTP：10.191.18.23 端⼝：9999 协议：SFTP
⽤户名和密码请向发布管理团队获取。

3、发布通知
发布停机通知由发布管理团队邮件发送，分以下⼏类：（格式不⼀⼀列出）
1、IT内部
2、分公司
3、神太可⽤性影响
4、业务分公司验证邮件。

以下六个系统必须发邮件：产险2005⼈意险系统、产险2007
版CIBS系统，产险2009版集中渠道管理系统、产险2007版车险承保业务系统、产险2007版集中收付处理系统、产险2004版车险理赔系统。

发布管理团队应将应⽤系统主管部门的接⼝⼈纳⼊通知范围。

业务部门接⼝⼈清单由需求部收集提供。

四、⾓⾊职责
1、发布⾓⾊按职能分类
规划职能：发布规划负责⼈，
审核职能：开发负责⼈、测试负责⼈、维护负责⼈、DBA、中间件、系统、⽹络、发布规划负责⼈
协调职能：发布经理、发布协调员、
执⾏职能：发布操作员
专家职能：技术⽀持团队、CAB专家
验证职能：业务验证代表、技术验证负责⼈
2、开发负责⼈：
提供发布材料
提供技术⽀持
传达业务意见
参与问题决策
3、测试负责⼈：
提供测试结论
提供测试报告
换包测试⽀持
4、维护负责⼈
预⽣产部署验证
⽣产部署验证
发布材料审核
换包回退决策
5、发布规划负责⼈
提供计划信息
进⾏计划决策
传达发布要求
6、发布协调员
负责发布的整体协调和⽀持⼯作；
负责发布通知的发送；
负责发布材料的检查；
负责召集发布评估；
负责发布申请和相关⼯单的创建和派发。

3、DBA
审核数据库脚本，对于违规及敏感的内容提出质疑，
4、技术⽀持团队
负责在发布当天或之后，提供相关领域技术⽀持。

对于发布后的现场保障要求：
1) 发布当天，开发、应⽤维护、中间件、数据库、系统、⽹络、安全团队，均现场⽀持。

对历史发布换包次数多或发布后故障较多的系统，发布当晚，测试团队须安排⼈员现场⽀持；
2) 发布后第⼆天，凡符合以下情况的，除应⽤维护、中间件、数据库、系统、⽹络、安全团队现场保障外，开发团队须安排核⼼⼈员现场保障；
a) 14个核⼼系统；
b) 历史发布故障记录多的系统（发布故障率由运维团队统计历史数据，给出参考指标）；
c) 发布过程中有换包情况的（测试团队也需安排现场保障⼈员）。

5、业务验证代表
业务验证：由业务代表负责组织业务验证，并通过邮件或UC反馈验证结果。

业务验证要求：
1)需求提出⼈，应在Jira平台中，如实填写业务验证要求，对于需要业务验证的，必
须提供验证负责⼈姓名及联系电话。

验证负责⼈应按约定做好验证⼯作，并将验证
结果邮件发⾄发布管理团队。

请需求管理部向业务部门做好宣导⼯作；
2)负责需求受理分析的需求管理部、开发部需求分析⼈员，应检查业务验证联系信息
填写是否完整，若否，应将需求退回提出⼈补全信息；
3)发布规划负责⼈在整理发布计划时，若发现业务验证联系信息不全，应通知需求分
析⼈员核实完整，并将完整的业务验证要求清单提交发布管理团队；
4)发布过程中，若发现业务验证联系信息⽆效，应通知需求分析⼈员联系业务部门及
时安排验证⼯作；
5)对于发布过程中出现验证信息⽆效的情况，发布后，通过问题机制定位原因，加以
改进。

五、各主要环节
1、提供发布计划
a.内容
由发布规划负责⼈整理确定每天的发布计划，计划内应包含：发布时间、发布类型、计划交付时间、发布原因、发布必要性说明、发布风险说明、业务验证安排信息、应急预案、系统关联性说明。

发布计划应经开发部门总经理审核同意。

b.提交
发布规划负责⼈通过邮件，发送⾄发布管理团队的专⽤邮箱“应⽤发布窗⼝”。

发布规划负责⼈应将开发部门总经理的同意意见转发发布管理专⽤邮箱。

c.登记
发布管理团队在收到发布计划后，在发布信息平台上登记。

d.修订
发布计划有任何变动，发布规划⼈应⽴即邮件告知修订内容与原因
2、发布版本交付
a.提供材料
开发团队将发布版本和相关材料，上传⾄专⽤的版本服务器。

提供的版本材料应包含：交付物清单，程序包，脚本，发布⼿册（⼿册⾥必须有发布⽅案），配置⽂档（如有），版本清单，申请表，系统关联性清单。

b.提供测试意见
测试负责⼈在版本测试通过后，在版本库对应系统的测试通过的版本⽬录中，创建“测试意见”⽬录，放置“测试通过.txt”⽂件，并上传测试报告。

c.材料检查
发布协调员，对发布交付物清单中的MD5码和实际交付物的MD5码进⾏⽐对。

d.材料审核，运维、DBA、中间件、⽹络等
发布协调员根据发布⽅案内的说明，将需要其他团队审核的发布材料邮件发送给相关⼈员进⾏审核
各技术团队收到审核材料后，应及时审核，并将结果告知发布协调员，未及时答复的，视为审核通过。

e.上传发布⽤版本库
发布协调员将各⽅审核通过的发布材料上传⾄10.191.17.59的发布版本库
3、remedy评估和派单
a、创建发布申请，添加评估⼈
由发布协调员创建发布申请，添加包括开发、运维、测试、发布规划负责⼈、安全扫描负责⼈、预⽣产协调员、发布经理等评估⼈
14个核⼼保障系统的常规发布，安全部参与评估。

其他系统不要求。

b、remedy评估
各评估⼈在remedy申请中填写评估意见，具体评估要求见下表：
开发负责⼈、测试负责⼈、运维负责⼈以CMDB中登记的姓名为准。

测试意见需在⾸⾏明确给出以下两种意见之⼀：
“测试通过。

”——见此意见，即为本次发布可以进⾏；
“测试不通过。

”——见此意见，即为本次发布不可进⾏。

c、派单
各⽅评估通过后，发布协调员将发布⼯单派给相应的操作⼈员。

d、启动任务
发布操作⼈员收到变更并创建任务后，由发布协调员启动任务。

4、发布评估和排期
a、核实实际发布清单
常规发布，由开发部召集，业务部门、需求管理和维护团队参与，对发布准备情况、发布风险，按系统逐⼀论证评估，形成纪要。

发布管理团队整理实际发布的清单，在uc群内进⾏评估，评估内容包括关联系统清单，发布⽅案评审等。

发布评估每个⼯作⽇下午进⾏，除确认当天发布清单外，须对第⼆天的发布计划进⾏评估。

发布评估结果，需报送⽣产调度会议（CAB）审核通过。

对于⾮常规发布的，由⽣产调度会议上报⼀级部领导审核。

发布评估要点如下：
系统发布的必要性：
–发布原因
–不发布的业务影响：⽤户范围、⽤户类型、⽤户数量
–⽬前采取了哪些应急措施
发布⽅案：对系统做哪些变动
发布风险：
–发布停机的影响范围：⽤户范围、⽤户类型、⽤户数量
–发布失败的影响范围：⽤户范围、⽤户类型、⽤户数量
–关联哪些系统，这些系统的影响范围是什么
–有⽆应急⽅案，是什么。

发布保障：
–发布后有何保障措施，特别是业务验证是否已安排
b、发布排期
发布管理团队确定每个系统发布的时间和⼈员后，编制发布排期表，邮件发送相关团队。

5、预⽣产验证
a、快照及数据库刷新
⽉初的5-6号左右，由发布协调员以邮件⽅式通知灾备⼈员进⾏数据库刷库与快照的操作，灾备区于⼀周内完成并反馈完成情况。

b、部署及验证
⽣产发布前要做预⽣产的部署验证操作，由维护团队负责，操作⽅式与⽣产发布操作⼀致，帐号⼝令从灾备的特权平台进⾏获取，⼝令不正确的情况下，操作⼈员可以找发布协调员协助解决。

发布结束后须向发布协调员反馈结果。

发布管理协调⼈将在remedy申请中填写预⽣产验证结果。

c、派单
发布申请提交后，派出预⽣产的变更⼯单。

6、预⽣产同步管理 /环境借⽤
a.预⽣产同步管理
由基础部变更协调团队分派预⽣产环境的同步变更⼯单，由发布管理团队集中受理后，根据环境当前使⽤情况，安排同步时间，转派⾄相应的执⾏团队完成同步操作。

b．环境借⽤
申请⽅将申请邮件发⾄“应⽤发布窗⼝”邮箱，发布管理团队评估后，根据申请时间范围，判断环境是否可以使⽤，邮件进⾏反馈。

如同意借⽤环境的，须先做快照，按借⽤需要进⾏刷库，完成后交付借⽤者，待环境借⽤完毕后，再进⾏快照的恢复与刷库，并对期间此系统产⽣的⽣产发布和变更安排同步。

7、发布过程实施
1、申请账号
发布操作员在特权平台上获取应⽤、数据库发布相应帐号的⼝令。

实际操作中如在特权平台上⽆法获得相应密码，向发布当晚提供⽀持的对应技术团队⼈员寻求解决
2、操作
发布操作员按照发布⼿册的⽅案和步骤进⾏操作
3、反馈结果
发布操作员将操作的结果反馈发布协调员。

发布操作员须在“当晚发布沟通uc群”告知发布开始与发布结束。

4、记录问题
如下情况请必须记录相关问题，以⽅便问题后续处理：
1、发布操作与操作⼿册不相符
2、发布中产⽣换包，与追加或减少发布内容
3、其他影响发布顺利进⾏的问题
发布操作⼈员或发布协调员在发布信息平台中记录发布中发⽣的问题
问题记录格式：
发⽣时间：20xx-xx-xx xx:xx
现象: 在（操作、验证等）时，（操作员、开发、运维等）发现（具体现象）
原因：（开发、运维、数据库、中间件、当晚值班⼈员等初步定位的原因）
处理过程：由（开发、运维、发布规划、测试等）同意更换或添加(发布包、数据库脚本、配置⽂件，发布⼿册)，由操作员执⾏。

或由（数据库、中间件、值班⼈员等）进⾏（具体处理内容）
问题处理时间：xx分钟
操作⼈：xxx
协调⼈：xxx
8、发布验证
1、发布操作结束后，应⽤负责⼈进⾏技术验证并反馈发布协调员，技术验证应按事先制定的技术验证⽅案执⾏。

2、技术验证通过后，应⽤负责⼈告知发布协调员，协调员通知预先安排的业务代表进⾏验证。

3、业务代表进⾏验证并通过oa或者uc反馈结果，业务验证应按事先制定的业务验证⽅案执⾏。

9、结果通知
由发布协调员发送发布结果通知：
1、短信⽅式
2、邮件简报⽅式：发布前1封，发布后2封
10、发布回顾
每⽇⽣产调度例会对昨天的发布结果进⾏回顾。

11、发布异常处理
a.发布中补单的要求：
1、对于发布过程出现的问题，技术⽀持团队给予临时性的处理⽅案（发布⼿册是正确的，因为权限或账号等问题导致的），⽆需提交补单。

2、对于发布过程出现的问题，技术⽀持团队给予定性的解决⽅案（发布⼿册是不完善的，需要修改发布内容步骤或⽅案），需提交补单。

3、技术⽀持团队在处理问题过程中给出尝试性的解决⽅案，以最终解决问题的⽅案来参照上述1和2决定是否提交补单。

4、其他情况，由服务导⼊功能区现场协调负责⼈和操作团队现场负责⼈商议决定是否补单。

5、 remedy上补单摘要必须以“补单”开头。

b. 回退所需进⾏的操作步骤：根据回退时间点的定义，发布⾄回退时间点时，发布管理团队向运维和开发团队确认是否回退的结果，结果为回退的，执⾏回退步骤，结果为继续发布的，告知新的发布预期结束时间点。

c.发布操作或验证时间超时：对发布超过预估时间较多的现象进⾏记录并且了解超时的原因，对于超时严重⾄回退时间点的，启动回退评估⽅案
d.⽆法找到所需⽀持⼈员的情况：上升⾄ECC值班经理进⾏处理
发布和变更实施过程中的问题解决时效要求：若出现⽀持⼈员⽆法到位的情况，现场协调⼈员应及时将问题升级，ECC值班经理作为当天数据中⼼的最⾼管理⼈员，有⼈员调度和安排权限，紧急问题应及时报值班经理。

对于⽀持团队，应确保⽀持⼈员的技术⽀持能⼒，避免出现同⼀团队给出不同⽅案的情况。

e．换包流程定义
1、属于环境配置问题，或语法、格式错误，引起的换包。

此类换包，由维护负责⼈对换包内容和更换的⽂件进⾏检查和判断。

如能确定情况属实，则可以允许换包。

若⽆法确定实际更换的内容，则视同第⼆种情况的换包。

2、⾮配置类和语法错误类问题，引起的换包。

此类换包，所更换的⽂件，必须经测试通过后⽅可放⼊⽣产。

若对应系统的测试⼯作由测试部负责，则由测试负责⼈出具是否通过的意见，若测试⼯。