面向大規(guī)模服務(wù)器的自動(dòng)化安全運(yùn)維方法

王一達(dá)

(1.北京大學(xué) 計(jì)算機(jī)學(xué)院，北京 100091；2.阿里巴巴集團(tuán) 云智能基礎(chǔ)產(chǎn)品事業(yè)部，北京 100102)

0 引 言

阿里巴巴公司當(dāng)前的物理服務(wù)器的數(shù)量已經(jīng)超過百萬臺(tái)，并且還在持續(xù)增長。為了實(shí)現(xiàn)應(yīng)用功能的迭代更新或保障運(yùn)行環(huán)境的穩(wěn)定性，生產(chǎn)環(huán)境下會(huì)頻繁地發(fā)起各種運(yùn)維操作，它們的執(zhí)行可能導(dǎo)致服務(wù)器上的進(jìn)程和數(shù)據(jù)在一段時(shí)間內(nèi)不可用，或者造成應(yīng)用程序性能的下降。如何在運(yùn)維過程中保障服務(wù)的可靠性和穩(wěn)定性至關(guān)重要。

阿里巴巴復(fù)雜的系統(tǒng)環(huán)境給運(yùn)維工作帶來了巨大的挑戰(zhàn)。目前僅運(yùn)行在物理服務(wù)器上的應(yīng)用程序就有數(shù)百種，它們的可用性設(shè)計(jì)和性能要求各不相同。各類應(yīng)用程序通常以混部的方式運(yùn)行在服務(wù)器上，進(jìn)一步增加了運(yùn)行環(huán)境的復(fù)雜性。為了保證業(yè)務(wù)的穩(wěn)定性，運(yùn)維操作給應(yīng)用程序帶來的影響需要被謹(jǐn)慎評(píng)估并據(jù)此制定相應(yīng)的運(yùn)維策略。而運(yùn)行環(huán)境的復(fù)雜性和運(yùn)維操作的多樣性大大提高了這種評(píng)估的難度。當(dāng)前針對(duì)物理機(jī)及運(yùn)行于其上的應(yīng)用程序的運(yùn)維任務(wù)平均每天達(dá)到數(shù)千次，如此大規(guī)模、高頻率的復(fù)雜運(yùn)維場景需要高度自動(dòng)化的運(yùn)維體系來進(jìn)行支撐。

為了解決上述問題，本研究提出了一套用于運(yùn)維平臺(tái)和應(yīng)用程序之間交互的協(xié)議——Decider協(xié)議。借助該協(xié)議，任何運(yùn)維操作所產(chǎn)生的影響都能夠被定義成標(biāo)準(zhǔn)格式，并傳遞給應(yīng)用程序。應(yīng)用程序能夠根據(jù)影響值以及自身的運(yùn)行狀態(tài)對(duì)運(yùn)維操作的執(zhí)行進(jìn)行決策和處理。Decider協(xié)議不僅保障了運(yùn)維執(zhí)行過程中應(yīng)用的穩(wěn)定性，同時(shí)也顯著提高了運(yùn)維的自動(dòng)化程度。基于Decider協(xié)議設(shè)計(jì)并實(shí)現(xiàn)的Tianji系統(tǒng)提供了自動(dòng)化、安全可靠的運(yùn)維能力。任何類型的運(yùn)維操作只要遵循協(xié)議的規(guī)范就能夠方便地接入Tianji系統(tǒng)，使得運(yùn)維平臺(tái)具有良好的擴(kuò)展性。本文將詳細(xì)介紹Decider協(xié)議的設(shè)計(jì)原則以及Tianji系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)方案。

1 背景與挑戰(zhàn)

1.1 應(yīng)用的多樣性

阿里巴巴的服務(wù)器上部署著各種類型的應(yīng)用程序，應(yīng)用的可用性設(shè)計(jì)各不相同，對(duì)于MapReduce[1]、Fuxi[2]這類分布式批處理應(yīng)用來說，即使多個(gè)計(jì)算節(jié)點(diǎn)同時(shí)發(fā)生故障也不會(huì)影響整體計(jì)算服務(wù)的可用性。而對(duì)于一個(gè)三副本的HDFS[3]分布式文件系統(tǒng)來說，當(dāng)一個(gè)數(shù)據(jù)分片的所有副本同時(shí)出現(xiàn)故障時(shí)就會(huì)導(dǎo)致數(shù)據(jù)丟失。還有一些應(yīng)用為了保證其可用性需要在運(yùn)維操作執(zhí)行之前進(jìn)行預(yù)處理操作。除可用性外各類應(yīng)用對(duì)于性能的要求也各不相同，例如批處理應(yīng)用更關(guān)注作業(yè)的吞吐能力，而交互式應(yīng)用則更關(guān)注請(qǐng)求的響應(yīng)延遲。

應(yīng)用程序在可用性和性能方面的不同決定了運(yùn)維策略的巨大差異。而且運(yùn)維策略和應(yīng)用實(shí)時(shí)的運(yùn)行狀態(tài)、系統(tǒng)環(huán)境緊密聯(lián)系，大大提高了運(yùn)維策略的復(fù)雜度。

1.2 應(yīng)用的混部

為了提高硬件資源的利用率或者為了不同模塊的協(xié)同工作，應(yīng)用程序通常以混部的方式運(yùn)行在服務(wù)器上。同一個(gè)服務(wù)器上運(yùn)行著不同類型、不同業(yè)務(wù)，甚至來自不同公司的應(yīng)用程序?；觳康慕Y(jié)果是機(jī)器級(jí)別的運(yùn)維操作可能會(huì)影響多個(gè)不同的應(yīng)用。為了確認(rèn)運(yùn)維操作對(duì)于不同應(yīng)用程序造成的影響效果，不僅需要了解不同應(yīng)用的可用性策略、部署架構(gòu)等設(shè)計(jì)方案，同時(shí)還要參考服務(wù)器上每個(gè)應(yīng)用當(dāng)前的實(shí)時(shí)負(fù)載情況，導(dǎo)致整個(gè)運(yùn)維系統(tǒng)的自動(dòng)化程度受到限制。

1.3 運(yùn)維操作的多樣性

從執(zhí)行對(duì)象來看，運(yùn)維操作可以分為機(jī)器級(jí)別和應(yīng)用級(jí)別兩類。機(jī)器級(jí)別的操作會(huì)影響機(jī)器上所有正在運(yùn)行的應(yīng)用。應(yīng)用級(jí)別的操作一般只會(huì)影響單一應(yīng)用。

從運(yùn)維操作產(chǎn)生的影響來看，有些操作會(huì)影響應(yīng)用進(jìn)程或者數(shù)據(jù)的可用性。比如機(jī)器重啟、磁盤格式化。有些則不會(huì)產(chǎn)生任何影響，可以在應(yīng)用不感知的情況下執(zhí)行。

