译者 | 崔皓
审校 | 梁策 孙淑娟
开篇
众所周知，云服务并非金刚不坏之身。现实中，云服务中断的例子比比皆是，一旦发生就会对企业造成巨大损失。那么，怎样才能保障业务在云服务中安全运行呢?
云中断所面临的问题
亚马逊云服务AWS 曾因一个错误字符导致其 S3 服务器瘫痪，连带大批互联网应用随之宕机，由此人们不得不意识到云服务和互联网是多么脆弱。在这次事件中，亚马逊的员工甚至都来不及登入自己的仪表板来发出警告，可见其故障影响程度之深。
除了如此震惊全球的大事件，小规模的云中断事件也接连不断。比如今年，一连串的云中断影响了一众云供应商，包括AWS、谷歌云以及微软 Azure等等。
对于许多 IT 团队来说，这些事件暴露了同一个问题，那就是小到拼写错误都有可能严重影响企业的整体业务。根据企业的部署和架构不同，其影响很可能带来灭顶之灾。
因此，在制定业务连续性计划时就需要考虑云中断的问题。但是，由于在公共云上的应用程序范围太广，要找到一种降低中断风险的方法实属困难。
遭遇云中断实属不幸，但无法避免
没有那个系统能确保万无一失。哪怕战略再周密，无法预计的黑天鹅事件也会带来恶果。
遭遇云中断确实是不幸的，但它也无法避免。它的发生就像家常便饭，几乎每个云服务商都会遇到。
虽然许多公司已将云中断纳入其灾难恢复计划，但仍有一些公司还在挠头应对中断对业务带来的全新风险。
使用“云无关架构”转移工作负载
使用“云无关架构”是企业保护自己免受云中断影响的一种方法。这意味着系统架构不依赖于任何单一的云供应商，并且能够在发生云中断时在云供应商和区域之间进行无缝切换，即在云服务商和区域之间进行工作负载的转移。“云无关架构”的模式使企业可以自由选择最适合其需求的云服务供应商，即使在某个云供应商离线的情况下也是如此，从而确保数据始终安全且可用(无缝切换到其他云供应商)。
但是，让企业应用“云无关架构”是一个复杂且昂贵的过程。
俗话说的好：“不要把所有的鸡蛋都放在一个篮子里!”所以，企业自然也可以将数据运行在多个云上，从而通过这种方式对抗云中断，让企业应用和数据更加安全。
这也就是为什么多云架构和分布式系统中的数据弹性最近成为了热门话题。当关键业务解决方案的架构设计在多个云供应商以及在本地基础设施运行时，业务领导者就可以放宽心了，因为他们知道数据的安全可以保障，公司能够持续 7*24 全天候运转。
也正是因为云中断，企业开始重新评估应用程序的部署和构建方式。意识到宕机不可避免可以帮助市场构筑一种适度的紧张感，从而推动人们思考如何构建软件系统，更加负责任地开展行动，并将弹性视为头等大事。
对于一些公司来说，这意味着要重构他们的应用程序，使其能够跨多个公平台运行——这对在云中断中幸存来说非常重要。
而创建与云无关的应用程序则是公司提高数据弹性的一种方法，这使他们的数据能够在发生灾难或中断时自由地在云区域和供应商之间无缝转移工作负载。
选择与云无关的架构则可以让公司省心，即使合作的云供应商发生了状况，他们的数据也能保证安全。
对大多数组织而言，云无关的复杂性令人望而却步
虽然与云无关架构的想法在理论上听起来很棒，但解决方案实施起来既不简单也不便宜。这需要花费大量时间，同时还要雇佣高技能的 IT 专业人员才能完成。
此外，公司也很难改造存在多年的复杂应用程序以让其跨多云运行。对于许多组织而言，其复杂性和成本可能令人望而却步，更不必说它要求的专业知识也是挑战。不过，还是有一些方法可以让 IT 团队轻松地部署这些新架构。
IT 团队可以寻找实施多云基础架构即服务 (IaaS) 的方法，而不是自己搭建工具。公司则需要提高弹性并采用与云无关的架构。此外，让多云变简单也是很重要的一方面，这样人们就无需担心它们的问题了。
公共云中断不可避免，我们也无力阻拦。但是，企业在应对时可以通过云无关架构让应用与云无关，并避免对单一云供应商的完全依赖。
译者介绍
崔皓，51CTO社区编辑，资深架构师，拥有18年的软件开发和架构经验，10年分布式架构经验。曾任惠普技术专家。乐于分享，撰写了很多热门技术文章，阅读量超过60万。《分布式架构原理与实践》作者。
原文标题：How to Architect for Resiliency in a Cloud Outages Reality，作者：Cyril Plisko
