内容


实现 “永远可用”

在实现无中断变更的同时提供创新

Comments

简介

下一次进入机场时,您可以看看身边疲惫的商务旅客。他们往往一边用智能手机交谈,一边在自己的平板电脑或笔记本电脑上工作。我们生活的世界是一个一旦停电就会导致效率低下的世界。除了少数例外,应用程序中的任何变化都会导致服务中断,客户不喜欢服务中断。

我们生活在一个不能容忍中断的时代。在当今的云计算、分析、移动和社交世界中,服务水平协议并不重要。人们期待其应用程序可用。分析从后台任务转变为实时业务交易的一部分。我们希望,当我们随时随地在手机和平板电脑上单击移动应用程序时,它们可以正常工作。公众对服务中断的反应会通过社交媒体被放大。中断可以摧毁来之不易的声誉。我们生活在一个扁平的世界里,在某个地方,全天 24 小时都会有人要使用我们的服务。不再有可用来实现计划性管理活动的 “下班时间”。换句话说,没有空间可用于计划性停机。

Always On(也称为持续可用)要求能够:

  • 承受组件故障。
  • 透明地承受灾难。
  • 无中断地引入变更。

在整个行业中记录并实现高可用性技术,比如减少单点故障。同样,诸如区域外异步复制之类的灾难恢复技术已让组织有望从天气、停电或其他灾难中恢复。然而,除了少数知名组织之外,大多数组织都可能在引入变更时造成中断。

也许我们应该首先从 Always On 的定义开始:

" 管理对解决方案的任何部分的计划变更,而不会影响服务的整体可用性的能力。"
 

Gartner 报告 "IT 服务连续性管理的炒作周期" 中指出:

"持续可用性涉及两个策略:高可用性(最大限度地减少计划外停机时间)和持续运营(最大限度地减少计划内停机时间)。"
 

最大限度地减少会影响最终用户的计划内停机,这样做还不够。几乎所有的计划性中断的原因都是维护操作(修复缺陷、安全补丁、硬件升级,或者将应用程序升级到下一个版本)。要在不中断的情况下引入变更,则要求使用有组织性、技术性的功能来管理对解决方案的任何部分的变更,使其不会导致性能影响、数据丢失,或影响解决方案的可用性。对服务的变更需要是透明的,而且不会损害用户体验。

大家都知道,一个系统是不可能永远不停机的。您需要提供停机时间窗口进行基础架构和应用程序的维护。关键的挑战是让这个 “中断” 对最终用户是透明的。无中断变更并不是没有变更,而是在引进变更时不会造成服务中断。持续交付中的关键准则是确保用户体验不会被削弱。

100% 可用性需要一种完全不同的方式来开发服务/应用程序,在部署中实现组件冗余,以便实现永远可用,并随着时间的推移和新版本的发布对其进行维护。这些都是严峻的挑战。

您可能会得出一个结论,解决这个问题的秘诀在于 DevOps 和敏捷开发。但 DevOps 只是持续交付解决方案中的一部分。解决方案的实际架构通常需要一定水平的重构,组织需要改进其部署实践。

支持无中断变更的需求和方法就是本文的重点。我们定义了不同类型的变更、组织方面和文化的重要性。我们对以不中断的方式引入变更的实践和技术,以及产品功能进行了描述。

以不中断的方式引入变更的迫切需求

在最近题为 "为什么基础架构很重要" 的一份 IBM 商业价值研究院的调用中,有以下几点说明了正进行的变更的程度:

  • 不到 10% 的组织为应对移动、社交、大数据/分析和云趋势做好了充分准备。
  • 超过 60% 的组织计划在未来 12-18 个月增加其 IT 基础架构投资。
  • 目前,80% 左右的工作负载在现有的 IT 基础架构平台上运行,而不是在云平台上。

这些统计数据说明基础架构的变更是不可避免的,并且指出了与其相关的挑战。与此同时,由于关键趋势的出现,这种变更的速度正在加快:

  • 移动应用和变更的速度:消费者习惯更新被定期推送到自己的手机,他们期待出色的应用程序体验。
  • 软件定义的环境 (SDE):SDE 优化存储、计算和网络,并允许 IT 组织以最有效的方式向组织提供服务。
  • 专家集成系统:这些系统包括一个预配置的解决方案,其中包含硬件和软件,捕获专业知识,源于设计的集成,并且提供简化的体验。
  • :云计算已经成为一种关键趋势,可以在内部部署和异地部署的拓扑结构中支持融合的基础架构和共享服务,从而产生混合云。
  • 持续交付/DevOps:这个过程让开发和运营团队的合作更加紧密。

