一、概述
2020年6月，阿裡雲對象存儲 OSS 通過十年積累的技術紅利，将可用性 SLA（Service Level Agreement) 提升 10 倍，做到了全球第一的核心競争力，是其他的雲廠家的 10～20 倍，如下圖所示。
其中， OSS 的标準型（同城備援）存儲，SLA 從 99.95% 提升到 99.995%，簡單了解就是如果 10萬 個請求中隻要有 5 個請求傳回服務端錯誤，OSS 将會賠付。
二、OSS 可用性 SLA 說明
2.1 常見的可用性名額（年故障時長）
業界對可用性的描述，通常采用年故障時長。比如，資料中心機房劃分為不同等級，如 T1～T4 機房，它們的可用性名額如下所示。
T1 機房：可用性 99.671%、年平均故障時間 28.8 小時
T2 機房：可用性 99.741%、年平均故障時間 22 小時
T3 機房：可用性 99.982%、年平均故障時間 1.6 小時
T4 機房：可用性 99.995%、年平均故障時間 0.4 小時
網絡服務的可用性，通常也會折算為不能提供服務的故障時間長度來衡量，比如典型的 5 個 9 可用性就表示年故障時長為 5 分鐘，如下表所示。
對于執行個體型雲服務，典型如阿裡雲的 ECS，它提供了一台計算執行個體，該執行個體的可用性直接與可用時間相關，是以它也是采用年故障時長來定義可用性。
2.2 對象存儲 OSS 可用性 SLA 名額
對象存儲是資源通路型雲服務，它不提供執行個體而是 Serverless 化的 API 調用，按照“年故障時長”計算可用性是不合适的。是以，阿裡雲對象存儲 OSS 選擇“失敗請求數：總請求數”的錯誤率嚴苛邏輯來計算可用性。
2.2.1 每5分鐘粒度計算錯誤率
每5分鐘錯誤率 = 每5分鐘失敗請求數/每5分鐘有效總請求數*100%
計算請求錯誤率時，将計算請求的時間範圍拉長，對雲服務有利。因為時間越長，總請求數越多，會導緻錯誤率降低。為了更好的從客戶角度計算錯誤率，按照5分鐘的粒度來計算。高可用系統設計關鍵是備援，而 5 分鐘是業界典型的機器故障恢複時間，能夠快速修複機器，可以将降低系統的錯誤率。
2.2.2 基于服務周期内的5分鐘錯誤率計算可用性
服務可用性=（1-服務周期内∑每5分鐘錯誤率/服務周期内5分鐘總個數）*100%
對象存儲 OSS 按月收費，是以服務周期就是自然月。服務可用性，就是将服務周期内的每5分鐘錯誤率求和，然後除以服務周期内 5 分鐘總個數(按照自然月 30 天算，該值為 302460/5=8640)，然後用 1 減去平均錯誤率，就可得到該月的可用性。
根據此公式，如果每 5 分鐘錯誤率過高，将會導緻可用性下降；是以，提升每 5 分鐘的請求成功率，将是提升可用性關鍵。
2.2.3 對比年故障時長和請求錯誤率模型
按照全年 26 分鐘故障為基礎，年故障時長模型可用性為99.995%。而 OSS 的請求錯誤率模型下，按每5分鐘錯誤率來算，26 分鐘至少有5個每5分鐘錯誤率為100%，其他的每5分鐘假設全部為0(沒有錯誤)，是以可用性最多為 1-5*100%/8640 = 1-0.058% = 99.942%，進而 OSS 的請求錯誤率模型更加嚴格。
2.2.4 OSS 可用性 SLA 承諾
基于上述可用性計算，使用者可以得到自然月内的實際可用性。按照 OSS 可用性 SLA 承諾，如果沒有達标，将進行賠付，真正做到“你敢用、我敢賠”，進而提升客戶業務的可用性。
2.3 雲廠商對象存儲可用性 SLA 對比分析
分析 AWS、AZURE、GCS、阿裡雲、騰訊雲、華為雲等廠家的對象存儲可用性 SLA，，可以看出阿裡雲對象存儲可用性 SLA 是其他廠家的 10～20 倍，而且采用最嚴苛的5分鐘粒度計算，保證客戶第一。其中，某傳統存儲轉向做公共雲的廠家，仍然采用傳統線下存儲的“可用時間方式”來計算可用性，确實還是延續原有的思路。
三、OSS 可用性體系建設
阿裡雲對象存儲 OSS 是曆經十年研發的雲服務，始終把可用性的建設作為核心競争力來建構，進而形成了如下的可用性體系。
3.1 本地備援和同城備援架構
OSS 提供了本地備援存儲（部署在一個 AZ）、同城備援（部署在三個 AZ）存儲類型，它們的邏輯架構相同，主要包含如下子產品：女娲一緻性服務、盤古分布式檔案系統、OSS 中繼資料（有巢分布式 KV 索引）、OSS 服務端、網絡負載均衡等。
同城備援存儲（3AZ）則是在實體架構上是提供機房級别的容災能力，将使用者資料副本分散到同城多個可用區。當出現火災、台風、洪水、斷電、斷網等災難事件，導緻某個機房不可用時，OSS 仍然可以提供強一緻性的服務能力。故障切換過程使用者業務不中斷、資料不丢失，可以滿足關鍵業務系統對于 RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）為 0 的強需求。同城備援存儲，可以提供 99.9999999999%（12個9）的資料設計可靠性以及99.995% 的服務設計可用性。
3.2 IDC 備援設計
要實作更高的可用性，就必須在實體層做好備援設計，包括如下的技術：
同城備援多 AZ的距離和時延設計。在公共雲部署時，會遵循阿裡雲IDC與網絡架構設計規則及AZ選址标準，特别是要滿足 OSS 的多 AZ 設計要求時，會嚴格要求時延和距離。
供電、制冷備援。OSS 對象存儲是多區域部署的雲服務，幾乎每年都會遇到自然災害、供電異常、空調裝置故障等問題，在資料中心建設時要做好雙路市電和柴油發電機備電的設計，以及連續制冷能力。
網絡備援。OSS 作為公共雲服務，既要提供外部的網際網路通路、VPC網絡通路，還要提供分布式系統的内部網絡連接配接，它們都需要做好備援設計。
外部網絡。網際網路接入多營運商的BGP和靜态帶寬，實作公網通路的備援。同時，VPC 網絡的接入則通過阿裡雲網絡的備援。
内部網絡。OSS 是分布式存儲，由多台伺服器組成，采用内部網絡将多台伺服器連通起來，通過資料中心的機櫃級交換機、機櫃間交換機、機房間交換機的分層設計實作備援，即使某台網絡裝置故障，系統仍然能夠正常工作。
伺服器。OSS 采用貔貅伺服器系列優化成本效益，基于分布式系統和軟體定義存儲的需求，硬體上采用通用伺服器（commodity server），并提供備援的網絡接口，無需采用傳統存儲陣列雙控備援設計的定制硬體。
3.3 分布式系統設計
3.3.1 女娲一緻性服務
女娲是阿裡雲飛天系統底層核心子產品之一，從2009年飛天建立起開始自主開發，女娲對外提供一緻性，分布式鎖，消息通知等服務。同業界類似功能的開源軟體（ZooKeeper、ETCD）相比，女娲在性能、可擴充性、和可運維性上有明顯的優勢。
女娲服務采用兩層架構，後端是一緻性維護的功能子產品，前端是達到分流效果的前端機。
前端機通過 VIP 做負載均衡。主要實作兩個功能：第一點，負責維護衆多用戶端的長連接配接通信，進而保證用戶端請求能夠均衡到後端；第二點，向用戶端隐藏後端的切換過程，同時提供高效的消息通知功能。
後端由多個伺服器組成 PAXOS 組，形成一緻性協定核心。對用戶端提供的資源（檔案，鎖等），在後端都有歸屬的 Paxos Group仲裁，它采用 PAXOS 分布式一緻性協定進行同步，保證資源的一緻性和持久化。為了提供更好的擴充能力，後端提供了多個 Paxos Group。
是以，通過多 VIP 備援、前端機透明切換、備援的一緻性仲裁 Paxos Group，實作故障時的快速切換，進而在一緻性協調時提供高可用性。
3.3.2 盤古分布式檔案
盤古2.0是第二代自研開發的分布式存儲系統，在高性能、大規模、低成本等方面深度挖掘了系統的極限能力，支援更豐富的接入形态，進一步提升了系統的部署運維自動化智能化能力，同時繼承了1.0在高可靠、高可用、資料強一緻性等方面的積累優勢。
3.3.3 對象服務有巢分布式KV中繼資料快速切換
有巢分布式 KV 為 OSS 對象存儲提供分布式 Key-Value 中繼資料功能，作為阿裡雲最早研發的的 KV 系統，曆經多年 OSS 的業務打磨，它在大規模叢集下有非常深厚的技術積累。2014 年實作了多執行個體備援的特性，把KV 分解為由多個副本成的分區組（partition group），該分區組通過一緻性協定選舉出 Leader 節點對外提供服務，當 Leader 節點故障或出現網絡分區時，能夠快速選出新的 Leader 節點并接管該分區的服務，進而提升 OSS 中繼資料服務的可用性，如下圖所示。
3.3.4 對象服務QoS
OSS 服務層聚焦資料組織和功能實作，由于底層盤古和有巢的分布式能力，OSS 服務層按照無狀态方式設計，進而故障時可以快速切換，提高可用性。但是，由于 OSS 是多租戶模型設計，做好 QoS 的監控和隔離，是保障租戶可用性的關鍵。
3.3.5 網絡負載均衡
OSS 要承接海量的通路請求，是以接入層采用負載均衡，通過綁定VIP提供高可用服務，并且和 OSS 的前端機（FrontEnd）叢集對接，任何子產品故障都能能夠快速切換，保證可用性。OSS 基于阿裡雲網絡團隊的負載均衡技術，提供了大流量、高性能通路能力。
3.4 安全防護
OSS 提供 HTTP/HTTPS 的資料通路服務，會受到來自“網際網路和VPC網絡”的安全攻擊，典型為DDoS (Distribution Deny of Service)，安全攻擊防護是保障 OSS 可用性的重要工作。
安全攻擊的一個目的，就是讓 OSS 之上的業務受損失，讓整體的可用性降低。
安全攻擊的兩種方法，就是擁塞 OSS 有限的帶寬入口（擁塞帶寬）、耗盡 OSS 的計算資源（耗盡資源）。
安全攻擊的三類攻擊方式，針對擁塞帶寬的網絡流量型攻擊（L3/L4 DDoS），針對耗盡資源的4層CC攻擊（連結資源）、7層CC攻擊（應用資源）。
細化的攻擊分類，如下表所示。
3.5 智能運維
3.5.1 赤骥
赤骥是阿裡雲存儲服務的管控平台，面向開發、運維、營運等内部使用者，目前已經介入對象存儲、檔案存儲、表格存儲、日志服務和函數計算五大産品，提供實時資料監控、智能運維管理、秒級的響應報警、安全審計保障等功能，緻力于用精準、高效、智能的管控系統為産品運作保駕護航。
為了更好的管控 OSS 可用性名額，赤骥從問題的發現、定位、恢複三個緯度，按照監控報警、分析診斷、問題解決分解設計，提高運維能力。同時，赤骥提供了月度 SLA 管理功能，監控月度 SLA 不達标名單以及不達标原因，進而支撐 SLA 的不斷優化。
3.5.2 OSS brain
OSS Brain 是智能運維平台，它的目标和使命是用資料+算法來保障OSS穩定運作，賦能線上運維及營運。它通過分析線上資料，提供智能決策，包括機器隔離、線上主動預警、使用者畫像、異常檢測、資源排程、使用者隔離等。通過快速靈活的智能運維、快速的隔離錯誤，進而提高可用性。
3.6 高可用解決方案
OSS 是區域級服務，區域故障将會導緻服務不可用，為了提供更高的業務可用性，OSS 提供了異地多活架構的高可用解決方案，如下所示。
寫入時隻寫主區域，開發便捷。利用 OSS 跨區域複制能力，将資料複制到備區域，進而備區域有全量的資料。
讀取時可根據地域就近讀取，降低延遲。由于寫入時隻寫資料到主區域，資料是異步複制到備區域，是以使用者讀備區域資料時，可能資料還未複制完成，此時可通過 OSS 鏡像回源功能從主區域讀取資料。
進而，可在不同的區域級故障場景時，實作快速切換，提供容災秒級 RPO(Recovery Point Objective)，保證業務應用連續性。
備區域不可用，上層業務快速切換到另外 2 個區域，并将流量均分，業務能立即恢複，切換也非常友善。
主區域不可用，則選擇新的主區域(如選擇區域2)，并開通區域2到區域3的跨域複制，進而業務可以将寫請求切換到新的主區域，讀請求也切換到剩下的區域；同時，基于 OSS 的版本控制 和 業務無更新寫，實作了主區域故障切換的資料一緻性。
3.7 管理機制
除了上述的各種技術保障外，還有如下的管理機制來提升可用性。
庫存管理。公共雲服務是重資産模式，需要自己管理供應鍊庫存，智能預測資源需求，按需提供服務是可用性的基本保證。
水位管理。對象存儲是雲存儲服務，監控容量水位、帶寬水位、QPS 等水位能力，進行動态的智能排程，可以優化系統的可用性。
穩定性文化。從開發、設計、測試、運維等環節制定穩定性制度，追求卓越的可用性能力。
雙十一錘煉和百萬級使用者打磨。OSS 長期參與阿裡叢集雙十一業務支撐，在業務洪峰的不斷錘煉下，持續淬煉産品的架構、特性、穩定性。在阿裡雲的公共雲服務體系下，有百萬級使用者的打磨，支撐各行各業的負載。經年累月的技術積累，總結了持續提升可用性的機制。
四、OSS 可用性未來工作
盡管OSS 将可用性 SLA 提升 10 倍，但是技術無止境，未來将在更新異常、超級熱點、高頻攻擊等場景下繼續優化可用性。