運(yùn)維操作對(duì)應(yīng)用產(chǎn)生的影響還和機(jī)器當(dāng)前的系統(tǒng)環(huán)境有關(guān)。例如在系統(tǒng)環(huán)境的變更中，執(zhí)行程序會(huì)根據(jù)機(jī)器當(dāng)前系統(tǒng)環(huán)境決定變更的具體流程，因而同一個(gè)運(yùn)維操作對(duì)不同機(jī)器產(chǎn)生的影響也存在差異。運(yùn)維操作在影響范圍和影響程度上的差異性大大提高了操作影響的評(píng)估難度。

1.4 運(yùn)維場景復(fù)雜

當(dāng)前阿里巴巴的物理機(jī)服務(wù)器的數(shù)量已經(jīng)達(dá)到百萬級(jí)，僅直接部署在物理機(jī)上的應(yīng)用程序就已經(jīng)達(dá)到上千種，平均每天發(fā)起數(shù)千次運(yùn)維任務(wù)，單次運(yùn)維任務(wù)的機(jī)器規(guī)模最高超過700 000臺(tái)。不同運(yùn)維任務(wù)的操作目標(biāo)可能存在交集，當(dāng)它們并發(fā)執(zhí)行的時(shí)候，運(yùn)維團(tuán)隊(duì)需要解決多個(gè)運(yùn)維流程之間的相互協(xié)調(diào)和沖突處理問題，嚴(yán)重影響了運(yùn)維的自動(dòng)化程度。

2 相關(guān)研究

為了保障應(yīng)用的高可用，藍(lán)綠發(fā)布(Blue/Green)、滾動(dòng)升級(jí)(Rolling Upgrade)、金絲雀發(fā)布(Canary)等部署升級(jí)策略被廣泛應(yīng)用在各類數(shù)據(jù)中心或者云計(jì)算環(huán)境下[4-6]。這些部署升級(jí)策略與Ansible[7]、SaltStack[8]、Puppet[9]、Chef[10]等自動(dòng)化運(yùn)維工具相結(jié)合，能夠?qū)崿F(xiàn)幾十至幾千節(jié)點(diǎn)規(guī)模下的自動(dòng)化配置管理、命令下發(fā)以及應(yīng)用部署升級(jí)等運(yùn)維操作，并保證運(yùn)維過程中服務(wù)質(zhì)量的穩(wěn)定性。但是滾動(dòng)升級(jí)、金絲雀發(fā)布等策略只能處理單一應(yīng)用程序的運(yùn)維場景。當(dāng)多個(gè)運(yùn)維任務(wù)并發(fā)執(zhí)行時(shí)，由于執(zhí)行流程之間缺乏協(xié)調(diào)，它們的執(zhí)行策略可能會(huì)發(fā)生沖突從而導(dǎo)致故障。盡管可以對(duì)并發(fā)運(yùn)維任務(wù)進(jìn)行細(xì)粒度的編排，但是這不僅增加了運(yùn)維的工作量，同時(shí)嚴(yán)重影響了運(yùn)維過程的自動(dòng)化程度。此外，有部分應(yīng)用希望在進(jìn)程被終止之前主動(dòng)執(zhí)行一些預(yù)處理來保障自身業(yè)務(wù)的穩(wěn)定。然而在上述運(yùn)維系統(tǒng)或工具中，應(yīng)用程序都只能被動(dòng)接受運(yùn)維操作所帶來的影響，這類應(yīng)用的需求無法得到滿足。

另外一個(gè)相關(guān)的研究領(lǐng)域是容器化技術(shù)及其相關(guān)的運(yùn)維系統(tǒng)[11-15]。由于容器支持靈活的銷毀與創(chuàng)建，當(dāng)運(yùn)維操作或者硬件異常導(dǎo)致單個(gè)應(yīng)用實(shí)例出現(xiàn)故障時(shí)，可以通過快速創(chuàng)建新的容器實(shí)例來保證服務(wù)質(zhì)量不受影響。這種機(jī)制同樣可以被用來支持應(yīng)用的版本或系統(tǒng)環(huán)境的升級(jí)。在Borg[13]、Kubernetes[14]、Docker Swarm[15]等容器編排系統(tǒng)中都支持應(yīng)用的滾動(dòng)升級(jí)等運(yùn)維策略。但是這種方式更加適合無狀態(tài)的應(yīng)用程序的升級(jí)，對(duì)于分布式存儲(chǔ)這類有狀態(tài)應(yīng)用程序的升級(jí)缺乏有效支持。

3 設(shè)計(jì)與實(shí)現(xiàn)方案

在阿里巴巴的運(yùn)維場景下，運(yùn)維操作的執(zhí)行和應(yīng)用程序之間是多對(duì)多的關(guān)系，即運(yùn)維操作的執(zhí)行可能影響多個(gè)應(yīng)用程序，同時(shí)應(yīng)用程序的可用性可能受到多個(gè)并發(fā)執(zhí)行的運(yùn)維任務(wù)的影響。單一的、靜態(tài)的運(yùn)維策略無法滿足這樣復(fù)雜的運(yùn)維場景。為了解決上述挑戰(zhàn)，應(yīng)用程序需要參與到運(yùn)維策略的決策中，而不只是被動(dòng)地接受運(yùn)維操作所帶來的影響。

應(yīng)用程序的運(yùn)維策略和它的設(shè)計(jì)方案和運(yùn)行狀態(tài)是緊密相關(guān)的。應(yīng)用的運(yùn)行狀態(tài)和負(fù)載情況是動(dòng)態(tài)變化的，應(yīng)用程序能夠通過進(jìn)程間的通信、元數(shù)據(jù)記錄以及各種監(jiān)控系統(tǒng)的協(xié)助，對(duì)于自身的運(yùn)行狀態(tài)有著更加準(zhǔn)確的了解。因此當(dāng)一個(gè)運(yùn)維操作導(dǎo)致進(jìn)程終止或者數(shù)據(jù)丟失時(shí)，應(yīng)用程序有能力判斷這些行為會(huì)對(duì)它自身的可用性或者性能造成怎樣的影響，并決定是否應(yīng)該允許運(yùn)維操作的執(zhí)行。當(dāng)環(huán)境中所有應(yīng)用都能夠在保障自身穩(wěn)定性的前提下分別對(duì)運(yùn)維操作進(jìn)行決策時(shí)，運(yùn)維的安全性就可以得到保障，自動(dòng)化程度也能夠顯著提高。

為了實(shí)現(xiàn)上述目標(biāo)，本研究提出了一套運(yùn)維平臺(tái)和各類應(yīng)用程序之間進(jìn)行交互的Decider協(xié)議。借助Decider協(xié)議，運(yùn)維操作所帶來的影響能夠被定義并傳遞給應(yīng)用程序，應(yīng)用程序能夠根據(jù)這些影響判斷是否允許一個(gè)運(yùn)維操作的執(zhí)行，或者在執(zhí)行之前完成預(yù)處理，從而保障自身業(yè)務(wù)的穩(wěn)定性。

