变更和发布管理

1）变更和发布管理的概念和目标

变更是指服务或基础设施配置项的变动，变动需求来自于用户或公司内部。发布则是将新增或修改后的配置项经过测试后移入实际生产环境。

ISO 20000定义变更管理目标是确保以一种受控的方式对变更进行评估、批准、实施和回顾，主要活动应包括：

（1）清楚定义服务和基础设施变更的范围并形成文件。

（2）对所有的变更请求进行记录、分类，评估变更请求的风险、影响和业务收益。

（3）变更管理流程应包括回退和纠正失败的方法。

（4）变更必须被批准、检查，并以受控的方式实施。

（5）为确保成功应回顾所有变更以及实施后所采取的措施。

（6）建立策略和流程控制紧急变更的授权和实施。

（7）建立变更评审委员会，负责对变更进行评估、批阅以及实施后的回顾。

（8）计划的变更日期应作为变更和发布调度的基础，时间表应包括批准实施的所有变更以及建议实施日期的详细信息，建议的实施日期应与相关方沟通并维护。

（9）应定期分析变更记录，以检测变更级别的提升、频繁发生的类型、新出现的趋势以及其他信息。

（10）应记录变更分析所得结果和结论，在这一过程识别出的改进措施应被记录并作为服务改进计划的输入。

一项或多项经过审批的变更组成了发布，发布管理采用项目规划的方法实施IT服务中的变更，贯穿于变更的整个生命周期。与变更管理不同的是，发布管理更加关注变更的实施，而变更管理关注的是变更过程中的风险，发布管理流程应在变更管理流程的控制下进行。ISO 20000定义的发布管理目标是交付、分发并追溯在一个版本中发布到实际运行环境中的一个或多个变更，主要活动应包括：

（1）就描述版本发布的频率和类型的版本发布方针达成一致，并形成文件。

（2）服务提供方根据业务情况对服务、系统、软件和硬件版本的发布进行计划。有关怎样进行版本导入的计划应获得所有相关方的同意和授权，如客户、用户、操作和支持人员。

（3）发布管理过程应包括失败后的回退和补救方法。

（4）版本发布计划应记录版本日期、可交付成果并关联相关的变更请求、已知错误和问题。发布管理过程应向事件管理过程传递适当的信息。

（5）评估变更请求对发布计划的影响。发布管理程序应包括配置信息的更新和变更，并做记录。紧急的版本发布应根据已定义的过程进行管理，并与紧急变更管理过程相对接。

（6）建立可控的验收测试环境，用于在版本分发前的创建和测试。

（7）对版本及其分发进行设计和实施，以保证在安装、处理、打包和交付过程中硬件和软件的完整性得以维持。

（8）对成功或失败的版本发布进行测量，测量应包括版本发布之后与版本发布相关的事件。测量分析应包括对业务评估、IT运作和支持性人力资源的影响评估，并作为服务改进计划的输入。

2）银联数据的变更和发布管理

所有配置项的变动，包括生产及灾备环境硬件设备、应用系统、系统软件以及数据库的变动都在银联数据的变更管理范围内。特别的，新服务的产生所导致新增配置项、旧服务的废弃所导致废止配置项、生产系统日志级别调整、故障设备的更换和系统切换演练等变更性质的生产维护类操作也属于变更范畴。银联数据的变更和发布流程是通过银联数据服务台进行整个过程的流程化管理控制的，主要步骤如下。

（1）变更方案编写和审批。

变更提交人创建变更单，填写变更需求，初步确定受影响的服务，参照变更分类标准对变更单进行初步分类，然后将变更单提交给方案编写人处理。方案编写人对变更进行如下三个方面评估，初步确定是否接受该变更：

根据上述评估结果调整变更原有优先级（影响层级和紧急性）和分类，编写变更计划和变更方案，将变更单提交给相应层级的变更审批人审批。如果审批通过，则可进行后续的开发和测试流程。特别要注意的是，对于需要得到客户确认的变更，必须得到客户的确认后方能进行后续开发测试流程。

对于突然的服务中断或服务组件损坏，变更是需要立即进行的。对于此类情况，如果变更紧急以至于来不及提交变更单，可暂不提交变更单，待变更实施完成后再补建紧急变更单。

（2）开发测试。

