六個(gè)人如何運(yùn)維一萬臺(tái)服務(wù)器？

我是2013年加入去哪兒網(wǎng)，加入之后一直在從事運(yùn)維開發(fā)工作。去哪兒網(wǎng)運(yùn)維開發(fā)有一個(gè)特點(diǎn)，我們所有開發(fā)既當(dāng)PM，又當(dāng)QA，也沒有區(qū)分前端工作還是后端工作，用現(xiàn)在比較流行的話說，我們都是全棧工程師。加入去哪兒這幾年做的工作也是比較零碎的，哪里有需求就去哪里。

概括起來主要涉及到主機(jī)管理、應(yīng)用管理、監(jiān)控、報(bào)警平臺(tái)等設(shè)計(jì)，開發(fā)和運(yùn)維這幾方面的工作。下面簡單介紹一下我們的運(yùn)維團(tuán)隊(duì)。

• 第一個(gè)方面 ，我們的運(yùn)維團(tuán)隊(duì)負(fù)責(zé)公司所有的服務(wù)器、網(wǎng)絡(luò)等硬件平臺(tái)的運(yùn)維工作；

• 第二個(gè)方面 ，部分人員從事日常運(yùn)維，包括QVS的部署，Nginx的配置，應(yīng)用上線的支持，還有存儲(chǔ)的部署等日常的運(yùn)維工作，這些運(yùn)維工作還包括報(bào)警的告知、故障的通報(bào)和跟蹤；

• 第三個(gè)方面 ，2013年左右我們開始研發(fā)自己的運(yùn)維平臺(tái)；

• 第四個(gè)方面 ，負(fù)責(zé)公司內(nèi)網(wǎng)的應(yīng)用，這些內(nèi)網(wǎng)包括OA系統(tǒng)、HR系統(tǒng)，還有IT資產(chǎn)管理平臺(tái)等等。

我們知道一個(gè)應(yīng)用從開發(fā)到線上運(yùn)行，它的生命周期主要涉及到四個(gè)部分：

• 第一部分 ，應(yīng)用的資源管理，這些資源包括應(yīng)用部署需要的主機(jī)、應(yīng)用的圖片、文件，對(duì)象存儲(chǔ)所需要的存儲(chǔ)資源，應(yīng)用通信和其他的網(wǎng)絡(luò)帶寬，還有應(yīng)用所需要的計(jì)算資源等等。

• 第二部分 ，為了提高應(yīng)用開發(fā)的效率，并且去保證應(yīng)用開發(fā)的規(guī)范，我們公司會(huì)提供公共的中間件，這些中間件包括日志收集、應(yīng)用配置注冊(cè)、監(jiān)控報(bào)警指標(biāo)的收集，還有應(yīng)用調(diào)用路徑。

• 第三部分 ，為了將我們的應(yīng)用發(fā)布到線上，我們需要對(duì)應(yīng)用進(jìn)行代碼管理和構(gòu)建測試到發(fā)布到線上，這需要 CI/CD 持續(xù)發(fā)布和持續(xù)集成。

• 第四部分 ，當(dāng)一個(gè)應(yīng)用發(fā)布到線上之后，我們需要對(duì)這個(gè)應(yīng)用的性能指標(biāo)和業(yè)務(wù)指標(biāo)進(jìn)行監(jiān)控、報(bào)警和分析，這樣我們就需要大家應(yīng)用相關(guān)的監(jiān)控、報(bào)警和日志分析平臺(tái)。

去哪兒網(wǎng)的業(yè)務(wù)也是一步步發(fā)展起來的，機(jī)器從幾十臺(tái)到上萬臺(tái)，在發(fā)展的過程中我們遇到了很多問題，在不同的階段我們也提出了不同的解決方案。

概括來說，去哪兒網(wǎng)經(jīng)歷的階段分為四個(gè)部分：

• 第一個(gè)階段 ，運(yùn)維機(jī)器數(shù)量比較少，大部分的工作都是應(yīng)急運(yùn)維。比如我們發(fā)現(xiàn)一個(gè)應(yīng)用有問題了，我們登錄到這個(gè)應(yīng)用的相關(guān)機(jī)器上，手動(dòng)執(zhí)行Linux命令，去查看這個(gè)機(jī)器的資源使用情況。比如CPU是不是太高了，是不是磁盤占滿了，這個(gè)階段也沒有用到太復(fù)雜的腳本，基本上都是手動(dòng)操作，幾十臺(tái)左右。

• 第二個(gè)階段 ，隨著規(guī)模擴(kuò)大，手動(dòng)寫了很多腳本，有了這些腳本之后我們就可以批量去執(zhí)行任務(wù)，可以在多臺(tái)機(jī)器上批量部署應(yīng)用和監(jiān)控。這個(gè)階段，我們稱為腳本運(yùn)維的階段，這個(gè)階段我們是利用腳本并且結(jié)合開源的系統(tǒng)，我們可以完成對(duì)數(shù)百臺(tái)機(jī)器的運(yùn)維。