本節(jié)剩余部分首先介紹基于Decider協(xié)議所實(shí)現(xiàn)的Tianji系統(tǒng)中運(yùn)維操作的執(zhí)行流程以及支撐該執(zhí)行流程的系統(tǒng)架構(gòu)設(shè)計(jì)，隨后將詳細(xì)介紹Decider協(xié)議的設(shè)計(jì)方案。

3.1 執(zhí)行流程

圖1展示了Tianji系統(tǒng)中一個(gè)運(yùn)維操作的執(zhí)行流程。當(dāng)機(jī)器/應(yīng)用實(shí)例成為運(yùn)維操作的目標(biāo)時(shí)，Tianji系統(tǒng)會(huì)為其設(shè)置操作類型(action)并記錄action的執(zhí)行狀態(tài)。圖1的下半部分展示了執(zhí)行過程中action的狀態(tài)轉(zhuǎn)換邏輯。執(zhí)行流程包含以下步驟：

圖1 運(yùn)維操作執(zhí)行流程及action狀態(tài)轉(zhuǎn)換邏輯

(1)發(fā)起階段。在這一階段，目標(biāo)機(jī)器或者應(yīng)用被設(shè)置相應(yīng)的action，并且將action狀態(tài)設(shè)置為pending，表示當(dāng)前該操作處在阻塞狀態(tài)，不允許執(zhí)行。

(2)影響傳遞階段。在這一階段，運(yùn)維操作產(chǎn)生的影響會(huì)被Tianji平臺(tái)傳遞給被影響的應(yīng)用程序。當(dāng)執(zhí)行機(jī)器級(jí)別的運(yùn)維操作時(shí)(如機(jī)器重啟)，操作對(duì)機(jī)器所產(chǎn)生的影響會(huì)被傳遞給該機(jī)器上部署的所有應(yīng)用程序。

(3)審批階段。應(yīng)用程序接收到運(yùn)維操作的影響后，根據(jù)當(dāng)前應(yīng)用的運(yùn)行狀態(tài)以及影響的大小對(duì)操作進(jìn)行審批，決定是否允許其執(zhí)行。如果審批通過允許執(zhí)行，應(yīng)用的action狀態(tài)被設(shè)置為approved。對(duì)于機(jī)器級(jí)別的操作，只有當(dāng)機(jī)器上部署的所有應(yīng)用都審批通過之后才會(huì)將機(jī)器的action狀態(tài)設(shè)置為approved，允許操作執(zhí)行。

(4)執(zhí)行階段。每一種action都有其對(duì)應(yīng)的執(zhí)行模塊。在這一階段，執(zhí)行模塊在檢查到action狀態(tài)轉(zhuǎn)換為approved后將其狀態(tài)修改為doing，并開始運(yùn)維操作的執(zhí)行。

(5)結(jié)束階段。執(zhí)行模塊在執(zhí)行完成后，根據(jù)執(zhí)行結(jié)果將action狀態(tài)設(shè)置為done或者failed，整個(gè)執(zhí)行流程結(jié)束。

3.2 系統(tǒng)架構(gòu)

為了實(shí)現(xiàn)上述執(zhí)行流程，Tianji系統(tǒng)中相關(guān)模塊的架構(gòu)組織如圖2所示。根據(jù)角色的不同可以將這些模塊分為4類：元數(shù)據(jù)管理模塊、操作發(fā)起模塊、操作執(zhí)行模塊以及影響傳遞模塊。

圖2 Tianji系統(tǒng)中相關(guān)模塊架構(gòu)設(shè)計(jì)

元數(shù)據(jù)管理模塊Master是系統(tǒng)的核心部分。它是一個(gè)部署在3～5臺(tái)機(jī)器上的高可用key-value存儲(chǔ)系統(tǒng)，使用raft協(xié)議[16]保證數(shù)據(jù)的強(qiáng)一致性。Master存儲(chǔ)了Tianji系統(tǒng)管理的所有機(jī)器以及應(yīng)用的元數(shù)據(jù)信息，包括機(jī)器或應(yīng)用當(dāng)前正在執(zhí)行的action名稱、action狀態(tài)以及action產(chǎn)生的影響等。Master提供了豐富的API以方便其它各模塊進(jìn)行數(shù)據(jù)訪問。操作發(fā)起模塊、操作執(zhí)行模塊以及影響傳遞模塊通過讀寫Master中的元數(shù)據(jù)實(shí)現(xiàn)信息的交互以及整個(gè)執(zhí)行流程的控制。

操作發(fā)起模塊負(fù)責(zé)根據(jù)用戶的請(qǐng)求，按照預(yù)先定義好的執(zhí)行策略在目標(biāo)機(jī)器或者應(yīng)用實(shí)例上發(fā)起運(yùn)維操作。操作發(fā)起的方式有多種，包括但不限于以下幾類：

(1)用戶可以通過UI或者API對(duì)單個(gè)機(jī)器發(fā)起操作。

(2)應(yīng)用升級(jí)模塊會(huì)根據(jù)用戶提交的最新版本對(duì)應(yīng)用實(shí)例發(fā)起升級(jí)操作。升級(jí)模塊同時(shí)還會(huì)根據(jù)用戶定義的升級(jí)策略對(duì)升級(jí)流程進(jìn)行編排，例如在滾動(dòng)升級(jí)策略下，應(yīng)用程序?qū)嵗龝?huì)被劃分成多個(gè)批次，分批執(zhí)行升級(jí)操作。

(3)自動(dòng)化運(yùn)維模塊會(huì)根據(jù)機(jī)器、應(yīng)用的實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)以及預(yù)先定義的觸發(fā)規(guī)則自動(dòng)觸發(fā)運(yùn)維操作。例如當(dāng)監(jiān)控發(fā)現(xiàn)磁盤損壞時(shí)自動(dòng)觸發(fā)磁盤替換操作。

每一種運(yùn)維操作都有其對(duì)應(yīng)的執(zhí)行模塊，例如，每個(gè)機(jī)器上都運(yùn)行著應(yīng)用進(jìn)程管控模塊，負(fù)責(zé)啟動(dòng)應(yīng)用進(jìn)程以及應(yīng)用版本的更新；機(jī)器上還運(yùn)行著系統(tǒng)環(huán)境管理模塊，負(fù)責(zé)對(duì)機(jī)器上的系統(tǒng)環(huán)境進(jìn)行變更。這些執(zhí)行模塊會(huì)周期性地訪問Master以獲取機(jī)器或應(yīng)用當(dāng)前的action以及執(zhí)行狀態(tài)，當(dāng)發(fā)現(xiàn)機(jī)器或應(yīng)用的action狀態(tài)已經(jīng)達(dá)到approved時(shí)，執(zhí)行模塊會(huì)開始在目標(biāo)機(jī)器上執(zhí)行運(yùn)維操作。執(zhí)行完成之后，執(zhí)行模塊會(huì)將執(zhí)行結(jié)果匯報(bào)到Master。

