发布管理规范指引_V1.3

1、中国太平洋保险信息技术中心发布管理规范指引发布管理功能区 版本：1.3 2014/7/18目录一、定义：41、发布（同变更的区别）42、发布窗口43、数据库DDL和DML44、发布停机时间窗口45、预生产环境（同灾备环境的区别）56、上线和投产57、堡垒机58、特权账号平台69、自动发布平台610、版本库611、发布信息平台612、remedy平台613、冻结期714、发布计划715、发布排期716、技术验证和业务验证7二、相关分类和标准81、发布的分类82、窗口的分类93、缺陷类紧急发布分级标准94、签字件标准10三、格式要求111、发布手册112、版本库目录113、发布通知12四、角色职责

2、131、发布角色按职能分类132、开发负责人：133、测试负责人：134、维护负责人135、发布规划负责人136、发布协调员143、DBA144、技术支持团队145、业务验证代表14五、各主要环节151、提供发布计划152、发布版本交付153、remedy评估和派单164、发布评估和排期165、预生产验证176、预生产同步管理 /环境借用177、发布过程实施188、发布验证189、结果通知1810、发布回顾1911、发布异常处理19六、时效要求201、测试通过时效要求202、发布材料评审时效要求213、Remedy派单时效要求21一、定义：1、发布（同变更的区别）应用系统的发布，一般指应用程序

3、的变动，可能包括程序文件的更新、数据库对象的调整、应用配置的变动、数据的更新等一系列动作。不涉及到应用程序变更的平台软件、硬件等升级或替换，应按变更管理流程管控。经开发、维护、数据库管理团队判定不会对应用系统功能/逻辑/数据产生影响的数据库对象调整也按变更管理流程管控。发布和变更如何界定的标准：对生产环境的变动，若对应用系统功能/逻辑/数据产生影响，则应通过发布流程管控，若无影响，可通过变更流程管控。2、发布窗口可默认安排发布的指定日期。3、数据库DDL和DML 1、数据库DDL数据定义语言DDL(Data Definition Language)，用来创建或改变数据库中的各种对象-表、视图、

4、索引、同义词、存储等，主要的命令有CREATE、ALTER、DROP等；在实际发布中还包括一些对表进行赋权的grant命令，执行存储的exec命令等DCL语句。2、数据库DML数据操纵语言DML(Data Manipulation Language)，使用户能够查询数据库以及操作已有数据库中的数据的计算机语言。具体是指是UPDATE、INSERT、DELETE等4、发布停机时间窗口Ø指每个系统预先定义的可以进行停机发布的并且对用户没有影响或者影响最小的一个时间段。Ø各系统发布停机时间窗口信息及回退时间点要求,可在发布信息平台上查阅。排期按照收集的各系统预定义的停机时间窗口进

5、行安排，若需调整停机时间定义，需维护负责人以邮件形式通知发布管理团队。若某次发布，停机时间无法按定义的窗口安排的，由发布管理团队在发布前召集开发、维护及发布操作团队进行评估。5、预生产环境（同灾备环境的区别）指用于在生产环境发布前对发布的部署过程、发布版本对环境的适应情况进行验证的环境，预生产环境具有数据同步程度高，应用节点拟真度高的特点（但性能配置差异较大），可在发布前检验和预防生产环境风险。对于拥有灾备环境的系统，不再单独搭建预生产环境，在系统需要预生产验证前，切换为预生产环境使用，并且做数据库刷库，应用节点快照等准备。对于没有灾备环境的系统，可以申请搭建专用的预生产环境。6、上线和投产上

6、线：新系统可以正式投产生产运行前的一系列检查和审核动作。系统上线后，原则上由应用负责人接收维护、由测试部负责测试、由发布规划负责人安排发布计划、由发布管理团队负责协调发布。投产：应用系统的新增节点可以正式启用前的一系列检查和审核动作。节点投产后，遵循生产网段的网络和安全策略，部署监控策略，CMDB更新策略等。上线、投产由应用运行支持部发布管理功能区发起会签，相关部门功能区区长或指定负责人填写相关审核意见。待全部通过后，系统或节点方可转为已上线/已投产状态。上线由项目组提出申请，投产由项目组或维护负责人提出申请，将所有材料（见附件）提供给发布管理团队。未投产通过的节点，进行网络隔离。投产通过后，

