“

明天給大家分享的主題是“去哪兒網(wǎng)應(yīng)用運(yùn)維的人工進(jìn)化之路”。人工建立過(guò)程中遇到的障礙以及我們是如何克服這些障礙的，遇到了哪些坑，這些坑的過(guò)程如何填。

我于 2013 年加入去哪兒，目前仍在從事運(yùn)維工作。去哪兒網(wǎng)具有運(yùn)維開(kāi)發(fā)的特點(diǎn)。所有開(kāi)發(fā)人員都是PM和QA，沒(méi)有后端工作和前端工作的區(qū)別。用當(dāng)今流行的話說(shuō)，我們都是全棧工程師。

加入去哪

綜上所述，主要涉及主機(jī)管理、應(yīng)用管理、監(jiān)控、告警平臺(tái)的設(shè)計(jì)、開(kāi)發(fā)和運(yùn)維。

簡(jiǎn)單介紹一下我們的運(yùn)維團(tuán)隊(duì)：

去哪兒應(yīng)用運(yùn)維平臺(tái)介紹

首先簡(jiǎn)單介紹一下去哪兒網(wǎng)的應(yīng)用運(yùn)維平臺(tái)。

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

去哪兒的業(yè)務(wù)也在一步步發(fā)展。機(jī)器的數(shù)量從幾十臺(tái)增加到幾萬(wàn)臺(tái)。在開(kāi)發(fā)過(guò)程中，我們遇到了很多問(wèn)題，在不同的階段提出了不同的解決方案。

去哪兒經(jīng)歷了四個(gè)階段：

應(yīng)用運(yùn)維平臺(tái)三大要點(diǎn)

在運(yùn)維平臺(tái)建設(shè)過(guò)程中，我們遇到了很多困難，遇到了很多陷阱。在這個(gè)難點(diǎn)中，我們可以總結(jié)出三個(gè)關(guān)鍵點(diǎn)：

主機(jī)管理

去哪兒的主機(jī)管理系統(tǒng)基于DNSDB，負(fù)責(zé)調(diào)度和創(chuàng)建虛擬機(jī)。 DNSDB 是一個(gè)域名管理系統(tǒng)。

通過(guò)DNSDB，我們可以將一臺(tái)機(jī)器的名稱、部門、用途和所在的機(jī)房組合成一個(gè)唯一的域名，我們用這個(gè)唯一的域名來(lái)識(shí)別這個(gè)主機(jī)。

在 DNSDB 之上，我們編寫(xiě)了大量的腳本文檔和工具，我們將這些腳本文檔和工具整理??并封裝到一個(gè)操作中，但我們?yōu)檫@些操作分配了一些相關(guān)的權(quán)限。

我們還將主機(jī)的信息、流通的管理、權(quán)限的配置、操作日志的查詢等存儲(chǔ)在日志庫(kù)中。最后，我們將一個(gè)主機(jī)管理系統(tǒng)的接口暴露給運(yùn)維人員，運(yùn)維人員通過(guò)這個(gè)接口來(lái)管理我們的主機(jī)。

通過(guò)主機(jī)管理平臺(tái)，運(yùn)維人員可以輕松地在該平臺(tái)上創(chuàng)建和銷毀主機(jī)服務(wù)器運(yùn)維，查看主機(jī)的相關(guān)信息，如主機(jī)配置、保外信息等。

p>

在添加每臺(tái)機(jī)器的過(guò)程中，我們會(huì)默認(rèn)為這臺(tái)機(jī)器添加監(jiān)控報(bào)告，當(dāng)機(jī)器有報(bào)告時(shí)我們會(huì)通知相關(guān)負(fù)責(zé)人。

這樣一來(lái)，還有一個(gè)很大的問(wèn)題，就是我們的系統(tǒng)是怎么開(kāi)發(fā)給運(yùn)維人員使用的，開(kāi)發(fā)者沒(méi)有權(quán)限登錄這個(gè)系統(tǒng)。

