應(yīng)用運維自動化演進之路

今天給大家分享的主題是“去哪兒網(wǎng)應(yīng)用運維自動化演進之路"。自動化構(gòu)建過程中

所遇到的障礙以及我們是怎么樣跨越這些障礙，我們遇到了哪些坑，以及怎么填平這

些坑的過程。

概括起來主要涉及主機管理、應(yīng)用管理、監(jiān)控、報警平臺等設(shè)計，開發(fā)和運維這幾方

面的工作。

團隊介紹

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

?我們的運維團隊負責公司所有的服務(wù)器、網(wǎng)絡(luò)等硬件平臺的運維工作。

?部分人員從事日常運維，包括QVS的部署，Nginx的配置，應(yīng)用上線的支持，存儲的

部署等，還包括報警的告知、故障的通報和跟蹤。

2013年左右，我們開始研發(fā)自己的運維平臺。

負責公司內(nèi)網(wǎng)的應(yīng)用，這些內(nèi)網(wǎng)包括0A系統(tǒng)、HR系統(tǒng)，還有IT資產(chǎn)管理平臺等

等。

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

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

*a

主機

儲

存

算

計

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

?應(yīng)用的資源管理，這些資源包括應(yīng)用部署需要的主機、應(yīng)用的圖片、文件，對象存儲所

需要的存儲資源，應(yīng)用通信和其他的網(wǎng)絡(luò)帶寬，還有應(yīng)用所需要的計算資源等等。

?為了提高應(yīng)用開發(fā)的效率，并且保證應(yīng)用開發(fā)的規(guī)范，我們公司會提供公共的中間件,

這些中間件包括日志收集、應(yīng)用配置注冊、監(jiān)控報警指標的收集，還有應(yīng)用調(diào)用路徑。

為了將我們的應(yīng)用發(fā)布到線上，我們需要對應(yīng)用進行代碼管理和構(gòu)建測試到發(fā)布到線上,

這需要CI/CD持續(xù)發(fā)布和持續(xù)集成。

當一個應(yīng)用發(fā)布到線上之后，我們需要對這個應(yīng)用的性能指標和業(yè)務(wù)指標進行監(jiān)控、報

警和分析，這樣就需要應(yīng)用用關(guān)的監(jiān)控、報警和日志分析平臺。

去哪兒網(wǎng)的業(yè)務(wù)也是一步步發(fā)展起來的，機器從幾十臺到上萬臺，在發(fā)展的過程中我

們遇到了很多問題，在不同的階段我們也提出了不同的解決方案。

去哪兒網(wǎng)經(jīng)歷的階段分為四個部分:

?運維機器數(shù)量比較少，大部分的工作都是應(yīng)急運維。比如我們發(fā)現(xiàn)一個應(yīng)用有問題了,

我們登錄到這個應(yīng)用的相關(guān)機器上，手動執(zhí)行Linux命令，去查看這個機器的斐源使

用情況。

比如CPU是不是太高了，是不是磁盤占滿了，這個階段也沒有用到太復雜的腳本，基

本上都是手動操作，幾十臺左右。

?隨著規(guī)模擴大，手動寫了很多腳本，有了這些腳本之后我們就可以批量去執(zhí)行任務(wù),

可以在多臺機器上批量部署應(yīng)用和監(jiān)控。

這個階段，我們稱為腳本運維的階段，即利用腳本并且結(jié)合開源的系統(tǒng)，完成對數(shù)百臺

機器的運維。

隨著規(guī)模越來越大，腳本運維不夠用了，遠遠不能滿足需求。腳本可能都是分類的腳本,

并沒有經(jīng)過合理的編排，這樣腳本的執(zhí)行順序就比較重要，沒有合理編排可能會導致

一些問題。

?我們開發(fā)一些相關(guān)的系統(tǒng)，用系統(tǒng)把相關(guān)的腳本串聯(lián)起來，編排好組成一個一個分離

的操作。比如說一臺機器的新建和刪除就是單獨的操作，把這些做成系統(tǒng)，運維人員可

以在界面上操作。