7、方可放开网络限制。参与审核人员通过会签平台签署意见，操作方法和检查要求详见附件。7、堡垒机由于网络限制，对生产环境或灾备环境（预生产环境）进行后台维护，需通过堡垒机的界面进行连接，其中登录堡垒机使用的是P13帐号，帐号及角色的申请通过IT热线进行申请。 8、特权账号平台对生产环境高权限账号进行集中保管和密码控制的工具平台。通过特权平台获取的帐号口令，并非长期有效，使用人须在规定时间内完成相应的工作，否则需在特权平台重新申请帐号口令。9、自动发布平台实现发布操作自动化的工具平台，其主要功能有：1、通过自动发布平台配置应用发布的步骤2、通过点击按钮做到一键发布的目的3、对发布过程进行程序包的自动M

8、D5码检查，确保版本一致4、登录地址：10、版本库集中存放发布版本的文件服务器。供开发团队上传版本，测试团队获取后进行测试的；测试通过，并通过最终发布的内容和操作手册。11、发布信息平台发布管理功能区所搭建的供发布相关人员获取发布信息的平台。这些信息主要包括： 发布计划清单 发布问题记录 发布过程信息 其他需公示的参考清单访问地址：12、remedy平台Remedy平台是集中进行运维工单流程的工具平台。在发布中的主要作用有：生成发布申请、进行发布评估和审批、分派发布变更、创建发布任务等。Remedy平台确保了发布操作的合规性，是发布操作人员获取发布账号密码的凭证，记录了发布从申请到操作完成的一

9、系列时间点，也是为发布后进行追溯和统计提供信息的平台。13、冻结期因月底业务结算、或特殊重大事项等原因须严格对生产环境的变更和发布进行控制的时期。一般冻结期的定义为：每月26日次月5日，其中年中为6月26日7月10日，年末为12月21日次年1月10日。特殊冻结期如：十八大保障期，630保障期，亚新峰会保障期具体要求应参照变更管理流程。14、发布计划指未来一定时间内的系统发布计划。由发布规划负责人最终制定，并向发布管理功能区提供。15、发布排期由发布管理功能区和相关人员商定后，安排的发布操作时间表，并包含操作人员、验证人员、及其他配合人员的信息。16、技术验证和业务验证技术验证：发布操作结束后，

10、由维护团队对系统发布后是否正常运行进行的验证动作。业务验证：由业务代表在发布后，对系统的相关功能进行验证，检查所对应的需求是否正常，由需求提出方在提出需求时给予明确的验证要求。如无特别情况，必须安排业务验证。发布规划负责人，在向发布管理团队提供发布计划时，应同时提供相关的业务验证安排信息。业务代表的确定方式如下：由需求发起人在jira平台中填写是否需业务验证以及业务代表姓名的必填项。后续可通过二部开发的发布管理平台获取业务代表信息。对于非开发部门开发的系统由此系统的开发负责人提交业务代表信息至发布管理团队 。二、相关分类和标准1、发布的分类发布的类型，按发布方式分类共分为五类：常规发布、配合发

11、布，专项发布，紧急发布，独立发布常规发布：在每月所属的常规窗口内安排的发布。独立发布：在所属独立窗口内安排的发布。独立发布可默认关联发布的系统，采用白名单制，预先指定。不可包含14个重点保障系统。配合发布： 根据监管机构、行业协会要求进行应用调整 配合第三方平台调整，对接口应用进行调整配合发布，仅需提供监管机构、行业协会、第三方正式函件或通知，无其他业务审核要求。专项发布： 因某业务活动，新产品发布等专项工作提出的需求； 交付时间要求超过2周的； 紧急发布：紧急发布按发布原因或性质可再细分为如下几类：业务需求、缺陷修复、常规延期、部署问题、数据迁移、安全组件加固、热发布。热发布：指通过应用系统