• 第三個(gè)階段 ，隨著規(guī)模越來越大，腳本運(yùn)維也不夠了，腳本運(yùn)維遠(yuǎn)遠(yuǎn)不能滿足，腳本可能都是分類的腳本，并沒有經(jīng)過合理的編排，這樣腳本的執(zhí)行順序就比較重要，沒有合理編排可能會(huì)導(dǎo)致一些問題。

  我們開發(fā)一些相關(guān)的系統(tǒng)，用系統(tǒng)把相關(guān)的腳本串聯(lián)起來，編排好組成一個(gè)一個(gè)分離的操作。比如說一臺(tái)機(jī)器的新建和刪除就是單獨(dú)的操作，把這些做成系統(tǒng)，運(yùn)維人員可以在界面上操作。

  這個(gè)階段，稱之為分立系統(tǒng)，他們的數(shù)據(jù)基本上在各個(gè)系統(tǒng)之間沒有實(shí)現(xiàn)一個(gè)比較好的共享。這個(gè)階段能運(yùn)維的主機(jī)數(shù)量也比較有限，數(shù)千臺(tái)的主機(jī)是比較好的。

• 第四個(gè)階段 ，緊接著去哪兒網(wǎng)的機(jī)器規(guī)模突破了萬臺(tái)以上，這時(shí)候我們考慮能不能從一個(gè)比較高的角度去合理設(shè)計(jì)一下我們的運(yùn)維平臺(tái)。為我們的運(yùn)維工作提供一站式的服務(wù)，在一站服務(wù)的基礎(chǔ)上我們實(shí)現(xiàn)數(shù)據(jù)互通，這樣就可以交互起來，做一些自動(dòng)化的工作。在這個(gè)時(shí)期也是今天我主要要講的內(nèi)容，就是運(yùn)維平臺(tái)的建設(shè)。

應(yīng)用運(yùn)維平臺(tái)的三個(gè)關(guān)鍵點(diǎn)

運(yùn)維平臺(tái)的建設(shè)過程中我們?cè)庥隽撕芏嗬щy也遇到了很多坑，在這些困難之中總結(jié)出來三個(gè)關(guān)鍵點(diǎn)，主機(jī)管理、監(jiān)控報(bào)警和數(shù)據(jù)互通。

去哪兒網(wǎng)的主機(jī)管理系統(tǒng)是以 OpenStack 和 DNSDB 為核心的 ， OpenStack 是調(diào)度創(chuàng)建虛擬機(jī)， DNSDB 是我們公司的域名管理系統(tǒng)。通過 DNSDB 我們就可以將一個(gè)機(jī)器的名稱、部門、用途和它所在的機(jī)房組成一個(gè)唯一的域名，我們用這個(gè)唯一的域名來標(biāo)識(shí)我們這臺(tái)主機(jī)。

在 OpenStack 、 DNSDB 之上，我們寫了大量的腳本文檔和工具，將這些腳本文檔和工具編排起來，封裝成一個(gè)一個(gè)的操作，并且我們給這些操作賦予一些相關(guān)的權(quán)限。我們把主機(jī)的信息、流通的管理、權(quán)限的配置還有操作日志的查詢都會(huì)存在日志庫里。最后我們會(huì)把一個(gè)主機(jī)管理系統(tǒng)的界面暴露給運(yùn)維人員，運(yùn)維人員通過這個(gè)界面來管理我們的主機(jī)。

有了主機(jī)管理平臺(tái)之后，運(yùn)維人員就可以非常方便的在這個(gè)平臺(tái)上創(chuàng)建、銷毀主機(jī)，查看主機(jī)的相關(guān)信息，比如說它的配置、過保信息等等。我們?cè)谛录用颗_(tái)機(jī)器的過程中都會(huì)默認(rèn)給這個(gè)機(jī)器加上監(jiān)控報(bào)警，機(jī)器有報(bào)警的時(shí)候也會(huì)通知到相關(guān)的負(fù)責(zé)人。

這樣做其實(shí)還是有一個(gè)問題，一個(gè)比較大的問題是，我們這個(gè)系統(tǒng)是怎么開發(fā)給運(yùn)維人員使用的，開發(fā)人員并沒有權(quán)限登錄這個(gè)系統(tǒng)。假如說開發(fā)人員提出來一個(gè)需求，我要?jiǎng)?chuàng)建一臺(tái)主機(jī)，就需要給OPS發(fā)郵件，OPS創(chuàng)建這臺(tái)主機(jī)的時(shí)候，其實(shí)并沒有非常準(zhǔn)確的記錄到這個(gè)負(fù)責(zé)人是誰，他可能會(huì)寫在備注里，這個(gè)備注隨著時(shí)間的推移，有可能不準(zhǔn)了。因?yàn)楫?dāng)時(shí)的負(fù)責(zé)人可能離職了或者轉(zhuǎn)崗，這種情況都是經(jīng)常發(fā)生的。