这些趋势将会彻底改变组织实现解决方案的设计、部署和管理的方式。响应对支持无中断变更的需求并不容易。在某些行业(如银行)中,法规对违反可用性的承诺有严格的要求。合规性需要时间、精力和金钱。在其他行业中,可用性甚至有更严重的后果,其中涉及到生命和经济破坏的潜在损失。想像一下,如果指挥军队调动的军事指挥和控制系统,或为跨国银行管理数十亿美元付款的系统,为了进行维护而进入离线状态...其影响可能是灾难性的。

Gartner 报告 "IT 服务持续性管理的炒作周期" 中指出:

"虽然关键任务应用程序(如记录型系统)的整体服务质量已有所提高,但对大多数企业来说,服务可用性仍然不是 “足够好”,原因是停机时间成本在不断上升。"
 

但是,不仅仅是避免停机时间,成功的企业还要从不同的角度考虑可用性。在当今的商业和经济环境中,每家公司都需要能够发现并快速应对市场变化。想一想 Netflix、Salesforce.com 或 Amazon。很明显,他们已经找到了持续交付的秘密(虽然他们偶尔也会出点状况)。在支持最大正常运行时间的方面,不仅涉及规避风险,还涉及基本的生存,如果您的组织正确实现了这种方法,那么就可以赢得竞争优势。

实现无中断变更的框架

在 Gartner 报告 "IT 服务连续性管理的炒作周期" 中,设计领域被强调为持续运营方法的一部分。该报告指出:

"要达到 100% 或接近 100% 的可用性,需要一个自上而下的方法来将可用性设计到应用程序、基础架构和运营架构中。

这些趋势对更系统地设计有影响,在应用程序(而不是基础架构)中实现更高的内置弹性,并且无需停机就可以更频繁地发布新版本,因此,一年前就将持续可用性架构的定位大幅推进至顶峰/通过中点到达接近顶峰。"
 

以此为前提,在评估 “无中断地引入变更” 概念时,您就可以隔离无中断变更的关键用例。下面的列表虽然尚不全面,但提供了一个良好的框架:

  • 维护:持续运营功能包括运行数据库统计和微调,以获得更好的性能。
  • 硬件升级:主要重点是当前的硬件的升级,包括固件升级和将新组件引入拓扑(比如,网络路由器)等领域。
  • OS 升级:主要是在新的操作系统版本、驱动程序和补丁管理等领域。
  • 软件升级:底层软件组件(如应用服务器、数据库和其他中间件基础)的升级,以便支持新版本和现有版本的补丁管理。
  • 应用程序升级:发布已开发解决方案的新版本。
  • 新应用程序部署:部署一个全新的应用程序到生产环境,提供给客户使用。

任何这些变更的传统实现方法都是计划性中断。如果一切都按计划进行,中断窗口应该比较小。不幸的是,情况并非总是如此。最近题为 "了解 IT 风险和声誉的经济性" 的 IBM 调研发现,人为错误导致的中断比 IT 专业人士所预期的高 70%。

要成功解决无中断变更挑战,需要使用一些技术方法,比如虚拟化、服务并行化和并发版本管理。还需要实现有组织的变更,比如技能、文化和实践。

为什么很难满足无中断变更的要求?

组织性问题是其中一个挑战。组织就绪性,无中断地引入变更,这需要一个灵活的、适应性强的组织。传统上采用筒仓式方法完成 IT 解决方案的设计和部署,这导致知识和专长变得比较分散。成功实现 Always On 需要进行协作与协调。此外,Always On 的迫切需求被高级管理层视为战略性需求,并提供相应的资金支持该措施。

  • 技能:在整个企业中,技能没有得到很好的理解。例如,即使应用程序基础架构支持 Always On 和无中断升级,应用程序所有者构建应用程序的方式也不能够充分利用它。
  • 治理和软件开发生命周期:虽然有适用于该领域的工具和方法,但组织需要采用更加灵活和适应性更强的方法来交付解决方案。