12、前台界面操作的方式完成业务功能或逻辑变化的一种操作行为。具备热发布功能的模块通过预登记方式管理，由运维负责人负责。登记时，对于已有功能，应核对功能上线时的测试是否完整。若否，重新测试。 若为新功能，按正常发布流程发布后登记 热发布窗口暂定为每天的非工作时间，即：中午12：00-13：00 和 18:00后。热发布单独设立指标，数据进行单独统计。热发布评估要求： 业务方，窗口内发布-业务代表，非窗口内发布-业务方部总室，邮件即可，项目经理提供 开发负责人（Remedy平台），运维负责人（Remedy平台）Ø对于未完成目录登记的热发布申请，应按照业务需求类紧急发布进行申请与发布准备。2、

13、窗口的分类常规窗口指年初定义的某一类系统可以安排发布的固定时间点，每类系统每月一个常规窗口，如寿险常规发布窗口，产险常规发布窗口 独立窗口对某个具体的系统，单独约定可安排发布的时间点，不限数量，但需事先确定。独立窗口目前采用两种模式：1、除每月常规窗口外，固定当月1天作为独立窗口。适用于结佣类、结算类、传统互联网应用。 2、除常规窗口外，设置3个不固定窗口或每周设置一个固定窗口，适用于创新类应用、新互联网应用。窗口外：指不在预定义的窗口内发布的情况。3、缺陷类紧急发布分级标准缺陷修复类紧急发布，按紧急程度划分为三级：高级，中级，低级，不同级别的缺陷类紧急发布的发布时间要求不同。 维护团队发现的

14、缺陷，由维护团队进行评估定级，通过缺陷流程传递给开发。 开发团队发现的缺陷，由开发团队征询维护意见进行定级。 在提交发布申请时，开发方应提供本次发布所修复的缺陷描述，缺陷级别，维护负责人在remedy的评估意见中，应对级别是否正确给出意见。 不同级别的缺陷类紧急发布的发布时间要求见下表： 缺陷级别 发布时间要求 高级 修复版本测试通过后，当日发布 。中级 修复版本测试通过后，就近的周五发布。低级 缺陷版本测试通过后，就近一个常规窗口进行发布 。安全组件加固类紧急发布的时间要求，参照缺陷类，根据安全部提供的关于漏洞的说明和风险等级，具体时间要求为：漏洞风险 发布时间要求 高、极高 修复版本测试通

15、过后，当日发布 中修复版本测试通过后，就近的周五发布 低修复版本测试通过后，就近常规窗口发布 4、签字件标准发布类型业务方审核要求 IT方审核要求常规发布、独立发布无 无紧急发布-业务需求类 公司分管领导 /集团一级部领导开发部门总经理、CAB、IT中心一级部领导 紧急发布-缺陷修复类无开发部门总经理、CAB、IT中心一级部领导紧急发布-热发布类窗口内发布-业务代表，非窗口内发布-业务方部总室，邮件即可开发部门总经理、CAB、IT中心一级部领导紧急发布-常规延期类公司分管领导 /集团一级部领导开发部门总经理、CAB、IT中心一级部领导紧急发布-部署问题类无开发部门总经理、CAB、IT中心一级部

16、领导紧急发布-数据迁移类无开发部门总经理、CAB、IT中心一级部领导紧急发布-开发组件加固类无开发部门总经理、CAB、IT中心一级部领导配合发布-第三方平台类提供第三方正式函件或通知 开发部门总经理、CAB、IT中心一级部领导配合发布-监管类提供监管机构、行业协会正式函件或通知开发部门总经理、CAB、IT中心一级部领导专项发布类公司分管领导 /集团一级部领导开发部门总经理、CAB、IT中心一级部领导注意，签字形式不限于纸质，可采用其他可识别、可记录的方式，如邮件。三、格式要求1、发布手册发布手册须按照发布手册模板的格式填写，对于新系统和尚未采用手册模板的系统，联系发布管理功能区进行手册模板的商

17、定。（模板在s 端口9999 ，用户名和密码请向发布管理功能区获取）每次发布前，项目组除填写应用发布和数据库发布的内容外，必须填写发布基本信息、发布方案、以及应用和数据库操作的相应回退方案。 对发布当晚的关联变更，应通过发布口径，在发布方案中一并体现，由发布管理团队根据发布方案统一安排，避免发布和变更间的冲突。开发团队须确保发布方案的完整性。发布手册由开发团队提供，但手册中和生产环境相关的路径、IP地址、账号，维护团队应严格审核，以确保和生产环境一致。发布方案的要求：项目组提交发布操作时，必须提供发布方案，方案中应写明与发布关联的变更内容，若本次发布的版本有非功能性方面的需求（如：监控、备份、

