一、問題與挑戰

從圖中可以看到，從17年開始，vivo的機器規模、服務數量都有很大的增長。在機器規模方面，從17年到22年大概是增長了五倍的左右，在服務數量方面也是基本上增長了十幾倍。

在規模增長的情況下，挑戰和復雜度肯定隨之上升，在vivo比較典型的挑戰主要分為變更挑戰和故障挑戰。

1、變更挑戰

變更中還是存在著或多或少的手工變更場景；

我們的單次的發布時間是比較長的；

存在很多的業務大量遷移的場景；

谷歌SRE有這樣一個概念：70%的故障是由變更引起的。對應到vivo也確實是存在這種情況，變更對線上穩定性確實存在很大的影響。

2、故障挑戰

• 機房級故障風險（大小公司都會遇到，光纖挖斷或機房內部故障等）；
• 業務快速增長對容量需求大幅增加。

在此挑戰下，我們分為了可用性能力和可用性階段兩個維度去建設，以此保障業務的穩定性。

二、可用性能力建設

1、基于故障的全生命周期開展

我們的可用性的能力建設是基于故障的全生命周期去開展的，從故障發生、發現、響應、恢復、復盤到再次發生。從故障發生到恢復的時間，稱為MTTR；從故障的恢復到發生，從穩定到不穩定，稱為MTTF；故障發生的間隔時間，稱為MTBF，總計3個指標。

故障管理無非就是這4點：

• 如何預防故障的發生？
• 如何盡快發現故障？
• 如何快速進行故障治愈？
• 故障恢復后，如何復盤跟進？

從業務可用性的角度來看，主要關注的是故障的發生頻次和影響時間。所以，減少故障發生頻次、快速定位故障發生、縮短故障持續時間、實現故障快速治愈，就是我們整個高可用能力建設的大體思路。下面從我們已落地的措施跟大家介紹：

2、故障發生分析

首先，要實現故障預防，首先要了解故障為什么發生，可以從服務視角和全鏈路視角來看。

1）服務視角

一個服務，無非就是有請求的輸入，正常來說有相應的輸出就可以。但實際上，很多方面都會影響服務最終的正確響應，在一些比較經典的場景里，總結出來的影響因素有：

• 容量方面：業務請求倍數級增長，會導致單個服務的輸出異常；
• 服務方面：軟件本身有bug在運行，結果服務運行crush了；
• 硬件方面：主機硬件、機房、網絡導致的異常。

2）全鏈路視角

• 容量層：請求突增，全鏈路的容量不足，導致服務出現異常；
• 服務層：服務和服務之間需要協同配置，配置設置不對也會導致全鏈路異常；
• 上下游依賴：一些關鍵服務的異常，會導致整個鏈路的異常。

從全鏈路的穩定性來看：上下游的依賴、容量不足和服務配置異常等，都是影響穩定性的重要因素。

3、故障預防建設

從服務和全鏈路兩個角度分析故障因素之后，故障預防建設就有了相應的思路：

• 全鏈路異常：要做好上下游強弱依賴分析，并對關鍵的服務器做專項保障，以此保障全鏈路的穩定性；
• 變更異常：建立變更流程規范、變更管理平臺；
• 基礎設施異常：依賴高可用架構，去除單點風險，做好冗余容災。

4、故障預防

前面講了整體的分析和建設思路，實際上vivo是怎么做的呢？

我們基于全鏈路做了建設保障，整個鏈路從接入層、業務邏輯層、中間件層、存儲層、基礎設施層進行了建設：

1）單元化：減少跨機房之間的服務調用，避免單機房的故障影響到所有機房服務；

2）多入口：之前很多業務只有單個接入層入口，建設IDC和公有云的多入口能力之后，單個入口異常對服務整體接入的影響就會變小；

3）過載保護：當業務突增容量的時候，接入層服務根據設置能夠主動拒絕部分突發請求，防止過高的請求流量把后面的服務打垮；

4）熔斷降級：對依賴服務做好壟斷降級，可以屏蔽異常服務帶來的影響，避免雪崩效應。

5、故障發現

我們建設了基于全鏈路的故障發現能力，目到故障主動發現率能達到90%，這當中包括客戶端監控、服務端監控和基礎監控：

1）客戶端監控：自建撥測系統，通過旁路的模擬用戶訪問方式，監控各服務的可用性情況；

2）服務端監控：包括域名監控、日志監控和服務之間的調用監控，按照監控的實現方式主要是metrics/logs/trace；

3）基礎監控：監控主機的硬件資源使用情況，主要是metrics方式。

6、故障處理

主要包括故障分析和故障處理。

• 故障分析：和監控系統聯動，支持基礎服務故障分析、域名可用性分析等；
• 故障處理：故障預案建設，包括預案的制定、演練等。

7、故障復盤

故障復盤在整個高可用建設周期里面是非常重要的一環。