影響傳遞模塊ActionManager會(huì)周期性地訪問Master模塊，掃描所有機(jī)器當(dāng)前的action。當(dāng)有機(jī)器級(jí)別的action被觸發(fā)時(shí)，ActionManager負(fù)責(zé)將action的影響傳遞到機(jī)器上部署的各個(gè)應(yīng)用實(shí)例上，并且在所有的應(yīng)用實(shí)例審批通過之后將機(jī)器上的action狀態(tài)轉(zhuǎn)換為approved。

除了上述Tianji系統(tǒng)內(nèi)部模塊之外，每種應(yīng)用程序需要實(shí)現(xiàn)他們自己的影響審批模塊——Decider程序。應(yīng)用的Decider程序需要周期性地訪問Master以獲取當(dāng)前是否有應(yīng)用實(shí)例被觸發(fā)action。當(dāng)發(fā)現(xiàn)應(yīng)用實(shí)例有action時(shí)，Decider程序從Master獲取到當(dāng)前action對(duì)其進(jìn)程或數(shù)據(jù)產(chǎn)生的影響，然后結(jié)合當(dāng)前應(yīng)用的運(yùn)行狀態(tài)決定是否允許當(dāng)前action的執(zhí)行。

3.3 Decider協(xié)議

上述運(yùn)維執(zhí)行流程之所以能夠有效保障服務(wù)的穩(wěn)定性，依賴的是運(yùn)維操作所產(chǎn)生的影響能夠被準(zhǔn)確定義后傳遞給應(yīng)用程序，并且被應(yīng)用程序正確地響應(yīng)和處理。為了實(shí)現(xiàn)這些能力，Tianji系統(tǒng)提供了Decider協(xié)議作為運(yùn)維平臺(tái)和應(yīng)用程序之間的交互協(xié)議。Decider協(xié)議的實(shí)現(xiàn)分為影響定義和影響處理兩部分。本節(jié)和下一節(jié)將分別介紹這兩部分的實(shí)現(xiàn)邏輯。

圖3展示了一個(gè)Decider協(xié)議的影響定義實(shí)例。運(yùn)維操作的影響被分為兩部分：服務(wù)進(jìn)程影響(Simpact)和數(shù)據(jù)影響(Dimpact)。

圖3 運(yùn)維操作影響實(shí)例

Simpact的含義是運(yùn)維操作執(zhí)行的過程中應(yīng)用進(jìn)程終止的持續(xù)時(shí)間。例如，應(yīng)用的升級(jí)過程中需要終止舊版本應(yīng)用進(jìn)程，然后拉起新版本。在應(yīng)用和機(jī)器本身沒有異常的情況下，Tianji運(yùn)維平臺(tái)承諾可以在120 s內(nèi)拉起應(yīng)用進(jìn)程，因此應(yīng)用升級(jí)的Simpact一般被設(shè)置為120。如果Simpact為0則表示運(yùn)維操作對(duì)進(jìn)程無影響，執(zhí)行過程中進(jìn)程不會(huì)被終止。

Dimpact的格式是：“存儲(chǔ)設(shè)備|持續(xù)時(shí)間”，其含義是運(yùn)維操作執(zhí)行過程中該存儲(chǔ)設(shè)備上的數(shù)據(jù)不可用狀態(tài)的持續(xù)時(shí)間。例如，一個(gè)針對(duì)sdb設(shè)備的磁盤固件升級(jí)的操作可能會(huì)導(dǎo)致磁盤性能的抖動(dòng)或者短暫的數(shù)據(jù)不可讀寫，這種情況下可以根據(jù)硬件團(tuán)隊(duì)的經(jīng)驗(yàn)和建議將Dimpact設(shè)置為“sdb|120”，表示該磁盤上的數(shù)據(jù)會(huì)在120 s內(nèi)短暫不可用。在執(zhí)行磁盤替換或者格式化這類導(dǎo)致數(shù)據(jù)永久性丟失的運(yùn)維操作時(shí)，Dimpact的影響時(shí)間可以設(shè)置為forever。

大部分運(yùn)維操作的影響值是固定的，它們的取值通常來自于開發(fā)和運(yùn)維團(tuán)隊(duì)的經(jīng)驗(yàn)。例如，應(yīng)用進(jìn)程的終止、重新拉起一般在120 s以內(nèi)完成，機(jī)器的重啟通常在20 min內(nèi)完成，安裝操作系統(tǒng)并格式化數(shù)據(jù)盤通常在3 h內(nèi)完成。操作執(zhí)行模塊的開發(fā)人員根據(jù)經(jīng)驗(yàn)數(shù)值來設(shè)置運(yùn)維操作的影響值，通常會(huì)取經(jīng)驗(yàn)值的上限，以避免影響被低估而造成意外的故障。

也有一些運(yùn)維操作的影響值是動(dòng)態(tài)變化的，例如系統(tǒng)環(huán)境變更操作。系統(tǒng)環(huán)境變更操作支持對(duì)服務(wù)器上的系統(tǒng)環(huán)境進(jìn)行熱升級(jí)，例如內(nèi)核模塊的升級(jí)安裝、內(nèi)核參數(shù)調(diào)整、系統(tǒng)bug修復(fù)等。一次系統(tǒng)環(huán)境變更造成的影響不僅取決于變更內(nèi)容本身，同時(shí)還取決于目標(biāo)機(jī)器上當(dāng)前的系統(tǒng)環(huán)境。因此這類運(yùn)維操作的影響無法預(yù)先定義，而是需要在影響傳遞階段之前額外增加一個(gè)“影響計(jì)算階段”。在影響計(jì)算階段，運(yùn)維系統(tǒng)會(huì)在目標(biāo)機(jī)器上執(zhí)行一次“預(yù)檢查”，計(jì)算出操作即將產(chǎn)生的影響值。計(jì)算結(jié)果被匯報(bào)到Master后再傳遞給應(yīng)用程序進(jìn)行審批。

3.4 影響處理

影響處理程序又稱為Decider程序，由每個(gè)應(yīng)用程序的開發(fā)人員負(fù)責(zé)開發(fā)和維護(hù)，通常作為應(yīng)用的一部分和應(yīng)用一起部署，負(fù)責(zé)對(duì)當(dāng)前正在執(zhí)行的運(yùn)維操作進(jìn)行審批。Decider程序需要周期性地訪問Master來獲取應(yīng)用程序當(dāng)前是否被觸發(fā)了某種action以及該action對(duì)應(yīng)用程序產(chǎn)生的影響。之后Decider程序根據(jù)操作的影響以及應(yīng)用程序當(dāng)前的運(yùn)行狀態(tài)決定是否允許當(dāng)前運(yùn)維操作的執(zhí)行：

