“

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

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

加入去哪

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

簡單介紹一下我們的運維團隊：

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

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

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

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

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

應(yīng)用運維平臺三大要點

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

主機管理

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

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

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

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

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

p>

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

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

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

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

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

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

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

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

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

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

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

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

因為機器負責(zé)人比較準確，所以我們的報告通知會默認通知機器監(jiān)控報告的相關(guān)負責(zé)人，負責(zé)人會處理機器相關(guān)的基礎(chǔ)硬件報告.

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

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

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

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

他需要給運營OPS的團隊發(fā)短信，說我想把應(yīng)用擴展到兩個主機，或者在哪個主機上加個賬號。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

監(jiān)控和報告

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

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

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

因為以前的系統(tǒng)沒有很好的權(quán)限管理，所以這個系統(tǒng)只能由專人處理。由于放權(quán)給其他人是危險的，有些人可能會不小心操作某些東西，刪除報告或更改報告配置，所以只有專人負責(zé)報告。

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

開發(fā)者覺得太麻煩，所以根本不做，或者做的很少，導(dǎo)致我們的監(jiān)控不夠?？赡苡幸恍┊惓Ｉ踔凉收蠜]有及時發(fā)現(xiàn)，效率比較低。

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

報告平臺有幾個目標：

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

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

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

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

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

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

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

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

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

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

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

能不能做一個統(tǒng)一的數(shù)據(jù)源供用戶使用，所以我們在組件中加入一個純指標庫。每次流量到來后，我們都會將這個指標的名稱告訴我們的數(shù)據(jù)庫。復(fù)制，同時將其記錄在該集群中。

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

第一部分

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

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

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

如果這個主機指標有斷點或者有問題，會上報case，檢測是??系統(tǒng)問題還是網(wǎng)絡(luò)問題。

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

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

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

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

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

我們來說說我們是如何在整個運維平臺上實現(xiàn)數(shù)據(jù)互通的。我們在監(jiān)控報告和主機管理中提到了一個。什么是去哪兒？

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

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

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

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

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

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

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

平臺介紹

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

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

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

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

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

例如對于應(yīng)用發(fā)布，有發(fā)布的主機列表，計費時計費的主機列表，收集日志時的主機列表，收集監(jiān)控報告的主機列表。

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

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

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

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

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

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

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

有了它之后，我們可以默認為每臺機器上的所有機器添加一個 GC 報告。 GC 報告聯(lián)系人是負責(zé)人。每臺機器擴容后，會手動添加其GC報告。

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

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

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

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

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

其次，可以優(yōu)化。如果你因為算法而使用大量機器資源，在有賬單之后，他們會自覺節(jié)約成本。

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

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

總結(jié)

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

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

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

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

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

因為我們有完善的監(jiān)控和報告系統(tǒng)，所以去哪兒的故障相對較少。平均而言，三天內(nèi)會出現(xiàn)兩到三個故障。

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

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

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

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