這個(gè)機(jī)器所負(fù)責(zé)的部門也沒有去很好的記錄，因?yàn)檫@個(gè)部門很多只是體現(xiàn)在主機(jī)這個(gè)名稱上，但是有可能這臺(tái)機(jī)器在使用的過程中可能會(huì)轉(zhuǎn)給其他業(yè)務(wù)線的部門使用，這樣我們拿到的部門信息也是不準(zhǔn)確的。還有一個(gè)問題DB系統(tǒng)只對(duì)運(yùn)維人員開放，業(yè)務(wù)線參與很少，導(dǎo)致整個(gè)主機(jī)的相關(guān)信息其實(shí)是不夠準(zhǔn)確的，因?yàn)镺PS人員畢竟有限，不可能非常準(zhǔn)確的維護(hù)這些信息。

這樣我們就想到一個(gè)方案，通過應(yīng)用樹去解決。

去哪兒網(wǎng)把業(yè)務(wù)線按照功能區(qū)劃分到各個(gè)BU，應(yīng)用樹BU作為第一級(jí)，下面有部門，部門下面還有更小的部門，這個(gè)層級(jí)可能是多個(gè)的。最后一級(jí)是部門下面所負(fù)責(zé)的應(yīng)用，應(yīng)用是作為最后一級(jí)的。我們把所有的級(jí)別都作為一個(gè)節(jié)點(diǎn)，在每個(gè)節(jié)點(diǎn)上都可以綁定主機(jī)，給節(jié)點(diǎn)添加負(fù)責(zé)人，給節(jié)點(diǎn)添加審批人，下面我會(huì)介紹審批人的權(quán)限和角色。有了這個(gè)應(yīng)用樹之后，業(yè)務(wù)線開發(fā)參與進(jìn)來，參與管理主機(jī)，他們的負(fù)責(zé)人和部門信息更加準(zhǔn)確。

一臺(tái)機(jī)器出現(xiàn)異常，我想非常迅速找到這個(gè)機(jī)器的負(fù)責(zé)人也非常容易。假如說宿主機(jī)馬上要過保了，它上面的所有的虛機(jī)我都需要找到這個(gè)虛機(jī)的負(fù)責(zé)人，通知這些人去執(zhí)行相關(guān)的操作，比如像虛機(jī)下線、應(yīng)用下線，這樣可以避免很多運(yùn)維宿主機(jī)過保而導(dǎo)致的故障。因?yàn)闄C(jī)器的負(fù)責(zé)人比較精確了，我們的報(bào)警通知會(huì)默認(rèn)把機(jī)器的監(jiān)控報(bào)警都通知給相關(guān)的負(fù)責(zé)人，由負(fù)責(zé)人來處理機(jī)器相關(guān)的基礎(chǔ)硬件報(bào)警。

每個(gè)季度都會(huì)統(tǒng)計(jì)資源的消耗，也會(huì)對(duì)下個(gè)季度機(jī)器的采購做規(guī)劃和預(yù)算。拿到比較上級(jí)的部門，比如拿到一個(gè)BU節(jié)點(diǎn)，可以通過應(yīng)用樹很容易拿到這個(gè)部門下都有哪些機(jī)器，他這個(gè)月的增長量是多少，我們就可以很方便的預(yù)測下個(gè)季度我們需要采購多少量的機(jī)器，從而制定更加合理的預(yù)算。有了用戶之后，負(fù)責(zé)人、部門和機(jī)器的關(guān)系都是比較明確的。

但是存在一個(gè)問題，申請(qǐng)資源的時(shí)候，仍然需要有OPS操作的，賬號(hào)添加也是由OPS負(fù)責(zé)，一個(gè)開發(fā)人員想要擴(kuò)容一臺(tái)機(jī)器或者給一個(gè)機(jī)器去添加賬號(hào)，要怎么做？他就需要給操作OPS的 team 發(fā)郵件，說我要給應(yīng)用擴(kuò)容兩主機(jī)，或者給哪臺(tái)主機(jī)添加一個(gè)賬號(hào)。這樣做有什么壞處，一是OPS不可能實(shí)時(shí)在線也不可能盯著系統(tǒng)，這樣OPS響應(yīng)非常慢，郵件查詢起來非常不方便，郵件時(shí)間長了可能丟失，定位問題也不容易。

怎么解決這個(gè)問題接下來又做了兩個(gè)系統(tǒng)，第一個(gè)是主機(jī)申請(qǐng)系統(tǒng)，第二是賬號(hào)申請(qǐng)系統(tǒng)。

這兩個(gè)系統(tǒng)以主機(jī)管理、應(yīng)用樹和審批中心為基礎(chǔ)，調(diào)用主機(jī)管理、應(yīng)用樹和審批中心為接口，通過調(diào)用接口去編排一些合理的主機(jī)申請(qǐng)和賬號(hào)申請(qǐng)的流程。剛才我們提到主機(jī)申請(qǐng)的時(shí)候，誰有權(quán)限申請(qǐng)，應(yīng)用樹上的每個(gè)節(jié)點(diǎn)的負(fù)責(zé)人都有權(quán)限去申請(qǐng)這個(gè)部門的主機(jī)或者這個(gè)應(yīng)用的主機(jī)，節(jié)點(diǎn)上的審批人他就有權(quán)限去審批這個(gè)節(jié)點(diǎn)下的主機(jī)。這樣OPS就不用參與太多，他們可以自動(dòng)申請(qǐng)主機(jī)和賬號(hào)。

