一、問題與挑戰(zhàn)
自2017年起，vivo的機器規(guī)模和服務數(shù)量都有顯著增長，這可以從圖表中看出。機器規(guī)模大約增長了五倍左右，服務數(shù)量也基本上增長了十幾倍，其時間跨度為從2017年至2022年。
在規(guī)模增長的情況下，挑戰(zhàn)和復雜度肯定隨之上升，在vivo比較典型的挑戰(zhàn)主要分為變更挑戰(zhàn)和故障挑戰(zhàn)。
1、變更挑戰(zhàn)
變更中還是存在著或多或少的手工變更場景；
我們的單次的發(fā)布時間是比較長的；
存在很多的業(yè)務大量遷移的場景；
谷歌SRE有這樣一個概念：70%的故障是由變更引起的。在vivo也存在這種情況，變更對線上穩(wěn)定性會有很大的影響。
2、故障挑戰(zhàn)
- 機房級故障風險（大小公司都會遇到，光纖挖斷或機房內(nèi)部故障等）；
- 業(yè)務快速增長對容量需求大幅增加。
在此挑戰(zhàn)下，我們分為了可用性能力和可用性階段兩個維度去建設，以此保障業(yè)務的穩(wěn)定性。
二、可用性能力建設
1、基于故障的全生命周期開展
我們的可用性能力建設是基于全周期故障管理開展的，涵蓋故障發(fā)生、發(fā)現(xiàn)、響應、恢復、復盤及預防措施。從故障發(fā)生到恢復的時間，稱為MTTR；從故障的恢復到發(fā)生，從穩(wěn)定到不穩(wěn)定，稱為MTTF；故障發(fā)生的間隔時間，稱為MTBF，總計3個指標。
故障管理無非就是這4點：
- 如何預防故障的發(fā)生？
- 如何盡快發(fā)現(xiàn)故障？
- 如何快速進行故障治愈？
- 故障恢復后，如何復盤跟進？
主要從業(yè)務可用性方面考慮，需要關注故障的發(fā)生頻率以及對業(yè)務的影響時間。所以，減少故障發(fā)生頻次、快速定位故障發(fā)生、縮短故障持續(xù)時間、實現(xiàn)故障快速治愈，就是我們整個高可用能力建設的大體思路。下面從我們已落地的措施跟大家介紹：
2、故障發(fā)生分析
首先，要實現(xiàn)故障預防，首先要了解故障為什么發(fā)生，可以從服務視角和全鏈路視角來看。
1）服務視角
一個服務，無非就是有請求的輸入，正常來說有相應的輸出就可以。在實際情況下，有很多方面會影響服務的正確響應。在一些經(jīng)典場景中，已經(jīng)總結(jié)出了影響因素
- 容量方面：業(yè)務請求倍數(shù)級增長，會導致單個服務的輸出異常；
- 服務方面：軟件本身有bug在運行，結(jié)果服務運行crush了；
- 硬件方面：主機硬件、機房、網(wǎng)絡導致的異常。
2）全鏈路視角
- 容量層：請求突增，全鏈路的容量不足，導致服務出現(xiàn)異常；
- 服務層：服務和服務之間需要協(xié)同配置，配置設置不對也會導致全鏈路異常；
- 上下游依賴：一些關鍵服務的異常，會導致整個鏈路的異常。
從全鏈路的穩(wěn)定性來看：上下游的依賴、容量不足和服務配置異常等，都是影響穩(wěn)定性的重要因素。
3、故障預防建設
從服務和全鏈路兩個角度分析故障因素之后，故障預防建設就有了相應的思路：
- 全鏈路異常：要做好上下游強弱依賴分析，并對關鍵的服務器做專項保障，以此保障全鏈路的穩(wěn)定性；
- 變更異常：建立變更流程規(guī)范、變更管理平臺；
- 基礎設施異常：依賴高可用架構(gòu)，去除單點風險，做好冗余容災。
4、故障預防
前面講了整體的分析和建設思路，實際上vivo是怎么做的呢？
我們基于全鏈路做了建設保障，整個鏈路從接入層、業(yè)務邏輯層、中間件層、存儲層、基礎設施層進行了建設：
1）單元化：減少跨機房之間的服務調(diào)用，避免單機房的故障影響到所有機房服務；
2）多入口：之前很多業(yè)務只有單個接入層入口，建設IDC和公有云的多入口能力之后，單個入口異常對服務整體接入的影響就會變小；
3）過載保護：當業(yè)務突增容量的時候，接入層服務根據(jù)設置能夠主動拒絕部分突發(fā)請求，防止過高的請求流量把后面的服務打垮；
4）熔斷降級：對依賴服務做好壟斷降級，可以屏蔽異常服務帶來的影響，避免雪崩效應。
5、故障發(fā)現(xiàn)
我們建設了基于全鏈路的故障發(fā)現(xiàn)能力，目到故障主動發(fā)現(xiàn)率能達到90%，這當中包括客戶端監(jiān)控、服務端監(jiān)控和基礎監(jiān)控：
1）客戶端監(jiān)控：自建撥測系統(tǒng)，通過旁路的模擬用戶訪問方式，監(jiān)控各服務的可用性情況；
2）服務端監(jiān)控：包括域名監(jiān)控、日志監(jiān)控和服務之間的調(diào)用監(jiān)控，按照監(jiān)控的實現(xiàn)方式主要是metrics/logs/trace；
3）基礎監(jiān)控：監(jiān)控主機的硬件資源使用情況，主要是metrics方式。
6、故障處理
主要包括故障分析和故障處理。
- 故障分析：和監(jiān)控系統(tǒng)聯(lián)動，支持基礎服務故障分析、域名可用性分析等；
- 故障處理：故障預案建設，包括預案的制定、演練等。
7、故障復盤
故障復盤在整個高可用建設周期里面是非常重要的一環(huán)。
我們通過基于業(yè)務的SLA分級，有的放矢地去保證業(yè)務的穩(wěn)定性，并做好業(yè)務的每一個故障記錄，改進和驗證能力建設：
1）業(yè)務分級：運維資源非常有限，保證保障所有業(yè)務有相同的SLA，因此分級保障是非常有必要的，我們基于業(yè)務的口碑、營收，分為核心、重要、一般、其它四個業(yè)務級別，以此指導投入到各業(yè)務的運維人力和保障力度；
2）故障記錄：提高復盤效率，同時跟蹤線上業(yè)務故障做后續(xù)分析，以此指導業(yè)務進行優(yōu)化；
3）故障改進：基于混沌工程做后向驗證，判斷改進措施是否有落地生效。
這是我們在故障復盤上的實踐，我們也將這些能力和實踐落地到了平臺，通過平臺去管理故障復盤工作。
8、容量管理
線上故障很多都是容量問題導致的，容量資源到位后，可用性也能得到一定的保障，在這方面，我們主要提升了兩方面的能力：資源彈性伸縮能力、資源交付運營管理能力。
- 資源彈性伸縮能力：建設基于混合云的資源保障能力，極大提升資源彈性能力；
- 資源交付運營管理能力：建設資源的全生命周期的管理機制，保證資源的供應跟使用效率最大化，實現(xiàn)了包括預算管理、需求管理、采購管理、存量運營管理。
三、可用性階段建設
在可用性能力建設之后，我們分成三個階段去建設可用性：標準性階段、流程性階段、平臺化階段。
1、標準化階段
為什么要建設標準化？
標準化能夠極大地減輕業(yè)務的運維復雜度，從而降低運維成本。我們在硬件和軟件層面，都做了很多標準化工作。
- 硬件層面：機房標準化、網(wǎng)絡標準化（公網(wǎng)、主動上網(wǎng)、內(nèi)網(wǎng)專線）；
- 軟件層面：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)定性。
四、可用性結(jié)果與展望
到2022年，整體業(yè)務穩(wěn)定性運維實現(xiàn)有序高效，業(yè)務可用性從之前的3個9提升到現(xiàn)在4個9，達標的業(yè)務個數(shù)也從之前的8個到現(xiàn)在的24個。
達到這個可用性結(jié)果，主要就是通過可用性能力建設和可用性階段建設：
- 可用性能力建設：故障預防、故障發(fā)現(xiàn)、故障治愈、故障復盤
- 可用性階段建設：標準化、流程/規(guī)范化、平臺/自動化
未來，我們會重點關注異地多活、容器/云原生的可用性保障。
以容器、云原生方面的可用性保障為例，我們之前更多的是純物理機，后面增加了虛擬機，再到后來補充了公有云，進一步降低了對底層基礎設施的直接依賴，同時我們也在做容器、云原生，將資源單元化、靈活調(diào)度，降低對物理硬件資源的直接依賴，因此我們要構(gòu)建不同基礎架構(gòu)的高可用能力。
可用性建設還能做些什么？
我個人認為，我們不單單只是考慮可用性，業(yè)務的質(zhì)量和運營成本都是需要我們考慮的，業(yè)務的運維保障后續(xù)要進入到精細化運營保障階段。
Q&A
Q1：在可用性建設落地的過程中，遇到的最大難點是什么？
A1：第一點是底層技術(shù)能力的建設規(guī)范，這些規(guī)范如果不準守會導致業(yè)務可用性結(jié)果存在很大的不確定性，所以要對團隊制定一定的規(guī)范，同時也要有一定的守底機制；
第二點是上層認可，每個業(yè)務在不同的階段訴求是不一樣的，穩(wěn)定性做得不好，會影響業(yè)務、口碑和營收，獲得上層的認可后，可用性建設也更容易推動。
Q2：請問貴司在CMDB落地過程中，除了關聯(lián)開發(fā)負責人、主機等信息，在實際過程中還關聯(lián)過哪些信息？比如是否關聯(lián)中間件的信息？
A2：我們很多系統(tǒng)當前都是以CMDB為底座的，不僅僅是運維系統(tǒng)，很多系統(tǒng)都是基于CMDB去搭建的，中間件服務也會和CMDB做關聯(lián)建設，比如微服務里面的dubbo，也是基于CMDB去做服務發(fā)現(xiàn)和治理。
講師介紹
周甲黎現(xiàn)在是vivo的運維總監(jiān)，負責vivo互聯(lián)網(wǎng)業(yè)務的運營和維護工作。這位曾經(jīng)在百度和騰訊工作過的人，擁有客戶端、國際化和大數(shù)據(jù)算法等離線業(yè)務運維方面的經(jīng)驗。加入vivo后，我主導了業(yè)務高可用性的建設，將業(yè)務的可用性提升至99.99%的水平。
