内容


DevOps 最佳实践

第 3 部分 通过 DevOps 实现 ITIL

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: DevOps 最佳实践

敬请期待该系列的后续内容。

此内容是该系列的一部分:DevOps 最佳实践

敬请期待该系列的后续内容。

简介

许多组织,从大型国际银行到互联网起步公司,都关注如何确保他们关键的基础设施及核心应用基础的可靠性和安全性。为了保持竞争力,这些组织需要在升级系统或引入新功能时最小化服务器中断的风险。这些中断有可能影响业务以及企业的信誉。IT 服务管理论坛(IT Service Management Forum,itSMF)的 IT 基础架构库(IT Infrastructure Library,ITIL)v3 框架提供了交付高质量 IT 服务所需的过程和功能的指南,并使 IT 服务与业务和目标相一致。

虽然 ITIL v3 的指南被高度认可,许多组织仍然在关于如何实现这些推荐的行业实践上遇到困难。DevOps 以实事求是的方式,提供了实现 ITIL 所必需的准确过程。这篇文章提供了实用的指南,来指导如何使用 DevOps 实践来实现 ITIL v3 框架中关于将服务从设计迁移到运维环节所需要的过程和功能。

配置管理数据库概览

一个在 ITIL 框架中最经常被运用的实践就是建立配置管理数据库(Configuration Management Database,CMDB),您可以将它用于验证在生产服务器上的代码组件(也被称为配置管理项,Configuration Items,CI)是否是正确的版本,并确保没有发生由于人为错误或恶意目的而产生的非授权变更。

ITIL 描述了使用 CMDB 来追踪对配置管理项的变更,并相应更新配置管理系统(configuration management system,CMS)。CMS 是任何高效变更管理系统的核心组成部分,并且依赖于 CMDB 来获得准确的信息。如果您成功实现这些实践,您的组织将会享受这一敏捷性带来的好处,而且能够通过交付新特性为业务交付价值。您同样可以管理和降低与更新任何复杂系统相关联的风险。

CMDB 及 CMS 是大型服务知识管理系统(Service Knowledge Management System,SKMS)的一部分。这些系统提供了范围广泛的信息,可以支持整个 IT 服务器管理过程。这一信息非常有价值,但它必须时刻保持最新和准确。

ITIL 框架建议配置管理项的变更以及它们的接口需要被追踪,但并没有为在技术层面如何追踪这些变更提供特定的指南。幸运的是,许多 DevOps 实践可以准确解释如何追踪对应用程序的构建、打包和部署的变更。当实现了这一切之后,这些 DevOps 实践将会帮助在 CMS 和 CMDB 中维护最新和最准确的信息。

追踪代码基线的能力对高效使用 ITIL 来说是必须的。服务资产和配置管理过程覆盖了这一需求。

服务资产和配置管理过程简介

服务资产和配置管理(service Asset and Configuration Management,SACM)过程的目的在于追踪和记录应用程序代码基线。许多组织在实现 CMDB 以及保持它们时刻更新 SACM 过程中所描述的最新和有用的信息方面遇到困难。ITIL 建议您追踪对配置管理项的变更。然而,期待手动更新 CMS 和 CMDB 是不切实际的。手动更新通常只能获得一些结果,而不是全部的准确信息。

一个更好的解决方案是去构建和部署 CMDB 可以自动发现的发布版本。您需要为您的应用程序能被发现而进行工程改造,以使 CMS 和 CMDB 系统能够被编程化更新。此外,构建可以被 SACM 过程编程化所发现的可验证基线,以及实现配置管理系统能够通过自动化过程时刻保持更新正确的和经过验证的信息。这一系列的文章解释了如何使用 DevOps 来实现 ITIL 所描述的发布版本控制和验证过程。

ITIL 发布版本控制和验证指南

ITIL v3 发布版本控制和验证框架描述了服务管理过程。它从建立一个有效的服务策略的需求开始,引导到细节服务设计,这部分设计将在服务设计包(service design package)中来描述。ITIL v3 框架描述了以下的发布版本控制以及验证过程,该过程可以用来将新的服务从设计迁移到运维:

这篇文章描述了这些过程所提供的价值,并接下来解释如何使用 DevOps 实现它们。

变更管理

变更管理过程评估,授权,并实现对服务的变更,这通常发生在您实现新的组件或更改已有的组件时。变更管理过程的设计目的是:

  • 评估一个变更的潜在下游影响
  • 降低风险
  • 改善所有利益相关者之间的沟通