最后我們做了一個(gè)界面，把這個(gè)界面暴露給開發(fā)人員，開發(fā)人員可以去申請(qǐng)主機(jī)申請(qǐng)賬號(hào)。通過應(yīng)用樹、主機(jī)管理、主機(jī)申請(qǐng)、賬號(hào)申請(qǐng)這四個(gè)平臺(tái)做了閉環(huán)，核心是應(yīng)用樹節(jié)點(diǎn)，應(yīng)用樹節(jié)點(diǎn)把四個(gè)部分串聯(lián)起來。

應(yīng)用樹節(jié)點(diǎn)有什么問題，我們會(huì)改變它，比如剛開始有個(gè) portal 應(yīng)用放在OPS開發(fā)下，有一天發(fā)現(xiàn)這個(gè)放的位置不太對(duì)，需要直接放在OPS下面就可以了，這樣就需要把 portal 從運(yùn)維開發(fā)移動(dòng)到OPS下面。

還有一個(gè)， portal 隨著業(yè)務(wù)增長，應(yīng)用越來越大，需要拆分成幾個(gè)部分，比如需要拆分成 portal-web 和 portal-api ，這種樹節(jié)點(diǎn)改變會(huì)導(dǎo)致什么？我們每個(gè)系統(tǒng)記錄的都是應(yīng)用樹節(jié)點(diǎn)，每個(gè)應(yīng)用樹節(jié)點(diǎn)的改變各個(gè)系統(tǒng)都需要去同步，這就相當(dāng)于在一個(gè)分布式系統(tǒng)里有一個(gè)有狀態(tài)的模塊，就是應(yīng)用樹節(jié)點(diǎn)這個(gè)模塊。其實(shí)它是有狀態(tài)的，有狀態(tài)就導(dǎo)致我們分布式比較困難，我們想把應(yīng)用樹節(jié)點(diǎn)推廣到更多的系統(tǒng)中，那就會(huì)非常困難，就會(huì)不斷面臨同步的問題。

這個(gè)問題怎么解決，比如說對(duì)于一個(gè)普通的居民來說，怎么在各個(gè)系統(tǒng)之間共享數(shù)據(jù)，比如我一個(gè)人怎么在公安系統(tǒng)在戶籍系統(tǒng)在銀行系統(tǒng)等等各個(gè)系統(tǒng)之間，怎么樣共享我的信息?，F(xiàn)實(shí)中就有一個(gè)非常好的實(shí)踐，那就是使用身份證，身份證有唯一的ID，通過這樣一個(gè)唯一的ID，就可以標(biāo)識(shí)這個(gè)應(yīng)用，并且這個(gè)ID永遠(yuǎn)不會(huì)改變。

我們?cè)鯓尤フ业竭@樣一個(gè)ID，第一個(gè)方案，用數(shù)據(jù)庫里的自增ID或者 UUID 來標(biāo)識(shí)應(yīng)用。這樣可以保證應(yīng)用ID唯一且不改變，但是因?yàn)樽栽鯥D和 UUID 在文字上沒有明確意義，我們開發(fā)人員拿到這個(gè)ID不便于記憶，也不便于溝通。

假如要用自增ID或 UUID ，需要用另外一個(gè)系統(tǒng)去專門看我有多少這樣的ID，先找到這個(gè)ID，再和其他系統(tǒng)進(jìn)行交互、溝通，非常不方便。第二個(gè)方案，借鑒身份證，用數(shù)字，比如110代表北京，后面代表縣區(qū)，代表自己的出生日期。

借鑒身份證ID，我們使用了這樣一個(gè)叫 Appcode 的來標(biāo)識(shí)應(yīng)用， Appcode 基本上以下滑線分割的，第一個(gè)是應(yīng)用所在的部門，第二個(gè)是應(yīng)用的描述，這個(gè)層級(jí)也可以非常長。用這樣一個(gè) Appcode 去代替應(yīng)用數(shù)節(jié)點(diǎn)，既能保證唯一且不可改變，便于大家記憶，溝通也比較方便，我們最后選的是第二套方案。

下面看一下我們是怎么在運(yùn)維平臺(tái)去做監(jiān)控報(bào)警的。作為一個(gè)互聯(lián)網(wǎng)公司，保證7x24小時(shí)的提供服務(wù)是一個(gè)最基本的要求，我們要怎么去保證7x24小時(shí)服務(wù)？假如說系統(tǒng)有問題的時(shí)候，我們能夠提前預(yù)警發(fā)現(xiàn)，等系統(tǒng)真正出現(xiàn)問題的時(shí)候，我們能夠及時(shí)的發(fā)現(xiàn)。要保證這兩點(diǎn)，我們就需要監(jiān)控報(bào)警系統(tǒng)。

去哪兒網(wǎng)的監(jiān)控報(bào)警系統(tǒng)也是經(jīng)歷了很長時(shí)間的掙扎，剛開始每個(gè)部門都會(huì)維護(hù)著自己一套系統(tǒng)，剛開始是 Cacti 和 Nagios 這兩個(gè)模塊去搭建的，這樣存在什么問題？