如果開(kāi)發(fā)者提出請(qǐng)求，我想創(chuàng)建一個(gè)主機(jī)，我需要給 OPS 發(fā)送一條短信。 OPS在創(chuàng)建這個(gè)host的時(shí)候，雖然沒(méi)有具體記錄誰(shuí)是負(fù)責(zé)人，但是他可能會(huì)寫(xiě)在筆記里，時(shí)間長(zhǎng)了可能會(huì)變得不準(zhǔn)確。

由于當(dāng)時(shí)的負(fù)責(zé)人可能已經(jīng)辭職或換工作，這種情況經(jīng)常發(fā)生。

這臺(tái)機(jī)器的負(fù)責(zé)部門沒(méi)有很好的記錄，因?yàn)檫@個(gè)部門很多只顯示在主機(jī)的名字上，有可能這臺(tái)機(jī)器在處理的過(guò)程中可能會(huì)轉(zhuǎn)移到其他業(yè)務(wù)線利用。 ，所以我們收到的部門信息也是不準(zhǔn)確的。

還有一個(gè)問(wèn)題是DB系統(tǒng)只對(duì)運(yùn)維人員開(kāi)放，涉及的業(yè)務(wù)線很少，所以整個(gè)主機(jī)的相關(guān)信息顯然不夠準(zhǔn)確。雖然 OPS 人員有限，但不可能非常準(zhǔn)確地維護(hù)這些信息。

所以我們想出了一個(gè)解決方案，通過(guò)應(yīng)用樹(shù)來(lái)解決它。

去哪兒網(wǎng)根據(jù)職能領(lǐng)域?qū)I(yè)務(wù)線定義到每個(gè)BU。應(yīng)用樹(shù)BU是第一層。它下面有部門，部門之下還有更小的部門。這個(gè)級(jí)別可能有多個(gè)。

最后一級(jí)是部門下的申請(qǐng)，申請(qǐng)是最后一級(jí)。我們把所有的層級(jí)看成一個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)可以綁定一個(gè)主機(jī)，給節(jié)點(diǎn)增加一個(gè)負(fù)責(zé)人，給節(jié)點(diǎn)增加一個(gè)審批者。下面我來(lái)介紹一下審批者的權(quán)限和角色。

有了這個(gè)應(yīng)用樹(shù)，涉及到業(yè)務(wù)線的開(kāi)發(fā)，涉及到主機(jī)的管理，他們的負(fù)責(zé)人和部門信息越來(lái)越準(zhǔn)確。

一臺(tái)機(jī)器出現(xiàn)異常，我覺(jué)得很容易很快找到機(jī)器負(fù)責(zé)人。

如果宿主機(jī)快過(guò)保修期了，我需要為前面的所有虛擬機(jī)找到這個(gè)虛擬機(jī)的負(fù)責(zé)人，并通知那些人進(jìn)行相關(guān)的操作，比如虛擬機(jī)離線，應(yīng)用離線，可以防止過(guò)多的運(yùn)維主機(jī)造成的故障。

因?yàn)闄C(jī)器負(fù)責(zé)人比較準(zhǔn)確，所以我們的報(bào)告通知會(huì)默認(rèn)通知機(jī)器監(jiān)控報(bào)告的相關(guān)負(fù)責(zé)人，負(fù)責(zé)人會(huì)處理機(jī)器相關(guān)的基礎(chǔ)硬件報(bào)告.

每個(gè)季度也會(huì)統(tǒng)計(jì)資源消耗，并制定下一季度機(jī)器采購(gòu)的計(jì)劃和預(yù)算。

如果你得到一個(gè)更高級(jí)別的部門，例如你得到一個(gè)BU節(jié)點(diǎn)，你可以很容易地通過(guò)應(yīng)用樹(shù)得到這個(gè)部門有哪些機(jī)器。我們可以很容易地預(yù)測(cè)本月會(huì)下跌多少。我們每個(gè)季度需要購(gòu)買的機(jī)器數(shù)量使得預(yù)算更加合理。

有了用戶，負(fù)責(zé)人、部門、機(jī)器的關(guān)系比較清晰。

