云服务宕机年年有，今年赶巧凑在了一起！当“开猿节流”、“草台班子”、“降本增笑”这些字眼跃然于眼前，不仅表达了用户的无奈，更引发了业界对于云业务连续性的担忧。

　　云计算已经发展了十多年了，在技术和运维上也投入了大量资源，为什么依然无法避免业务中断风险？如何杜绝层出不穷的宕机事件？

　　答案是：不是云不靠谱，只是部分企业在构建安全稳定可信云服务的道路上还有一些“功课”要补！正所谓“经验没有压缩算法”，没经历过全球大规模云客户的历练，就没有广泛而深入的全球云基础设施和服务支撑能力。即便我们“胆子大”、“速度快”、“步伐宽”，但终究会为成长而买单。

　　那么，在云数智融合的历史节点上，到底有没有一种更有效的手段去防范于未然，如何才能构建出靠谱云服务？云计算领域“老大哥”亚马逊云科技的经验是，提高云服务韧性从设计之初就已经开始！

　　打造靠谱云服务，高手支招

　　持续增加的远程系统调用、日益复杂和分布式系统，以及系统功能的频繁更新……现代企业正在为确保软件系统的持续可用而承受着巨大压力，因为系统宕机不仅会给企业造成数百万美元的经济损失，还会对品牌形象以及客户产生负面影响。

　　打造靠谱云服务，将韧性根植于服务设计之中，亚马逊云科技给出 “三大绝招”。

　　第一招，尽可能扩大自动化范围。为了防止人为造成的数据中断，尽量减少手动操作，必须从从备份到测试需要尽可能地自动化，自动化是创建韧性架构的关键。

　　以一家医院为例，位于马里兰州农村地区的一家独立医院CalvertHealth, 将其应用恢复系统迁移到亚马逊云科技，看重的就是这样一个优势，恢复时间目标（RTO）降至两小时以下，缩短了97%。有了自动化数据备份能力，这家医院不再手动管理服务器数据，借助机器学习（ML）加持的代码审查工具，该医院还可以优化应用性能，识别应用部署之前潜在的代码问题。

　　第二招，通过持续测试应对未知风险。我们经常会听到一个词，叫做“混沌工程”。说白了，就是对应用做持续测试，主要方式就是故意搞“破坏”，把故障引入实验场景，用以发现分布式系统中难以甄别的隐藏错误、盲点和性能瓶颈，应对不可预知风险。

　　亚马逊云科技在不会对用户业务产生影响的情况下，经常做故障演练，来提高运维人员的应对能力。由于亚马逊云科技早已对最坏的情况做好了准备，所以即便一不小心触发了罕见事件，也能从容应对。

　　为了提高云服务韧性，亚马逊云科技还创造了一个融入企业文化的安全活动，运维人员把这一行动叫做“game days”。在演练日，“破坏者”会以更逼真的事件来测试系统的健壮性、流程反应的速度和团队的响应能力。

　　第三招，以统一可观测性指标快速定位和解决问题。一旦事故发生，能够快速了解系统运行情况，这点至关重要，也是衡量云服务是否健壮的关键点。然而，这样的能力，并不是一朝一夕就能具备，企业需要不断收集和分析应用数据，才能更快速地检测和解决应用可用性和性能方面存在的问题，从而应对不断变化的复杂业务环境。

　　以家全球电子学习技术供应商Docebo为例，以往遇到故障需要花费几天时间来解决，而利用亚马逊云科技的多种分析服务，该服务商可以将其所有日志记录和跟踪数据进行结合，建立单一事实来源，最终将故障排除时间缩短了90%，修复错误的时间从70%-80%减少到15%以下。过去需要几天才可以完成的工作，现在只需要几分钟。

　　发挥云规模化效应，将韧性植入客户服务的方方面面

　　用户选择把业务迁移到云上，看重的就是云可以大大降低业务中断风险。为了发挥云规模化效应，让云服务更安全稳定，亚马逊云科技的做法是，在提供服务之前，就在基础设施设计与部署、运营模式和机制中将韧性考虑其中。

　　例如，在Amazon Elastic Compute Cloud (Amazon EC2)中，实例启动后就和数据中心中的物理服务器一样可用。其他亚马逊云科技资源如虚拟私有云(VPC)、Amazon Simple Storage Service (Amazon S3)存储桶以及Amazon Elastic Block Store (Amazon EBS)卷也具有相同的特性。

　　除了设计因素，全球数百万用户更愿意选择亚马逊云科技的另一个原因是，该公司的服务韧性体现在方方面面，其覆盖全球的基础设施能力，能真正提供全面、稳定、可信赖的云，满足用户业务需求。

　　亚马逊云科技部署在世界各地的数据中心比较多，地理位置分散，遍及 33 个地理区域的 105 个可用区。为了避免几乎任何类型或任意规模化业务服务的中断，亚马逊云科技会尽量让可用区的覆盖更广泛，让全球基础设施之间的互联性降低到最小，该公司也是唯一在每个区域内提供三个或更多可用区的云提供商。

　　为了获得高可用性的同时可以实现更大的容错能力，客户可以将他们的应用程序设计为在多个可用区中运行。但是，常见故障点，如发电机和冷却设备等，不会在可用区之间共享，并且设计为由独立的电力变电站供电。

　　亚马逊云科技的区域由一个地理区域内的多个相互独立，且在物理上分隔的可用区组成。每个可用区都有独立的电力、制冷和物理安全设施，可用区之间通过冗余的超低延迟网络连接。同一区域内的可用区之间具有足够的距离，最远可达约100公里，既能防止相关故障，又能实现单位毫秒级延迟的同步复制。

　　在用户关键业务领域，亚马逊云科技还将更多策略和架构实践覆盖在五个阶段，即设定目标、设计和实施、评估和测试、运营以及响应和学习。弹性生命周期框架模仿标准软件开发生命周期，因此客户可以轻松地将韧性纳入现有流程。

　　例如，客户可以使用Amazon Resilience Hub来设置目标，根据这些目标评估韧性状况，并根据Amazon Well-Architected Framework和Amazon Trusted Advisor的建议实施改进措施。在Resilience Hub中，客户可以创建和运行Amazon Fault Injection Service实验，这些实验允许客户测试其应用程序将如何响应某些类型的中断。

　　其他服务，如Amazon Backup、Amazon Elastic Disaster Recovery (Amazon DRS)和Amazon Route53 Application Recovery Controller (Route 53 ARC)，可以帮助客户快速响应和从中断中恢复。

　　小结：

　　看来，姜还是老的辣！面对云中断事件，亚马逊云科技表现出“一哥”该有的“风范”。面对灾难，我们每个人都不应该有“看热闹不嫌事大”的心理，因为每次故障背后，都是一部血泪史。服务中断、数据丢失，不仅代表相关的云运维人员将会神经紧绷，以争分夺秒的速度恢复业务，还会给企业带来直接的经济损失，带来云信任危机。

　　对于更多迈向云端的企业来说，只有不断总结前人经验，才能在未来的征程中行稳致远，拥抱人人都向往的数智化星辰大海。