這個階段，我們稱之為分立系統(tǒng)，數(shù)據(jù)基本上在各個系統(tǒng)之間沒有實現(xiàn)一個比較好的

共享。這個階段能運維的主機數(shù)量也比較有限，數(shù)千臺的主機是比較好的。

緊接著去哪兒網(wǎng)的機器規(guī)模突破了萬臺以上，這時候我們考慮能不能從一個比較高的角

度去合理設(shè)計一下運維平臺。

為我們的運維工作提供一站式的服務(wù)，在一站式服務(wù)的基礎(chǔ)上我們實現(xiàn)數(shù)據(jù)互通，這樣

就可以交互起來，做一些自幼化的工作。這個時期也是今天我們主要要講的內(nèi)容，即運

維平臺的建設(shè)。

應(yīng)用運維平臺的三個關(guān)鍵點

?運維平臺的建設(shè)過程中，我們遭遇了很多困難也遇到了很多坑，在這些困難之中

總結(jié)出來三個關(guān)鍵點：

?主機管理。

?監(jiān)控報警。

?數(shù)據(jù)互通。

主機管理

運■維人員

主機管理系統(tǒng)

畬

腳本文檔工具權(quán)限D(zhuǎn)B

t

openstackDNSDB

去哪兒網(wǎng)的主機管理系統(tǒng)是以O(shè)penStack和DNSDB為核心的，OpenStack負責

調(diào)度創(chuàng)建虛擬機，DNSDB是域名管理系統(tǒng)。

通過DNSDB我們可以將一個機器的名稱、部門、用途和它所在的機房組成一個唯一的

域名，我們用這個唯一的域名來標識這臺主機。

在OpenStack、DNSDB之上，我們寫了大量的腳本文檔和工具，將這些腳本文檔和

工具編排起來，封裝成一個一個的操作，并且我們給這些操作賦予一些相關(guān)的權(quán)限。

我們把主機的信息、流通的管理、權(quán)限的配置還有操作日志的查詢都會存在日志庫里。

最后我們會把一個主機管理系統(tǒng)的界面暴露給運維人員，運維人員通過這個界面來管理

我們的主機。

有了主機管理平臺之后，運維人員就可以非常方便的在這個平臺上創(chuàng)建、銷毀主機，查

看主機的相關(guān)信息，比如說它的配置、過保信息等等C

我們在新加每臺機器的過程中都會默認給這個機器加上監(jiān)控報警，機器有報警的時候

也會通知到相關(guān)的負責人。

找負責人困難

部門統(tǒng)計困難

業(yè)務(wù)線參與少

這樣做還是會存在一個比較大的問題，即我們這個系統(tǒng)是怎么開發(fā)給運維人員使用的，

開發(fā)人員并沒有權(quán)限登錄這個系統(tǒng)。

假如說開發(fā)人員提出來一個需求，我要創(chuàng)建一臺主機，就需要給OPS發(fā)郵件，OPS創(chuàng)

建這臺主機的時候，其實并沒有非常準確的記錄到這個負責人是誰，他可能會寫在備注

里，這個備注隨著時間的推移，有可能不準了。

因為當時的負責人可能離職了或者轉(zhuǎn)崗，這種情況都是經(jīng)常發(fā)生的。

這個機器所負責的部門也沒有去很好的記錄，因為這個部門很多只是體現(xiàn)在主機這個名

稱上，但是有可能這臺機器在使用的過程中可能會轉(zhuǎn)給其他業(yè)務(wù)線的部門使用，這樣我

們拿到的部門信息也是不準確的。

還有一個問題DB系統(tǒng)只對運維人員開放，業(yè)務(wù)線參與很少，導致整個主機的相關(guān)信息

其實是不夠準確的，因為OPS人員畢竟有限，不可能非常準確的維護這些信息。

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

應(yīng)用樹

BU

節(jié)點

主機負責人審批人

去哪兒網(wǎng)把業(yè)務(wù)線按照功能區(qū)劃分到各個BU,應(yīng)用樹BU作為第一級，下面有部門,