18、容量、可用性等），必须在发布方案中一并说明。回退方案的要求：回退手册的编写要尽量详尽、傻瓜化，强化实施操作步骤。2、版本库目录开发用于上传ftp版本库的目录如下： 端口：9999账号：默认用户名为系统英文简称，如产险2003版银保通系统，其用户名为PT03BAI。帐号异常的处理方式：UC联系“服务导入值班员”检查， 33965995。由于涉及到自动打包及材料审核，ftp的发布材料放置必须按照以下规则：发布材料上传后必须包含用于比对发布材料准确性的发布交付物清单，交付清单模板获取地址如下：FTP： 端口：9999 协议：SFTP用户名和密码请向发布管理团队获取。3、发布通知发布停机通知由发布管理

19、团队邮件发送，分以下几类：（格式不一一列出）1、 IT内部2、 分公司3、 神太可用性影响4、 业务分公司验证邮件。以下六个系统必须发邮件：产险2005人意险系统、产险2007版CIBS系统，产险2009版集中渠道管理系统、产险2007版车险承保业务系统、产险2007版集中收付处理系统、产险2004版车险理赔系统。发布管理团队应将应用系统主管部门的接口人纳入通知范围。业务部门接口人清单由需求部收集提供。四、角色职责1、发布角色按职能分类规划职能：发布规划负责人，审核职能：开发负责人、测试负责人、维护负责人、DBA、中间件、系统、网络、发布规划负责人协调职能：发布经理、发布协调员、执行职能：发布

20、操作员专家职能：技术支持团队、CAB专家验证职能：业务验证代表、技术验证负责人2、开发负责人：提供发布材料 提供技术支持 传达业务意见参与问题决策 3、测试负责人：提供测试结论 提供测试报告 换包测试支持 4、维护负责人预生产部署验证 生产部署验证 发布材料审核 换包回退决策5、发布规划负责人提供计划信息 进行计划决策 传达发布要求 6、发布协调员负责发布的整体协调和支持工作；负责发布通知的发送；负责发布材料的检查；负责召集发布评估；负责发布申请和相关工单的创建和派发。3、DBA审核数据库脚本，对于违规及敏感的内容提出质疑， 4、技术支持团队负责在发布当天或之后，提供相关领域技术支持。

21、6;对于发布后的现场保障要求：1)发布当天，开发、应用维护、中间件、数据库、系统、网络、安全团队，均现场支持。对历史发布换包次数多或发布后故障较多的系统，发布当晚，测试团队须安排人员现场支持；2)发布后第二天，凡符合以下情况的，除应用维护、中间件、数据库、系统、网络、安全团队现场保障外，开发团队须安排核心人员现场保障；a)14个核心系统；b)历史发布故障记录多的系统（发布故障率由运维团队统计历史数据，给出参考指标）；c)发布过程中有换包情况的（测试团队也需安排现场保障人员）。5、业务验证代表业务验证：由业务代表负责组织业务验证，并通过邮件或UC反馈验证结果。业务验证要求：1) 需求提出人，应在

22、Jira平台中，如实填写业务验证要求，对于需要业务验证的，必须提供验证负责人姓名及联系 。验证负责人应按约定做好验证工作，并将验证结果邮件发至发布管理团队。请需求管理部向业务部门做好宣导工作；2) 负责需求受理分析的需求管理部、开发部需求分析人员，应检查业务验证联系信息填写是否完整，若否，应将需求退回提出人补全信息；3) 发布规划负责人在整理发布计划时，若发现业务验证联系信息不全，应通知需求分析人员核实完整，并将完整的业务验证要求清单提交发布管理团队；4) 发布过程中，若发现业务验证联系信息无效，应通知需求分析人员联系业务部门及时安排验证工作；5) 对于发布过程中出现验证信息无效的情况，发布后

