在北京寒冬的夜裏，小程加班完成了當天最後一個任務，他拖着疲憊的身體離開了位於西二旗的工位，走到辦公樓下，下意識地拿出手機打開滴滴，準備打車回家，但是他卻發現滴滴的打車頁面顯示網絡異常。起初小程以為是手機流量沒開或者手機欠費，經過反覆確認後發現不是話費欠費問題，於是他重啓了滴滴 app，甚至重啓了手機，但都是一樣的結果：
在寒風中折騰了半個小時，將本來就沒穿秋褲的小程凍得瑟瑟發抖，直到在 DevOps 技術交流羣中看到很多小夥伴都遇到了這種情況，小程意識到，可能是滴滴出問題了。 羣裏的小夥伴也在討論：是不是高可用沒做好？
事後，滴滴出行發佈了致歉信併發布了事故的初步調查原因：並不是網絡攻擊而是底層系統軟件發生故障。
同樣的 P0 事故在半個月之前發生在了阿里雲身上。
11 月 12 日，雙十一剛過，阿里雲發生了宕機，旗下的釘釘、淘寶、閒魚等產品皆受到了不同程度的影響，此次事故還影響到了使用阿里雲的一些企業級客户。經過數小時的修復後，服務恢復正常。
如果再往前一個月，同樣的 P0 事故又發生在了語雀身上。
10 月 23 日，程序員節的前一天，語雀出現重大服務故障，持續了 7 個多小時才完全恢復。事故的整個過程及原因分析法不在了關於語雀 23 日故障的公告中。
一個多月的時間內，大廠的產品相繼發生了三起 P0 事故。其實任何一家企業都不想自身的產品或服務出現 P0 事故，任何一個程序員都不想有處理 P0 事故的機會。事故既然已經發生，那麼就要去覆盤，然後制定對應的計劃避免後續再發生類似的故障。而這類計劃中可能會有一個永遠繞不過去的話題：高可用。
高可用是一種軟件架構模式，主要是為了讓應用程序能夠滿足業務規模的快速發展，尤其對於大規模或者超大規模的企業來講，高可用是提升企業服務可靠性、可用性的重要手段。
設想一個場景：企業內部正在抓緊研發一款基於 AIGC 的產品，產品所處的賽道還處於空白狀態，突然得知，另外一家競品公司決定提前發佈產品。於是公司全員開始加班，希望能比競品更早發佈產品，以達到快速佔領市場的目的。但是在關鍵時刻，源代碼託管平台崩了，數千人無法提交代碼了。運維人員查看之後發現單點設置的源代碼託管平台，在數千人的協作下崩盤了。由於沒有采用企業級的服務，運維人員只能自行查找資料去修復。ETA：unknown。所有人只能眼睜睜地在辦公室看競品的發佈會了。
如何避免這種“悲劇”？
答案是：搭建源代碼託管平台的高可用架構。
極狐GitLab 高可用方案
極狐GitLab 高可用擴展性架構
極狐GitLab 提供高可用擴展性架構，其源自全球最大代碼託管平台之一的 GitLab.com 十多年的技術實踐沉澱，該架構通過了全球 3000 萬註冊用户的檢驗。
極狐GitLab 高可用擴展性架構通過把極狐GitLab 中所有組件單獨抽出來，以分佈式集羣的方式部署，每一個服務和組件都是多副本的，在整體架構設計上不存在單點故障，並結合負載均衡、水平伸縮、分佈式架構、主從多副本機制和雲原生等多種機制，實現理論上無限擴展的能力。
極狐GitLab 提供支撐從 1000 人到 50000 人規模架構最佳實踐參考和專業服務支持，為企業構建高度可靠 DevOps 研運平台保駕護航。
極狐GitLab 在數據存儲方面使用了多個組件，如 PGSQL 和 Redis，不少客户已經將極狐GitLab 實例中的這些組件替換為第三方的高可用組件。但極狐GitLab 中最核心的存儲組件卻不是 PGSQL 也不是 Redis，而是 Gitaly，這是 GitLab 自研的組件，用於對代碼倉庫進行管理和指令互動，因此它的地位最重要，負載也最高。
因為有些企業的數據量多達 30 T 級別，使用單個磁盤或單個節點的成本很高，且性能無法保證。Gitaly Cluster 高可用 Git 倉庫服務持多副本和分片，把不同的代碼庫分到不同的存儲片上，這也是提高可用性和性能的方式。
極狐GitLab GEO 多地域部署架構
相較於支持 1000 人起步的高可用可擴展架構，極狐GitLab GEO 多地域部署架構則更為輕量和簡單，更加適合中小型企業。
GEO 多地域部署架構實現一主多從，主從之間的數據實時同步。極狐GitLab GEO 多地域部署方案是熱備份，即便主節點宕機，也可以把從節點處將其恢復，或提升從節點為主節點，那麼丟失的數據最多是 1～2 分鐘的數據。所以 GEO 多地域部署的時效性和可靠性大大高於傳統冷備份方式，屬於準高可用，同時是災備架構，並支持異地容災。
極狐GitLab 的高可用架構和 GEO 功能配合使用，能夠為大規模甚至超大規模企業的高效協作提供有力保障，避免因為代碼託管平台自身的故障而導致代碼無法提交，影響產品的正常發佈及系統的穩健運行。
為了方便大家體驗極狐GitLab 一體化 DevOps 平台的專業版功能，大家可以申請 60 天專業版免費試用。