(1)如果當(dāng)前運(yùn)維操作不會(huì)影響應(yīng)用程序的功能或性能，則審批通過允許操作的執(zhí)行。例如MapReduce[1]這類分布式批處理系統(tǒng)在執(zhí)行滾動(dòng)升級(jí)的過程中，只要計(jì)算節(jié)點(diǎn)的存活率高于預(yù)先定義好的存活率閾值就可以允許計(jì)算節(jié)點(diǎn)的升級(jí)而不會(huì)影響整體系統(tǒng)的服務(wù)質(zhì)量。

(2)如果當(dāng)前運(yùn)維操作會(huì)導(dǎo)致應(yīng)用功能受到影響，或者嚴(yán)重影響應(yīng)用的性能，則需要阻塞該操作在當(dāng)前節(jié)點(diǎn)的執(zhí)行，直到應(yīng)用能夠接受當(dāng)前操作的影響。例如一個(gè)使用三副本存儲(chǔ)策略的HDFS分布式文件系統(tǒng)[3]，如果因?yàn)闄C(jī)器或磁盤故障原因?qū)е履硞€(gè)數(shù)據(jù)分片的兩個(gè)副本不可用，那么在第三個(gè)副本所在的機(jī)器上執(zhí)行的應(yīng)用升級(jí)或者操作系統(tǒng)升級(jí)等操作就會(huì)被阻塞，防止數(shù)據(jù)所有副本不可用造成的故障。此時(shí)應(yīng)用程序可以根據(jù)自身的設(shè)計(jì)原則選擇不同的處理策略：備份數(shù)據(jù)副本后允許操作執(zhí)行，或者等待故障機(jī)器的狀態(tài)恢復(fù)。

考慮到不是所有的應(yīng)用都需要這種細(xì)粒度的自定義影響處理邏輯，Tianji還提供了一種默認(rèn)的影響處理邏輯：Simple Decider。Simple Decider支持用戶定義應(yīng)用進(jìn)程的存活率閾值，只要運(yùn)維操作不會(huì)導(dǎo)致進(jìn)程存活率下降到閾值以下，操作就可以被審批通過開始執(zhí)行。大部分無狀態(tài)服務(wù)都可以采用這種簡單的影響處理模式來保證服務(wù)的可用性。

3.5 小 結(jié)

Decider協(xié)議為大規(guī)模服務(wù)器的復(fù)雜運(yùn)維場景提供了一種行之有效的解決方案。運(yùn)維操作影響的數(shù)字化使得整個(gè)運(yùn)維流程的自動(dòng)化成為可能。應(yīng)用有能力對(duì)來自不同運(yùn)維團(tuán)隊(duì)的運(yùn)維操作的執(zhí)行進(jìn)行決策，從而保障自身服務(wù)的穩(wěn)定性。這種決策能夠自動(dòng)適應(yīng)應(yīng)用各種運(yùn)行狀態(tài)，有效屏蔽了系統(tǒng)環(huán)境和應(yīng)用狀態(tài)的復(fù)雜性。而且這種決策能力可以被開發(fā)人員沉淀到代碼中，隨著應(yīng)用設(shè)計(jì)方案的變化而持續(xù)演進(jìn)，實(shí)現(xiàn)了運(yùn)維策略的可編程、可迭代以及運(yùn)維過程的自動(dòng)化。

Decider協(xié)議的存在使得運(yùn)維操作產(chǎn)生的“預(yù)期內(nèi)影響”得到了有效的響應(yīng)和處理。除“預(yù)期內(nèi)影響”之外，還有一些“預(yù)期外異?！蓖瑯訒?huì)影響應(yīng)用的可用性。例如新的應(yīng)用版本存在缺陷，導(dǎo)致應(yīng)用升級(jí)后服務(wù)不可用；或者各種硬件故障導(dǎo)致的機(jī)器宕機(jī)、網(wǎng)絡(luò)斷連等問題。對(duì)于這類“預(yù)期外異?！?，Tianji系統(tǒng)能夠通過對(duì)機(jī)器、應(yīng)用的監(jiān)控以及異常捕獲后的即時(shí)響應(yīng)將異常的影響控制在合理的范圍內(nèi)，防止異常的擴(kuò)散。這些“預(yù)期外異?！钡奶幚頇C(jī)制不是本文的研究重點(diǎn)，這里不再贅述。Decider協(xié)議作為Tianji運(yùn)維體系重要的組成部分，與“預(yù)期外異常”的處理機(jī)制共同保障了運(yùn)維過程中各類服務(wù)質(zhì)量的穩(wěn)定性。任何運(yùn)維操作只要根據(jù)Decider協(xié)議進(jìn)行改造，都能夠非常方便地接入到Tianji系統(tǒng)，使得Tianji運(yùn)維平臺(tái)具有良好的擴(kuò)展性。

4 實(shí)驗(yàn)結(jié)果與分析

4.1 實(shí)驗(yàn)環(huán)境

為了驗(yàn)證Decider協(xié)議的有效性，實(shí)現(xiàn)了運(yùn)維系統(tǒng)模擬器tianji_simulator。該模擬器具有以下能力：

模擬Tianji系統(tǒng)中各模塊的工作方式，包括原數(shù)據(jù)存儲(chǔ)、影響傳遞、運(yùn)維操作執(zhí)行等。

模擬運(yùn)維任務(wù)的生成和運(yùn)維流程的編排，支持常用的滾動(dòng)升級(jí)、滑動(dòng)窗口等運(yùn)維策略。

模擬分布式存儲(chǔ)、分布式計(jì)算等常見應(yīng)用的負(fù)載以及應(yīng)用的Decider程序邏輯。

本節(jié)各實(shí)驗(yàn)中所有運(yùn)維任務(wù)的生成以及執(zhí)行均由tianji_simulator在一臺(tái)高性能服務(wù)器上完成，實(shí)驗(yàn)環(huán)境見表1。

表1 模擬實(shí)驗(yàn)使用的服務(wù)器配置

4.2 分布式存儲(chǔ)應(yīng)用升級(jí)

4.2.1 實(shí)驗(yàn)背景

Pangu系統(tǒng)是基于HDFS[3]架構(gòu)實(shí)現(xiàn)的阿里巴巴內(nèi)部自研的分布式文件系統(tǒng)。為了保障數(shù)據(jù)的可用性，Pangu中存儲(chǔ)的文件被劃分為固定大小的數(shù)據(jù)分片，每個(gè)數(shù)據(jù)分片被復(fù)制成多個(gè)副本(一般為3個(gè))，分散保存在不同存儲(chǔ)節(jié)點(diǎn)的本地磁盤中。Pangu服務(wù)不僅是阿里多個(gè)存儲(chǔ)類云產(chǎn)品(如云盤、對(duì)象存儲(chǔ)、日志存儲(chǔ)等)的底層存儲(chǔ)服務(wù)，同時(shí)也為很多內(nèi)部應(yīng)用提供數(shù)據(jù)存儲(chǔ)服務(wù)，因而廣泛部署在各個(gè)業(yè)務(wù)線的服務(wù)器上。