還有一個(gè)問(wèn)題。申請(qǐng)資源的時(shí)候，OPS還是需要操作的，賬戶添加也是OPS負(fù)責(zé)的。開(kāi)發(fā)者想要擴(kuò)展機(jī)器或者給機(jī)器添加賬號(hào)應(yīng)該怎么做？

他需要給運(yùn)營(yíng)OPS的團(tuán)隊(duì)發(fā)短信，說(shuō)我想把應(yīng)用擴(kuò)展到兩個(gè)主機(jī)，或者在哪個(gè)主機(jī)上加個(gè)賬號(hào)。

這樣做有什么好處？首先，OPS不能實(shí)時(shí)在線，無(wú)法跟蹤系統(tǒng)，所以O(shè)PS響應(yīng)很慢，查郵件很不方便。但是，郵件可能會(huì)丟失很長(zhǎng)時(shí)間，并且不容易定位問(wèn)題。

如何解決這個(gè)問(wèn)題？拿出來(lái)后服務(wù)器運(yùn)維，我做了兩個(gè)系統(tǒng)：第一個(gè)是主機(jī)應(yīng)用系統(tǒng)，第二個(gè)是賬戶應(yīng)用系統(tǒng)。

兩個(gè)系統(tǒng)以主機(jī)管理、應(yīng)用樹(shù)和審批中心為基礎(chǔ)，將主機(jī)管理、應(yīng)用樹(shù)和審批中心調(diào)用為，通過(guò)調(diào)用安排一些合理的主機(jī)申請(qǐng)和賬號(hào)申請(qǐng)流程。

剛才講宿主應(yīng)用，誰(shuí)有權(quán)限申請(qǐng)，應(yīng)用樹(shù)上每個(gè)節(jié)點(diǎn)的負(fù)責(zé)人都有權(quán)申請(qǐng)這個(gè)部門的宿主或者這個(gè)應(yīng)用的宿主，審批人在節(jié)點(diǎn)是他，它有權(quán)批準(zhǔn)該節(jié)點(diǎn)下的主機(jī)。

這樣OPS就不用過(guò)多介入了，他們可以手動(dòng)申請(qǐng)主機(jī)和賬號(hào)。

最后我們做了一個(gè)接口，把這個(gè)接口暴露給開(kāi)發(fā)者，他們可以申請(qǐng)主機(jī)和賬號(hào)。

通過(guò)應(yīng)用樹(shù)、主機(jī)管理、主機(jī)應(yīng)用、賬號(hào)應(yīng)用四個(gè)平臺(tái)形成閉環(huán)。核心是應(yīng)用樹(shù)節(jié)點(diǎn)，應(yīng)用樹(shù)節(jié)點(diǎn)將四個(gè)部分串聯(lián)起來(lái)。

應(yīng)用程序樹(shù)節(jié)點(diǎn)有什么問(wèn)題，我們會(huì)改變它。比如一開(kāi)始，一個(gè)應(yīng)用是放在OPS開(kāi)發(fā)下的。三天后，發(fā)現(xiàn)這個(gè)位置不對(duì)。需要直接放在OPS下。需要將運(yùn)維開(kāi)發(fā)連接到OPS底層。

還有一個(gè)，隨著業(yè)務(wù)的下滑，應(yīng)用越來(lái)越大，需要拆分成幾個(gè)部分，比如需要拆分成-web和-api。這些樹(shù)節(jié)點(diǎn)的變化會(huì)導(dǎo)致什么？

每個(gè)系統(tǒng)都記錄應(yīng)用樹(shù)節(jié)點(diǎn)，每個(gè)應(yīng)用樹(shù)節(jié)點(diǎn)的變化都需要與每個(gè)系統(tǒng)同步，相當(dāng)于分布式系統(tǒng)中有一個(gè)有狀態(tài)的模塊，就是這個(gè)模塊的應(yīng)用樹(shù)節(jié)點(diǎn)。

它是有狀態(tài)的，這讓我們很難分發(fā)。如果我們想將應(yīng)用樹(shù)節(jié)點(diǎn)擴(kuò)展到更多的系統(tǒng)，那將是特別困難的，并且我們將繼續(xù)面臨同步問(wèn)題。