23、，通过问题机制定位原因，加以改进。五、各主要环节1、提供发布计划a.内容由发布规划负责人整理确定每天的发布计划，计划内应包含：发布时间、发布类型、计划交付时间、发布原因、发布必要性说明、发布风险说明、业务验证安排信息、应急预案、系统关联性说明。发布计划应经开发部门总经理审核同意。b.提交发布规划负责人通过邮件，发送至发布管理团队的专用邮箱“应用发布窗口”。发布规划负责人应将开发部门总经理的同意意见转发发布管理专用邮箱。c.登记发布管理团队在收到发布计划后，在发布信息平台上登记。d.修订发布计划有任何变动，发布规划人应立即邮件告知修订内容与原因2、发布版本交付a.提供材料开发团队将发布版本和相关

24、材料，上传至专用的版本服务器。提供的版本材料应包含：交付物清单，程序包，脚本，发布手册（手册里必须有发布方案），配置文档（如有），版本清单，申请表，系统关联性清单。b.提供测试意见 测试负责人在版本测试通过后，在版本库对应系统的测试通过的版本目录中，创建“测试意见”目录，放置“测试通过.txt”文件，并上传测试报告。c.材料检查 发布协调员，对发布交付物清单中的MD5码和实际交付物的MD5码进行比对。d.材料审核，运维、DBA、中间件、网络等发布协调员根据发布方案内的说明，将需要其他团队审核的发布材料邮件发送给相关人员进行审核各技术团队收到审核材料后，应及时审核，并将结果告知发布协调员，未及时

25、答复的，视为审核通过。e.上传发布用版本库 发布协调员3、remedy评估和派单a、创建发布申请，添加评估人由发布协调员创建发布申请，添加包括开发、运维、测试、发布规划负责人、安全扫描负责人、预生产协调员、发布经理等评估人14个核心保障系统的常规发布，安全部参与评估。其他系统不要求。b、remedy评估 各评估人在remedy申请中填写评估意见，具体评估要求见下表：开发负责人、测试负责人、运维负责人以CMDB中登记的姓名为准。测试意见需在首行明确给出以下两种意见之一： “测试通过。”见此意见，即为本次发布可以进行；“测试不通过。”见此意见，即为本次发布不可进行。c、派单 各方评估通过后，发布协

26、调员将发布工单派给相应的操作人员。d、启动任务发布操作人员收到变更并创建任务后，由发布协调员启动任务。4、发布评估和排期a、核实实际发布清单 常规发布，由开发部召集，业务部门、需求管理和维护团队参与，对发布准备情况、发布风险，按系统逐一论证评估，形成纪要。发布管理团队整理实际发布的清单，在uc群内进行评估，评估内容包括关联系统清单，发布方案评审等。发布评估每个工作日下午进行，除确认当天发布清单外，须对第二天的发布计划进行评估。发布评估结果，需报送生产调度会议（CAB）审核通过。对于非常规发布的，由生产调度会议上报一级部领导审核。发布评估要点如下：系统发布的必要性： 发布原因 不发布的业务影响：

27、用户范围、用户类型、用户数量 目前采取了哪些应急措施发布方案：对系统做哪些变动 发布风险： 发布停机的影响范围：用户范围、用户类型、用户数量 发布失败的影响范围：用户范围、用户类型、用户数量 关联哪些系统，这些系统的影响范围是什么有无应急方案，是什么。发布保障： 发布后有何保障措施，特别是业务验证是否已安排 b、发布排期 发布管理团队确定每个系统发布的时间和人员后，编制发布排期表，邮件发送相关团队。5、预生产验证a、快照及数据库刷新 月初的5-6号左右，由发布协调员以邮件方式通知灾备人员进行数据库刷库与快照的操作，灾备区于一周内完成并反馈完成情况。b、部署及验证 生产发布前要做预生产的部署验证

28、操作，由维护团队负责，操作方式与生产发布操作一致，帐号口令从灾备的特权平台进行获取，口令不正确的情况下，操作人员可以找发布协调员协助解决。发布结束后须向发布协调员反馈结果。发布管理协调人将在remedy申请中填写预生产验证结果。c、派单发布申请提交后，派出预生产的变更工单。6、预生产同步管理 /环境借用a.预生产同步管理由基础部变更协调团队分派预生产环境的同步变更工单，由发布管理团队集中受理后，根据环境当前使用情况，安排同步时间，转派至相应的执行团队完成同步操作。b环境借用申请方将申请邮件发至“应用发布窗口”邮箱，发布管理团队评估后，根据申请时间范围，判断环境是否可以使用，邮件进行反馈。如同意

