“

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

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

加入去哪

綜上所述，主要涉及主機管理、應用管理、監控、告警平臺的設計、開發和運維。

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

去哪兒應用運維平臺介紹

首先簡單介紹一下去哪兒網的應用運維平臺。

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

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

去哪兒經歷了四個階段：

應用運維平臺三大要點

在運維平臺建設過程中，我們遇到了很多困難，遇到了很多陷阱。在這個難點中，我們可以總結出三個關鍵點：

主機管理

去哪兒的主機管理系統基于DNSDB，負責調度和創建虛擬機。 DNSDB 是一個域名管理系統。

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

在 DNSDB 之上，我們編寫了大量的腳本文檔和工具，我們將這些腳本文檔和工具整理??并封裝到一個操作中，但我們為這些操作分配了一些相關的權限。

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

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

p>

在添加每臺機器的過程中，我們會默認為這臺機器添加監控報告，當機器有報告時我們會通知相關負責人。

這樣一來，還有一個很大的問題，就是我們的系統是怎么開發給運維人員使用的，開發者沒有權限登錄這個系統。

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

由于當時的負責人可能已經辭職或換工作，這種情況經常發生。

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

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

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

去哪兒網根據職能領域將業務線定義到每個BU。應用樹BU是第一層。它下面有部門，部門之下還有更小的部門。這個級別可能有多個。

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

有了這個應用樹，涉及到業務線的開發，涉及到主機的管理，他們的負責人和部門信息越來越準確。

一臺機器出現異常，我覺得很容易很快找到機器負責人。

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

因為機器負責人比較準確，所以我們的報告通知會默認通知機器監控報告的相關負責人，負責人會處理機器相關的基礎硬件報告.

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

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

有了用戶，負責人、部門、機器的關系比較清晰。

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

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

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

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

兩個系統以主機管理、應用樹和審批中心為基礎，將主機管理、應用樹和審批中心調用為，通過調用安排一些合理的主機申請和賬號申請流程。

剛才講宿主應用，誰有權限申請，應用樹上每個節點的負責人都有權申請這個部門的宿主或者這個應用的宿主，審批人在節點是他，它有權批準該節點下的主機。

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

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

通過應用樹、主機管理、主機應用、賬號應用四個平臺形成閉環。核心是應用樹節點，應用樹節點將四個部分串聯起來。

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

還有一個，隨著業務的下滑，應用越來越大，需要拆分成幾個部分，比如需要拆分成-web和-api。這些樹節點的變化會導致什么？

每個系統都記錄應用樹節點，每個應用樹節點的變化都需要與每個系統同步，相當于分布式系統中有一個有狀態的模塊，就是這個模塊的應用樹節點。

它是有狀態的，這讓我們很難分發。如果我們想將應用樹節點擴展到更多的系統，那將是特別困難的，并且我們將繼續面臨同步問題。

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

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

我們如何找到這樣的ID，第一個解決方案是使用數據庫中的自增ID或UUID來識別應用程序。

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

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

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

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

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

監控和報告

我們來看看我們是如何在運維平臺上做監控和報告的。作為一家互聯網公司，保證7x24小時服務是基本要求。我們如何保證 7x24 小時服務？

如果系統出現問題，我們可以及早發現，當系統真正出現問題時，我們可以及時發現。為了確保這兩點，我們需要監控報告系統。

去哪兒網的監控和報告系統也經歷了長期的斗爭。一開始，每個部門都會維護自己的一套系統。一開始是由 Cacti 和這兩個模塊構建的。存在哪些問題？ ?

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

訂購一個報告監控和溝通成本非常高，需要聯系我們的相關負責人，然后去報告配置。

開發者覺得太麻煩，所以根本不做，或者做的很少，導致我們的監控不夠。可能有一些異常甚至故障沒有及時發現，效率比較低。

如何解決這個問題？我們建立了公司級統一監控和報告平臺。

報告平臺有幾個目標：

簡要介紹是基于深入開發。該平臺支持基本的主機監控和報告，以及業務監控和報告，所有這些都在一個統一的平臺上。開發人員可以在統一的界面上查看和配置監控和報告。 .