变更顾问委员会(Change Advisory Board,CAB)是一个专门审核每一次提议变更的监管主体。变更管理驱动整个发布控制及验证过程。高效的变更管理会平衡由实现新变更的需要所带来的风险,并使之能为业务交付价值而使组织具备竞争力。变更管理依赖于工作流自动化,以及资产和配置管理基线的准确和最新的信息。

服务资产及配置管理

服务资产及配置管理(Service Asset and Configuration Management,SACM)过程管理软件资产,并维护配置管理项的准确信息。这些过程创建和管理基线,追踪每一个配置管理项变更的状态。

SACM 还提供了所有其他的过程和功能,例如 CMDB 及 CMS,而且还提供了配置基线状态的准确和及时更新的信息。

每一个软件资产需要一个所有者(owner)来负责该资产,并找出相应可以准确评估和鉴定变更潜在下游影响的主题相关专家(subject matter expert)。

理解不同配置项之间的接口非常重要。SACM 追溯变更到每一个基线。这一追溯能力对于可追溯性(traceability)来说非常关键。对于许多组织来说,追溯是遵从联邦法规和审计控制所必须要求的。通过及时更新的信息,可以更加容易运行业务,来确保实现所预期变更的敏捷性,执行变更计划,并在事故发生时作出响应。在许多方式下,SACM 是将其他发布控制和验证功能粘合在一起的“胶水”。SACM 中的活动包括:

  • 管理和规划
  • 配置标识
  • 配置变更控制
  • 状态核算
  • 验证及审计

软件配置管理计划(software Configuration Management Plan,SCMP)提供了策略,用于处理为实现代码开发阶段成功的应用程序构建、打包和配置过程所必须的所有活动。规划部分可以简单地指定发布迭代的时间表,或指定发布和部署过程的每一个方面。SCMP 传统上由四个经典功能所组成:配置标识(configuration identification)、状态核算(status accounting)、配置变更控制(configuration change control)以及配置审计(configuration audit)。为每一组这四个功能指定以下信息:

  • 配置标识:为每一个配置项指定一个命名规则,以帮助确保您为每一次版本发布选择了正确的配置项。
  • 配置变更控制:包括用来管理对配置项的变更、管理新发布版本,及撤销配置项等方面的特定规程。
  • 状态核算:文档化一个配置项从最初始的创建到终结的整个路径。状态核算包括配置基线及被开发的配置项的状态。
  • 验证及审计:帮助确保正确的配置项被部署了。审计信息可以被独立验证。组织依靠被良好定义的过程来管理发布和部署。

发布及部署管理

发布和部署管理(Release and Deployment Management,RDM)过程关注于构建、打包、部署以及测试新服务所必须的活动。RDM 创建了详细的计划来帮助确保配置管理项能够被成功地构建和测试。这些计划强调了自动化过程,这些自动化过程是可重复和可验证的。RDM 使得利益相关者可以更容易地理解有哪些活动正在完成,并增加了他们对服务从设计迁移到运维后的效果感到满意的可能性。

RDM 为构建作准备,包括准备自动化过程,并帮助确保测试被执行以及测试环境是协调的。RDM 过程包括了对服务在刚迁移到运维时,与初始引导及生命周期早期支持相关的任务。当 RDM 验证所有这些步骤之后,它还负责评审和关闭迁移工作。

当您将一个服务从设计迁移到运维时,服务的验证和测试也是关键的方面。

服务验证及测试

服务验证及测试(service validation and testing)帮助确保 IT 服务满足:

  • 与目标相符:与设计所包括的需求相一致
  • 与用途相符:与设想用途所需需求相一致

服务验证及测试过程帮助确保服务设计包准确定义了需求。它同时还帮助确保服务为业务提供价值,并在生产环境中得到很好地执行,以及满足了质量的目标水平。

这一过程关注于以下方面所要求的活动:

  • 创建和验证测试计划
  • 管理测试计划和测试环境
  • 执行测试
  • 验证结果
  • 与利益相关者沟通结果
  • 创建测试报告
  • 根据退出条件评估测试

在测试阶段之后,您需要评估变更以确保它为业务交付了价值。

变更评估

依据更新后的代码应被如何使用,以及代码是否交付了服务的预期水平,来判断变更是否满足了客户的所需。变更评估(change evaluation)确保您理解变更的预期和非预期影响。变更评估监控可预测的性能并管理风险。

请求履行

请求履行(request fulfillment)是运维的一部分,关注于完成常规请求的过程。请求履行流水线化了常规请求的完成过程,解放资源使之更加关注于更加需要资源和非常规的请求。

知识管理

