今天給大家分享的主題是“去哪兒網應用運維自動化演進之路”。自動化構建過程中所遇到的障礙以及我們是怎么樣跨越這些障礙，我們遇到了哪些坑，以及怎么填平這些坑的過程。

[[212285]]

我 2013 年加入去哪兒網，一直在從事運維開發工作。去哪兒網運維開發有一個特點，所有開發既當 PM，又當 QA，也沒有區分前端工作還是后端工作，用現在比較流行的話說，我們都是全棧工程師。

加入去哪兒這幾年，我做的工作也是比較零碎的，哪里有需求就去哪里。

概括起來主要涉及主機管理、應用管理、監控、報警平臺等設計，開發和運維這幾方面的工作。

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

• 我們的運維團隊負責公司所有的服務器、網絡等硬件平臺的運維工作。
• 部分人員從事日常運維，包括 QVS 的部署，Nginx 的配置，應用上線的支持，存儲的部署等，還包括報警的告知、故障的通報和跟蹤。
• 2013 年左右，我們開始研發自己的運維平臺。
• 負責公司內網的應用，這些內網包括 OA 系統、HR 系統，還有 IT 資產管理平臺等等。

去哪兒網應用運維平臺介紹

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

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

• 應用的資源管理，這些資源包括應用部署需要的主機、應用的圖片、文件，對象存儲所需要的存儲資源，應用通信和其他的網絡帶寬，還有應用所需要的計算資源等等。
• 為了提高應用開發的效率，并且保證應用開發的規范，我們公司會提供公共的中間件，這些中間件包括日志收集、應用配置注冊、監控報警指標的收集，還有應用調用路徑。
• 為了將我們的應用發布到線上，我們需要對應用進行代碼管理和構建測試到發布到線上，這需要 CI/CD 持續發布和持續集成。
• 當一個應用發布到線上之后，我們需要對這個應用的性能指標和業務指標進行監控、報警和分析，這樣就需要應用相關的監控、報警和日志分析平臺。

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

去哪兒網經歷的階段分為四個部分：

運維機器數量比較少，大部分的工作都是應急運維。比如我們發現一個應用有問題了，我們登錄到這個應用的相關機器上，手動執行 Linux 命令，去查看這個機器的資源使用情況。

比如 CPU 是不是太高了，是不是磁盤占滿了，這個階段也沒有用到太復雜的腳本，基本上都是手動操作，幾十臺左右。

隨著規模擴大，手動寫了很多腳本，有了這些腳本之后我們就可以批量去執行任務，可以在多臺機器上批量部署應用和監控。

這個階段，我們稱為腳本運維的階段，即利用腳本并且結合開源的系統，完成對數百臺機器的運維。

隨著規模越來越大，腳本運維不夠用了，遠遠不能滿足需求。腳本可能都是分類的腳本，并沒有經過合理的編排，這樣腳本的執行順序就比較重要，沒有合理編排可能會導致一些問題。

我們開發一些相關的系統，用系統把相關的腳本串聯起來，編排好組成一個一個分離的操作。比如說一臺機器的新建和刪除就是單獨的操作，把這些做成系統，運維人員可以在界面上操作。

這個階段，我們稱之為分立系統，數據基本上在各個系統之間沒有實現一個比較好的共享。這個階段能運維的主機數量也比較有限，數千臺的主機是比較好的。

緊接著去哪兒網的機器規模突破了萬臺以上，這時候我們考慮能不能從一個比較高的角度去合理設計一下運維平臺。

為我們的運維工作提供一站式的服務，在一站式服務的基礎上我們實現數據互通，這樣就可以交互起來，做一些自動化的工作。這個時期也是今天我們主要要講的內容，即運維平臺的建設。

應用運維平臺的三個關鍵點

運維平臺的建設過程中，我們遭遇了很多困難也遇到了很多坑，在這些困難之中總結出來三個關鍵點：

