亚马逊云服务故障的教训和思索——你的云服务如何做更好呢？

前不久亚马逊的云服务出了故障，这可能会导致许多公司持保留态度，不敢将解决方案部署到公共云中。

前不久亚马逊的云服务出了故障，这可能会导致许多公司持保留态度，不敢将解决方案部署到公共云中。许多公司可能会关注私有云解决方案，直到它们认为安全了，才会试水公共云。事后查明，导致亚马逊云服务出现停运的原因是网络基础设施的部件配置不当。人为错误导致了重大的云服务故障和经济损失。

这次故障表明了云服务存在一大安全弱点。我在之前一篇有关灾难恢复的文章中提到，关键的基础设施产品有太多的功能特性和款式型号。它们有必要像汽车那样采用共同的发动机配置；换句话说，云产品也要有共同的功能特性。当然，汽车类型或云产品类型的数量要有所限制。

整个云系统要大大减少不同版本，那样那些产品的集成就能进行合理的测试，以确保灾难恢复效果。版本太多的话，测试起来成本过于高昂。像控制电网的能源管理系统（EMS）这一些软件有复杂的有限状态机、高级的功率算法以及全面的系统故障切换功能。但是与许多软件产品一样，一些软件错误路径从来就没有测试过。

与EMS系统不同，云服务必须避免版本未经测试的情况，为此要通过高级的模块化产品来简化集成。复杂性在产品里面隐藏起来，但是对集成并不造成负面影响。与大型航空、电信和国防项目一样，我们需要云系统架构师来负责对多家厂商的产品进行必要的集成和测试工作。他们能够分析产品和集成方面的相关风险。如果他们看到了安全弱点，就能把注意力集中在其他的产品供应商。他们还能对服务提供商或公司所部署的云服务版本的数量进行限制。

让架构师参与这些解决方案的设计会给云产品提供商带来压力，不过这种压力是积极的、正面的。他们会影响提供商对产品的选择，最终选出来的是满足客户要求、易于集成的产品。不妨把这些产品称之为能够识别云（cloud-aware）。这些产品可能拥有数量有限的预定义模板，这些模板得到提供商的支持，又能与其他产品很好地集成起来。使用模板让这些产品不需要太多的干预就能集成起来。

现在用到架构师的现象其实很普遍。那么，云服务提供商如何着手找到一名优秀的架构师呢？我建议要物色既洞察“全局”，又是通才的架构师。在开发布鲁克林大桥这样的大项目时，项目负责人常常是通才型的架构师。他们常常不是最聪明的，而许多侧重于小众领域的架构师可能更关注细节。可是他们擅长沟通，关注关键的设计问题，并且能够很好地消除争议。他们实施***秀的架构师提出来的想法，并且推动项目前进。

云系统架构师需要拥有类似布鲁克林大桥设计师那样的技能。他们需要与应用架构师、平台架构师、基础设施虚拟化架构师、存储和网络架构师以及关注灾难恢复及其他产品安全问题的安全架构师加强联系。应该要从外面请来多个顾问和外部专家，着手解决云服务或私有云的设计。这笔前期费用完全值得花出去，因为这将有助于避免对灾难恢复的需要以及/或者潜在的故障和诉讼。

另外还要更多地考虑云产品如何才能彼此很好地集成起来。也许云服务行业需要像存储行业那样有一个类似存储网络行业协会（SNIA）的组织。我们需要加强交流，讨论如何避免故障以及改进/简化产品。

原文名：Amazon’s Cloud Failed: How Can Yours Be Better?作者：Gregory Machler

【本文乃51CTO精选译文，转载请标明出处！】