总之,持续交付(比如 Always On)需要成为组织 DNA 的一部分,它需要处理解决方案的设计、开发和解决方案管理的多个方面。它需要提供一个企业级的成功方面的承诺。

这些组织性问题导致我们要审查关键的技术问题:

  • 产品和平台技术:业内已经提供了需要中断和手动操作的产品。
  • 解决方案架构:解决方案复杂性是一个越来越大的挑战,特别是在引入第三方组件的情况下,例如云服务或其他解决方案依赖性。
  • 软件生命周期管理:许多组织通过构建自己的解决方案来支持解决方案交付的规划和设计方面,以及部署和运营管理。这些内部开发的解决方案(比如脚本、自动化框架)可能导致下游问题。

可以使用一些技术来支持无中断地引入变更。本文接下来的章节将详细探讨具体的方法。

实现持续运营的技术

Always On 的许多挑战都与组织沟通和协作的能力有关。一个组织可能提供了最好的应用基础架构,但如果开发人员无法正确使用它,他们的代码就有可能导致破坏或中断。反之亦然,具有创新思路的开发人员可能会受到限制,因为需要很长时间才获得能够满足其特定需求的业务开发展基础架构,这会让其感到沮丧。考虑到这一点,DevOps 及其支持无中断引入变更的能力似乎是一个良好的起点。推动创新实现持续运营的关键是 DevOps 的发展空间。

DevOps 使得软件开发和 IT 运营之间建立了某种联系,通过采用各种技术,支持将软件快速实现和部署到生产环境。

Puppet Lab 的 2014 "DevOps 状态" 报告指出,高绩效组织部署代码的频率高达 30 倍,并且故障减少了 50%。该报告介绍了各种 IT 性能指标,比如部署频率、变更的前置时间(吞吐量)、从失败恢复的平均时间(稳定性)和变更失败率。DevOps 显然是无中断地引入变更的一个推动因素。组织可以利用许多关键的 DevOps 和非 DevOps 的技术和实践来为持续运营提供一个基础。

持续交付:持续交付是一种敏捷软件实践,使得将变更交付给用户的过程变得更直观。持续交付通常与连续集成(频繁、定期地合并代码更改)、自动化测试和连续部署一起出现。它以某种可预见的、可靠的方式将变更(bug修复或创新)推送给最终用户。

作为一个侧面说明:其中一种在持续交付的情况下使用的基础架构技术被称为 Light Pool/Dark Pool(亮池/暗池):如果利用这种技术,只有亮池接受请求(打开)。两种池都在生产环境中。暗池用于让应用程序的下一个版本做好准备。当新的应用程序准备就绪时,IT Ops 就会在亮池和暗池之间翻转。暗池变亮,并开始接受请求(使用应用程序的新版本)。亮池变暗,而且在要求回滚的情况下是必需的。不久之后,亮池可以用作下一个版本的应用程序的临时平台。
 

再举一个例子,让我们来看看通过 iStore 实现的 Apple 移动应用交付模型。不要求用户检查更新,而是在应用程序变更时将通知发送给用户。对于某个给定的应用程序,这种情况可能每月出现 2-3 次。

自动测试:计划外中断的主要原因是人员(40%)和流程(40%)。硬件和操作系统只占 20% 的问题。80% 属于应用程序领域,以及创建应用程序的人员和流程。自动化测试可以提高稳定性和质量,消除尽可能多的手动步骤,并加速交付周期。自动测试适用于回归测试和用户验收测试。

恢复或回滚及重新创建:在中断(希望中断对用户是透明的)后要回到一个可用版本,回滚是绝对必需的。此外,需要提供重新创建环境的能力,让开发人员可以修复错误。这些实践是由版本控制支持,应该使用尽可能多的工件(例如,应用程序代码、系统配置、测试用例、部署脚本)。自助服务是这个领域中的关键推动因素。例如,开发人员应该能够自行提供特定的环境,或访问测试数据,不需要 IT 运营人员。