部門下面還有更小的部門，這個層級可能是多個的。

最后一級是部門下面所負責的應(yīng)用，應(yīng)用是作為最后一級的。我們把所有的級別都作為

一個節(jié)點，在每個節(jié)點上都可以綁定主機，給節(jié)點添加負責人，給節(jié)點添加審批人，下面

我會介紹審批人的權(quán)限和角色。

有了這個應(yīng)用樹之后，業(yè)務(wù)線開發(fā)參與進來，參與管理主機，他們的負責人和部門信息更

加準確。

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

假如說宿主機馬上要過保了，它上面的所有的虛機我都需要找到這個虛機的負責人，通

知這些人去執(zhí)行相關(guān)的操作，比如像虛機下線、應(yīng)用下線，這樣可以避免很多運維宿主

機過保而導致的故障。

因為機器的負責人比較精確了，我們的報警通知會默認把機器的監(jiān)控報警都通知給相關(guān)

的負責人，由負責人來處理機器相關(guān)的基礎(chǔ)硬件報警C

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

拿到比較上級的部門，比如拿到一個BU節(jié)點，可以通過應(yīng)用樹很容易拿到這個部門下

都有哪些機器，他這個月的增長量是多少，我們就可以很方便的預測下個季度我們需要

采購多少量的機器，從而制定更加合理的預算。

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

?^9

業(yè)務(wù)線參與管理主機主機擴容仍由OPS負責

負責人定位迅速賬號添加仍由OPS負責

報警通知給負責人通過郵件溝通

部門主機統(tǒng)計方便記錄不易查詢

但是存在一個問題，申請資源的時候，仍然需要由OPS進行操作，賬號添加也是由

OPS負責，一個開發(fā)人員想要擴容一臺機器或者給一個機器去添加賬號，要怎么做？

他就需要給操作OPS的team發(fā)郵件，說我要給應(yīng)用擴容兩臺主機，或者給哪臺主機

添加一個賬號。

這樣做有什么壞處，一是OPS不可能實時在線也不可能盯著系統(tǒng)，這樣OPS響應(yīng)非

常慢，郵件查詢起來非常不方便，而且郵件時間長了可能丟失，定位問題也不容易。

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

請系統(tǒng)。

這兩個系統(tǒng)以主機管理、應(yīng)用惻和審批中心為基礎(chǔ)，調(diào)用主機管理、應(yīng)用樹和審批中心

為接口，通過調(diào)用接口去編排一些合理的主機申請和賬號申請的流程。

剛才我們提到主機申請的時候，誰有權(quán)限申請，應(yīng)用樹上的每個節(jié)點的負責人都有權(quán)限

去申請這個部門的主機或者這個應(yīng)用的主機，節(jié)點上的審批人他就有權(quán)限去審批這個節(jié)

點下的主機。

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

應(yīng)用主機

樹管理qunar.ops.dev.portal

應(yīng)用樹

節(jié)點qunar.ops.portal

主機賬號

qunar.ops.portal_web

申請申請

樹節(jié)點改變〉各系統(tǒng)同步>分布式困難

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

賬號。

通過應(yīng)用樹、主機管理、主機申請、賬號申請這四個平臺做了閉環(huán)，核心是應(yīng)用樹節(jié)點,

應(yīng)用樹節(jié)點把四個部分串聯(lián)起來。

應(yīng)用樹節(jié)點有什么問題，我們會改變它，比如剛開始有個portal應(yīng)用放在OPS開發(fā)

下，有一天發(fā)現(xiàn)這個放的位置不太對，需要直接放在OPS下面就可以了，這樣就需要

把portal從運維開發(fā)移動到OPS下面。

還有一個，portal隨著業(yè)務(wù)增長，應(yīng)用越來越大，需要拆分成幾個部分，比如需要拆分

成portal-web和portal-api,這種樹節(jié)點改變會導致什么？

我們每個系統(tǒng)記錄的都是應(yīng)用惻節(jié)點，每個應(yīng)用樹節(jié)點的改變各個系統(tǒng)都需要去同步，