29、借用环境的，须先做快照，按借用需要进行刷库，完成后交付借用者，待环境借用完毕后，再进行快照的恢复与刷库，并对期间此系统产生的生产发布和变更安排同步。7、发布过程实施1、申请账号发布操作员在特权平台上获取应用、数据库发布相应帐号的口令。实际操作中如在特权平台上无法获得相应密码，向发布当晚提供支持的对应技术团队人员寻求解决 2、操作发布操作员按照发布手册的方案和步骤进行操作3、反馈结果发布操作员将操作的结果反馈发布协调员。发布操作员须在“当晚发布沟通uc群”告知发布开始与发布结束。4、记录问题如下情况请必须记录相关问题，以方便问题后续处理：1、发布操作与操作手册不相符2、发布中产生换包，与追加或减

30、少发布内容3、其他影响发布顺利进行的问题发布操作人员或发布协调员在发布信息平台中记录发布中发生的问题问题记录格式：发生时间：20xx-xx-xx xx:xx现象: 在（操作、验证等）时，（操作员、开发、运维等）发现（具体现象）原因：（开发、运维、数据库、中间件、当晚值班人员等初步定位的原因）处理过程：由（开发、运维、发布规划、测试等）同意更换或添加(发布包、数据库脚本、配置文件，发布手册)，由操作员执行。或由（数据库、中间件、值班人员等）进行（具体处理内容）问题处理时间 ：xx分钟操作人：xxx协调人：xxx8、发布验证1、发布操作结束后，应用负责人进行技术验证并反馈发布协调员，技术验证应按事

31、先制定的技术验证方案执行。2、技术验证通过后，应用负责人告知发布协调员，协调员通知预先安排的业务代表进行验证。3、业务代表进行验证并通过oa或者uc反馈结果，业务验证应按事先制定的业务验证方案执行。9、结果通知由发布协调员发送发布结果通知：1、短信方式2、邮件简报方式：发布前1封，发布后2封10、发布回顾 每日生产调度例会对昨天的发布结果进行回顾。11、发布异常处理a.发布中补单的要求： 1、对于发布过程出现的问题，技术支持团队给予临时性的处理方案（发布手册是正确的，因为权限或账号等问题导致的），无需提交补单。2、对于发布过程出现的问题，技术支持团队给予定性的解决方案（发布手册是不完善的，需要

32、修改发布内容步骤或方案），需提交补单。3、技术支持团队在处理问题过程中给出尝试性的解决方案，以最终解决问题的方案来参照上述1和2决定是否提交补单。4、其他情况，由服务导入功能区现场协调负责人和操作团队现场负责人商议决定是否补单。5、remedy上补单摘要必须以“补单”开头。b. 回退所需进行的操作步骤：根据回退时间点的定义，发布至回退时间点时，发布管理团队向运维和开发团队确认是否回退的结果，结果为回退的，执行回退步骤，结果为继续发布的，告知新的发布预期结束时间点。c.发布操作或验证时间超时：对发布超过预估时间较多的现象进行记录并且了解超时的原因，对于超时严重至回退时间点的，启动回退评估方案d.

33、无法找到所需支持人员的情况：上升至ECC值班经理进行处理发布和变更实施过程中的问题解决时效要求：若出现支持人员无法到位的情况，现场协调人员应及时将问题升级，ECC值班经理作为当天数据中心的最高管理人员，有人员调度和安排权限，紧急问题应及时报值班经理。对于支持团队，应确保支持人员的技术支持能力，避免出现同一团队给出不同方案的情况。e换包流程定义1、 属于环境配置问题，或语法、格式错误，引起的换包。此类换包，由维护负责人对换包内容和更换的文件进行检查和判断。如能确定情况属实，则可以允许换包。若无法确定实际更换的内容，则视同第二种情况的换包。2、 非配置类和语法错误类问题，引起的换包。此类换包，所更换的文件，必须经测试通过后方可放入生产。若对应系统的测试工作由测试部负责，则由测试负责人出具是否通过的意见，若测试工作仍由开发部负责，则由开发部的相关负责人出具意见。3、 当晚换包申请方邮件通知角色：发布规划负责人（开发一：姜宜辰