• 主機管理。
• 監控報警。
• 數據互通。

主機管理

去哪兒網的主機管理系統是以 OpenStack 和 DNSDB 為核心的， OpenStack 負責調度創建虛擬機， DNSDB 是域名管理系統。

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

在 OpenStack 、 DNSDB 之上，我們寫了大量的腳本文檔和工具，將這些腳本文檔和工具編排起來，封裝成一個一個的操作，并且我們給這些操作賦予一些相關的權限。

我們把主機的信息、流通的管理、權限的配置還有操作日志的查詢都會存在日志庫里。最后我們會把一個主機管理系統的界面暴露給運維人員，運維人員通過這個界面來管理我們的主機。

有了主機管理平臺之后，運維人員就可以非常方便的在這個平臺上創建、銷毀主機，查看主機的相關信息，比如說它的配置、過保信息等等。

我們在新加每臺機器的過程中都會默認給這個機器加上監控報警，機器有報警的時候也會通知到相關的負責人。

這樣做還是會存在一個比較大的問題，即我們這個系統是怎么開發給運維人員使用的，開發人員并沒有權限登錄這個系統。

假如說開發人員提出來一個需求，我要創建一臺主機，就需要給 OPS 發郵件，OPS 創建這臺主機的時候，其實并沒有非常準確的記錄到這個負責人是誰，他可能會寫在備注里，這個備注隨著時間的推移，有可能不準了。

因為當時的負責人可能離職了或者轉崗，這種情況都是經常發生的。

這個機器所負責的部門也沒有去很好的記錄，因為這個部門很多只是體現在主機這個名稱上，但是有可能這臺機器在使用的過程中可能會轉給其他業務線的部門使用，這樣我們拿到的部門信息也是不準確的。

還有一個問題 DB 系統只對運維人員開放，業務線參與很少，導致整個主機的相關信息其實是不夠準確的，因為 OPS 人員畢竟有限，不可能非常準確的維護這些信息。

這樣我們就想到一個方案，通過應用樹去解決。

去哪兒網把業務線按照功能區劃分到各個 BU，應用樹 BU 作為第一級，下面有部門，部門下面還有更小的部門，這個層級可能是多個的。

最后一級是部門下面所負責的應用，應用是作為最后一級的。我們把所有的級別都作為一個節點，在每個節點上都可以綁定主機，給節點添加負責人，給節點添加審批人，下面我會介紹審批人的權限和角色。

有了這個應用樹之后，業務線開發參與進來，參與管理主機，他們的負責人和部門信息更加準確。

一臺機器出現異常，我想非常迅速找到這個機器的負責人也非常容易。

假如說宿主機馬上要過保了，它上面的所有的虛機我都需要找到這個虛機的負責人，通知這些人去執行相關的操作，比如像虛機下線、應用下線，這樣可以避免很多運維宿主機過保而導致的故障。

因為機器的負責人比較精確了，我們的報警通知會默認把機器的監控報警都通知給相關的負責人，由負責人來處理機器相關的基礎硬件報警。

每個季度都會統計資源的消耗，也會對下個季度機器的采購做規劃和預算。

拿到比較上級的部門，比如拿到一個 BU 節點，可以通過應用樹很容易拿到這個部門下都有哪些機器，他這個月的增長量是多少，我們就可以很方便的預測下個季度我們需要采購多少量的機器，從而制定更加合理的預算。

有了用戶之后，負責人、部門和機器的關系都是比較明確的。

但是存在一個問題，申請資源的時候，仍然需要由 OPS 進行操作，賬號添加也是由 OPS 負責，一個開發人員想要擴容一臺機器或者給一個機器去添加賬號，要怎么做？

他就需要給操作 OPS 的 team 發郵件，說我要給應用擴容兩臺主機，或者給哪臺主機添加一個賬號。

這樣做有什么壞處，一是 OPS 不可能實時在線也不可能盯著系統，這樣 OPS 響應非常慢，郵件查詢起來非常不方便，而且郵件時間長了可能丟失，定位問題也不容易。

