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

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

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

1、變更挑戰(zhàn)

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

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

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

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

2、故障挑戰(zhàn)

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

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

二、可用性能力建設(shè)

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

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

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

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

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

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

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

1）服務(wù)視角

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

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

2）全鏈路視角

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

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

3、故障預(yù)防建設(shè)

從服務(wù)和全鏈路兩個角度分析故障因素之后，故障預(yù)防建設(shè)就有了相應(yīng)的思路：

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

4、故障預(yù)防

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

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

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

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

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

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

5、故障發(fā)現(xiàn)

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

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

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

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

6、故障處理

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

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

7、故障復(fù)盤

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

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

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

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

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

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

8、容量管理

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

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

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

三、可用性階段建設(shè)

在可用性能力建設(shè)之后，我們分成三個階段去建設(shè)可用性：標(biāo)準(zhǔn)性階段、流程性階段、平臺化階段。

1、標(biāo)準(zhǔn)化階段

為什么要建設(shè)標(biāo)準(zhǔn)化？

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

• 硬件層面：機房標(biāo)準(zhǔn)化、網(wǎng)絡(luò)標(biāo)準(zhǔn)化（公網(wǎng)、主動上網(wǎng)、內(nèi)網(wǎng)專線）；
• 軟件層面：OS標(biāo)準(zhǔn)化、主機環(huán)境標(biāo)準(zhǔn)化、服務(wù)目錄標(biāo)準(zhǔn)化、Agent標(biāo)準(zhǔn)化、接入nginx集群標(biāo)準(zhǔn)化、服務(wù)能力標(biāo)準(zhǔn)化（中間件服務(wù)）。

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

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

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

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

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

四、可用性結(jié)果與展望

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

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

• 可用性能力建設(shè)：故障預(yù)防、故障發(fā)現(xiàn)、故障治愈、故障復(fù)盤
• 可用性階段建設(shè)：標(biāo)準(zhǔn)化、流程/規(guī)范化、平臺/自動化

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

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

可用性建設(shè)還能做些什么？

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

Q&A

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

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

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

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

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

講師介紹

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