北京時間2020年12月14日晚間，由於內部技術故障導致大面積宕機，谷歌多項服務均無法提供服務，類似的宕機新聞時有發生，每次的主角都可能都不一樣，到底誰的宕機次數和宕機時間更少呢？
市面上有一些公開的監測數據，比如來自downdetector.com和cloudharmony.com的數據，也有廠商比較自豪說自己宕機時間比同行老夥計時間短的，比如在2018年，亞馬遜雲服務（AWS）表示第二大雲計算公司的宕機時間是AWS的7倍。
AWS坐擁全球近一半的雲市場份額，理論上規模越大越容易出錯才對，AWS為了減少宕機時間都做了什麼呢？
在亞馬遜re:Invent大會，AWS全球基礎架構和客戶支持高級副總裁Peter DeSantis介紹了基礎設施層面上方方面面的創新，包括如何減少宕機，如何降本增效等等。
在減少宕機時間，在提升服務連續性方面，AWS有挺多的有意義的做法，AWS大中華區產品部計算與存儲總監周舸向中國媒體介紹了其中幾點。
AWS數據中心電力冗餘設計簡介發電機組
從電力供應開始說起，周舸介紹了柴油發電機，介紹了配電室（E-house），UPS備用電源等方面。
E-house
令人印象深刻的是，為了減少可能發生的故障，AWS在採用現有商用方案（一般是嵌入式系統）的基礎上，捨棄了許多原有的東西，自己設計了控制電路的代碼。
AWS對基礎架構的控制能力可見一斑。
原裝設備控制電路存在的問題
在AWS看來，這些控制軟體有可能有Bug，如果Bug發生，廠商無法在短時間內完成修復，而如果這些軟體本身就是自己寫的，那麼就可以很快進行修復。這種對於現有服務方案的「不信任」貫穿著AWS架構設計的方方面面。
AWS CTO Werner Vogels曾說過，」Everything fails, all the time」，也就是說，所有東西都可能會壞掉，既然無法避免會壞掉，那就坦然接受，但一定要儘量減少壞掉造成的影響，要能預測什麼時候會壞、怎麼壞的，提前做出防範和應對。
比如，為了保障電力供應，AWS會在有外部電網供電和內部發電機組的基礎上，再加一組發電機，採用冗餘的供電方式，冗餘設計是貫穿整體架構設計的方方面面，但這會大大提升複雜度，越複雜就越危險。
在2020 re:Invent大會上，Peter DeSantis張貼了這樣一張圖，橫軸表示系統複雜度，縱軸表示故障造成的傷害（爆炸半徑），原本的Switch Gear（配電控制系統）和UPS系統處在較為危險的位置。
在Switch Gear（配電控制系統）系統的優化改造中，AWS通過自己寫軟體控制系統，刪除一些沒用的、添加部分對AWS有用的功能後，降低了系統複雜度，提升了系統的可靠性和安全性。
使用Rack Level小電池塊的UPS
在UPS系統改造中，除了軟體層的改進，還使用小容量（Rack Level電池）的電池，而不是以前超大容量的電池，從而降低電池爆炸造成的傷害，從而遠離了爆炸半徑。
2000年左右，那是一個還沒有AWS的時代，Amazon在美國西雅圖有一個數據中心，隨著業務規模的擴大，亞馬遜開始意識到海嘯和地震的潛在風險，不能把所有東西都放這裡，於是就想在沒有地震海嘯威脅的美國東海岸建一個數據中心。
東西海岸70ms的超高延遲是絕對不能接受的
各種自然災害的影響範圍與距離造成的延遲
兩個數據中心放的太近，可能遭受同一個自然災害的侵襲，如果離得太遠，延遲會帶來數據同步的問題也同樣不可接受，美國東西海岸的距離就會造成這一問題。所以，數據中心之間需要保持一定的安全距離，而且要保證一毫秒以內的延遲。
類似的，AWS強調多AZ（Avaibable Zone）與多機房的概念不一樣，AWS每個Region有至少三個AZ，AWS認為多個AZ相互間要有一定的安全距離，以此來降低外部環境同時對多個AZ造成影響，來提升服務的可用性。
從Region的角度看，AWS為了減少Region間可能造成的幹擾，設計原則上是將各個Region獨立運作，一個Region出的問題不會傳遞到別的Region，在Region的級別提供冗餘。
AWS供應鏈保障
2020年是黑天鵝滿天飛的一年，突如其來的疫情，急劇增長的在線業務量，逼著所有雲廠商在加班加點忙著擴容資源，AWS也不例外，就AWS的規模來猜測，擴容規模要遠大於大部分雲廠商。
2015年，AWS供應鏈概況
為了保障擴容的順利進行，AWS在供應鏈採購管理上採取了多元化策略，供應商的數量，供應商覆蓋的國家和地區在數量上有了很大提升。如今，AWS的供應鏈系統覆蓋7個國家，86家供應商，以此來暴漲供應鏈的穩定。
2020年，AWS供應鏈概況
在疫情在全球爆發的2020年，多元化管理策略確實挺有價值，疫情的不確定性給供應鏈帶來很大挑戰，許多國家的生產環節和清關效率都出了很大問題，對此，周舸表示深有體會。
寫在最後
在可用性方面，公有雲作為公開可見的服務，更容易受到公眾關注，造成公有雲更容易出故障的印象。
拋開客觀感受不說，由於公有雲作為一種服務，而不是一個個on-premise產品盒子，要考慮的內容更多一些，比如供電，比如網絡，比如運營能力等，確實非常考驗雲廠商的綜合實力，需要有數不清的技術創新來打造更高的可用性和業務連續性。
隨著一步步迭代和發展，技術只會更成熟，運營經驗會更豐富。