應(yīng)用升級(jí)是Pangu系統(tǒng)日常運(yùn)維中使用頻率最高的運(yùn)維操作?？紤]到當(dāng)前Pangu存儲(chǔ)集群的機(jī)器數(shù)量可以達(dá)到數(shù)千甚至上萬節(jié)點(diǎn)，在升級(jí)過程中不僅需要保障升級(jí)的效率，同時(shí)還要能夠應(yīng)對(duì)升級(jí)過程中隨機(jī)發(fā)生的各類異常。

在接入Decider協(xié)議之前，Pangu通常采用滾動(dòng)升級(jí)策略。為了避免三副本同時(shí)不可用，每個(gè)批次只允許升級(jí)一臺(tái)存儲(chǔ)節(jié)點(diǎn)，嚴(yán)重影響了升級(jí)的效率。在大規(guī)模服務(wù)器環(huán)境下，機(jī)器或者應(yīng)用的異常十分常見，運(yùn)維團(tuán)隊(duì)需要在升級(jí)執(zhí)行過程中隨時(shí)關(guān)注異常情況并及時(shí)暫?；蛘{(diào)整升級(jí)任務(wù)，整個(gè)過程耗時(shí)耗力。在應(yīng)用迭代速度不斷加速的今天，這樣的升級(jí)運(yùn)維效率顯然無法滿足開發(fā)和運(yùn)維團(tuán)隊(duì)的需求。

4.2.2 實(shí)驗(yàn)設(shè)計(jì)與結(jié)果

本節(jié)實(shí)驗(yàn)?zāi)繕?biāo)是驗(yàn)證Decider協(xié)議對(duì)于Pangu服務(wù)升級(jí)過程的運(yùn)維效率以及服務(wù)穩(wěn)定性的影響。

實(shí)驗(yàn)1：運(yùn)維效率

驗(yàn)證Decider協(xié)議對(duì)Pangu應(yīng)用升級(jí)效率的影響。實(shí)驗(yàn)使用10 000節(jié)點(diǎn)的Pangu存儲(chǔ)集群，分別測試兩種運(yùn)維策略下應(yīng)用的升級(jí)效率：

策略1：不使用Decider協(xié)議，滾動(dòng)升級(jí)策略，每個(gè)批次升級(jí)一臺(tái)機(jī)器。

策略2：使用Tianji系統(tǒng)執(zhí)行，使用Pangu自定義Decider，滾動(dòng)升級(jí)策略，每個(gè)批次升級(jí)的機(jī)器數(shù)量為10，20，30，40，50遞增。

實(shí)驗(yàn)結(jié)果如圖4所示。使用Decider協(xié)議能夠顯著提高應(yīng)用升級(jí)的效率，使得升級(jí)時(shí)間減少了89.3%～95.9%。這是因?yàn)樵谑褂肈ecider協(xié)議后，Pangu應(yīng)用的Decider程序能夠獲取到各個(gè)節(jié)點(diǎn)的數(shù)據(jù)分布情況，因而能夠在不引起數(shù)據(jù)丟失的情況下同時(shí)審批多臺(tái)機(jī)器，允許它們并發(fā)執(zhí)行升級(jí)，大幅提升升級(jí)的并發(fā)度。而使用傳統(tǒng)運(yùn)維方式時(shí)，無法判斷同時(shí)升級(jí)多臺(tái)機(jī)器是否會(huì)導(dǎo)致數(shù)據(jù)丟失，因此只能通過每批次一臺(tái)的方式進(jìn)行。

圖4 Pangu集群在不同運(yùn)維策略下的升級(jí)時(shí)間

實(shí)驗(yàn)中隨著升級(jí)批次中并發(fā)度的提高，運(yùn)維效率的提升并不是線性的，這是因?yàn)楫?dāng)單個(gè)批次的機(jī)器數(shù)量較大時(shí)，無法同時(shí)升級(jí)批次內(nèi)所有的機(jī)器。因此在同一個(gè)批次內(nèi)Decider程序的審批是分批進(jìn)行的：先審批通過一部分機(jī)器并執(zhí)行升級(jí)，每當(dāng)有機(jī)器完成升級(jí)恢復(fù)運(yùn)行后，Decider程序都會(huì)檢查是否有新的機(jī)器允許升級(jí)，并且審批通過。

實(shí)驗(yàn)2：數(shù)據(jù)可用性

實(shí)驗(yàn)驗(yàn)證應(yīng)用升級(jí)過程中Decider協(xié)議對(duì)于Pangu系統(tǒng)穩(wěn)定性的保障。在實(shí)際的生產(chǎn)環(huán)境中會(huì)因?yàn)楦鞣N原因?qū)е履硞€(gè)節(jié)點(diǎn)上的進(jìn)程或者數(shù)據(jù)不可用，例如隨機(jī)產(chǎn)生的機(jī)器宕機(jī)。當(dāng)這類異常發(fā)生時(shí)，運(yùn)維團(tuán)隊(duì)需要保證運(yùn)維操作的執(zhí)行不會(huì)導(dǎo)致數(shù)據(jù)塊丟失。

本實(shí)驗(yàn)使用10 000節(jié)點(diǎn)的Pangu存儲(chǔ)集群，存儲(chǔ)了1 000 000個(gè)數(shù)據(jù)塊。分別測試兩種運(yùn)維策略下Pangu應(yīng)用升級(jí)過程中的數(shù)據(jù)可用性：

策略1：不使用Decider協(xié)議，使用滾動(dòng)升級(jí)策略，每個(gè)批次升級(jí)一臺(tái)機(jī)器。

策略2：使用Tianji系統(tǒng)執(zhí)行，使用Pangu自定義Decider程序，滾動(dòng)升級(jí)策略，每個(gè)批次升級(jí)的機(jī)器數(shù)量為10個(gè)。

升級(jí)過程中會(huì)隨機(jī)地選取部分機(jī)器使其宕機(jī)，宕機(jī)比例為0.02%～0.1%遞增。宕機(jī)本身不會(huì)造成數(shù)據(jù)丟失，但是會(huì)導(dǎo)致部分?jǐn)?shù)據(jù)塊的副本數(shù)量減少。實(shí)驗(yàn)中對(duì)每一種升級(jí)策略和宕機(jī)率的組合會(huì)執(zhí)行100次升級(jí)任務(wù)，并統(tǒng)計(jì)其中發(fā)生數(shù)據(jù)丟失故障的任務(wù)比例。實(shí)驗(yàn)結(jié)果見表2。

表2 不同宕機(jī)率下不同運(yùn)維策略的故障率

