Day 03 介紹過 Berry AI 的四個團隊，其中 SRE 負責橫跨 edge 與 cloud 的系統穩定性。前面各篇描述的雲地整合架構，讓 Berry AI 的 SRE 工作與純 SaaS (例如 Web 服務) 公司的 SRE 有很大的差異。本篇先用一個可用性估算說明差異從何而來，再帶出接下來幾篇 SRE Team 要談的主題。

純雲端服務可以把基礎設施風險轉嫁給 CSP

純 Web 服務的基礎設施風險，可以透過雲端服務供應商 (Cloud Service Provider, CSP) 的 SLA 轉嫁出去，再以混合雲或多雲架構做高可用 (High Availability, HA)。熟悉 SLI / SLO (Service Level Indicator / Objective，服務水準指標與目標) 概念的讀者可以想像，這樣的架構幾乎可以不必在意基礎設施層的 SLI / SLO。以下用一個跨 CSP、從 Load Balancer 到容器層級的 Web 服務為例，估算基礎設施的可用性。

Route53  --> GCP LB -> GCP Cloud Run
(failover)|-> AWS LB -> AWS ECS

---
GCP path = 99.99% × 99.95%
         = 99.940005%

AWS path = 99.99% × 99.99%
         = 99.980001%

兩邊同時失效 =
(1 - 0.99940005) × (1 - 0.99980001)
= 0.000000119984

Global =
1 - 0.000000119984
= 99.9999880016%
≈ 99.999988%

估算的前提如下：

• Route 53 的 SLA 是 100%，直接略過不計。
• 先不看 DNS record 與服務切換時的延遲。
• 各項數字都取官方 SLA 的最高條件：GCP Load Balancing 的 99.99% 限 Premium Tier，Cloud Run 的 99.95% 限非 GPU 服務，AWS ELB (Elastic Load Balancing) 與 ECS 的 99.99% 都要求 Multi-AZ 部署。
• SLA 直接當作可靠度。實際上 CSP 未達 SLA 是以服務抵用金 (service credit) 補償，所以這只是估算。

以上概算，就能讓純 SaaS 的 SRE 不必為基礎設施的可用性操心。

實體設備讓 SRE 無法只依靠 CSP

Berry AI 的產品除了雲端資料服務，還包含特製的 edge server 與 AI 模型。每一套服務的可用性都與實體環境及硬體狀況綁定，SRE 無法單純依靠 CSP 來確保服務穩定。

面對實體設備的管理，我們需要在實驗室與實地場域進行大量穩定性測試。這套做法是逐步建立起來的：從草創初期，到累積大量的設備監控資料，再到建立流程以提升軟硬體變更 (change) 的掌握度，每個環節都會影響最終的產品品質與用戶體驗。如今 Berry AI 管理著上萬台實體設備，SLI 仍能長期維持在 99.9% 以上。

小結

純雲端服務的基礎設施可用性可以用 CSP 的 SLA 估算出來，做了多雲 failover 之後的數字高到幾乎不必擔心。Berry AI 的服務多了實體設備這一層，可靠性無法由 CSP 的 SLA 推導，必須靠測試、監控與變更流程自己建立。接下來幾篇會介紹 SRE Team 目前專注的項目，讓讀者一窺 Berry AI 的 SRE 工作。

參考資料

• Amazon Route 53 Service Level Agreement
• Compute Engine Service Level Agreement (SLA)
• Cloud Run Service Level Agreement (SLA)
• Elastic Load Balancing Service Level Agreement
• Amazon ECS Service Level Agreement

本系列由 Berry AI 工程團隊出品。更多工程實戰紀錄都在 Berry AI 技術部落格。