我是2014年左右開始做的，到現在已經兩年了，在公司里推廣的很好。

如今已經連接了1500多個應用程序，目前指標數已經超過2000萬，報告病例數已經超過40萬，連接基礎監控的機器數已經超過4萬臺。

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

這個架構圖只是我們其中一個集群的架構圖。當我們計數時，我們將區分每個指標將命中哪個集群。我們如何區分？

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

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

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

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

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

這是一個集群架構，我們有多個集群。做一個統一的界面，在這個界面上配置自己的監控的時候，選擇好數據源，統計的人知道指標在哪里。

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

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

第一部分

-api就是用這個來報案的。說完了整個結構，我們來看看主機監控是怎么做的？

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

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

如果這個主機指標有斷點或者有問題，會上報case，檢測是??系統問題還是網絡問題。

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

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

業務監控類似。應用連接后，會暴露api。以上是應用最近1分鐘的監控數據。每分鐘，文件都會從所有機器中提取。文件取完后，會集中分析。 ，分析后做相應的處理。

例如對應用進行計數，將其作為指標來區分不同的指標，并將指標推送到。推送完成后，還可以查詢監控，檢測應用指標的健康狀況。

數據交換

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

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

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

我們為什么要像這樣可視化應用程序？可視化的用處在于我們不需要考慮服務和資源的具體細節，而是用一個App來表示一個服務或者一個資源。在可視化的過程中，不需要考慮服務做什么，資源長什么樣。

定義通用應用的通用屬性，包括應用負責人、應用權限、應用賬單等。

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

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

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

平臺介紹

平臺簡介，目前正在開發中。

它是基礎，各種運維系統都是在它的基礎上連接起來的。

例如主機、賬號、GPU云、ES云、應用注冊、應用配置、應用中間件、環境配置、代碼倉庫、測試、發布、監控、告警、日志采集、故障管理等。

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

數據通信的另一種用途就是談論主機管理。宿主可能有不同的維度來說明宿主不一樣。

例如對于應用發布，有發布的主機列表，計費時計費的主機列表，收集日志時的主機列表，收集監控報告的主機列表。

只要數據是通信的，我們就可以將這些數據串聯起來。比如在我們的應用中，它的主機需要擴容，可以擴容兩臺主機。擴容后，我們可以根據應用負責人手動添加對應賬號到主機。

這樣，負責人就可以使用這個賬號登錄相應的系統，進行相應的操作了。

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

在CI/CD部分，應用發布的主機也與主機相關聯，應用擴展后發布的主機也是同步的。選擇本主機即可直接發布主機，無需自動填寫本主機。列表。

監控分為兩個方面，一是基礎監控，二是業務監控。基礎監控也是對相關主機的基礎監控，可以通過維度查看。

對于業務監控的應用監控指標采集，也可以通過to獲取其主機列表，手動將本機列表加入業務監控指標采集，添加后采集本應用相關主機的監控指標并記錄。

報表系統有了之后，會對應一些常見的監控報表項，比如Java中的GC報表。

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

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

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

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

例如，一個業務線有一些數據需要記錄。它可以選擇任何系統，也可以選擇數據庫，也可以選擇。

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

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

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

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

總結

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

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

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

我們仍然保持六人的狀態。我們的規模增長了很多倍，從一百到一萬，規模擴大了數百倍，我們的日常運維人員沒有減少。這是手動操作和維護平臺。好處。

應用程序的可用性需要通過監控和報告系統來保證。基本上，在一個應用上線之前，它的所有關鍵報告和監控框架都會建立起來，這樣如果應用出現問題，它會迅速回滾或調試。

因為我們有完善的監控和報告系統，所以去哪兒的故障相對較少。平均而言，三天內會出現兩到三個故障。

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

例如，監控系統不在畫面中。已經超過5分鐘了。我們可以考慮P1和P2的失敗。

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

為了保證我們整個運維生態的發展，我們需要開放數據，開放需要給應用一個ID。有了這個ID，我們就可以在各種運維系統和平臺上共享數據，形成良性的生態循環。