如何解決這個(gè)問(wèn)題，比如對(duì)于一個(gè)普通公民來(lái)說(shuō)，如何在各個(gè)系統(tǒng)之間共享數(shù)據(jù)，比如我在公安系統(tǒng)、戶籍系統(tǒng)、建行系統(tǒng)等中如何獨(dú)處系統(tǒng)等，如何分享我的信息。

其實(shí)有一個(gè)特別好的做法，就是使用身份證。 ID 卡具有唯一的 ID。通過(guò)這樣一個(gè)唯一的ID，可以識(shí)別應(yīng)用程序，但這個(gè)ID永遠(yuǎn)不會(huì)改變。

我們?nèi)绾握业竭@樣的ID，第一個(gè)解決方案是使用數(shù)據(jù)庫(kù)中的自增ID或UUID來(lái)識(shí)別應(yīng)用程序。

這樣可以保證應(yīng)用ID是唯一的，不會(huì)改變，而且由于自增ID和UUID在文中沒(méi)有明確的含義，我們的開(kāi)發(fā)者不容易記住這個(gè)ID并與之交流。

如果我想使用自增 ID 或 UUID，我需要使用另一個(gè)系統(tǒng)來(lái)查看我有多少這樣的 ID。先找到這個(gè)ID，再與其他系統(tǒng)交互通信，非常不方便。

第二個(gè)方案，在身份證上畫(huà)，用數(shù)字，比如110代表上海，前面代表縣，代表出生日期。

利用 ID，我們使用稱為 id 的方案來(lái)識(shí)別應(yīng)用程序。基本上，它被一條下降的線分開(kāi)。第一個(gè)是申請(qǐng)所在的部門，第二個(gè)是申請(qǐng)的描述。這個(gè)級(jí)別也可以很長(zhǎng)。

使用這樣的節(jié)點(diǎn)代替申請(qǐng)?zhí)柟?jié)點(diǎn)，可以保證其唯一性和不可更改性，讓你記憶和交流更方便。我們最終選擇了第二套方案。

監(jiān)控和報(bào)告

我們來(lái)看看我們是如何在運(yùn)維平臺(tái)上做監(jiān)控和報(bào)告的。作為一家互聯(lián)網(wǎng)公司，保證7x24小時(shí)服務(wù)是基本要求。我們?nèi)绾伪ＷC 7x24 小時(shí)服務(wù)？

如果系統(tǒng)出現(xiàn)問(wèn)題，我們可以及早發(fā)現(xiàn)，當(dāng)系統(tǒng)真正出現(xiàn)問(wèn)題時(shí)，我們可以及時(shí)發(fā)現(xiàn)。為了確保這兩點(diǎn)，我們需要監(jiān)控報(bào)告系統(tǒng)。

去哪兒網(wǎng)的監(jiān)控和報(bào)告系統(tǒng)也經(jīng)歷了長(zhǎng)期的斗爭(zhēng)。一開(kāi)始，每個(gè)部門都會(huì)維護(hù)自己的一套系統(tǒng)。一開(kāi)始是由 Cacti 和這兩個(gè)模塊構(gòu)建的。存在哪些問(wèn)題？ ?

因?yàn)橐郧暗南到y(tǒng)沒(méi)有很好的權(quán)限管理，所以這個(gè)系統(tǒng)只能由專人處理。由于放權(quán)給其他人是危險(xiǎn)的，有些人可能會(huì)不小心操作某些東西，刪除報(bào)告或更改報(bào)告配置，所以只有專人負(fù)責(zé)報(bào)告。

訂購(gòu)一個(gè)報(bào)告監(jiān)控和溝通成本非常高，需要聯(lián)系我們的相關(guān)負(fù)責(zé)人，然后去報(bào)告配置。

開(kāi)發(fā)者覺(jué)得太麻煩，所以根本不做，或者做的很少，導(dǎo)致我們的監(jiān)控不夠。可能有一些異常甚至故障沒(méi)有及時(shí)發(fā)現(xiàn)，效率比較低。