怎么解決這個問題？接下來又做了兩個系統：第一個是主機申請系統，第二是賬號申請系統。

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

剛才我們提到主機申請的時候，誰有權限申請，應用樹上的每個節點的負責人都有權限去申請這個部門的主機或者這個應用的主機，節點上的審批人他就有權限去審批這個節點下的主機。

這樣 OPS 就不用參與太多，他們可以自動申請主機和賬號。

最后我們做了一個界面，把這個界面暴露給開發人員，開發人員可以去申請主機、申請賬號。

通過應用樹、主機管理、主機申請、賬號申請這四個平臺做了閉環，核心是應用樹節點，應用樹節點把四個部分串聯起來。

應用樹節點有什么問題，我們會改變它，比如剛開始有個 portal 應用放在 OPS 開發下，有一天發現這個放的位置不太對，需要直接放在 OPS 下面就可以了，這樣就需要把 portal 從運維開發移動到 OPS 下面。

還有一個， portal 隨著業務增長，應用越來越大，需要拆分成幾個部分，比如需要拆分成 portal-web 和 portal-api ，這種樹節點改變會導致什么？

我們每個系統記錄的都是應用樹節點，每個應用樹節點的改變各個系統都需要去同步，這就相當于在一個分布式系統里有一個有狀態的模塊，就是應用樹節點這個模塊。

它是有狀態的，有狀態就導致我們分布式比較困難，我們想把應用樹節點推廣到更多的系統中，那就會非常困難，就會不斷面臨同步的問題。

這個問題怎么解決，比如說對于一個普通的居民來說，怎么在各個系統之間共享數據，比如我一個人怎么在公安系統、在戶籍系統、在銀行系統等等各個系統之間，怎么樣共享我的信息。

現實中就有一個非常好的實踐，那就是使用身份證，身份證有唯一的 ID，通過這樣一個唯一的 ID，就可以標識這個應用，并且這個 ID 永遠不會改變。

我們怎樣去找到這樣一個 ID，第一個方案，用數據庫里的自增 ID 或者 UUID 來標識應用。

這樣可以保證應用 ID 唯一且不改變，但是因為自增 ID 和 UUID 在文字上沒有明確意義，我們開發人員拿到這個 ID 不便于記憶，也不便于溝通。

假如要用自增 ID 或 UUID ，需要用另外一個系統去專門看我有多少這樣的 ID，先找到這個 ID，再和其他系統進行交互、溝通，非常不方便。

第二個方案，借鑒身份證，用數字，比如 110 代表北京，后面代表縣區，代表自己的出生日期。

借鑒身份證 ID，我們使用了這樣一個叫 Appcode 的方案來標識應用。Appcode 基本上以下滑線分割的，第一個是應用所在的部門，第二個是應用的描述，這個層級也可以非常長。

用這樣一個 Appcode 去代替應用數節點，既能保證唯一且不可改變，便于大家記憶，溝通也比較方便，我們最后選的是第二套方案。

監控報警

下面看一下我們是怎么在運維平臺去做監控報警的。作為一個互聯網公司，保證 7x24 小時提供服務是一個最基本的要求，我們要怎么去保證 7x24 小時服務？

假如說系統有問題的時候，我們能夠提前預警發現，等系統真正出現問題的時候，我們能夠及時的發現。要保證這兩點，我們就需要監控報警系統。

去哪兒網的監控報警系統也是經歷了很長時間的掙扎，剛開始每個部門都會維護自己的一套系統，剛開始是 Cacti 和 Nagios 這兩個模塊去搭建的，這樣存在什么問題？

Cacti 部署在單機上，不能橫向拓展，導致性能比較差。假如單機出現異常甚至宕機，那我們的監控報警系統就完全不可用，所以這是一個非高可用的方案。