对于应用变更，方案编写人根据变更需求和已制订的变更方案，编写设计说明书，进行应用开发、单元测试并编写单元测试报告。客户支持人员据此编写或更新功能说明书、用户操作手册等文档。开发完成后，还应由开发复核人对上述开发成果进行复核，直至复核通过才算开发完成。开发复核通过后，测试负责人根据变更需求和已制订的变更方案，编写测试计划和测试案例，进行功能测试并编写功能测试报告。功能测试通过后，变更提交人协助用户进行用户验收测试（UAT）并提交测试报告，如用户验收测试通过，即可进入发布环节。

对于非应用变更，不需要进行开发设计，方案编写人只需根据变更需求和已制订的变更方案对硬件或系统软件进行相关配置。如果该硬件或系统软件需要进行测试且具备测试条件，则在实施并通过相关测试后方能进入发布环节。

（3）发布计划和方案。

变更进入到发布环节后，发布提交人可根据各个变更单中的变更计划，通过银联数据服务台生成或更新发布单，将发布单提交方案编写人进行计划和设计。发布计划的内容包括：发布的实施时间、发布内容（关联的变更、打包发布的发布清单、应用发布的版本信息等）、人员安排（发布实施人、实施复核人）。根据发布计划，方案编写人准备待发布的配置项和编写发布方案，交由相关复核人复核通过后才能够使用。

（4）提交物审核。

银联数据在最初建立和开始运行IT服务管理体系时，根据各应用系统本身的性质（包括性能、复杂程度、功能完善程度等）、各种硬件设备的性质、系统软件的性质、后台数据库的性质以及客户对发布的需求（如客户要求的发布频率和次数等）等，制订了发布策略，对发布管理的组织、角色和责任，发布类型和频次，发布授权，发布的命名和版本标识，将变更打包发布的方法，发布的验证和接受，发布的实施要求等方面进行了详细描述和要求。

发布管理员根据发布策略审核发布及其对应变更的各类提交物是否齐全，并将审核结果提交配置控制委员会会审或投产审批人审批时参考。其中，各类变更提交物包括需求分析文档、设计说明、单元测试报告、功能测试报告、用户验收测试报告或同意上线的说明、功能说明书和用户手册等。各类发布提交物包括发布方案、上线验证测试报告、集成测试报告、发布评估单等。

如果是应用类发布，配置管理员还会同时审核发布的配置项是否已提交到受控软件库。

（5）配置控制委员会会审、投产实施。

银联数据建立了配置控制委员会（Configuration Control Board，CCB）来对日常的发布进行管理，组成人员包括公司管理层代表、相关部门评审专家、发布管理部门负责人、发布管理员。

发布管理员每周一之前收集好本周需要进行的发布（已通过提交物审核）相关信息，组织召开配置控制委员会会议，在会上对上述材料进行上线实施评审。

如果配置控制委员会批准发布且其提交物齐全，发布管理员将评审结果及对发布计划的调整情况更新到对应发布单中，发布实施人根据发布方案进行上线实施，并在实施完成后记录实施结果。同时，实施复核人提供现场或电话支持，复核整个实施过程和结果。特别需要注意的是，对于高风险的发布单，经配置控制委员会评审通过后，还需要相关公司领导在银联数据服务台上进行投产审批，审批通过后方可实施投产。若发布属于新系统投产或对客户有直接影响，经配置控制委员会评审通过后，还需要完成相关上线准备后才能够进行投产实施。上线准备包括：客户经理向客户发布上线通知，必要时，分别安排面向客户和针对内部支持人员的新功能相关培训；客户经理和方案编写人需准备并发布包括接口文档、用户手册、监控需求、更新后的应急预案、新银行上线网络配置等文档。

（6）投产实施后续。

在发布实施后24小时内，如果没有回退操作即视为发布成功。如果发布成功，配置项维护人根据方案编写人提供的更新后的配置项信息进行相应的配置管理操作。之后，发布提交人审阅发布结果（包括配置项更新情况），如审阅通过，则可以关闭发布单。

如果发布失败，发布实施人应根据发布方案中的回退步骤进行回退操作，并记录回退结果。回退完成后，若需重新发布，则重新创建或更新发布计划。

（7）关键绩效指标。

目前，银联数据通过如表4.5所示的几个关键绩效指标来衡量变更和发布流程的有效性并识别待改进之处，根据统计频率定期收集这些指标值，并通过ISO 20000 IT服务管理体系的季度管理层服务报告，向公司管理层呈现这些指标情况。

表4.5　银联数据变更和发布流程KPI