這就相當于在一個分布式系統(tǒng)里有一個有狀態(tài)的模塊,就是應(yīng)用樹節(jié)點這個模塊。

它是有狀態(tài)的，有狀態(tài)就導致我們分布式比較困難，我們想把應(yīng)用樹節(jié)點推廣到更多的

系統(tǒng)中，那就會非常困難，就會不斷面臨同步的問題。

這個問題怎么解決，比如說對于一個普通的居民來說，怎么在各個系統(tǒng)之間共享數(shù)據(jù)，比

如我一個人怎么在公安系統(tǒng)、在戶籍系統(tǒng)、在銀行系統(tǒng)等等各個系統(tǒng)之間，怎么樣共享

我的信息。

現(xiàn)實中就有一個非常好的實踐，那就是使用身份證，身份證有唯一的ID,通過這樣一

個唯一的ID,就可以標識這個應(yīng)用，并且這個ID永遠不會改變。

解決方案

方案一萬某一

節(jié)點自增ID或UUIDAppcode(ops__portal_web)

能保證唯一且不改變能保證唯一且不改變

無意義，溝通不方便有意義,溝通方便

我們怎樣去找到這樣一個ID,第一個方案，用數(shù)據(jù)庫里的自增ID或者UUID來標識

應(yīng)用。

這樣可以保證應(yīng)用ID唯一且不改變，但是因為自增ID和UUID在文字上沒有明確

意義，我們開發(fā)人員拿到這個ID不便于記憶，也不便于溝通。

假如要用自增ID或UUID,需要用另外一個系統(tǒng)去專門看我有多少這樣的ID,先找

到這個ID,再和其他系統(tǒng)進行交互、溝通，非常不方便。

第二個方案，借鑒身份證，用數(shù)字，比如110代表北京，后面代表縣區(qū)，代表自己的出

生日期。

借鑒身份證ID,我們使用了這樣一個叫Appcode的方案來標識應(yīng)用。Appcode基

本上以下滑線分割的，第一個是應(yīng)用所在的部門，第二個是應(yīng)用的描述，這個層級也可以

非常長。

用這樣一個Appcode去代替應(yīng)用數(shù)節(jié)點，既能保證唯一且不可改變，便于大家記憶，

溝通也比較方便，我們最后選的是第二套方案。

監(jiān)控報警

下面看一下我們是怎么在運維平臺去做監(jiān)控報警的。作為一個互聯(lián)網(wǎng)公司，保證7x24

小時提供服務(wù)是一個最基本的要求，我們要怎么去保證7x24小時服務(wù)？

假如說系統(tǒng)有問題的時候，我們能夠提前預警發(fā)現(xiàn)，等系統(tǒng)真正出現(xiàn)問題的時候，我們

能夠及時的發(fā)現(xiàn)。要保證這兩點，我們就需要監(jiān)控報警系統(tǒng)。

原來的報警監(jiān)控

去哪兒網(wǎng)的監(jiān)控報警系統(tǒng)也是經(jīng)歷了很長時間的掙孔，剛開始每個部門都會維護自己

的一套系統(tǒng)，剛開始是Cacti和Nagios這兩個模塊去搭建的，這樣存在什么問

題？

存在的I可題

Cacti部署在單機上，不能橫向擴展，性能差，非高可用

各部門維護一套甚至多套，運維成本高

報警配置有專人負責,不能由開發(fā)人員定制，效率低

Cacti部署在單機上，不能橫向拓展，導致性能比較差。假如單機出現(xiàn)異常甚至宕機，

那我們的監(jiān)控報警系統(tǒng)就完全不可用，所以這是一個非高可用的方案。

每個部門都會維護一套自己的監(jiān)控系統(tǒng)，甚至比較大的部門，像酒店機票這種大部門，

他們可能會維護很多套，每一套都需要有專門的人員來運維，運維成本也非常高。

由于之前的系統(tǒng)沒有很好的權(quán)限管理，這個系統(tǒng)只能由專門的人來負責，因為放開給其