• 第一Cacti 部署在單機(jī)上，不能橫向拓展，導(dǎo)致性能比較差。假如單機(jī)出現(xiàn)異常甚至宕機(jī)，那我們的監(jiān)控報(bào)警系統(tǒng)就完全不可用，所以這是一個(gè)非高可用的方案。

• 第二是每個(gè)部門都會(huì)維護(hù)一套自己的監(jiān)控系統(tǒng)，甚至比較大的部門，像酒店機(jī)票這種大部門，他們可能會(huì)維護(hù)很多套，每一套都需要有專門的人員來運(yùn)維，運(yùn)維成本也非常高。

由于之前的系統(tǒng)沒有很好的權(quán)限管理，這個(gè)系統(tǒng)只能有專門的人來負(fù)責(zé)，因?yàn)榉砰_給其他人權(quán)限是比較危險(xiǎn)的，可能有人不小心操作了什么，把報(bào)警刪掉或者修改報(bào)警配置，所以只有把報(bào)警交給專人負(fù)責(zé)。

要定制一個(gè)報(bào)警監(jiān)控溝通成本非常高，我們需要聯(lián)系自己的相關(guān)負(fù)責(zé)人，然后再去報(bào)警配置。開發(fā)人員覺得太麻煩了，干脆不做了，或者做得非常少，導(dǎo)致我們監(jiān)控的面不夠全，可能有一些異常甚至是故障都沒有及時(shí)發(fā)現(xiàn)，效率是比較低下的。怎么解決這個(gè)問題？我們做了一個(gè)公司級(jí)的統(tǒng)一監(jiān)控報(bào)警平臺(tái) Watcher 。有這樣幾個(gè)目標(biāo)：

• 第一是高可用，一臺(tái)機(jī)器或幾臺(tái)機(jī)器掛了，對(duì)我們沒有影響或者影響很小。

• 第二是比較容易的讓大家去配置這個(gè)報(bào)警，我們做了一個(gè)權(quán)限管理系統(tǒng)，也是借鑒應(yīng)用樹做了一個(gè)樹狀的權(quán)限管理系統(tǒng)，把整個(gè) Watcher 界面開放給所有的開發(fā)人員，這樣大家就可以非常方便的配自己的報(bào)警和監(jiān)控。

簡單介紹一下 Watcher ， Watcher 是基于 Graphite 深度開發(fā)的， Watcher 平臺(tái)既支持主機(jī)基礎(chǔ)監(jiān)控報(bào)警同時(shí)也支持業(yè)務(wù)監(jiān)控報(bào)警，都在一個(gè)統(tǒng)一的平臺(tái)上，監(jiān)控報(bào)警可以由開發(fā)人員在統(tǒng)一的界面上查看和配置。

Watcher  大概2014年開始做，現(xiàn)在有三年時(shí)間，在公司也推廣得很好?，F(xiàn)在 Watcher 已經(jīng)接入1500個(gè)以上的應(yīng)用， Watcher 目前的指標(biāo)數(shù)量已經(jīng)超過了2000萬，報(bào)警數(shù)量已經(jīng)超過了40萬，接入了基礎(chǔ)監(jiān)控的機(jī)器數(shù)量也超過了4萬臺(tái)。 Watcher 這么大的規(guī)模，我們用了什么樣一個(gè)架構(gòu)呢？

這個(gè)架構(gòu)圖只是我們一個(gè) Watcher 集群的架構(gòu)圖，我們?cè)诖驍?shù)的時(shí)候會(huì)區(qū)分每個(gè)指標(biāo)要打到哪個(gè)集群上，我們?cè)趺磪^(qū)分？以  Metrics 作為標(biāo)識(shí)，比如所有的測試數(shù)據(jù)測試指標(biāo)都以t開頭，所有的主機(jī)數(shù)據(jù)都以h開頭，我們用s.flat就代表機(jī)票這個(gè)部門，機(jī)票這個(gè)部門所有指標(biāo)打數(shù)的時(shí)候就要配置好一個(gè)服務(wù)器，這個(gè)服務(wù)器也是用域名來表示的，它自己本身就代表一個(gè)機(jī)票的監(jiān)控報(bào)警集群。

在上面的集群架構(gòu)圖里，最下邊綠色的是 Graphite 原有的組件，在原有組件上我們自己開發(fā)了幾個(gè)相關(guān)的組件。第一個(gè)是 Relay ，每個(gè)指標(biāo)打過來之后，我們通過 Relay 把指標(biāo)分布在多臺(tái)機(jī)器上，這個(gè)是通過一致性哈希來實(shí)現(xiàn)的。

等我們?nèi)?shù)的時(shí)候， Graphite-api 這部分也是我們自己開發(fā)的， Graphite-api 里也有同樣的一致性哈希算法，通過這個(gè)算法找到這個(gè)指標(biāo)在這個(gè)集群的哪一個(gè)機(jī)器上，調(diào)用這個(gè)機(jī)器上的 Graphite-web 下的api，然后拿相關(guān)的數(shù)據(jù)。