生命周期过程覆盖了在发布控制和验证范畴之下,提供支持可靠和高效服务所需的核心知识。知识管理(knowledge management)过程捕获一系列广泛的信息,可以帮助驱动整个过程。配置管理数据库和配置管理系统是服务知识管理系统的一部分。

实现 ITIL 的 DevOps 实践

为了帮助实现 ITIL v3 框架中所包含的指南,DevOps 实践满足了以下方面:

关注于更好的沟通

DevOps 实践强调改善开发和运维之间的沟通与协作这一目标。增强沟通所需的结构贯穿描述在整个 ITIL 框架里。DevOps 实践增强开发团队、运维团队和其他关键利益相关者之间的沟通,这些利益相关者还包括信息安全(InfoSec)、质量保证和测试团队。这些实践使得跨不同的群体分享知识和首选的实践,建立跨功能团队,并降低竖井带来的影响等方面成为可能。

IBM 产品和解决方案支持 DevOps 方式并加速其引入。它们都构建在开放标准之上,并以互相之间能结合工作,以及能与开源解决方案结合工作作为设计目标。了解更多关于 DevOps 产品的信息:

构建可被发现的软件

DevOps 实践自动化相应的过程来构建、打包和部署应用软件。持续集成采用可验证的源代码基线构建代码,而这些代码基线在开发版本控制库中受到保护。对于里程碑版本发布,代码基线则存储在最终介质库(Definitive Media Library,DML)中。

这些规程与 SACM 采用编程化的方式发现和验证基线的过程是相吻合的。配置变更的自动化发现使得 CMDB 和 CMS 保持更新成为可能。自动化发现依赖于自动化构建过程。为了实现 SACM,以及包括在 CMS 和 CMDB 中实现正确、及时更新和可验证的信息,您需要在一开始就将质量建立到构建过程里。您需要嵌入版本 ID 到配置项中,以便使版本 ID 可以被用于物理配置审计。许多这些工具和技术还同时采用加密哈希值(cryptographic hash)来验证配置项的合法性和完整性。

可以考虑采用 Rational Team Concert 来使您与跨越多个规程(开发、运维、测试,等等)的软件开发专业人员得以相互协作。

一旦配置项被使用自动化和可验证的过程所构建好,下一步就是将它们打包到发布版本基线中去。

建立基线发布版本

发布和部署管理(Release and Deployment Management)过程确保应用程序可以被打包和部署。使用自动化的构建和持续集成实践在可验证的包(package)中创建发布版本。确保这些包(package)包括了其中所包含所有配置项的清单,以及被加密签名的资源配置文件(manifest)。这一加密哈希值可用于两个重要的功能。它可以验证包是来自于预定的源(不可抵赖),以及确保包没有被篡改。

持续交付

持续交付(Continuous Delivery)依赖于支持部署流水线的自动化脚本的创建。为了实现持续交付,您需要为整个应用程序的构建、打包和部署等任务编写脚本。部署流水线提供了用于确保信息可以在配置管理系统、配置管理数据库,以及最终介质库中被自动化更新的理想构造。部署流水线同样还提供了信息可用于服务知识管理系统(Service Knowledge Management System)。这一信息可以支持持续改善 IT 服务。以下的产品实现了持续交付功能:

自动化工作流

在 ITIL v3 框架中所描述的过程依赖于工作流(workflow)自动化,来确保利益相关者可以理解和完成分配给他们的任务。自动化工作流使需求在被逐渐实现时得以被追踪,并改善查看变更、变更的影响、审批和验证的能力。

多个 IBM 产品支持基于任务的开发(task-based development):

放大反馈回路

DevOps 关注于为所有利益相关者放大反馈的途径。反馈可以改进过程和增加沟通的有效性。在线虚拟社区帮助建立对整体过程改进的高效沟通。

迭代化改善过程和自动化

ITIL v3 框架依赖在作为 DevOps 敏捷文化所固有的迭代化开发过程之上。DevOps 团队需要指导这些过程来估计其实现是有效和适于使用的。通过敏捷追溯的帮助,团队评估每一个过程来断定什么做得好,什么做得不好,以及我们能如何进行改进。通过这种方式,相关过程可以随着每一次迭代而得到改进。

结论

ITIL v3 框架提供了关于 IT 服务管理的卓越指南。它包括的指南可以对跨发布控制和验证生命周期的过程进行指导。DevOps 还提供了规程可以让 ITIL 更加有效和实用。通过这些正确的工具和过程,组织可以认识到可靠 IT 服务的价值——帮助建立业务和改善质量及生产力。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational, DevOps
ArticleID=969808
ArticleTitle=DevOps 最佳实践: 第 3 部分 通过 DevOps 实现 ITIL
publish-date=04282014