他人權(quán)限是比較危險的，可能有人不小心操作了什么，把報警刪掉或者修改報警配置，所

以只有把報警交給專人負責。

要定制一個報警監(jiān)控溝通成本非常高，我們需要聯(lián)系自己的相關(guān)負責人，然后再去報警

配置。

開發(fā)人員覺得太麻煩了，干脆不做了，或者做得非常少，導致我們監(jiān)控的面不夠全，可能

有一些異常甚至是故障都沒有及時發(fā)現(xiàn)，效率是比較低下的。

怎么解決這個問題？我們做了一個公司級的統(tǒng)一監(jiān)控報警平臺Watcher。

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

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

比較容易的讓大家去配置這個報警，我們做了一個權(quán)限管理系統(tǒng)，也是借鑒應(yīng)用樹做

了一個樹狀的權(quán)限管理系統(tǒng)，把整個Watcher界面開放給所有的開發(fā)人員，這樣大

家就可以非常方便的配自己的報警和監(jiān)控。

Watcher簡介

基于開源項目Graphite深度開發(fā)

報警監(jiān)控可由開發(fā)人員在統(tǒng)一界面上查看和配置

簡單介紹一下Watcher,Watcher是基于Graphite深度開發(fā)的，Watcher平臺

既支持主機基礎(chǔ)監(jiān)控報警，同時也支持業(yè)務(wù)監(jiān)控報警，都在一個統(tǒng)一的平臺上，監(jiān)控報警

可以由開發(fā)人員在統(tǒng)一的界面上查看和配置。

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

現(xiàn)在Watcher已經(jīng)接入1500個以上的應(yīng)用，目前的指標數(shù)量已經(jīng)超過了2000

萬，報警數(shù)量已經(jīng)超過了40萬，接入了基礎(chǔ)監(jiān)控的機器數(shù)量也超過了4萬臺。

Watcher這么大的規(guī)模，我們用了什么樣一個架構(gòu)呢？

Watcher架構(gòu)

這個架構(gòu)圖只是我們一個Watcher集群的架構(gòu)圖，我們在打數(shù)的時候會區(qū)分每個指標

要打到哪個集群上，我們怎么區(qū)分？

以Metrics作為標識，比如所有的測試數(shù)據(jù)測試指標都以t開頭，所有的主機數(shù)據(jù)都

以h開頭。

我們用s.flat就代表機票這個部門，機票這個部門所有指標打數(shù)的時候就要配置好一個

服務(wù)器，這個服務(wù)器也是用域名來表示的，它自己本身就代表一個機票的監(jiān)控報警集

群。

在上面的集群架構(gòu)圖里，最下邊綠色的是Graphite原有的組件，在原有組件上我們自

己開發(fā)了幾個相關(guān)的組件。

第一個是Relay,每個指標打過來之后，我們通過Relay把指標分布在多臺機器上，

這個是通過一致性哈希來實現(xiàn)的。

等我們?nèi)?shù)的時候，Graphite-api這部分也是我們自己開發(fā)的，Graphite-api里也

有同樣的一致性哈希算法，通過這個算法找到這個指標在這個集群的哪一個機器上，調(diào)

用這個機器上的Graphite-web下的api,然后拿相關(guān)的數(shù)據(jù)。

這是一個集群的架構(gòu)，我們有多個集群。Watcher要做一個統(tǒng)一的界面，在這個界面上

配置自己的監(jiān)控的時候，選擇數(shù)據(jù)源，對于打數(shù)的人他清楚這個指標在什么地方。

能不能做一個統(tǒng)一的數(shù)據(jù)源，讓用戶來使用，這樣我們就在組件里加上了一個純指標的

數(shù)據(jù)庫，每次流量過來之后，我們就會把這個指標的名稱寫到我們數(shù)據(jù)庫里一份，同時記

錄它在哪個集群。

這樣我們就可以對外報一個統(tǒng)一的Graphite-api,假如說一個指標我們要起s.flat-xx

的指標，首先是調(diào)用api,去找s.flat-xx這個指標在什么集群里，發(fā)現(xiàn)在機票的集群里,

