亞馬遜云服務故障的教訓和思索——你的云服務如何做更好呢？
原創前不久亞馬遜的云服務出了故障，這可能會導致許多公司持保留態度，不敢將解決方案部署到公共云中。
前不久亞馬遜的云服務出了故障，這可能會導致許多公司持保留態度，不敢將解決方案部署到公共云中。許多公司可能會關注私有云解決方案，直到它們認為安全了，才會試水公共云。事后查明，導致亞馬遜云服務出現停運的原因是網絡基礎設施的部件配置不當。人為錯誤導致了重大的云服務故障和經濟損失。
這次故障表明了云服務存在一大安全弱點。我在之前一篇有關災難恢復的文章中提到，關鍵的基礎設施產品有太多的功能特性和款式型號。它們有必要像汽車那樣采用共同的發動機配置；換句話說，云產品也要有共同的功能特性。當然，汽車類型或云產品類型的數量要有所限制。
整個云系統要大大減少不同版本，那樣那些產品的集成就能進行合理的測試，以確保災難恢復效果。版本太多的話，測試起來成本過于高昂。像控制電網的能源管理系統（EMS）這一些軟件有復雜的有限狀態機、高級的功率算法以及全面的系統故障切換功能。但是與許多軟件產品一樣，一些軟件錯誤路徑從來就沒有測試過。
與EMS系統不同，云服務必須避免版本未經測試的情況，為此要通過高級的模塊化產品來簡化集成。復雜性在產品里面隱藏起來，但是對集成并不造成負面影響。與大型航空、電信和國防項目一樣，我們需要云系統架構師來負責對多家廠商的產品進行必要的集成和測試工作。他們能夠分析產品和集成方面的相關風險。如果他們看到了安全弱點，就能把注意力集中在其他的產品供應商。他們還能對服務提供商或公司所部署的云服務版本的數量進行限制。
讓架構師參與這些解決方案的設計會給云產品提供商帶來壓力，不過這種壓力是積極的、正面的。他們會影響提供商對產品的選擇，最終選出來的是滿足客戶要求、易于集成的產品。不妨把這些產品稱之為能夠識別云（cloud-aware）。這些產品可能擁有數量有限的預定義模板，這些模板得到提供商的支持，又能與其他產品很好地集成起來。使用模板讓這些產品不需要太多的干預就能集成起來。
現在用到架構師的現象其實很普遍。那么，云服務提供商如何著手找到一名優秀的架構師呢？我建議要物色既洞察“全局”，又是通才的架構師。在開發布魯克林大橋這樣的大項目時，項目負責人常常是通才型的架構師。他們常常不是最聰明的，而許多側重于小眾領域的架構師可能更關注細節?？墒撬麄兩瞄L溝通，關注關鍵的設計問題，并且能夠很好地消除爭議。他們實施***秀的架構師提出來的想法，并且推動項目前進。
云系統架構師需要擁有類似布魯克林大橋設計師那樣的技能。他們需要與應用架構師、平臺架構師、基礎設施虛擬化架構師、存儲和網絡架構師以及關注災難恢復及其他產品安全問題的安全架構師加強聯系。應該要從外面請來多個顧問和外部專家，著手解決云服務或私有云的設計。這筆前期費用完全值得花出去，因為這將有助于避免對災難恢復的需要以及/或者潛在的故障和訴訟。
另外還要更多地考慮云產品如何才能彼此很好地集成起來。也許云服務行業需要像存儲行業那樣有一個類似存儲網絡行業協會（SNIA）的組織。我們需要加強交流，討論如何避免故障以及改進/簡化產品。
原文名： 作者：Gregory Machler
【本文乃51CTO精選譯文，轉載請標明出處！】
【編輯推薦】
- SAP稱亞馬遜服務故障影響其云計算推廣
- 亞馬遜為宕機事件道歉 已找到EC2設計缺陷
- 亞馬遜服務器宕機背后：云計算依然安全嗎？
- 亞馬遜稱云計算服務故障已大部分解決
- 云遷移全攻略：哪些應用適合遷移
- 亞馬遜 谷歌 微軟三大試用云服務大比拼（上）
- 亞馬遜推出1年免費云計算服務
- 亞馬遜EC2中斷 “可用區”遭質疑
- 傷不起！亞馬遜史前***宕機事件的啟示
- 云震 -- 亞馬遜4.21事故的反思
- 從亞馬遜云服務故障中吸取的七個教訓
- 云計算與集群：是攜手還是爭斗？
