“

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

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

加入去哪

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

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

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

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

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

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

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

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

在運(yùn)維平臺建設(shè)過程中，我們遇到了很多困難，遇到了很多陷阱。在這個(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)。

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

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

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

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

p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這樣OPS就不用過多介入了，他們可以手動申請主機(jī)和賬號。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果系統(tǒng)出現(xiàn)問題，我們可以及早發(fā)現(xiàn)，當(dāng)系統(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)歷了長期的斗爭。一開始，每個(gè)部門都會維護(hù)自己的一套系統(tǒng)。一開始是由 Cacti 和這兩個(gè)模塊構(gòu)建的。存在哪些問題？ ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們拿到數(shù)字后，-api部分也是我們自己開發(fā)的。 -api 也具有相同的一致性哈希算法。通過這個(gè)算法，我們可以找到指標(biāo)在這個(gè)集群中的哪臺機(jī)器上，并調(diào)用這臺機(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ù)源供用戶使用，所以我們在組件中加入一個(gè)純指標(biāo)庫。每次流量到來后，我們都會將這個(gè)指標(biāo)的名稱告訴我們的數(shù)據(jù)庫。復(fù)制，同時(shí)將其記錄在該集群中。

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

第一部分

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

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

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

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

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

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

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

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

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

我們來說說我們是如何在整個(gè)運(yùn)維平臺上實(shí)現(xiàn)數(shù)據(jù)互通的。我們在監(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來表示一個(gè)服務(wù)或者一個(gè)資源。在可視化的過程中，不需要考慮服務(wù)做什么，資源長什么樣。

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

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

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

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

平臺介紹

平臺簡介，目前正在開發(fā)中。

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

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

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

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

例如對于應(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)起來。比如在我們的應(yīng)用中，它的主機(jī)需要擴(kuò)容，可以擴(kuò)容兩臺主機(jī)。擴(kuò)容后，我們可以根據(jù)應(yīng)用負(fù)責(zé)人手動添加對應(yīng)賬號到主機(jī)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

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

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

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

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

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