阿里雲和騰訊雲都曾出現過因一個元件故障而導致所有可用區同時癱瘓的情況。本文將探討如何從架構設計的角度減小故障域，在故障發生時最小化業務損失，並以 Sealos 的穩定性實踐為例，分享經驗教訓。
拋棄主從，擁抱點對點架構
從騰訊雲故障報告中可以看出來多可用區一起掛基本都是因為一些集中化的元件造成，比如統一 API，統一鑑權認證之類的系統故障。
所以這個 X 系統一掛，故障域就會非常大。
相比之下，去中心化的點對點架構能夠很好地規避這一風險。以比特幣網路為例，由於不存在中心節點，其穩定性遠高於傳統的主從式叢集，幾乎很難掛機。
所以 Sealos 在設計多可用區的時候就充分吸取了阿里雲騰訊雲的教訓，採用了一種無主的架構，所有可用區都是自治的，主要問題是像使用者賬戶這些資料如何在多可用區同步的問題。變成了這樣的一種架構：
各可用區完全自治，僅在關鍵的共享資料 (如使用者賬戶資訊) 上透過跨區域分散式資料庫 (我們使用的是 CockroachDB) 進行同步。每個可用區都連線分散式資料庫 CockroachDB 在本地的節點。
這樣一來，單個可用區的故障就不會影響其他區域的業務連續性。只有在分散式資料庫叢集整體發生問題時，才會導致所有可用區的控制面不可用。好在 CockroachDB 本身在容錯、災備、應對網路分割槽等方面有著出色的表現，大大降低了這種情況的發生機率。這樣整體的架構就簡單了，集中精力把資料庫的穩定性做好就行，監控，破壞性測試都做好。
這樣做的另外一個好處是為灰度釋出、差異化運營提供了便利。例如，新功能可以先在部分割槽域進行小流量驗證，待穩定後再全量上線；不同區域也可以根據客戶群體的特點，提供定製化的服務，而不必保持完全一致。
絕對穩定的系統不存在
大家對雲的穩定性噴的比較多，但凡是個雲廠商無一例外都出現過故障，我們也出現過過非常多的故障，這裡最重要的是如何收斂，他不僅是個技術問題，也是個組織管理問題，同樣也還是個成本問題，這塊我結合創業過程中我們遇到的具體例子來給大家做個分享。
Sealos 從故障中汲取的教訓
2023.3.17 日 Laf 重大故障
這是創業首次遇到的重大故障，產品上線還沒兩天就給我們當頭一棒，時間記的這麼清楚是因為剛好是公司一週年慶祝，蛋糕都沒有時間切，一直恢復到夜裡三點多。
最終故障原因很奇葩，是我們貪圖便宜用了輕量伺服器，輕量伺服器上做容器的網路虛擬化會導致丟包，最終我們把整個叢集遷移到了正常的一個 VPC 伺服器上，所以很多時候解決穩定性和成本分不開。
所以很多都覺得公有云貴什麼的，很多時候為了解決剩下的那 10% 的問題確實要花很多倍的成本。
Laf 後續有出現了一系列資料庫相關的穩定性問題，因為使用的是多租戶共享一個 MongoDB 庫的模型，最終論證的結論是這條路我們走不通，資料庫隔離性問題我們很難解決，所以現在全部採用了獨立資料庫的方式，問題得到最終解決。
還有閘道器上的穩定性問題，我們一開始選了某個不靠譜的 Ingress 控制器，問題頻發，具體是哪家就不點名了，最終換成了 Higress，徹底解決這個問題，目前不僅資源佔用更少，而且更穩定，這裡也非常感謝阿里 Higress 團隊的貼身支援，我們暴露的問題也更好的幫助了 Higress 的更成熟，雙贏。
2023 年 6 月我們 Sealos 公有云正式上線，遇到一個最大的問題就是被攻擊，流量很大的 CC 攻擊，加防護能解決但是也意味著成本的飆升，所以在這兩者之間的權衡就很糾結了，不防穩定性難解決，防了賣的錢收不回成本。後來我們把閘道器換掉之後，發現 Envoy 是真的強，居然能把攻擊的流量抗下來了，在那之前用的是 Nginx，一掛掛一片。而且 K8s 厲害的的地方就是自愈能力強，即便閘道器掛了 5min 內也能實現自愈，只要不是同時掛，業務基本不受影響。
穩定性不斷收斂的最佳實踐
故障處理的流程
為了讓系統穩定性不斷收斂提升，Sealos 在內部建立了一套嚴格的故障管理流程：
每次故障發生後，都要詳細記錄，並持續跟進。很多公司走到故障覆盤就結束了，但事實上覆盤不是目的，關鍵要形成切實可行的整改措施，並予以落實，徹底防止類似故障再次發生。故障處置完成後仍需持續觀察一段時間，直至確認問題不再出現。
在管理目標上，一開始我們在 2024 Q1 OKR 中這樣去定義了穩定性收斂的目標：
後來發現這種籠統的口號式 OKR 並不靠譜，穩定性的收斂需要更具體，這個 KR 的結果是我們沒達成，幾乎沒起到什麼效果。在收斂的過程你並不需要全面開花，每個季度聚焦在幾個核心點上，持續迭代幾個季度就會收斂的非常好。
所以在 Q2 時我們定了更具體的目標：
對穩定性的設定，不能僅停留於設定個指標，也不能過於籠統，需要具體可見的措施，需要具體的衡量辦法。
比如，如果設定 99.9%，如何達到？那麼當前的可用性是多少？當前的核心問題是什麼？如何測量？需要做些什麼？誰來做？設定不侷限於可用時長，要列細一些，比如故障等級、故障次數、故障時長、大客戶故障觀測等等。
要分出專項類別，列出優先順序，比如：資料庫穩定性、閘道器穩定性、大客戶服務可用性指標、CPU/記憶體資源過載故障。
還要重點監測大客戶，比如自走棋、FastGPT 商業大客戶、匆匆雪工作室等 (月使用 30 核以上，挑出 5 個典型)。
穩定性問題就那麼多，當服務好了這些大客戶基本就能覆蓋掉小客戶，不追求多，聚焦解決當前最核心的穩定性問題，然後一定要建立起一個完善的跟蹤流程。
造成故障的同學可能會收到懲罰，扣獎金，甚至開除。我們作為創業公司通常不會用懲罰的措施，因為當事人也不想造成故障，而且大家都也確實很辛苦的在解決問題，真正能打仗的都是負過傷的，我們更傾向正面的激勵，比如如果季度故障頻率降低，就適當給些激勵。
大道至簡的架構設計
系統架構從設計開始就關係到了穩定性，越複雜的架構越容易出問題，所以很多公司沒有重視到這一點，我經常參與公司架構設計和評審，通常發現設計過於複雜在我這都很難過得去，就感覺哪不對，Sealos 多可用區就是一個非常好的例子，把一個複雜的事情變成一個簡單的 CRUD，那隻需要把資料庫穩定性做好，資料庫表結構設計簡單很多穩定性問題就被扼殺在搖籃中了。
我們的計量系統也是這樣，起初設計了怕有十幾個 CRD，折騰了大半年穩定性也收斂不下來，最後重新設計選型，差不多兩週開發完了，一個月就穩定上線了。
所以：大道至簡的設計對穩定性至關重要！
適度監控，有的放矢
監控是把雙刃劍，過猶不及。Sealos 很多次故障都是因為監控造成的，Prometheus 佔用資源過大，API Server 不堪重負，反而引發了新的穩定性問題。吸取教訓後，我們改用 VictoriaMetrics 這種更輕量級的監控方案，同時嚴格控制監控指標的數量。類似 Uptime Kuma 這種工具就很實用，跨區域相互撥測，及時發現問題。
on call 也是如此，每天幾千條告警，on call 什麼東西？所以這裡基本是從 0 開始慢慢做加法，比如我們是先從 “大客戶業務最終穩定性” 這個視角去做的，比如一個容器故障推出了這個如果要 on call 的話那估計電話響個不停。再慢慢加上比如主機 not ready 這些。主機 not ready 理論上不應該影響業務，隨著系統的逐漸成熟，最終可以做到 not ready 也不需要 on call。
故障通報不能怕丟人
騰訊雲的覆盤報告就做得非常好，如實說明故障發生的原因，客觀分析哪些地方做得還不夠，並承諾積極整改。這種坦誠、負責的態度，其實更容易贏得使用者的信任。相比之下，對問題諱莫如深，生怕輿論發酵，無異於飲鴆止渴，反而讓使用者覺得是個不透明的黑盒，今後還不知會出什麼么蛾子。真正熱愛你的產品、願意與你相伴成長的客戶，是能夠包容非原則性錯誤的。關鍵要拿出實實在在改進的誠意和行動。
總結
Sealos 公有云服務上線一年多來，已經積累了十多萬註冊使用者。憑藉出色的功能、體驗和價效比，不少開發者青睞有加，部分大客戶也開始嘗試將業務遷移到我們 Sealos 雲上。這其中不乏一些大型網際網路產品，例如《開心自走棋》遊戲就有 400 多萬活躍使用者。
放眼未來，我們相信透過系統化的故障管理不斷收斂穩定性，透過簡潔高效的架構設計、穩紮穩打的監控策略，再輔之以開誠佈公的溝通態度，Sealos 這個由國內開源小公司孕育發展起來的雲一定會變成一朵非常先進的雲！