這是一個(gè)集群的架構(gòu)，有多個(gè)集群，我們 Watcher 要做一個(gè)統(tǒng)一的界面，在這個(gè)界面上配置自己的監(jiān)控的時(shí)候，選擇數(shù)據(jù)源，對(duì)于打數(shù)的人他清楚這個(gè)指標(biāo)在什么地方。能不能做一個(gè)統(tǒng)一的數(shù)據(jù)源，讓用戶來使用，這樣我們就在組件里加上了一個(gè)純指標(biāo)的數(shù)據(jù)庫，每次流量過來之后，我們就會(huì)把這個(gè)指標(biāo)的名稱寫到我們數(shù)據(jù)庫里一份，同時(shí)記錄它在哪個(gè)集群。

這樣我們就可以對(duì)外報(bào)一個(gè)統(tǒng)一的 Graphite-api ，假如說一個(gè)指標(biāo)我們要起 s.flat-xx 的指標(biāo)，首先是調(diào)用api，去找 s.flat-xx 這個(gè)指標(biāo)在什么集群里，發(fā)現(xiàn)在機(jī)票的集群里，再通過一致性哈希就可以把這個(gè)指標(biāo)取出來了。 Graphite-api 上第一部分是借這個(gè) Dashboard ，是借這個(gè)報(bào)警。

講完整個(gè)的 Watcher 架構(gòu)，看一下主機(jī)監(jiān)控怎么做的？

首先有一個(gè)硬件管理平臺(tái)，維護(hù)著主機(jī)監(jiān)控的相關(guān)信息。最主要的是會(huì)編排代理，去維護(hù)代理的版本配置，會(huì)不停的去掃描這個(gè)主機(jī)，往主機(jī)上部署，也會(huì)定時(shí)檢查指標(biāo)是否收集了。假如這個(gè)主機(jī)指標(biāo)出現(xiàn)斷點(diǎn)了或者有問題了，會(huì)報(bào)警去檢查，到底是 Collectd 出問題了還是系統(tǒng)出問題了還是網(wǎng)絡(luò)出問題了。

每個(gè)主機(jī)上部署 Collectd 之后會(huì)根據(jù)不同的配置打不同的指標(biāo)，比如CPU的使用情況，內(nèi)存的使用情況，網(wǎng)絡(luò)帶寬的使用情況，這些都將指標(biāo)打成了 Watcher 。每個(gè)主機(jī)的指標(biāo)可能都是相同的，怎么區(qū)分不同主機(jī)的指標(biāo)，我們就以主機(jī)的名稱作為區(qū)分。接入到 Watcher 之后，我們就可以調(diào)用api，在 Dashboard 上調(diào)用。

業(yè)務(wù)監(jiān)控也是比較類似的，應(yīng)用接入之后會(huì)暴露出api，里面就是最近1分鐘之內(nèi)應(yīng)用的監(jiān)控?cái)?shù)據(jù)，每分鐘 Qmonitor server從所有的機(jī)器上去拉這個(gè)文件，拿了文件之后做集中的分析，分析完之后做相應(yīng)的處理。比如說對(duì)應(yīng)用進(jìn)行計(jì)數(shù)，算完之后以 Appcode 作為標(biāo)識(shí)來區(qū)分不同的指標(biāo)，將指標(biāo)推送到 Watcher 。推送到 Watcher 之后，同樣可以查詢監(jiān)控，檢查應(yīng)用指標(biāo)的健康狀態(tài)。

為什么要對(duì)應(yīng)用做這樣的抽象化，做抽象化的好處就是我們不用去考慮服務(wù)和資源的具體細(xì)節(jié)，就用一個(gè)App代表一個(gè)服務(wù)或者代表一個(gè)資源，在這個(gè)抽象化的過程中可以不考慮這個(gè)服務(wù)到底做什么，這個(gè)資源到底什么樣。給廣義的應(yīng)用定義共同的屬性，包括這個(gè)應(yīng)用的負(fù)責(zé)人、應(yīng)用的權(quán)限、應(yīng)用的賬單等等。

有了這些共同的屬性，我們就可以將 Appcode 在多個(gè)系統(tǒng)中進(jìn)行擴(kuò)展，分布在各個(gè)系統(tǒng)中去共享數(shù)據(jù)。這樣做的作用是什么？有了 Appcode 之后，我們就可以在我們的各個(gè)系統(tǒng)中形成一種共同的語言，這個(gè)共同語言就是 Appcode 。有了這個(gè)共同語言之后，我們就可以把各個(gè)系統(tǒng)之間的數(shù)據(jù)連接起來，最后實(shí)現(xiàn)一個(gè)數(shù)據(jù)的互通。實(shí)現(xiàn)數(shù)據(jù)互通之后有什么好處？