實(shí)驗(yàn)結(jié)果顯示在使用策略1時(shí)，應(yīng)用升級(jí)任務(wù)的執(zhí)行有一定幾率導(dǎo)致數(shù)據(jù)丟失故障，而且隨著宕機(jī)比例的提高，升級(jí)導(dǎo)致的故障概率隨之提高。這是因?yàn)樵诓皇褂肈ecider協(xié)議的情況下，運(yùn)維操作的執(zhí)行只能按照預(yù)先編排好的發(fā)布計(jì)劃進(jìn)行。當(dāng)運(yùn)維過程中發(fā)生宕機(jī)時(shí)，部分?jǐn)?shù)據(jù)塊的副本數(shù)量可能下降到1。由于運(yùn)維工具/系統(tǒng)無法自動(dòng)獲取副本數(shù)量下降的風(fēng)險(xiǎn)以及剩余副本的存儲(chǔ)位置，因而繼續(xù)升級(jí)剩余機(jī)器有可能導(dǎo)致剩余數(shù)據(jù)副本丟失，并進(jìn)而影響上層業(yè)務(wù)。

在實(shí)際的生產(chǎn)環(huán)境下，為了避免上述故障的發(fā)生，運(yùn)維團(tuán)隊(duì)通常有兩種選擇：

一是在運(yùn)維工具中調(diào)用各類應(yīng)用程序提供的接口獲取應(yīng)用的運(yùn)行狀態(tài)，并根據(jù)應(yīng)用運(yùn)行狀態(tài)控制運(yùn)維任務(wù)的執(zhí)行，從而實(shí)現(xiàn)運(yùn)維的自動(dòng)化。然而由于各類應(yīng)用提供的接口調(diào)用方式和語義存在差異，導(dǎo)致這種方法很難方便地?cái)U(kuò)展到所有應(yīng)用。

二是在運(yùn)維執(zhí)行過程中人工觀察應(yīng)用的運(yùn)行狀態(tài)，例如節(jié)點(diǎn)的存活率、數(shù)據(jù)的分布情況等。當(dāng)異常出現(xiàn)的時(shí)候及時(shí)暫停運(yùn)維任務(wù)并調(diào)查問題。這種方式要求運(yùn)維團(tuán)隊(duì)在升級(jí)過程中24 h在線，不僅效率低下，而且也消耗了大量不必要的人力資源。

通過使用Decider協(xié)議，Pangu的Decider程序能夠隨時(shí)監(jiān)控自身服務(wù)的狀態(tài)，并且根據(jù)數(shù)據(jù)塊副本的分布情況決定是否允許特定機(jī)器上的服務(wù)升級(jí)。運(yùn)維任務(wù)能夠在異常發(fā)生時(shí)主動(dòng)暫停，避免數(shù)據(jù)丟失。實(shí)驗(yàn)中所有使用策略2的運(yùn)維任務(wù)均沒有發(fā)生數(shù)據(jù)丟失故障，而是被Decider程序阻塞在審批階段，無法繼續(xù)執(zhí)行變更。運(yùn)維人員不需要關(guān)心應(yīng)用的具體運(yùn)行狀態(tài)就能夠?qū)崿F(xiàn)應(yīng)用的自動(dòng)化安全升級(jí)。

4.3 分布式計(jì)算系統(tǒng)環(huán)境運(yùn)維

4.3.1 實(shí)驗(yàn)背景

Fuxi[2]是阿里巴巴的分布式計(jì)算框架，能夠利用機(jī)器上的CPU和GPU計(jì)算資源為機(jī)器學(xué)習(xí)、數(shù)據(jù)挖掘等業(yè)務(wù)提供海量的計(jì)算能力。為了充分發(fā)揮GPU硬件的計(jì)算能力，運(yùn)維團(tuán)隊(duì)需要定期升級(jí)機(jī)器上的GPU驅(qū)動(dòng)，升級(jí)過程需要重啟機(jī)器，因而會(huì)影響機(jī)器上運(yùn)行的Fuxi應(yīng)用進(jìn)程。

Fuxi系統(tǒng)具有比較好的容錯(cuò)能力，當(dāng)任意計(jì)算節(jié)點(diǎn)發(fā)生故障時(shí)能夠?qū)⑷蝿?wù)重新調(diào)度到其它計(jì)算節(jié)點(diǎn)。但是由于大部分計(jì)算任務(wù)的中間結(jié)果都存儲(chǔ)在內(nèi)存或者節(jié)點(diǎn)的本地存儲(chǔ)設(shè)備中，因此任務(wù)重新調(diào)度之后會(huì)丟失之前的計(jì)算進(jìn)度，需要重新開始執(zhí)行。根據(jù)統(tǒng)計(jì)，大部分Fuxi計(jì)算任務(wù)都能夠在數(shù)小時(shí)之內(nèi)完成，但是仍然會(huì)有少量的任務(wù)需要花費(fèi)接近數(shù)天時(shí)間才能夠完成，最長不超過一周。如果一個(gè)已經(jīng)執(zhí)行了數(shù)天的任務(wù)由于GPU驅(qū)動(dòng)升級(jí)導(dǎo)致重新調(diào)度，雖然不會(huì)對(duì)整個(gè)作業(yè)的計(jì)算結(jié)果造成影響，但是會(huì)延后整個(gè)作業(yè)的完成時(shí)間，影響上層業(yè)務(wù)及用戶。

在接入Decider協(xié)議之前，為了防止任務(wù)重新調(diào)度影響作業(yè)的完成進(jìn)度，運(yùn)維團(tuán)隊(duì)通常在滾動(dòng)升級(jí)的每個(gè)升級(jí)批次執(zhí)行之前將批次中的機(jī)器加入調(diào)度黑名單，保證后續(xù)不會(huì)有新的任務(wù)調(diào)度到機(jī)器上。隨后等待一周時(shí)間，確保所有機(jī)器上的任務(wù)都執(zhí)行完成后再開始執(zhí)行GPU驅(qū)動(dòng)升級(jí)。這種方式雖然能夠保障計(jì)算任務(wù)按期完成，但是會(huì)大幅增加GPU升級(jí)的完成時(shí)間。

Decider協(xié)議的存在使得對(duì)升級(jí)流程的細(xì)粒度控制成為可能。Fuxi系統(tǒng)的Decider程序會(huì)在審批階段將節(jié)點(diǎn)加入調(diào)度黑名單，然后等待節(jié)點(diǎn)上當(dāng)前任務(wù)執(zhí)行完成之后再審批通過，開始執(zhí)行GPU驅(qū)動(dòng)升級(jí)。在驅(qū)動(dòng)升級(jí)完成之后Decider程序會(huì)再將節(jié)點(diǎn)從調(diào)度黑名單中釋放出來，允許后續(xù)的計(jì)算任務(wù)調(diào)度到機(jī)器上。不僅保障了計(jì)算作業(yè)的完成進(jìn)度，同時(shí)也能夠加速GPU驅(qū)動(dòng)的升級(jí)。