每個部門都會維護一套自己的監控系統，甚至比較大的部門，像酒店機票這種大部門，他們可能會維護很多套，每一套都需要有專門的人員來運維，運維成本也非常高。

由于之前的系統沒有很好的權限管理，這個系統只能由專門的人來負責，因為放開給其他人權限是比較危險的，可能有人不小心操作了什么，把報警刪掉或者修改報警配置，所以只有把報警交給專人負責。

要定制一個報警監控溝通成本非常高，我們需要聯系自己的相關負責人，然后再去報警配置。

開發人員覺得太麻煩了，干脆不做了，或者做得非常少，導致我們監控的面不夠全，可能有一些異常甚至是故障都沒有及時發現，效率是比較低下的。

怎么解決這個問題？我們做了一個公司級的統一監控報警平臺 Watcher 。

報警平臺有這樣幾個目標：

高可用，一臺機器或幾臺機器掛了，對我們沒有影響或者影響很小。

比較容易的讓大家去配置這個報警，我們做了一個權限管理系統，也是借鑒應用樹做了一個樹狀的權限管理系統，把整個 Watcher 界面開放給所有的開發人員，這樣大家就可以非常方便的配自己的報警和監控。

簡單介紹一下 Watcher ， Watcher 是基于 Graphite 深度開發的， Watcher 平臺既支持主機基礎監控報警，同時也支持業務監控報警，都在一個統一的平臺上，監控報警可以由開發人員在統一的界面上查看和配置。

Watcher 大概 2014 年開始做，現在有三年時間，在公司也推廣得很好。

現在 Watcher 已經接入 1500 個以上的應用， 目前的指標數量已經超過了 2000 萬，報警數量已經超過了 40 萬，接入了基礎監控的機器數量也超過了 4 萬臺。 

Watcher 這么大的規模，我們用了什么樣一個架構呢？

這個架構圖只是我們一個 Watcher 集群的架構圖，我們在打數的時候會區分每個指標要打到哪個集群上，我們怎么區分？

以  Metrics 作為標識，比如所有的測試數據測試指標都以 t 開頭，所有的主機數據都以 h 開頭。

我們用 s.flat 就代表機票這個部門，機票這個部門所有指標打數的時候就要配置好一個服務器，這個服務器也是用域名來表示的，它自己本身就代表一個機票的監控報警集群。

在上面的集群架構圖里，最下邊綠色的是 Graphite 原有的組件，在原有組件上我們自己開發了幾個相關的組件。

第一個是 Relay ，每個指標打過來之后，我們通過 Relay 把指標分布在多臺機器上，這個是通過一致性哈希來實現的。

等我們取數的時候， Graphite-api 這部分也是我們自己開發的， Graphite-api 里也有同樣的一致性哈希算法，通過這個算法找到這個指標在這個集群的哪一個機器上，調用這個機器上的 Graphite-web 下的 api，然后拿相關的數據。

這是一個集群的架構，我們有多個集群。Watcher 要做一個統一的界面，在這個界面上配置自己的監控的時候，選擇數據源，對于打數的人他清楚這個指標在什么地方。

能不能做一個統一的數據源，讓用戶來使用，這樣我們就在組件里加上了一個純指標的數據庫，每次流量過來之后，我們就會把這個指標的名稱寫到我們數據庫里一份，同時記錄它在哪個集群。

這樣我們就可以對外報一個統一的 Graphite-api ，假如說一個指標我們要起 s.flat-xx 的指標，首先是調用api，去找 s.flat-xx 這個指標在什么集群里，發現在機票的集群里，再通過一致性哈希就可以把這個指標取出來了。

Graphite-api 上第一部分是借這個 Dashboard 來報警。講完整個的 Watcher 架構，下面看一下主機監控是怎么做的？

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

最主要的是會編排代理，去維護代理的版本配置，會不停的去掃描這個主機，往主機上部署，也會定時檢查指標是否收集了。