• 第一個(gè)方面，我們把 Appcode 放在各個(gè)系統(tǒng)之中監(jiān)控 ，比如說主機(jī)、存儲(chǔ)、計(jì)算，這是應(yīng)用的資源部分。 Appcode 分布在多個(gè)系統(tǒng)之中，多個(gè)系統(tǒng)中相互作用，一個(gè)數(shù)據(jù)只有分布的節(jié)點(diǎn)越多，對(duì)這個(gè)數(shù)據(jù)的準(zhǔn)確性要求越高，因?yàn)檫@個(gè)數(shù)據(jù)可能在多個(gè)系統(tǒng)間使用，它的負(fù)責(zé)人就會(huì)更加重視這份數(shù)據(jù)，所以他們更愿意讓這個(gè)數(shù)據(jù)變得更加準(zhǔn)確。

  數(shù)據(jù)更準(zhǔn)確之后，它就變得更加有用，各個(gè)系統(tǒng)之間因?yàn)閿?shù)據(jù)準(zhǔn)確了，都愿意使用這份數(shù)據(jù)，形成比較良性的生態(tài)循環(huán)。因?yàn)閿?shù)據(jù)互通了，我們就可以做一個(gè) Portal 平臺(tái)，對(duì)外暴露一個(gè)統(tǒng)一的界面，可以對(duì)我們應(yīng)用所涉及的所有部分進(jìn)行一站式管理。

• 第二是CI/CD部分 ，應(yīng)用發(fā)布的主機(jī)也是和 Appcode 相關(guān)聯(lián)的，應(yīng)有擴(kuò)容之后發(fā)布的主機(jī)也是同樣同步過來，發(fā)布選擇這些主機(jī)直接發(fā)布就可以了，不需要手動(dòng)再在去填寫這些主機(jī)列表。

• 第三是監(jiān)控分為兩個(gè)方面，一個(gè)是基礎(chǔ)監(jiān)控，一個(gè)是業(yè)務(wù)監(jiān)控 ?；A(chǔ)監(jiān)控也是通過 Appcode 維度可以查看相關(guān)的主機(jī)的基礎(chǔ)監(jiān)控。對(duì)于業(yè)務(wù)監(jiān)控在應(yīng)用監(jiān)控指標(biāo)的收集，也可以通過 Appcode 來拿到它的主機(jī)列表，自動(dòng)去給業(yè)務(wù)監(jiān)控指標(biāo)收集添加這些機(jī)器列表，添加完之后收集上來這些應(yīng)用相關(guān)主機(jī)的監(jiān)控指標(biāo)和日志。

• 第四是報(bào)警系統(tǒng) ，因?yàn)橛辛?Appcode 之后， Appcode 它會(huì)對(duì)應(yīng)著一些共同的監(jiān)控報(bào)警項(xiàng)，比如像 JAVA 里的GC報(bào)警。我們有了 Appcode 之后，就可以給每個(gè) Appcode 上的所有機(jī)器都默認(rèn)添加GC報(bào)警。這個(gè)GC報(bào)警聯(lián)系人就是 Appcode 一個(gè)負(fù)責(zé)人，每臺(tái)機(jī)器擴(kuò)容之后它的GC報(bào)警也就自動(dòng)添加了。日志收集也是一樣的，之前我們可能還是需要在這個(gè)平臺(tái)手動(dòng)維護(hù)，有了 Appcode 就可以同步這個(gè)列表。

  簡單介紹一下 Portal 平臺(tái)，現(xiàn)在也是正在開發(fā)中的平臺(tái)。

Portal 就是以 Appcode 為基礎(chǔ)，在 Appcode 的基礎(chǔ)上連接了各個(gè)運(yùn)維系統(tǒng)，比如說主機(jī)、賬號(hào)、GPU云、ES云，應(yīng)用注冊(cè)、應(yīng)用配置、應(yīng)用中間件，環(huán)境配置、代碼倉庫、測試、發(fā)布、監(jiān)控、報(bào)警、日志收集，故障管理。我們把這些系統(tǒng)都匯總到一個(gè) Portal 界面上暴露給開發(fā)人員，開發(fā)人員進(jìn)入這個(gè)系統(tǒng)之后就可以一站式的把應(yīng)用相關(guān)的想做的事情都做完，這樣開發(fā)人員也非常方便。

數(shù)據(jù)互通另外一個(gè)好處，剛才講主機(jī)管理，主機(jī)可能會(huì)有不同維度來解釋這個(gè)主機(jī)是不太一樣的。比如應(yīng)用發(fā)布，有發(fā)布主機(jī)列表，算賬單的時(shí)候有個(gè)賬單主機(jī)列表，收集日志的時(shí)候也有主機(jī)列表，收集監(jiān)控報(bào)警也有主機(jī)列表。

只要數(shù)據(jù)互通之后，我們就可以將這些數(shù)據(jù)串聯(lián)起來。比如我們應(yīng)用，它的主機(jī)需要擴(kuò)容了，擴(kuò)容兩臺(tái)主機(jī)，擴(kuò)容之后我們就可以自動(dòng)根據(jù)這個(gè)應(yīng)用上的負(fù)責(zé)人去為主機(jī)添加對(duì)應(yīng)的賬號(hào)，這樣它的負(fù)責(zé)人就可以利用這個(gè)賬號(hào)登錄相應(yīng)的系統(tǒng)，進(jìn)行相應(yīng)的操作。

數(shù)據(jù)庫還有其他的有IP白名單限制，有了數(shù)據(jù)互通之后，一個(gè)應(yīng)用它的白名單配置就沒必要記錄每一個(gè)主機(jī)了，就記錄 Appcode 就可以了。