并发版本控制:并发版本控制让组织可以支持新应用程序版本的分阶段部署。通常情况下,应用程序的新版本被逐渐部署到生产,以便尽量减少在引入错误时对生产环境造成潜在影响。如果采用这种实践,在同一段时间中会有两个(或更多)版本的应用程序被部署到生产环境中,并接受请求。在这个阶段,两个不同的客户(例如,根据他们的客户数量或基于其地理位置)可能被定向到不同版本的应用程序。在应用程序发布版本 N 和版本 N-1 的过程可能(或必须)并存,这是由业务需求驱动的。A/B 测试也要求这一点。

正如本节所述,支持持续运营的能力涵盖许多技术领域。要提供无中断引入变更的能力,需要具备管理层支持和资金的企业方法。

持续运营的组织方面

对于一些已经获得成功的组织,Always On 和无中断变更是组织的 DNA 的一部分。当他们做出决定时,无论该决定的大小,员工自然会想到无中断变更,因为 Always On 和无中断变更是企业文化的一部分。对于这样的组织,最迫切的需求不是响应合规性,而是提供出色的客户体验。这些组织中的员工可以轻松地将 Always On 的重要性与他们的任务陈述关联起来。每个人都知道和关心受中断影响的客户。通过防止中断来保护最终用户体验的实践已经存在。通过不断将新的创新带给客户来不断完善体验的实践也已存在。通过反复试验、开放性、经验教训,以及分享最佳实践的文化支持创新。

如果您是这些组织的一员,恭喜您!我敢肯定,您会有些故事愿意与其他读者分享。如果不是,您也并不孤单,但您需要成为改变的代理人(没有双关语意)!一步一个脚印,每次提供一个成功的项目或产品,您想影响公司文化,使无中断变更成为第一个设计原则。文化就是这个游戏的名称。为此,您还应该考虑以下几件事情:

  • 成熟度水平:了解您目前的成熟度水平是非常重要的。这适用于多个不同的领域。例如:您是否为开发人员提供自助服务功能来重新创建环境?您是否支持 A/B 测试?您如何对两个相互竞争的项目做出执行/不执行的决策?了解这些问题,您就会有一个基线和起点。接下来,在这些领域设定与希望达到的成熟度相关的目标。这些目标就会形成最后的目标。最后,应用技术和项目,从基线移动到目标。
  • 沟通:必须有沟通程序来宣传高管的承诺和任务,定期分享所取得的进展,庆祝成功,并认可主要贡献者。您的沟通方式取决于在您的公司有哪些可行方法,大会、时事通讯、博客、邮件、海报、公告板,或上述所有?这也适用于那些一致的、可识别的内部营销和品牌是很重要的地方。
  • 技能:从跟随更有经验的从业者学习,到午餐和学习计划,再到正规教育,技能与支持都非常重要。在这里,您可能想考虑不同的简历或工作角色(例如,软件开发,IT 管理员),并为他们制定相应的课程。有些公司已经通过游戏和徽章获得了成功,如果员工成功完成一部分课程,就会获得相应的徽章。

产品和服务能力的考虑因素

文化和流程比工具更重要,但工具仍然在实现无中断变更的过程中发挥至关重要的作用。本节探讨对供应商和合作伙伴的一些关键的产品和服务要求,他们对于支持无中断变更这个目标有很大的帮助。下列条件或功能为讨论和评估具体的产品提供了基础,无论产品被打包为软件即服务(SaaS)解决方案还是传统的软件都适用。

  • 无中断地实现更新:该标准属于可维护性的领域。产品或服务被更新到新的代码水平,而不会引起明显的中断或数据损失。请注意,此标准适用于产品或服务本身,及其底层的先决条件软件和硬件组件。
  • A/B 测试:部署产品或服务的新版本,并在生产环境中通过部分用户进行测试。新版本与当前版本并行运行,并允许进行实验,比如新版本试点。
  • 并发版本控制:两个版本的产品或服务都在生产环境中部署和运行。这是 A/B 测试的必要步骤,但在支持新代码级别的分阶段发布时更常见。
  • 恢复/回滚:产品或服务的实例是恢复到其先前的版本。在已经引入错误的情况下,该操作是必需的。
  • 在多个可用性区域中部署:这适用于 SaaS,也适用于部署软件的方式。通过在不同的可用性层(例如,第 1 层,第 2 层)运行,而不仅仅在所要求的最高可用性层运行,从较低的层次开始引入变更和执行质量保证会更容易。

