DevOps 最佳实践: 第 4 部分 通过 DevOps 驱动敏捷应用生命周期管理
-
简介
DevOps 通过推广一组务实的原则和实践从根本上转换了开发和运维专业人员一起工作的方式，可以帮助交付可靠、安全和没有缺陷的软件和系统，尤其是当这些软件和系统有可能会威胁整个企业的成功的话。DevOps 的主要关注点在于改善沟通和协作，这是任何团队得以一起有效工作的两个核心的质量要素。许多组织认识到还有更多其他利益相关者也可以同样从 DevOps 方法中受益，包括信息安全（InfoSec）、质量保证（QA）以及测试。应用生命周期管理（Application Lifecycle Management，ALM）的范畴非常广泛，包括从由产品所有者所设想的服务策略和设计，到当发生事故时所需的帮助中心电话服务，所有这些都会影响交付给客户的服务的成功交付。这篇文章描述了如何来对整个应用生命周期应用 DevOps 原则和实践。
变更对软件可靠性、安全性和质量的影响
软件及系统开发是一个复杂的工作，通常牵涉到许多利益相关者并需要可观的时间和资源来完成。应用生命周期管理（ALM）提供了相关的结构和过程来从开始到结束指导这些工作。应用生命周期帮助指导每一个对系统实现有贡献的资源，例如包括从帮助定义需求的产品所有者，到确保服务持续可用的运维专业人员。
大型企业系统开发很容易由于软件或系统开发工作中任何一个步骤所引入的缺陷而受到严重影响。很常见的是，组织层面的各种竖井会导致沟通和协作的缺乏，而且这一问题可以引起非常严重的后果。DevOps 的原则可以被成功应用在开发和运维之间的沟通和协作上，可以改善应用生命周期中每一个利益相关者与团队其他成员之间交互的方式。这种自组织、跨功能的团队已经逐渐显见于很多成功的敏捷开发项目，而且被认为是核心的组成部分。这些高性能的团队可以担当很多方面，从而让整个软件和系统开发工作更加成功。在整个应用生命周期中使用 DevOps 最佳实践的关键是理解生命周期中每一个功能之间的联系。应用生命周期功能和不同功能之间的联系
应用生命周期中的许多点要求跨多个利益相关者的沟通与协作。这些点有许多是生命周期中的不同阶段，其他的则是在众多功能之间交集中的点，这些都是团队应当了解和管理的：
任何软件或系统开发工作应当从一个关于要构建什么的清晰的规格说明开始。
需求定义
生命周期中每一个利益相关者都需要理解需求。需求变更总是发生，经常是由于：
- 您对于所想要构建的东西有了更多的理解。
- 市场发生了改变。
当您理解更多的时候所发生的需求变更
通过每一次的迭代，在进一步理解技术和系统的能力（或局限性）之后，业务专家经常都会精炼和校准他们的需求。显然，对需求的变更需要被追踪和控制。许多组织使用版本管理工具来维护一个关于需求变更的完成记录，并监管需求变更的审批。实现在需求与测试用例之间的可追溯性也是很常见的，这可以用来验证发布版本中的功能是否符合预期。这些都是追踪需求的重要方面，而且他们与 DevOps 原则中关于良好的沟通与协作的原则是一致的。
一个更加务实的场景例子要求所有产品所有者之间必须有有效的沟通，无论是开发团队、测试团队还是运维团队之间的沟通，这对管理由于外部业务压力所带来风险来说是必须的，包括市场上竞争者的涌入。
由于市场压力所带来的需求变更
一个发布版本如果突然赶着投入生产环境通常会产生不可接受的风险。DevOps 关注于管理部署相关风险的需求。同时还创建工具和过程来提供敏捷性，从而来使得持续交付竞争优势成为可能。有时候，一个未按时完成的最后期限（deadline）会比一个赶工期的部署更能招致更大的风险。作为一个部署工程师，我知道很多时候，更快交付应用到市场会有多重要，因为未按时完成的最后期限有可能会将公司的未来毁于一旦。为了选择对公司从整体上来说最佳的行动，技术专家和业务专家需要更加有效的协作与沟通。
比竞争者抢先交付系统的一个测试版（beta version）到市场，有时候远远胜过系统故障或停机所带来的风险。在这些案例中，您需要完全理解风险，并与所有利益相关者进行沟通。通常，风险可以被额外的随叫随到支持服务（on-call support service）所缓解，这在 ITIL V3 框架中被称为早期生命支持（early life support）。
例如，在一个用例中，一个新交易平台的测试版被交付到一个只有两个客户的市场，而且这两个客户喜于尝试新的测试版平台。通过提供额外的支持，故障可以被解决。很快之后，销售团队得到了大量新订单，公司在市场上从众多相近的竞争者中胜出。
在本例中，运维团队理解部署一个并不完美的系统的要求。在一个月之后，团队为剩余的其它客户交付了经过完全测试的系统。这一案例中，团队同意交付一个测试版到生产环境，因为业务专业人员表达了迫切感，并认识到首先交付市场的竞争优势。系统设计
系统设计要求来自许多不同利益相关者的专业技能。在设计阶段，DevOps 原则对于项目的成功来说非常关键。
- 开发人员（developer） 通常更加理解技术，但对于基础设施是否可以满足峰值性能要求方面并不一定完全了解。
- 架构团队（architecture team） 可以帮助开发和运维团队理解特定技术框架的能力和风险。
- 业务用户（business user） 可以帮助技术专家理解潜在的峰值用量以及潜在的长期增长和性能需求。
通过跨功能视图，系统基础设施团队可以创建一个务实的系统设计，可以让产品更快交付到市场，符合预算，并具备满足长期能力需求的潜能。在系统设计阶段，团队需要以组件接口的术语来理解和文档化所有依赖关系，并考虑运行时依赖关系。
建模依赖关系
当今的软件系统有很多优秀的能力，但它们同样涉及到了显著的复杂性。参与开发、集成和定制这些系统的技术专家通常需要拥有广泛的专业技能，和对技术及其依赖关系有深入的知识。很常见的是，这些专家通常只短期参与项目，并随后参与到下一个项目，对维护系统所需的依赖关系和接口没有留下足够的信息。
即便软件可以在它首次部署时运行得很好，如果未来需要进行变更，对依赖关系没有足够的知识的话，这对于更新系统来说便充满了挑战。为了在未来避免问题，您需要沟通和文档化一个全面的模型，以展示所需要的接口以及所有的依赖关系。因为这一信息会很快变得过时和不可靠，系统需要被重新设计以便使其依赖关系可以被自动发现和被很好地理解。
架构团队可以帮助开发团队派生一个文档化依赖关系的方法。例如，一个 XML 文件可以被用于发现和沟通依赖关系。为了设计可以易于维护的复杂系统，开发团队可以依赖于其他利益相关者所拥有的专业技能，包括架构、信息安全、质量保证（QA）、测试，以及对于系统成功运行来说非常核心的中间件维护专家。中间件管理
中间件（Middleware）通常被描述为介于操作系统和应用程序之间，或介于数据库与应用程序之间的软件层。中间件被认为是核心的但又是不可见的，包括支持消息队列的服务或内存缓存管理器等等。中间件经常被一个专职的团队所管理，并需要专门的专业技能 。中间件专家被认为至少需要与开发团队、运维团队以及架构团队进行协作。在许多案例中，咨询数据库专家也是非常有帮助的。
数据库专家
数据库对于任何系统来说都是一个关键技术，但通常数据库管理员并未包括在 DevOps 跨功能团队中。因为数据库可以成为系统一个单独的失败点，对数据库的变更需要被理解和进行版本控制，这与其他任何配置项（configuration item）一样。DevOps 方法为了改善沟通与协作，对于想要获得成功的团队，推荐数据库管理员也应被包括进来。为了基于对数据库变更的理解来规划相关的应用程序变更，开发团队需要与数据库管理员一起协作。质量和测试团队也同样应该在整个应用生命周期中被考虑。
质量保证及测试
在整个软件和系统开发生命周期当中，质量保证及测试团队需要成为跨功能团队中的主动成员。在应用生命周期中的每一个利益相关者都可以从将质量保证及测试策略包括进来的决定当中获益，而且这一决定应当贯穿从早期阶段的需求收集，设计与开发，以及到功能与用户验收测试的整个生命周期。质量保证及测试同时还在系统维护中担当重要的角色，可以帮助管理与缺陷修复相关的风险，并持续进行维护。
知识管理
许多技术专家拥有贯穿整个应用生命周期所需要的广泛的知识和专业技能。DevOps 方法就是要应用优秀的沟通与协作方法，以便所有利益相关者可以作为一个跨功能和高度有效的团队进行工作。捕获每一个利益相关者所处理的知识非常重要，以便使团队可以定位和处理在系统的生命周期当中经常发生的事故。
持续集成与交付
贯穿整个应用生命周期，技术专家需要经常了解系统到底需要什么做什么和当前应当如何运作。持续集成（Continuous Integration）与持续交付（Continuous Delivery）提供了根本性技术用于集成经常发生的变更，并使它们变得可用。集成一个小的变更比集成一组变更要容易。而且，如果一个小变更无法工作，从中回退也要比判断一组变更为何中断系统并从它们中回退要容易得多。持续集成很有效，因为它降低了复杂性并使得识别集成事故的根本原因变得更加简单。如果您拥有自动化的集成过程而且经常执行这一任务的话，您将会更加容易识别和修复问题。
持续交付也以同样的方式运作。为了帮助一个团队从发布和部署中解放出来，应当让他们更加经常地交付小的代码包，而不是过段时间交付一个大的代码包。在部署任务方面，每周发布两次版本的团队要比每个月只发布一次版本的团队要轻松得多。即便如果您每次都发布整个系统，一小集合的变更也明显风险更低，即便问题发生也更容易定位问题。从整个应用生命周期的视角看，持续集成和持续部署最大的回报，就是提供了最新的代码可以被所有利益相关者进行评审的能力。里程碑发布版本（Milestone Release）或甚至测试发布版本（Test Release）都可以从 Scrum 迭代中获益，并使得验证需求、建立持续测试和更新改善系统设计成为可能，并让每一个利益相关者得以积极地参与到应用生命周期管理当中。这些变更也帮助持续改善过程。
对应用生命周期的回顾
许多组织由于他们不能以一种开放和诚实的方式讨论他们的成功及失败之处，而错失了业务机会。回顾是一个强有力的工具，可以使生命周期管理所有参与者都能开放和直接地讨论什么做得好，什么可以改进。DevOps 方法培育利益相关者之间开放的沟通，并使之迫切保持尽早和经常进行回顾。这一实践开发了一种诚实和开放沟通的文化。
结论
DevOps 并不仅仅是开发和运维这么简单。团队中所有参与到应用生命周期过程的重要信息的成员，都可以帮助跨功能团队变得更加有效和使之成为一个更高性能的团队。在开发团队和运维团队之间增加协作与沟通，可以改善双方的生产力和可靠性。扩展这些 DevOps 原则和实践到整个应用生命周期中，来将您整个组织转换成为一个更加合作和高性能的团队，从而获得更大的成功。
原文链接： http://www.ibm.com/developerworks/cn/rational/d-drive-agile-lifecycle-management-devops/index.html