再通過一致性哈希就可以把這個指標取出來了。

Graphite-api上第一部分是借這個Dashboard來報警。講完整個的Watcher架

構(gòu)，下面看一下主機監(jiān)控是怎么做的？

主機監(jiān)控報警

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

最主要的是會編排代理，去維護代理的版本配置，會不停的去掃描這個主機，往主機上部

署，也會定時檢查指標是否收集了。

假如這個主機指標出現(xiàn)斷點了或者有問題了，會報警去檢直，到底是Collectd出問題

了還是系統(tǒng)出問題了還是網(wǎng)絡(luò)出問題了。

每個主機上部署Collectd之后會根據(jù)不同的配置打不同的指標，比如CPU的使用情

況，內(nèi)存的使用情況，網(wǎng)絡(luò)帶寬的使用情況，這些都將指標打成了Watcher。

每個主機的指標可能都是相同的，怎么區(qū)分不同主機的指標，我們就以主機的名稱作

為區(qū)分。接入到Watcher之后，我們就可以調(diào)用api,在Dashboard上調(diào)用。

業(yè)務(wù)監(jiān)控報警

業(yè)務(wù)監(jiān)控也是比較類似的，應(yīng)用接入之后會暴露出api,里面就是最近1分鐘之內(nèi)應(yīng)用

的監(jiān)控數(shù)據(jù)，每分鐘Qmonitorserver從所有的機器上去拉這個文件，拿了文件之后

做集中的分析，分析完之后做相應(yīng)的處理。

比如說對應(yīng)用進行計數(shù)，算完之后以Appcode作為標識來區(qū)分不同的指標，將指標推

送到Watcher.推送到Watcher之后，同樣可以查詢監(jiān)控，檢查應(yīng)用指標的健康狀

態(tài)。

數(shù)據(jù)互通

下面講一下我們怎么在整個運維平臺實現(xiàn)數(shù)據(jù)互通的。我們在監(jiān)控報警和主機管理里

都提到了一個Appcode,在去哪兒網(wǎng)Appcode到底是什么？

Appcode是什么

H唯一標識一個抽象的應(yīng)用（廣義）

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

在去哪兒網(wǎng)一個應(yīng)用可以是一個Web服務(wù)，也可以是一個GPU云實例，也可以是

MySQL實例，甚至可以是一組交換機，還可以是其他的。

為什么要抽象化

不用考慮服務(wù)和資源的具體細節(jié)

定義共同的屬性（負責人、權(quán)限、賬單等）

易于擴展，便于在多個系統(tǒng)共享

為什么要對應(yīng)用做這樣的抽象化，做抽象化的好處就是我們不用去考慮服務(wù)和資源的具

體細節(jié)，就用一個App代表一個服務(wù)或者代表一個資源，在這個抽象化的過程中可以

不考慮這個服務(wù)到底做什么，這個資源到底什么樣。

給廣義的應(yīng)用定義共同的屬性，包括這個應(yīng)用的負責人、應(yīng)用的權(quán)限、應(yīng)用的賬單等

等。

有了這些共同的屬性，我們就可以將Appcode在多個系統(tǒng)中進行擴展，分布在各個系

統(tǒng)中去共享數(shù)據(jù)。這樣做的作用是什么？

有了Appcode之后，我們就可以在我們的各個系統(tǒng)中形成一種共同的語言，這個共同

語言就是Appcode。

有了這個共同語言之后，我們就可以把各個系統(tǒng)之間的數(shù)據(jù)連接起來，最后實現(xiàn)一個

數(shù)據(jù)的互通。實現(xiàn)數(shù)據(jù)互通之后有什么好處？

生數(shù)據(jù)互通的好處

?我們把Appcode放在各個系統(tǒng)之中監(jiān)控，比如說主機、存儲、計算，這是應(yīng)用的資源

部分。

Appcode分布在多個系統(tǒng)之中，多個系統(tǒng)中相互作用，一個數(shù)據(jù)只有分布的節(jié)點越多,