我們通過基于業務的SLA分級，有的放矢地去保證業務的穩定性，并做好業務的每一個故障記錄，改進和驗證能力建設：

1）業務分級：運維資源非常有限，保證保障所有業務有相同的SLA，因此分級保障是非常有必要的，我們基于業務的口碑、營收，分為核心、重要、一般、其它四個業務級別，以此指導投入到各業務的運維人力和保障力度；

2）故障記錄：提高復盤效率，同時跟蹤線上業務故障做后續分析，以此指導業務進行優化；

3）故障改進：基于混沌工程做后向驗證，判斷改進措施是否有落地生效。

這是我們在故障復盤上的實踐，我們也將這些能力和實踐落地到了平臺，通過平臺去管理故障復盤工作。

8、容量管理

線上故障很多都是容量問題導致的，容量資源到位后，可用性也能得到一定的保障，在這方面，我們主要提升了兩方面的能力：資源彈性伸縮能力、資源交付運營管理能力。

• 資源彈性伸縮能力：建設基于混合云的資源保障能力，極大提升資源彈性能力；

• 資源交付運營管理能力：建設資源的全生命周期的管理機制，保證資源的供應跟使用效率最大化，實現了包括預算管理、需求管理、采購管理、存量運營管理。

三、可用性階段建設

在可用性能力建設之后，我們分成三個階段去建設可用性：標準性階段、流程性階段、平臺化階段。

1、標準化階段

為什么要建設標準化？

通過標準化，我們能夠極大降低業務的運維復雜度，進而降低運維成本。我們在硬件和軟件層面，都做了很多標準化工作。

• 硬件層面：機房標準化、網絡標準化（公網、主動上網、內網專線）；
• 軟件層面：OS標準化、主機環境標準化、服務目錄標準化、Agent標準化、接入nginx集群標準化、服務能力標準化（中間件服務）。

2、流程化與規范化建設

首先，我們會將運維過程中做得比較好的實踐和方法沉淀成流程機制和規范，讓業務穩定性保障有序可控，包括運維軍規、故障響應機制、公共事項規范、大型活動保障規范等。

例如大型活動的保障規范，在規范沒有建立起來之間，如有大型運營活動或春節紅包派送活動的時候，線上很容易出故障，自從2018年把大型活動保障規范建立起來之后，春節等重保都能保障平穩運行。

3、平臺與系統建設

在平臺與系統建設上，以CMDB為底座，把往常較好的流程機制更進一步做成平臺，如變更平臺、監控平臺、服務工具平臺等，以此支撐業務穩定性。

四、可用性結果與展望

到2022年，整體業務穩定性運維實現有序高效，業務可用性從之前的3個9提升到現在4個9，達標的業務個數也從之前的8個到現在的24個。

達到這個可用性結果，主要就是通過可用性能力建設和可用性階段建設：

• 可用性能力建設：故障預防、故障發現、故障治愈、故障復盤
• 可用性階段建設：標準化、流程/規范化、平臺/自動化

未來，我們會重點關注異地多活、容器/云原生的可用性保障。

以容器、云原生方面的可用性保障為例，我們之前更多的是純物理機，后面增加了虛擬機，再到后來補充了公有云，進一步降低了對底層基礎設施的直接依賴，同時我們也在做容器、云原生，將資源單元化、靈活調度，降低對物理硬件資源的直接依賴，因此我們要構建不同基礎架構的高可用能力。

可用性建設還能做些什么？

我個人認為，我們不單單只是考慮可用性，業務的質量和運營成本都是需要我們考慮的，業務的運維保障后續要進入到精細化運營保障階段。

Q&A

Q1：在可用性建設落地的過程中，遇到的最大難點是什么？

A1：第一點是底層技術能力的建設規范，這些規范如果不準守會導致業務可用性結果存在很大的不確定性，所以要對團隊制定一定的規范，同時也要有一定的守底機制；

第二點是上層認可，每個業務在不同的階段訴求是不一樣的，穩定性做得不好，會影響業務、口碑和營收，獲得上層的認可后，可用性建設也更容易推動。

Q2：請問貴司在CMDB落地過程中，除了關聯開發負責人、主機等信息，在實際過程中還關聯過哪些信息？比如是否關聯中間件的信息？

A2：我們很多系統當前都是以CMDB為底座的，不僅僅是運維系統，很多系統都是基于CMDB去搭建的，中間件服務也會和CMDB做關聯建設，比如微服務里面的dubbo，也是基于CMDB去做服務發現和治理。

講師介紹

周甲黎，現任vivo運維總監，負責vivo互聯網業務的業務運維工作。曾先后就職于百度、騰訊，具有客戶端、國際化、大數據算法等在離線業務運維經驗。加入vivo后主導了業務的高可用性建設，使業務可用性達到99.99%水平。