數(shù)據(jù)互通還有另外一個(gè)好處，有 Appcode 之后我們就可以非常方便的去計(jì)算這個(gè)應(yīng)用所耗費(fèi)的賬單。為什么要計(jì)算一個(gè)應(yīng)用的賬單？

一方面，讓我們提高一下成本意識(shí)，成本意識(shí)在選的過程中也是需要考慮的。比如一個(gè)業(yè)務(wù)線它有一些數(shù)據(jù)需要記錄下來，它可以選擇任何系統(tǒng)，也可以選擇數(shù)據(jù)庫，也可以選擇  Watcher 。假如說這個(gè)業(yè)務(wù)訪問的頻率非常低，比如一天就幾次、十幾次，把這個(gè)數(shù)據(jù)記錄到 Watcher 其實(shí)成本非常高昂，因?yàn)?Watcher 數(shù)據(jù)膨脹非常厲害，選擇數(shù)據(jù)庫或者日志其實(shí)更劃算。

第二可以優(yōu)化實(shí)現(xiàn)，假如你由于算法導(dǎo)致機(jī)器資源大量使用，有了賬單之后，他們會(huì)去節(jié)約成本。有了成本意識(shí)之后，我們可以更加合理的分配資源。比如有的應(yīng)用本身不是很重要，還申請(qǐng)了特別多的機(jī)器，機(jī)器使用率也不高，拿到賬單一看，這么一個(gè)不重要的應(yīng)用竟然耗費(fèi)這么大的賬單，然后他們就會(huì)回收一部分。

目前我們也在不斷的去接入各種各樣的應(yīng)用賬單，比如說主機(jī)賬單、網(wǎng)絡(luò)帶寬賬單、監(jiān)控報(bào)警、日志收集、大量的存儲(chǔ)，還有計(jì)算資源賬單，還有其他的一系列的賬單，都會(huì)慢慢接入進(jìn)來。

最后做一下總結(jié)，在去哪兒網(wǎng)運(yùn)維自動(dòng)化歷程中，我們經(jīng)歷了不同的階段。我們發(fā)現(xiàn)等應(yīng)用擴(kuò)大到一定規(guī)模的時(shí)候，需要運(yùn)維平臺(tái)化，自動(dòng)的或者半自動(dòng)的方式是非常耗費(fèi)人力資源的，并且它也會(huì)大致發(fā)現(xiàn)一些錯(cuò)誤甚至是故障。去哪兒網(wǎng)運(yùn)維自動(dòng)化也是做得非常不錯(cuò)的，怎么來體現(xiàn)？

我入職的時(shí)候日常運(yùn)維的人員大概有五六個(gè)，現(xiàn)在我們?nèi)粘＿\(yùn)維的人員仍然是六個(gè)，我們又推了一個(gè)運(yùn)維機(jī)器人，運(yùn)維第七人。我們其實(shí)還是保持在六人的狀態(tài)，我們規(guī)模擴(kuò)大了很多倍，從百臺(tái)到萬臺(tái)，擴(kuò)大了上百倍的規(guī)模，但是我們?nèi)粘＿\(yùn)維人員并沒有增加，這是運(yùn)維平臺(tái)自動(dòng)化帶來的好處。

應(yīng)用的可用性需要監(jiān)控報(bào)警系統(tǒng)的保證，基本上在一個(gè)應(yīng)用上線之前就會(huì)去把它所有關(guān)鍵的報(bào)警和監(jiān)控架好，這樣應(yīng)用有問題的話就會(huì)迅速回滾或者去 debug 。因?yàn)槲覀冇型晟频谋O(jiān)控報(bào)警系統(tǒng)，所以去哪兒網(wǎng)的故障還算比較少的，平均來說一天也就兩三個(gè)故障。

但是去哪兒網(wǎng)的故障和其他的故障可能不太一樣，去哪兒網(wǎng)的故障要求比較苛刻，一次網(wǎng)絡(luò)故障我們就會(huì)記錄批次的故障。比如 Watcher 的監(jiān)控系統(tǒng)不出圖了，超過5分鐘了，我們可能會(huì)深究P1和P2的故障。在這樣的嚴(yán)格要求下，我們的故障也不會(huì)太高，我入職四年來，現(xiàn)在累計(jì)的故障數(shù)也就3000個(gè)左右。

要保證我們整個(gè)運(yùn)維生態(tài)的發(fā)展，我們需要將數(shù)據(jù)打通，打通需要給應(yīng)用一個(gè)ID，有了這個(gè)ID之后，我們就可以在各個(gè)運(yùn)維系統(tǒng)和平臺(tái)上共享數(shù)據(jù)，形成一個(gè)良性的生態(tài)循環(huán)。

作者介紹 ：鄭松寬， 去哪兒網(wǎng) 高級(jí)運(yùn)維工程師。2013年加入去哪兒網(wǎng)平臺(tái)事業(yè)部，從事運(yùn)維開發(fā)工作。工作中主要負(fù)責(zé)公司監(jiān)控系統(tǒng)的開發(fā)，應(yīng)用管理平臺(tái)Portal的設(shè)計(jì)、開發(fā)和運(yùn)維

轉(zhuǎn)自 ：【高效運(yùn)維