一、問題與挑戰(zhàn)

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

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

1、變更挑戰(zhàn)

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

我們的單次的發(fā)布時間是比較長的；

存在很多的業(yè)務大量遷移的場景；

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

2、故障挑戰(zhàn)

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

在此挑戰(zhàn)下，我們分為了可用性能力和可用性階段兩個維度去建設，以此保障業(yè)務的穩(wěn)定性。

二、可用性能力建設

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

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

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

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

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

2、故障發(fā)生分析

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

1）服務視角

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

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

2）全鏈路視角

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

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

3、故障預防建設

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

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

4、故障預防

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

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

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

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

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

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

5、故障發(fā)現

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

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

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

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

6、故障處理

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

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

7、故障復盤

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

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

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

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

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

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

8、容量管理

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

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

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

三、可用性階段建設

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

1、標準化階段

為什么要建設標準化？

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

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

2、流程化與規(guī)范化建設

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

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

3、平臺與系統(tǒng)建設

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

四、可用性結果與展望

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

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

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

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

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

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

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

Q&A

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

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

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

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

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

講師介紹

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