4.3.2 實(shí)驗(yàn)設(shè)計(jì)與結(jié)果

實(shí)驗(yàn)驗(yàn)證Decider協(xié)議對(duì)Fuxi集群GPU驅(qū)動(dòng)升級(jí)效率的影響。實(shí)驗(yàn)使用400節(jié)點(diǎn)的Fuxi計(jì)算集群，F(xiàn)uxi任務(wù)調(diào)度器會(huì)持續(xù)地向各個(gè)計(jì)算節(jié)點(diǎn)調(diào)度計(jì)算任務(wù)。任務(wù)完成時(shí)間由調(diào)度器隨機(jī)生成。平均每個(gè)計(jì)算任務(wù)的完成時(shí)間為30 s，但是其中包含5%的大型任務(wù)，其完成時(shí)間在1500 s～1600 s之間。實(shí)驗(yàn)分別測試兩種運(yùn)維策略下GPU驅(qū)動(dòng)的升級(jí)效率：

策略1：不使用Decider協(xié)議。使用滾動(dòng)升級(jí)策略，每個(gè)批次升級(jí)20臺(tái)機(jī)器，每個(gè)批次開始之前都會(huì)將批次中所有機(jī)器加入黑名單，等待1600 s之后開始執(zhí)行升級(jí)。

策略2：使用Tianji系統(tǒng)執(zhí)行，使用Fuxi自定義Decider程序。使用滑動(dòng)窗口的運(yùn)維策略，滑動(dòng)窗口大小為20，即允許窗口內(nèi)20臺(tái)機(jī)器并發(fā)執(zhí)行升級(jí)。每當(dāng)一臺(tái)機(jī)器升級(jí)完成并離開窗口后，就將一臺(tái)新的未升級(jí)機(jī)器加入窗口。

圖5展示了兩種升級(jí)策略下GPU升級(jí)任務(wù)的完成進(jìn)度。實(shí)驗(yàn)結(jié)果顯示，使用策略2能夠?qū)PU驅(qū)動(dòng)的升級(jí)時(shí)間縮短72.9%。這是因?yàn)镈ecider協(xié)議使得滑動(dòng)窗口的升級(jí)方式成為可能，節(jié)點(diǎn)能夠在當(dāng)前任務(wù)完成之后馬上開始驅(qū)動(dòng)升級(jí)，而不需要等待同一批次中其它節(jié)點(diǎn)的任務(wù)完成。在策略1的升級(jí)過程中，由于無法根據(jù)各個(gè)節(jié)點(diǎn)上任務(wù)的執(zhí)行狀態(tài)做決策，因此無法使用滑動(dòng)窗口的升級(jí)方式，每個(gè)批次都需要同步等待所有節(jié)點(diǎn)的任務(wù)執(zhí)行完成后才能開始升級(jí)。

圖5 不同運(yùn)維策略下GPU驅(qū)動(dòng)升級(jí)時(shí)間對(duì)比

4.4 小 結(jié)

在上述兩組實(shí)驗(yàn)中，Decider協(xié)議的使用達(dá)到了提高運(yùn)維效率、保障服務(wù)穩(wěn)定性等目標(biāo)。雖然通過優(yōu)化現(xiàn)有的運(yùn)維工具同樣可以達(dá)到上述目標(biāo)，例如在運(yùn)維工具中增加獲取各類應(yīng)用程序的運(yùn)行狀態(tài)的邏輯來決定運(yùn)維任務(wù)的執(zhí)行流程。但是這要求運(yùn)維團(tuán)隊(duì)了解各種應(yīng)用程序的設(shè)計(jì)原則以及狀態(tài)獲取接口。隨著應(yīng)用數(shù)量的持續(xù)增長，這種方法難以擴(kuò)展。而Decider協(xié)議提供了一種標(biāo)準(zhǔn)化的保障機(jī)制，應(yīng)用能夠借助協(xié)議保護(hù)自身運(yùn)行的穩(wěn)定性，防止運(yùn)維操作影響應(yīng)用狀態(tài)。運(yùn)維團(tuán)隊(duì)也能夠在不需要了解各類應(yīng)用狀態(tài)的前提下實(shí)現(xiàn)安全、高效的自動(dòng)化運(yùn)維。

Tianji運(yùn)維系統(tǒng)已經(jīng)作為阿里巴巴的物理機(jī)運(yùn)維平臺(tái)服務(wù)了7年，管理了百萬級(jí)別的物理服務(wù)器以及數(shù)百種應(yīng)用程序，其中50余種應(yīng)用已經(jīng)實(shí)現(xiàn)了自定義的Decider程序。根據(jù)統(tǒng)計(jì)數(shù)據(jù)，當(dāng)前Tianji平臺(tái)上平均每天會(huì)觸發(fā)數(shù)千次運(yùn)維任務(wù)，包括應(yīng)用程序版本升級(jí)、配置變更、操作系統(tǒng)升級(jí)、系統(tǒng)環(huán)境變更等各類運(yùn)維操作。Decider協(xié)議的使用確保了這些運(yùn)維任務(wù)的安全、自動(dòng)化執(zhí)行。

5 結(jié)束語

為了應(yīng)對(duì)大規(guī)模服務(wù)器環(huán)境下應(yīng)用種類多樣、運(yùn)維場景復(fù)雜所帶來的挑戰(zhàn)，本文提出了一種自動(dòng)化安全運(yùn)維方法。該方法通過Decider協(xié)議實(shí)現(xiàn)了運(yùn)維平臺(tái)和應(yīng)用程序之間的交互，使得應(yīng)用程序能夠參與到運(yùn)維操作執(zhí)行的決策中。運(yùn)維操作所產(chǎn)生的“預(yù)期內(nèi)影響”能夠被準(zhǔn)確定義后傳遞給應(yīng)用程序，因而任何可能破壞應(yīng)用可用性的運(yùn)維操作能夠被提前攔截，業(yè)務(wù)的穩(wěn)定性得到了保障。此外，運(yùn)維操作的執(zhí)行決策被分散到各個(gè)應(yīng)用程序中，運(yùn)維的自動(dòng)化程度大幅提高。在模擬實(shí)驗(yàn)中，Decider協(xié)議顯著提高了運(yùn)維的效率，并保障了運(yùn)維過程中服務(wù)的穩(wěn)定性。基于Decider協(xié)議實(shí)現(xiàn)的Tianji系統(tǒng)已經(jīng)作為阿里巴巴的物理機(jī)運(yùn)維平臺(tái)服務(wù)了7年以上，真實(shí)生產(chǎn)環(huán)境下的使用經(jīng)驗(yàn)驗(yàn)證了Decider協(xié)議以及Tianji系統(tǒng)的有效性。