如何解決這個(gè)問(wèn)題？我們建立了公司級(jí)統(tǒng)一監(jiān)控和報(bào)告平臺(tái)。

報(bào)告平臺(tái)有幾個(gè)目標(biāo)：

簡(jiǎn)要介紹是基于深入開(kāi)發(fā)。該平臺(tái)支持基本的主機(jī)監(jiān)控和報(bào)告，以及業(yè)務(wù)監(jiān)控和報(bào)告，所有這些都在一個(gè)統(tǒng)一的平臺(tái)上。開(kāi)發(fā)人員可以在統(tǒng)一的界面上查看和配置監(jiān)控和報(bào)告。 .

我是2014年左右開(kāi)始做的，到現(xiàn)在已經(jīng)兩年了，在公司里推廣的很好。

如今已經(jīng)連接了1500多個(gè)應(yīng)用程序，目前指標(biāo)數(shù)已經(jīng)超過(guò)2000萬(wàn)，報(bào)告病例數(shù)已經(jīng)超過(guò)40萬(wàn)，連接基礎(chǔ)監(jiān)控的機(jī)器數(shù)已經(jīng)超過(guò)4萬(wàn)臺(tái)。

這么大的規(guī)模，我們用了什么樣的框架？

這個(gè)架構(gòu)圖只是我們其中一個(gè)集群的架構(gòu)圖。當(dāng)我們計(jì)數(shù)時(shí)，我們將區(qū)分每個(gè)指標(biāo)將命中哪個(gè)集群。我們?nèi)绾螀^(qū)分？

標(biāo)記，例如所有測(cè)試數(shù)據(jù)和測(cè)試指標(biāo)都以t開(kāi)頭，所有主機(jī)數(shù)據(jù)都以h開(kāi)頭。

我們用 s.flat 來(lái)代表機(jī)票部門。當(dāng)機(jī)票部門的所有指標(biāo)都統(tǒng)計(jì)完畢后，應(yīng)該配置一臺(tái)服務(wù)器。這個(gè)服務(wù)器也是用域名來(lái)表示的，它本身就代表了一個(gè)針對(duì)機(jī)票的監(jiān)控和報(bào)告集群。 .

在集群照明的前面，底部的紅色是原始組件。我們?cè)谠薪M件的基礎(chǔ)上開(kāi)發(fā)了幾個(gè)相關(guān)組件。

第一個(gè)是繼電器。每個(gè)指標(biāo)被調(diào)用后，我們通過(guò) Relay 將指標(biāo)分發(fā)到多臺(tái)機(jī)器上。這是通過(guò)一致性哈希實(shí)現(xiàn)的。

我們拿到數(shù)字后，-api部分也是我們自己開(kāi)發(fā)的。 -api 也具有相同的一致性哈希算法。通過(guò)這個(gè)算法，我們可以找到指標(biāo)在這個(gè)集群中的哪臺(tái)機(jī)器上，并調(diào)用這臺(tái)機(jī)器上-web下的api，然后得到相關(guān)數(shù)據(jù)。

這是一個(gè)集群架構(gòu)，我們有多個(gè)集群。做一個(gè)統(tǒng)一的界面，在這個(gè)界面上配置自己的監(jiān)控的時(shí)候，選擇好數(shù)據(jù)源，統(tǒng)計(jì)的人知道指標(biāo)在哪里。

能不能做一個(gè)統(tǒng)一的數(shù)據(jù)源供用戶使用，所以我們?cè)诮M件中加入一個(gè)純指標(biāo)庫(kù)。每次流量到來(lái)后，我們都會(huì)將這個(gè)指標(biāo)的名稱告訴我們的數(shù)據(jù)庫(kù)。復(fù)制，同時(shí)將其記錄在該集群中。

這樣，我們就可以向外界報(bào)告一個(gè)統(tǒng)一的-api。如果我們要為一個(gè)指標(biāo)啟動(dòng)s.flat-xx指標(biāo)，首先是調(diào)用api查找指標(biāo)s.flat-xx在哪些集群中，并找出在集群中，這個(gè)指標(biāo)可以是通過(guò)一致的哈希刪除。