假如這個主機指標出現斷點了或者有問題了，會報警去檢查，到底是  Collectd 出問題了還是系統出問題了還是網絡出問題了。

每個主機上部署 Collectd 之后會根據不同的配置打不同的指標，比如 CPU 的使用情況，內存的使用情況，網絡帶寬的使用情況，這些都將指標打成了 Watcher。

每個主機的指標可能都是相同的，怎么區分不同主機的指標，我們就以主機的名稱作為區分。接入到 Watcher 之后，我們就可以調用 api，在 Dashboard 上調用。

業務監控也是比較類似的，應用接入之后會暴露出 api，里面就是最近 1 分鐘之內應用的監控數據，每分鐘 Qmonitor server 從所有的機器上去拉這個文件，拿了文件之后做集中的分析，分析完之后做相應的處理。

比如說對應用進行計數，算完之后以 Appcode 作為標識來區分不同的指標，將指標推送到 Watcher。推送到 Watcher 之后，同樣可以查詢監控，檢查應用指標的健康狀態。

數據互通

下面講一下我們怎么在整個運維平臺實現數據互通的。我們在監控報警和主機管理里都提到了一個 Appcode ，在去哪兒網 Appcode 到底是什么？

其實它就是唯一的一個標識應用，我們將一個應用進行了抽象化，意思更加廣義了。

在去哪兒網一個應用可以是一個 Web 服務，也可以是一個 GPU 云實例，也可以是 MySQL 實例，甚至可以是一組交換機，還可以是其他的。

為什么要對應用做這樣的抽象化，做抽象化的好處就是我們不用去考慮服務和資源的具體細節，就用一個 App 代表一個服務或者代表一個資源，在這個抽象化的過程中可以不考慮這個服務到底做什么，這個資源到底什么樣。

給廣義的應用定義共同的屬性，包括這個應用的負責人、應用的權限、應用的賬單等等。

有了這些共同的屬性，我們就可以將 Appcode 在多個系統中進行擴展，分布在各個系統中去共享數據。這樣做的作用是什么？

有了 Appcode 之后，我們就可以在我們的各個系統中形成一種共同的語言，這個共同語言就是 Appcode 。

有了這個共同語言之后，我們就可以把各個系統之間的數據連接起來，最后實現一個數據的互通。實現數據互通之后有什么好處？

• 我們把 Appcode 放在各個系統之中監控，比如說主機、存儲、計算，這是應用的資源部分。

Appcode 分布在多個系統之中，多個系統中相互作用，一個數據只有分布的節點越多，對這個數據的準確性要求越高，因為這個數據可能在多個系統間使用，它的負責人就會更加重視這份數據，所以他們更愿意讓這個數據變得更加準確。

• 數據更準確之后，它就變得更加有用，各個系統之間因為數據準確了，都愿意使用這份數據，形成比較良性的生態循環。

因為數據互通了，我們就可以做一個 Portal 平臺，對外暴露一個統一的界面，可以對我們應用所涉及的所有部分進行一站式管理。

Portal 平臺簡介

簡單介紹一下 Portal 平臺，現在也是正在開發中的平臺。

Portal 就是以 Appcode 為基礎，在 Appcode 的基礎上連接了各個運維系統。

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

我們把這些系統都匯總到一個 Portal 界面上暴露給開發人員，開發人員進入這個系統之后就可以一站式的把應用相關的想做的事情都做完。

數據互通另外一個好處，剛才講主機管理，主機可能會有不同維度來解釋這個主機是不太一樣的。

比如應用發布，有發布主機列表，算賬單的時候有個賬單主機列表，收集日志的時候也有主機列表，收集監控報警也有主機列表。

只要數據互通之后，我們就可以將這些數據串聯起來。比如我們應用，它的主機需要擴容了，擴容兩臺主機，擴容之后我們就可以自動根據這個應用上的負責人去為主機添加對應的賬號。

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

