云计算时代频发的服务中断事件，突显了企业面临的巨大运营风险。建立运维弹性，势在必行。
译自 What Is Operational Resilience?，作者 Robert Kimani 是一位系统工程师和开源倡导者，他喜欢分享知识。他相信帮助别人，并充满同情心地回报社区。当他没有沉浸在 Linux 中时，他喜欢远足、山地自行车和探险。
数字领域曾被认为是可靠性的堡垒，企业和组织都信任云服务提供商来保证其业务的连续运行。然而，这种说法正在发生变化。最近发生的一系列事件凸显出这些系统中的漏洞以及重大中断所带来的深远影响。
4月，谷歌云平台的欧洲西部9区发生了全面中断，中断持续了整整一天。这次中断源自一处巴黎数据中心发生火灾，随后是水灾，在 Google 云平台中形成连锁反应，区域和服务在数日内逐步恢复。
6月，亚马逊网络服务在其美国东部一区遭遇了严重中断。一个内部域名系统和监控系统因为流量过大而发生故障，这是自动扩容操作出错所导致。随之而来的是一系列连接错误和重试。这次中断产生了立竿见影的影响，数以百万计依赖这个关键区域的用户和企业客户都受到了影响。
这些事件的影响范围不容小觑。企业、学校、医院、政府机构和无数其他机构突然发现自己陷入了运营混乱之中，这引发了一个基本问题:在云服务中断变得越来越常见的环境中，我们如何确保业务连续性？
答案在于运营弹性这个概念，这是一种策略，它让组织能够在发生中断时适应和响应，同时保持持续运营，确保客户几乎不会或根本不会受到影响，即使他们周围的世界正在动荡。
随着云服务提供商中断事件持续增多，运营弹性从未如此重要过。下面是对运营弹性的细节、重要性和实现策略的解释。
运营弹性围绕连续性这个原则，企业及其核心功能尽管面临挑战，但仍然持续。这是对客户的承诺，无论幕后存在什么破坏，他们的体验都不会中断。
它还确保了客户(和组织自身)数据的安全，随着每一天的过去，这个问题变得越来越重要。
运营弹性的重要性远远超出“保持系统运行”，它意味着即使在最艰难的环境下也能提供没有动摇的产品和服务。
运营弹性面临许多挑战，从普通的到非同寻常的，每一项都可能引起中断。其中的风险包括:
技术故障，可能包括硬件故障、软件错误或基础设施问题。这类故障可能对提供持续服务的能力产生连锁反应。
网络攻击，网络威胁变得越来越复杂。像分布式拒绝服务攻击（DDoS）或数据泄露等可能危及数据的完整性、可访问性和服务的可靠性。
自然灾害，可能会中断数据中心和基础设施，导致长时间的服务中断。
供应链中断，组织依赖复杂的供应链。其中的任何中断，无论是由于地缘政治事件还是后勤问题，都可能导致服务中断和经济损失。
运营弹性对金融机构尤其重要，因为它们的运营与全球经济息息相关。区域范围内的中断可能对金融稳定造成灾难性影响。
如果主要的云服务供应商出现故障，导致大型银行业务长时间瘫痪，可能会停止数百万笔交易，影响消费者和企业。这种事件的经济影响可能是深远的，突显了金融业以至更广泛行业对运营弹性的迫切需求。
运营弹性和业务连续性是密切相关的概念，但它们并不等同。为了说明其区别，考虑一个常见的类比:视频游戏。
运营弹性:无缝游戏体验
假设你正在玩一个视频游戏，正处于一个激烈的头目大战中。突然，游戏崩溃了。在运营弹性设置中，游戏已经设计好了无缝处理这种中断。你按一个按钮，就回到之前的状态，好像什么都没有发生过。
在这种情况下，玩家代表着你服务的最终用户。即使遇到问题，他们使用你组织的服务也几乎没有中断。
业务连续性:从保存点加载
现在，考虑业务连续性，有点像是一个视频游戏，重点是在中断后确保你可以从停止的地方继续。当游戏崩溃时，你需要从保存的进度加载，可能会损失一些进度。
因此，运营弹性需要稳健的计划和积极的措施，以确保组织能够在问题来临时度过难关。等待这些罕见事件的发生是不可行的；做好准备工作是最小化其影响的关键。
本质上，运营弹性旨在防止在不可预见的挑战期间结束用户中断，从用户的角度来看，这会让人感觉好像没有发生任何问题。
另一方面，业务连续性确认可能会发生中断，但重点是最小化停机时间并确保快速恢复关键功能。这两个概念本身都非常重要，它们都有助于组织在数字时代有效地应对逆境。
运营弹性远不仅仅是客户满意度，它超越了经济稳定和全球影响等领域。它是把现代社会复杂的机器连接在一起的关键部分。
主要的云服务提供商中断事件可能很少见，但不可避免——并且由于气候变化和其他因素，可能变得更加频繁。即使是最可靠的提供商也无法免受中断的影响。
因此，运营弹性需要健全的规划和积极的措施，以确保组织能够抵御风暴的袭来。等待这种罕见事件的发生是不可行的；做好准备工作是最大限度减少其影响的关键。
运营弹性不能只通过文字来达成；它必须内嵌在组织应用程序的架构本身。这意味着企业必须将其作为设计和战略的基本部分。
为了真正确保运营弹性，重要的是要认识到依赖单一云提供商的局限性，以及切换提供商的困难。
集成弹性，运营弹性应集成到每个应用程序的架构中。系统必须以弹性为核心原则进行设计。等待中断发生已经太迟了；主动准备是关键。
单一云提供商的局限性，许多组织传统上依赖单一云提供商。这种方法之所以流行，是因为其简单性和成本效益。然而，缺点是它本质上缺乏运营弹性所必需的健壮性。单一云提供商不能提供多云或与云无关的策略所带来的冗余和故障转移。
切换提供商的挑战，从一个云提供商迁移到另一个并不像看起来那么简单直接。假设应用程序可以轻松在提供商之间切换是具有误导性的。不同的云提供商都有专有的接口和架构，使转换过程复杂且耗时。
面对这些挑战，与云无关的应用程序架构浮现为一个引人瞩目的解决方案。它意味着确保应用程序的每个组件都是与平台无关的。
与云无关的架构提供了可扩展性、灵活性和运营弹性的三重优势。这种设计有助于根据业务需求轻松扩展，允许动态分配资源。其固有的灵活性支持在不需要重大代码改写的情况下添加或替换各种服务和平台。
或许最关键的是，与云无关的架构通过确保跨多个云服务提供商的互操作性来固有地增强运营弹性。应用程序的每个组件都呈现出与平台无关，可以在不同提供商之间无缝运行。
这种方法不仅可以缓解供应商锁定的担忧，而且与未来监管要求的预期完全吻合，这在运营弹性不断发展的环境中是必不可少的。
在弹性是必不可少资产的世界里，向与云无关的架构转型已经超越了战略选择——它成为了必要。
随着世界互联程度日益提高，对运营弹性的需求不断增强，全球各地的政府正在做出回应，引入法规以确保关键服务(尤其是金融业)能够承受中断。
这些法规旨在提供一个安全网，保护经济和基本服务免受重大服务故障的影响。
一些最近的例子:
英国处于运营弹性法规的最前沿。通过2022年上线的运营弹性框架，英国当局已指示金融公司在2025年3月31日前满足特定的运营弹性要求。这些措施将政府监管覆盖到组织自己的内部战略之上。
通过满足最低运营弹性标准，首席信息官有灵活性选择最适合其组织需求的策略，如运营混合云基础架构或在多个云提供商平台上运行。
欧盟的数字运营弹性法(DORA)旨在确保所有数字服务提供商(包括云服务提供商、搜索引擎、电子商务平台和在线市场)都有效的战略和能力来管理运营弹性，无论它们在欧盟境内还是境外。
DORA法规于2023年1月上线；金融实体预计将在2025年初之前符合法规要求。
在美国，2021年3月，美联储系统等发布了运营弹性指南。同年5月，拜登政府发布了一项包含与运营弹性相关规则的网络安全行政令。
关于运营弹性的法规正在扩展到金融服务公司之外。推动新的法规反映了人们对现代服务互联性的认识日益增强。
监管范围可能很快会扩展到公用事业、运输和医疗保健等部门，因为它们在日常生活中的关键作用，被视为基本服务。监管机构认识到这些服务的弹性对公共福利至关重要。