第一部分

-api就是用這個(gè)來(lái)報(bào)案的。說(shuō)完了整個(gè)結(jié)構(gòu)，我們來(lái)看看主機(jī)監(jiān)控是怎么做的？

首先，有一個(gè)硬件管理平臺(tái)來(lái)維護(hù)有關(guān)主機(jī)監(jiān)控的信息。

最重要的是安排代理，維護(hù)代理的版本配置，不斷掃描主機(jī)，部署在主機(jī)上，定期檢查指標(biāo)是否采集。

如果這個(gè)主機(jī)指標(biāo)有斷點(diǎn)或者有問(wèn)題，會(huì)上報(bào)case，檢測(cè)是??系統(tǒng)問(wèn)題還是網(wǎng)絡(luò)問(wèn)題。

在每臺(tái)主機(jī)上部署后，會(huì)根據(jù)不同的配置標(biāo)記不同的指標(biāo)，如CPU使用率、顯存使用率、網(wǎng)絡(luò)帶寬使用率等。所有這些指標(biāo)都被標(biāo)記了。

每個(gè)主機(jī)的指標(biāo)可能相同。如何區(qū)分不同主機(jī)的指標(biāo)是根據(jù)主機(jī)的名稱。訪問(wèn)后，我們就可以調(diào)用該api并對(duì)其進(jìn)行調(diào)用。

業(yè)務(wù)監(jiān)控類似。應(yīng)用連接后，會(huì)暴露api。以上是應(yīng)用最近1分鐘的監(jiān)控?cái)?shù)據(jù)。每分鐘，文件都會(huì)從所有機(jī)器中提取。文件取完后，會(huì)集中分析。 ，分析后做相應(yīng)的處理。

例如對(duì)應(yīng)用進(jìn)行計(jì)數(shù)，將其作為指標(biāo)來(lái)區(qū)分不同的指標(biāo)，并將指標(biāo)推送到。推送完成后，還可以查詢監(jiān)控，檢測(cè)應(yīng)用指標(biāo)的健康狀況。

數(shù)據(jù)交換

我們來(lái)說(shuō)說(shuō)我們是如何在整個(gè)運(yùn)維平臺(tái)上實(shí)現(xiàn)數(shù)據(jù)互通的。我們?cè)诒O(jiān)控報(bào)告和主機(jī)管理中提到了一個(gè)。什么是去哪兒？

雖然是唯一的標(biāo)注應(yīng)用，但是我們把一個(gè)應(yīng)用可視化了，它的含義也變得更加籠統(tǒng)了。

任何應(yīng)用程序都可以是 Web 服務(wù)、GPU 云實(shí)例、MySQL 實(shí)例，甚至是一組交換機(jī)或其他。

我們?yōu)槭裁匆襁@樣可視化應(yīng)用程序？可視化的用處在于我們不需要考慮服務(wù)和資源的具體細(xì)節(jié)，而是用一個(gè)App來(lái)表示一個(gè)服務(wù)或者一個(gè)資源。在可視化的過(guò)程中，不需要考慮服務(wù)做什么，資源長(zhǎng)什么樣。

定義通用應(yīng)用的通用屬性，包括應(yīng)用負(fù)責(zé)人、應(yīng)用權(quán)限、應(yīng)用賬單等。

有了這個(gè)共同的屬性，我們可以跨多個(gè)系統(tǒng)擴(kuò)展，跨系統(tǒng)分布數(shù)據(jù)來(lái)共享數(shù)據(jù)。這是做什么的？

有了這個(gè)，我們可以在我們的各種系統(tǒng)中生成一種通用語(yǔ)言，而這種通用語(yǔ)言就是。

通過(guò)這種通用語(yǔ)言，我們可以將各個(gè)系統(tǒng)之間的數(shù)據(jù)連接起來(lái)，最終實(shí)現(xiàn)一次數(shù)據(jù)交換。實(shí)現(xiàn)數(shù)據(jù)互操作有什么好處？

平臺(tái)介紹