數據庫還有其他的比如 IP 白名單限制，有了數據互通之后，一個應用它的白名單配置就沒必要記錄在每一個主機上了，就記錄在 Appcode 就可以了。

CI/CD部分，應用發布的主機也是和 Appcode 相關聯的，應用擴容之后發布的主機也是同樣同步過來，發布選擇這些主機直接發布就可以了，不需要手動再去填寫這些主機列表。

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

對于業務監控在應用監控指標的收集，也可以通過 Appcode 來拿到它的主機列表，自動去給業務監控指標收集添加這些機器列表，添加完之后收集上來這些應用相關主機的監控指標和日志。

報警系統，因為有了 Appcode 之后，它會對應著一些共同的監控報警項，比如像 Java 里的 GC 報警。

我們有了 Appcode 之后，就可以給每個 Appcode 上的所有機器都默認添加 GC 報警。這個 GC 報警聯系人就是 Appcode 一個負責人，每臺機器擴容之后它的 GC 報警也就自動添加了。

日志收集也是一樣的，之前我們可能還是需要在這個平臺手動維護，有了 Appcode 就可以同步這個列表。

數據互通還有另外一個好處，有 Appcode 之后我們就可以非常方便的去計算這個應用所耗費的賬單。為什么要計算一個應用的賬單？

一方面，讓我們提高了成本意識，成本意識在選型過程中也是需要考慮的。

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

假如說這個業務訪問的頻率非常低，比如一天就幾次、十幾次，把這個數據記錄到 Watcher 其實成本非常高昂，因為 Watcher 數據膨脹非常厲害，選擇數據庫或者日志更劃算。

第二可以優化實現，假如你由于算法導致機器資源大量使用，有了賬單之后，他們會有意識去節約成本。

有了成本意識之后，我們可以更加合理的分配資源。比如有的應用本身不是很重要，還申請了特別多的機器，機器使用率也不高，拿到賬單一看，這么一個不重要的應用竟然耗費這么大的賬單，然后他們就會回收一部分資源。

目前我們也在不斷的去接入各種各樣的應用賬單，比如說主機賬單、網絡帶寬賬單、監控報警、日志收集、大量的存儲，還有計算資源賬單，還有其他的一系列的賬單，都會慢慢接入進來。

總結

最后做一下總結，在去哪兒網運維自動化歷程中，我們經歷了不同的階段。

我們發現等應用擴大到一定規模的時候，需要運維平臺化，自動的或者半自動的方式是非常耗費人力資源的，并且它也會大致發現一些錯誤甚至是故障。去哪兒網運維自動化也是做得非常不錯的，怎么來體現？

我 2013 年入職，我入職的時候日常運維的人員大概有五六個，現在我們日常運維的人員仍然是六個，我們又推出了一個運維機器人，運維第七人。

我們還是保持在六人的狀態，我們規模擴大了很多倍，從百臺到萬臺，擴大了上百倍的規模，但是我們日常運維人員并沒有增加，這是運維平臺自動化帶來的好處。

應用的可用性需要監控報警系統的保證，基本上在一個應用上線之前就會去把它所有關鍵的報警和監控架好，這樣應用有問題的話就會迅速回滾或者去 debug 。

因為我們有完善的監控報警系統，所以去哪兒網的故障還算比較少的，平均來說一天也就兩三個故障。

但是去哪兒網的故障和其他的故障可能不太一樣，去哪兒網的故障要求比較苛刻，一次網絡故障我們就會記錄批次的故障。

比如 Watcher 的監控系統不出圖了，超過 5 分鐘了，我們可能會深究 P1 和 P2 的故障。

在這樣的嚴格要求下，我們的故障也不會太高，我入職四年來，現在累計的故障數也就 3000 個左右。

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

[[212293]]

鄭松寬，去哪兒網高級運維工程師。2013年加入去哪兒網平臺事業部，從事運維開發工作。工作中主要負責公司監控系統的開發，應用管理平臺 Portal 的設計、開發和運維。