對這個數(shù)據(jù)的準確性要求越高，因為這個數(shù)據(jù)可能在多個系統(tǒng)間使用，它的負責人就

會更加重視這份數(shù)據(jù)，所以他們更愿意讓這個數(shù)據(jù)變得更加準確。

數(shù)據(jù)更準確之后，它就變得更加有用，各個系統(tǒng)之間因為數(shù)據(jù)準確了，都愿意使用這份數(shù)

據(jù)，形成比較良性的生態(tài)循環(huán)。

因為數(shù)據(jù)互通了，我們就可以做一個Portal平臺，對外暴露一個統(tǒng)一的界面，可以對我

們應(yīng)用所涉及的所有部分進行一站式管理。

Portal平臺簡介

簡單介紹一下Portal平臺，現(xiàn)在也是正在開發(fā)中的平臺。

Portal

Appcode

Portal就是以Appcode為基礎(chǔ)，在Appcode的基礎(chǔ)上連接了各個運維系統(tǒng)。

比如說主機、賬號、GPU云、ES云，應(yīng)用注冊、應(yīng)用配置、應(yīng)用中間件，環(huán)境配置、

代碼倉庫、測試、發(fā)布、監(jiān)控、報警、日志收集故障管理。

我們把這些系統(tǒng)都匯總到一個Portal界面上暴露給開發(fā)人員，開發(fā)人員進入這個系

統(tǒng)之后就可以一站式的把應(yīng)用相關(guān)的想做的事情都做完。

數(shù)據(jù)互通另外一個好處，剛才講主機管理，主機可能會有不同維度來解釋這個主機是不

太一樣的。

比如應(yīng)用發(fā)布，有發(fā)布主機列表，算賬單的時候有個賬單主機列表，收集日志的時候也有

主機列表，收集監(jiān)控報警也有主機列表。

只要數(shù)據(jù)互通之后，我們就可以將這些數(shù)據(jù)串聯(lián)起來C比如我們應(yīng)用，它的主機需要擴

容了，擴容兩臺主機，擴容之后我們就可以自動根據(jù)這個應(yīng)用上的負責人去為主機添加

對應(yīng)的賬號。

這樣它的負責人就可以利用這個賬號登錄相應(yīng)的系統(tǒng),進行相應(yīng)的操作。

數(shù)據(jù)庫還有其他的比如IP白名單限制，有了數(shù)據(jù)互通之后，一個應(yīng)用它的白名單配置就

沒必要記錄在每一個主機上了，就記錄在Appcode就可以了。

CI/CD部分，應(yīng)用發(fā)布的主機也是和Appcode相關(guān)聯(lián)的，應(yīng)用擴容之后發(fā)布的主機也

是同樣同步過來，發(fā)布選擇這些主機直接發(fā)布就可以了，不需要手動再去填寫這些主機

列表。

監(jiān)控分為兩個方面，一個是基礎(chǔ)監(jiān)控，一個是業(yè)務(wù)監(jiān)控。基礎(chǔ)監(jiān)控也是通過Appcode

維度可以查看相關(guān)的主機的基礎(chǔ)監(jiān)控。

對于業(yè)務(wù)監(jiān)控在應(yīng)用監(jiān)控指標的收集，也可以通過Appcode來拿到它的主機列表，自

動去給業(yè)務(wù)監(jiān)控指標收集添加這些機器列表，添加完之后收集上來這些應(yīng)用相關(guān)主機的

監(jiān)控指標和日志。

報警系統(tǒng)，因為有了Appcode之后，它會對應(yīng)著一些共同的監(jiān)控報警項，比如像

Java里的GC報警。

我們有了Appcode之后，就可以給每個Appcode上的所有機器都默認添加GC報

警。這個GC報警聯(lián)系人就是Appcode一個負責人，每臺機器擴容之后它的GC報

警也就自動添加了。

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

可以同步這個列表。

數(shù)據(jù)互通還有另外一個好處，有Appcode之后我們就可以非常方便的去計算這個應(yīng)

用所耗費的賬單。為什么要計算一個應(yīng)用的賬單？

賬單的作用

成本意識