業務指數級成長，可用性建置也可以如此穩定？

一、问题与挑战

自2017年起，vivo的机器规模和服务数量都有显著增长，这可以从图表中看出。机器规模大约增长了五倍左右，服务数量也基本上增长了十几倍，其时间跨度为从2017年至2022年。

在规模增长的情况下，挑战和复杂度肯定随之上升，在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%的水平。

以上是業務指數級成長，可用性建置也可以如此穩定？的詳細內容。更多資訊請關注PHP中文網其他相關文章！