平臺(tái)簡(jiǎn)介，目前正在開(kāi)發(fā)中。

它是基礎(chǔ)，各種運(yùn)維系統(tǒng)都是在它的基礎(chǔ)上連接起來(lái)的。

例如主機(jī)、賬號(hào)、GPU云、ES云、應(yīng)用注冊(cè)、應(yīng)用配置、應(yīng)用中間件、環(huán)境配置、代碼倉(cāng)庫(kù)、測(cè)試、發(fā)布、監(jiān)控、告警、日志采集、故障管理等。

我們將此系統(tǒng)聚合到一個(gè)界面中，并將其公開(kāi)給開(kāi)發(fā)人員。進(jìn)入該系統(tǒng)后，開(kāi)發(fā)者可以一站式完成與應(yīng)用相關(guān)的所有想做的事情。

數(shù)據(jù)通信的另一種用途就是談?wù)撝鳈C(jī)管理。宿主可能有不同的維度來(lái)說(shuō)明宿主不一樣。

例如對(duì)于應(yīng)用發(fā)布，有發(fā)布的主機(jī)列表，計(jì)費(fèi)時(shí)計(jì)費(fèi)的主機(jī)列表，收集日志時(shí)的主機(jī)列表，收集監(jiān)控報(bào)告的主機(jī)列表。

只要數(shù)據(jù)是通信的，我們就可以將這些數(shù)據(jù)串聯(lián)起來(lái)。比如在我們的應(yīng)用中，它的主機(jī)需要擴(kuò)容，可以擴(kuò)容兩臺(tái)主機(jī)。擴(kuò)容后，我們可以根據(jù)應(yīng)用負(fù)責(zé)人手動(dòng)添加對(duì)應(yīng)賬號(hào)到主機(jī)。

這樣，負(fù)責(zé)人就可以使用這個(gè)賬號(hào)登錄相應(yīng)的系統(tǒng)，進(jìn)行相應(yīng)的操作了。

數(shù)據(jù)庫(kù)還有IP白名單等其他限制。數(shù)據(jù)交換后，無(wú)需記錄每個(gè)主機(jī)上某個(gè)應(yīng)用的白名單配置，記錄即可。

在CI/CD部分，應(yīng)用發(fā)布的主機(jī)也與主機(jī)相關(guān)聯(lián)，應(yīng)用擴(kuò)展后發(fā)布的主機(jī)也是同步的。選擇本主機(jī)即可直接發(fā)布主機(jī)，無(wú)需自動(dòng)填寫(xiě)本主機(jī)。列表。

監(jiān)控分為兩個(gè)方面，一是基礎(chǔ)監(jiān)控，二是業(yè)務(wù)監(jiān)控。基礎(chǔ)監(jiān)控也是對(duì)相關(guān)主機(jī)的基礎(chǔ)監(jiān)控，可以通過(guò)維度查看。

對(duì)于業(yè)務(wù)監(jiān)控的應(yīng)用監(jiān)控指標(biāo)采集，也可以通過(guò)to獲取其主機(jī)列表，手動(dòng)將本機(jī)列表加入業(yè)務(wù)監(jiān)控指標(biāo)采集，添加后采集本應(yīng)用相關(guān)主機(jī)的監(jiān)控指標(biāo)并記錄。

報(bào)表系統(tǒng)有了之后，會(huì)對(duì)應(yīng)一些常見(jiàn)的監(jiān)控報(bào)表項(xiàng)，比如Java中的GC報(bào)表。

有了它之后，我們可以默認(rèn)為每臺(tái)機(jī)器上的所有機(jī)器添加一個(gè) GC 報(bào)告。 GC 報(bào)告聯(lián)系人是負(fù)責(zé)人。每臺(tái)機(jī)器擴(kuò)容后，會(huì)手動(dòng)添加其GC報(bào)告。

日志收集也是如此。之前，我們可能還需要自動(dòng)維護(hù)這個(gè)平臺(tái)。一旦我們有了它，我們就可以同步這個(gè)列表。