您当前的产品供应商可能并不支持所有这些方面。正如前面提到的,关于 Always On 和无中断变更的其中一个大挑战是,您不能自己实现这一目标。您要依靠供应商和业务合作伙伴生态系统。组织让业务合作伙伴和供应商参与,以便影响产品路线图,随时间的推移为持续运营提供更好的支持,这一点至关重要。

为支持无中断变更制定行动计划

从技术角度来看,组织应采取以下关键步骤,为持续交付和无中断地引入变更的能力制定一项战略:

  • 评估和定义一个计划,以便支持在应用交付和部署中用作关键组件的 DevOps 和并发版本控制技术。
  • 对自动测试和恢复/回滚管理领域中的组织性功能进行评估,确保运营流程已满足变更管理的要求。
  • 实现敏捷事件管理流程,作为生产故障测试的一部分。
  • 在新应用程序和服务的开始或设计阶段定义并记录可用性要求。
  • 将可用性和持续交付功能设计到应用程序架构中。
  • 确保可用性要求的更新,这是持续业务影响评估过程的一部分。
     

在组织调整方面,组织可以:

  • 确保持续交付和变更管理的高管支持。有一些组织方面需要获得成功缓解,而且需要 C 级支持。
  • 根据可用性和持续交付要求对应用程序进行评估和分类。
  • 评估可用性的组织成熟度水平。没有可靠的可用性方法的组织可能会在提供持续交付时遇到更多的障碍。制定一个路线图,以便完成推进组织成熟度所需的步骤,并根据需要重复这些步骤。
  • 投资可以支持与当前的和设想的企业架构一致的持续交付和持续可用性的技能。
  • 基于业务影响一致地定义和记录可用性需求和成本,这是业务需求过程的一部分。
  • 沟通持续交付的战略和目标,以及实现无中断变更所必需的方法。
     

最后,组织需要解决基础架构技术中所需的关键功能,以支持持续交付和无中断变更。具体来说,IT 需要与他们的战略供应商和集成合作伙伴密切合作,以确保与持续交付的目标一致。这包括:

  • 无中断技术更新的厂商支持。
  • 新的更新使用集成测试方法,以确保最小的服务中断。
  • 支持并发版本控制的能力(例如,在生产中运行应用程序的多个实例)。
  • 对基础架构更新实现恢复/回滚功能。

结束语

我们生活在一个不断注入大量信息的社会中,我们的文化需要 Always On 功能。无中断地引入变更的能力是成功提供 Always On 业务的障碍之一。其中一些挑战可以通过对应用程序架构设计和持续交付来解决,可以使用的技术包括 DevOps,但解决这些挑战需要的不仅仅是技术方面。业务合作伙伴和供应商的整个生态系统都需要向着这一领域的共同目标而努力。

Gartner 报告 "IT 服务连续性管理的炒作周期" 说明了满足这一需求的优先事项。

对创新服务进行频繁和连续的变更,其好处大于可能出现的任何中断所带来的损害。因此,在竞争力要求快速变化的情况下,企业可以更改其流程,最大程度地降低停机时间成本,或通过其他方式消除该成本,例如动态重新配置。在采用这种方式时,用户可能不了解出现问题的功能。
 

在本文中,您了解了无中断变更及其相关的挑战和驱动因素,这包括人员、流程和技术方面的因素。您了解不同群体(比如开发和 IT 运营)之间需要的协同效应,以及有助于实现这一目标的产品功能。Always On 和无中断变更是有代价的。它并不适用于所有应用程序。一些内部应用程序不会成为这些先进的目标,至少最初不是。同时,相信随着时间的推移,大多数应用程序会根据组织优先级逐步移动到该模型。

将支持无中断变更的原则作为第一原则,这将大幅改进的客户体验。实现无中断变更是一个战略性举措,此外,更重要的是,这是一种文化变迁。要采用敏捷应用程序交付和强大的变更管理的方法,需要提供有组织的协调和关注。不要忘了这个说法,“文化将战略当早餐吃掉了!”

致谢

作者非常感谢 Chris Molloy、Sencan Segul 和 Marc Fiammante 分享他们的宝贵洞察并审阅本文。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=DevOps, Rational
ArticleID=1001827
ArticleTitle=实现 “永远可用”
publish-date=03262015