數(shù)據(jù)共享還有另一種用途，然后我們可以輕松估算此應(yīng)用程序的費(fèi)用。為什么要為應(yīng)用估算賬單？

一方面，它可以讓我們提高成本意識(shí)，這也是在選擇過(guò)程中需要考慮的。

例如，一個(gè)業(yè)務(wù)線有一些數(shù)據(jù)需要記錄。它可以選擇任何系統(tǒng)，也可以選擇數(shù)據(jù)庫(kù)，也可以選擇。

如果訪問(wèn)這個(gè)服務(wù)的頻率很低，比如三天幾次，或者十幾次，那么記錄這個(gè)數(shù)據(jù)是非常昂貴的。由于數(shù)據(jù)的巨大膨脹，選擇數(shù)據(jù)庫(kù)或日志更實(shí)惠。

其次，可以優(yōu)化。如果你因?yàn)樗惴ǘ褂么罅繖C(jī)器資源，在有賬單之后，他們會(huì)自覺(jué)節(jié)約成本。

有了成本意識(shí)，我們可以更合理地分配資源。比如有些申請(qǐng)本身不是很重要，申請(qǐng)了很多機(jī)器，機(jī)器的使用率不高。收到賬單后，一個(gè)不重要的應(yīng)用程序居然要花這么大的賬單，他們以后會(huì)回收的。一些資源。

目前我們也在不斷的訪問(wèn)各種應(yīng)用賬單，比如托管賬單、網(wǎng)絡(luò)帶寬賬單、監(jiān)控報(bào)告、日志收集、海量存儲(chǔ)、預(yù)估資源賬單等。還有其他系列的法案會(huì)陸續(xù)進(jìn)來(lái)。

總結(jié)

最后，讓我總結(jié)一下。在去哪兒的人工運(yùn)維過(guò)程中，我們經(jīng)歷了不同的階段。

我們發(fā)現(xiàn)當(dāng)應(yīng)用擴(kuò)展到一定規(guī)模時(shí)，需要對(duì)平臺(tái)進(jìn)行運(yùn)維。手工或半手工的方法特別費(fèi)力，但一般也會(huì)發(fā)現(xiàn)一些錯(cuò)誤甚至失敗。去哪兒的人工運(yùn)維也做得非常好。如何展示？

我是2013年加入公司的，剛加入公司的時(shí)候，日常運(yùn)維大概有五六個(gè)人。現(xiàn)在我們有六人日常運(yùn)維。我們推出了運(yùn)維機(jī)器人，運(yùn)維第七人。 .

我們?nèi)匀槐３至说臓顟B(tài)。我們的規(guī)模增長(zhǎng)了很多倍，從一百到一萬(wàn)，規(guī)模擴(kuò)大了數(shù)百倍，我們的日常運(yùn)維人員沒(méi)有減少。這是手動(dòng)操作和維護(hù)平臺(tái)。好處。

應(yīng)用程序的可用性需要通過(guò)監(jiān)控和報(bào)告系統(tǒng)來(lái)保證。基本上，在一個(gè)應(yīng)用上線之前，它的所有關(guān)鍵報(bào)告和監(jiān)控框架都會(huì)建立起來(lái)，這樣如果應(yīng)用出現(xiàn)問(wèn)題，它會(huì)迅速回滾或調(diào)試。

因?yàn)槲覀冇型晟频谋O(jiān)控和報(bào)告系統(tǒng)，所以去哪兒的故障相對(duì)較少。平均而言，三天內(nèi)會(huì)出現(xiàn)兩到三個(gè)故障。

但是，去哪兒的故障可能與其他故障不一樣。去哪兒對(duì)故障的要求更加嚴(yán)格。我們會(huì)為每個(gè)網(wǎng)絡(luò)故障記錄成批的故障。

例如，監(jiān)控系統(tǒng)不在畫(huà)面中。已經(jīng)超過(guò)5分鐘了。我們可以考慮P1和P2的失敗。

在這樣嚴(yán)格的要求下，我們的失敗率不會(huì)太高。加入公司四年以來(lái)，累計(jì)失敗次數(shù)只有3000左右。

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