本文根據(jù)白海強(qiáng)老師的主題演講《蘑菇街應(yīng)⽤運(yùn)維體系建設(shè)及運(yùn)維⾃動化實(shí)踐》整理而成。

[[214089]]

本次分享的內(nèi)容主要分為以下三個方面：

• 蘑菇街技術(shù)架構(gòu)及運(yùn)維演進(jìn)
• 應(yīng)用運(yùn)維體系建設(shè)思路
• 應(yīng)用運(yùn)維自動化實(shí)踐過程

蘑菇街技術(shù)架構(gòu)及運(yùn)維演進(jìn)

導(dǎo)購期（2011年-2012年）

2011 年蘑菇街上線時，它的主要業(yè)務(wù)是分享社區(qū)，就是買家買了商品以后，把這個商品分享出來給大家。

2012 年開始轉(zhuǎn)型商品導(dǎo)購，早期業(yè)務(wù)比較簡單，相對設(shè)備比較少，基本上是一套業(yè)務(wù)代碼。運(yùn)維都是由具體的開發(fā)同學(xué)自己去管理的，根本不需要專業(yè)的運(yùn)維人員。

轉(zhuǎn)型期（2013年-2014年）

從 2013 年開始，我們開始自建電商平臺，從下單到支付整條鏈路開始自主建設(shè)。

業(yè)務(wù)發(fā)生了變化，但是整個架構(gòu)沒有太大的變化，只是把中間層，數(shù)據(jù)層脫離出來了。設(shè)備增加了不少，從原來個位數(shù)增加到三位數(shù)了，還有網(wǎng)絡(luò)設(shè)備了。

業(yè)務(wù)這一塊是開發(fā)自己維護(hù)，運(yùn)維這邊主要建設(shè)了一些初級版的服務(wù)器管理系統(tǒng)、發(fā)布系統(tǒng)、監(jiān)控系統(tǒng)。

社交化電商（2015年-至今）

2015 年整個業(yè)務(wù)開始發(fā)生變化了，集團(tuán)開始從原來的 PHP 開發(fā)，逐步轉(zhuǎn)向了 Java 開發(fā)，從原來主站一套單一業(yè)務(wù)套代碼拆分成各個子業(yè)務(wù)系統(tǒng)，整個架構(gòu)發(fā)生改變。

流量入口我們分成兩塊，無線端和 PC 端二塊接入。MWP 為無線網(wǎng)關(guān)，其他 PC 端的流量通過代理層分發(fā)到各個不同的子業(yè)務(wù)系統(tǒng)，部分系統(tǒng)實(shí)現(xiàn)前后端分離服務(wù)化，最底層為數(shù)據(jù)層。

從原來業(yè)務(wù)再新加業(yè)務(wù)需求，我們逐漸演變成目前擁有 1300 多個應(yīng)用系統(tǒng)。

業(yè)務(wù)快速發(fā)展給我們運(yùn)維帶來的挑戰(zhàn)：

第一：1300 多個應(yīng)用如何進(jìn)行管理，這是一個大的問題。不同業(yè)務(wù)如何區(qū)分？業(yè)務(wù)肯定要部署在具體服務(wù)器上面，不同業(yè)務(wù)部署不同服務(wù)器，業(yè)務(wù)和服務(wù)器之間的對應(yīng)關(guān)系如何管理？

還有業(yè)務(wù)部署環(huán)境，不同的業(yè)務(wù)運(yùn)行的環(huán)境有可能存在差異的，所以我們需要把業(yè)務(wù)與環(huán)境之間的對應(yīng)關(guān)系也要管理起來。

第二：早期業(yè)務(wù)之間可以依賴簡單應(yīng)用代碼之間內(nèi)部的調(diào)用，拆分演變成應(yīng)用與應(yīng)用之間的依賴關(guān)系，如何管理業(yè)務(wù)之間的上下游依賴？如何快速定位排查問題？這對我們排查工具帶來了挑戰(zhàn)和要求。

我們帶著這些問題看一下運(yùn)維體系建設(shè)的思路。

應(yīng)用運(yùn)維體系建設(shè)思路

運(yùn)維核心理念

運(yùn)維工作圍繞這四個主題展開：

• 穩(wěn)定性。保證業(yè)務(wù)穩(wěn)定快速地發(fā)展。
• 成本。成本涉及到兩塊：人力成本和系統(tǒng)資源成本，我們期望以最小的成本創(chuàng)造最大生產(chǎn)價值。
• 效率。運(yùn)維工作自動化，提高工作效率，減少成本。
• 安全。

我們?nèi)粘＿\(yùn)維工作都是圍繞這四塊展開的，系統(tǒng)建設(shè)的時候也是圍繞這四個主題展示。

這四塊主題的優(yōu)先等級我個人認(rèn)為是：安全第一，如果系統(tǒng)存在安全問題，那肯定是第一時間處理；其次是穩(wěn)定性、成本、效率。

應(yīng)用運(yùn)維系統(tǒng)架構(gòu)

基于運(yùn)維需求，我們逐步建設(shè)起目前的運(yùn)維體系的架構(gòu)。

從最底層看：

• 第一層基礎(chǔ)的硬件環(huán)境，如 IDC/服務(wù)器/網(wǎng)絡(luò)設(shè)務(wù)。
• 第二層為業(yè)務(wù)需要的底層基礎(chǔ)服務(wù)，如 DNS、NTP、YUM 源、LVS 等。
• 第三層針對這些系統(tǒng)資源管理平臺，虛擬化平臺，DNS 管理系統(tǒng)等。

上面三層針對業(yè)務(wù)的，我們有應(yīng)用管理系統(tǒng)、服務(wù)器管理系統(tǒng)、DBMS 等；還有常用的系統(tǒng)，像發(fā)布系統(tǒng)、部署系統(tǒng)之類的。

最頂層是開放給業(yè)務(wù)開發(fā)使用的統(tǒng)一運(yùn)維平臺。這些系統(tǒng)并不是說在我們建設(shè)當(dāng)中一下就能建設(shè)好的，而是根據(jù)我們?nèi)粘２僮鳟?dāng)中運(yùn)維的需要逐步搭建而成。

應(yīng)用標(biāo)準(zhǔn)化規(guī)范-思路

如果一個系統(tǒng)業(yè)務(wù)要接入進(jìn)來，第一步要做的是標(biāo)準(zhǔn)化。按照我們規(guī)范進(jìn)行改造，符合我們要求才能接入進(jìn)來。

不然 1300 多個應(yīng)用沒有一個統(tǒng)一接入標(biāo)準(zhǔn)，讓我們?nèi)プ鲞m配打造運(yùn)維相關(guān)的系統(tǒng)，那是不可能的。

我們總體的思路，先標(biāo)準(zhǔn)、后接入，只有按標(biāo)準(zhǔn)改造了，業(yè)務(wù)開發(fā)才能方便地使用我們的運(yùn)維系統(tǒng)。

應(yīng)用標(biāo)準(zhǔn)化規(guī)范-范圍

標(biāo)準(zhǔn)化到底要做哪些事情呢？主要分成三塊：

• 基礎(chǔ)環(huán)境?；A(chǔ)環(huán)境里面規(guī)范有哪些呢？我們可以分為兩塊：硬件、軟件。

硬件我們規(guī)范了使用的服務(wù)器硬件配置規(guī)格，目前虛擬機(jī)規(guī)格分成三類：2 核 4G 內(nèi)存的、4 核 8G 內(nèi)存的、8 核 16G 內(nèi)存的；目前要求都使用的是虛擬機(jī)。

• 軟件方面我們主要規(guī)范部署需要的軟件的版本、管理方式和部署目錄。
• 應(yīng)用配置。這里規(guī)范了應(yīng)用部署目錄、應(yīng)用包名和應(yīng)用配置等。

技術(shù)架構(gòu)。規(guī)范了業(yè)務(wù)對基礎(chǔ)組件使用姿勢，如流量接入層、ZK、Kafka 等。

應(yīng)用標(biāo)準(zhǔn)化規(guī)范-內(nèi)容

集團(tuán)應(yīng)用體系規(guī)范

接下來看一下具體的標(biāo)準(zhǔn)化定義內(nèi)容，整個運(yùn)維標(biāo)準(zhǔn)化體系是我們運(yùn)維部牽頭搞的。

主要是剛才講到的內(nèi)容，定義了具體我們使用的應(yīng)用和基礎(chǔ)服務(wù)的接入、目錄的規(guī)范。

旁邊可以看一下應(yīng)用的管理規(guī)范，詳細(xì)定義應(yīng)用名命名規(guī)范、應(yīng)用包命名規(guī)范、應(yīng)用目錄、部署目錄等內(nèi)容，形成文件，在整個集團(tuán)各個部門里面?zhèn)鬟_(dá)執(zhí)行。

應(yīng)用標(biāo)準(zhǔn)化規(guī)范文檔-實(shí)例

應(yīng)用部署規(guī)范

我們按照開發(fā)語言不同，應(yīng)用服務(wù)對服務(wù)器的部署環(huán)境要求也不同；我們先后制定 Java 版、PHP 版、GO 版和 Node.js 版等。

每個版本的規(guī)范里面都基本上定義了這些內(nèi)容：

• 目錄：基礎(chǔ)軟件部署目錄和版本要求。
• 應(yīng)用運(yùn)行的用戶賬號是什么、權(quán)限是什么。

應(yīng)用標(biāo)準(zhǔn)化規(guī)范文檔-實(shí)例說明

應(yīng)用啟停腳本

接下來我們還規(guī)范了啟停腳本，定義了這個腳本里面?zhèn)鞯膮?shù)，可以支持哪些參數(shù)，啟動或者重啟；每條指令里面做什么事情都進(jìn)行了說明和規(guī)范。

規(guī)范應(yīng)用上線標(biāo)準(zhǔn)

除此之外還定義了一個業(yè)務(wù)上線之前要遵循的標(biāo)準(zhǔn)，上線的標(biāo)準(zhǔn)和下線的標(biāo)準(zhǔn)。

上線之前需要業(yè)務(wù)方提供標(biāo)準(zhǔn)的自檢功能，要怎么知道你這個應(yīng)用是成功還是失敗的，那肯定需要有一個檢測機(jī)制告訴我，腳本里面通過這個檢測機(jī)制知道這個業(yè)務(wù)到底是否正常，這是一個強(qiáng)制性的規(guī)范。

下線也是一樣，上流根據(jù)定時檢測指定這個 URL，根據(jù)訪問結(jié)果判斷是否把流量自動地切掉。

標(biāo)準(zhǔn)化文檔里面主要就是規(guī)范上述一些內(nèi)容，這些內(nèi)容為后面的運(yùn)維系統(tǒng)做了規(guī)范，我們運(yùn)維系統(tǒng)都是基于這個規(guī)范來做。

應(yīng)用運(yùn)維自動化實(shí)踐過程

應(yīng)用運(yùn)維核心概念

1300 多個應(yīng)用如何管理？在介紹應(yīng)用管理之前需要重點(diǎn)介紹一下這幾個概念，這作為蘑菇街應(yīng)用運(yùn)維核心概念：

• 應(yīng)用名代表在蘑菇街應(yīng)用系統(tǒng)中具體業(yè)務(wù)的功能，不同的應(yīng)用名用于區(qū)分不同的業(yè)務(wù)，我們按照一套業(yè)務(wù)代碼進(jìn)行劃分。
• 應(yīng)用名分組是用來組織管理服務(wù)器的。

兩者之間的關(guān)系是什么？一個應(yīng)用下面可以對應(yīng)多個應(yīng)用分組。

這個分組按照什么維度來劃分的呢？可以根據(jù)環(huán)境，也可以根據(jù)穩(wěn)定性的要求來拆分的。應(yīng)用名作為應(yīng)用運(yùn)維的核心，運(yùn)維系統(tǒng)都以應(yīng)用名作為資源的組織方式。

應(yīng)用管理系統(tǒng)

系統(tǒng)里面主要管哪些內(nèi)容呢？其中一塊用于管理業(yè)務(wù)、部門、人員三者之間的關(guān)系。

可以看一下這個圖，像這個業(yè)務(wù)是屬于哪一個部門的，開發(fā)者是誰，代碼 review 是誰，這個里面都會維護(hù)好。

除此之外還會定義這個應(yīng)用的部署特征，這個應(yīng)用部署類型是什么，這個比較關(guān)鍵。

后期的運(yùn)維系統(tǒng)我們會拿著部署特征信息后做判斷應(yīng)用于具體操作。應(yīng)用管理系統(tǒng)中定義的每一個字段在后面運(yùn)維系統(tǒng)里面都會存在一定關(guān)聯(lián)。

服務(wù)器管理

接下來服務(wù)器管理也有單獨(dú)的系統(tǒng)，服務(wù)器管理系統(tǒng)前面說了，分組是作為管理服務(wù)器的，在這一層可以看到我們整個層次結(jié)構(gòu)分成兩層：部門下面是具體的應(yīng)用，應(yīng)用下面是分組。

應(yīng)用分組默認(rèn)有三個組：

• DEV 代表線下測試環(huán)境。
• PRE 代表預(yù)發(fā)環(huán)境。
• ONLINE 代表生產(chǎn)環(huán)境。

我們在分組上面建立了不同環(huán)境的標(biāo)識，發(fā)布系統(tǒng)或其他運(yùn)維系統(tǒng)就可以根據(jù)需求按應(yīng)用的緯度獲取不同環(huán)境的機(jī)器列表。

同一個應(yīng)用目前我們只分了三套環(huán)境：測試環(huán)境、預(yù)發(fā)環(huán)境和線上環(huán)境，一般默認(rèn)對應(yīng) 3 個應(yīng)用分組。

但有時基于穩(wěn)定性考慮，會把線上環(huán)境的服務(wù)器拆分成多個應(yīng)用分組。假如某個應(yīng)用是為其他應(yīng)用業(yè)務(wù)提供基礎(chǔ)服務(wù)的。

如果調(diào)用服務(wù)不隔離管理的話，很容易出現(xiàn)穩(wěn)定性的問題，如非核心業(yè)務(wù)調(diào)用量過大，導(dǎo)致核心業(yè)務(wù)調(diào)用失敗或超時。

基于上述問題，我們很容易想到解決方案就是把服務(wù)拆分成不同服務(wù)集群，讓核心業(yè)務(wù)調(diào)用 1 個服務(wù)集群，讓非核心業(yè)務(wù)調(diào)用另外一個集群。

這個需求 RPC 服務(wù)管理控制臺都可以實(shí)現(xiàn) IP 與服務(wù)關(guān)系綁定，根據(jù)依賴業(yè)務(wù)重要程度區(qū)分出不同的服務(wù)集群，再根據(jù)不同集群調(diào)用量需求將服務(wù)器劃到不同的應(yīng)用分組中進(jìn)行管理，這個拆分分組是比較好的一個解決方案。

既然 RPC 這邊已經(jīng)把服務(wù)邏輯分組，那服務(wù)器管理系統(tǒng)中是不是可以不用區(qū)分了？服務(wù)器放在同一個應(yīng)用分組下進(jìn)行管理，這樣不是更簡單嗎？

不拆分出應(yīng)用分組，對于業(yè)務(wù)訪問是沒有影響的，因?yàn)閼?yīng)用分組的作用只是管理服務(wù)器，不會影響線上正常訪問。

但是運(yùn)維系統(tǒng)是不知道應(yīng)用業(yè)務(wù)內(nèi)部邏輯訪問分組是什么樣，那些機(jī)器屬于同一個服務(wù)集群，操作時必須一起操作。

如果同一個集群一起操作的話，那線上的服務(wù)就掛完了；所以必須把這個體現(xiàn)出來，管理起來。

應(yīng)用分組這個管理方式是比較靈活的，可以根據(jù)不同業(yè)務(wù)的特征建立不同的分組，比如說機(jī)房緯度、地域緯度等。

分組可以理解為是一個集群的概念，同一個應(yīng)用分組下提供服務(wù)和服務(wù)對象都是相同的，這是服務(wù)器管理這一塊。

應(yīng)用部署類型模板管理

同一類開發(fā)語言開發(fā)出來的業(yè)務(wù)應(yīng)用對于部署環(huán)境依賴大致都是相同的。

基于這個特征，我們基于應(yīng)用部署類型制定應(yīng)用部署模板，用于管理同類應(yīng)用部署服務(wù)器環(huán)境的需求。

我們基于不同部署類型建立對應(yīng)的應(yīng)用部署模板，如 Java 版、C++、GO 等。在這個模板里面我們定義了：部署的軟件和常規(guī)配置文件等內(nèi)容。

舉個例子，Java 開發(fā)類應(yīng)用，一般部署服務(wù)器環(huán)境所需要的包括一個 JDK，容器使用 Tomcat，Nginx 作為 Web 代理服務(wù)器；除此之外，我們還有可能需要啟停腳本和配置文件，用于保證環(huán)境正常運(yùn)行。

應(yīng)用基線管理

部署模板的用途是什么呢？它主要為應(yīng)用基線提供服務(wù)的。

應(yīng)用基線建立的維度我們是按照應(yīng)用分組維度來建立的。一般情況下應(yīng)用基線部署的內(nèi)容配置都是從部署模板里面導(dǎo)過來的，基本上都能滿足相應(yīng)的應(yīng)用部署環(huán)境的需要。

當(dāng)個別應(yīng)用需要個性化的環(huán)境配置或軟件時，我們就可以針對相應(yīng)的應(yīng)用分組的應(yīng)用基線進(jìn)行修改補(bǔ)充，以滿足業(yè)務(wù)方的需求。

應(yīng)用基線產(chǎn)生時間點(diǎn)是在應(yīng)用申請流程結(jié)束后，根據(jù)應(yīng)用申請時選擇的部署類型自動地把應(yīng)用模板相應(yīng)配置信息導(dǎo)入到該應(yīng)用下的所有應(yīng)用分組下面。

應(yīng)用部署系統(tǒng)

通過前面幾個系統(tǒng)，我們基本上把環(huán)境、應(yīng)用都管理起來了。但如何實(shí)現(xiàn)環(huán)境的自動化部署？

我們建立了應(yīng)用的部署系統(tǒng)，應(yīng)用部署系統(tǒng)里面定義什么呢？就是我們定義了部署環(huán)境的執(zhí)行步驟。

如第一步，部署安裝軟件；第二步配置文件；第三步初始化等等。根據(jù)我們應(yīng)用的部署類型建立不同的部署需要執(zhí)行的步驟，按照定義執(zhí)行步驟能完整地構(gòu)建起一個應(yīng)用的運(yùn)行環(huán)境。

運(yùn)維工單管理

最后缺一個觸發(fā)的場景，能把上面各個相關(guān)系統(tǒng)串聯(lián)起來的系統(tǒng)。像申請服務(wù)器、擴(kuò)容，新應(yīng)用申請，因?yàn)檫@些都是業(yè)務(wù)開發(fā)提出了需求，如何組織在一起，跟我們的環(huán)境部署系統(tǒng)組織在一起呢？

通過運(yùn)維工單的方式，需要業(yè)務(wù)開發(fā)提相應(yīng)的工單，根據(jù)不同的工單把我們前面運(yùn)維的步驟總的綜合在一起。

目前我們工單的范圍比較多，覆蓋了我們運(yùn)維當(dāng)中常見的一些運(yùn)維需求，像服務(wù)器申請、新應(yīng)用申請之類的。

這些步驟里面，每個工單里面都包含兩部分：

• 流程審批，因?yàn)橛械娜撕芊磳α鞒?，但流程是為了保證穩(wěn)定性的手段而已。
• 工單，是具體做的事情。

應(yīng)用運(yùn)維自動化實(shí)現(xiàn)總結(jié)

接下來說一下整個過程，當(dāng)運(yùn)維開發(fā)提交一個工單給我們的時候，假設(shè)新應(yīng)用申請，從新應(yīng)用里面根據(jù)這個應(yīng)用里面定義的內(nèi)容獲取應(yīng)用的配置信息。

應(yīng)用的審核人員是誰，根據(jù)這個審核人員審批流程通過以后，會獲取對應(yīng)系統(tǒng)里面部署的機(jī)器列表，根據(jù)部署列表拿到以后，把數(shù)據(jù)傳給應(yīng)用部署系統(tǒng)里面的部署環(huán)境。

部署環(huán)境里面，部署哪些軟件、同步哪些配置文件，這些數(shù)據(jù)從哪取？從應(yīng)用基線里面取。

應(yīng)用基線里面如果是空的，就從應(yīng)用模板里面獲取。當(dāng)環(huán)境部署完成以后或者出了異常以后把具體信息返回給工單系統(tǒng)，工單系統(tǒng)可以做一次重試任務(wù)或者結(jié)單。

應(yīng)用運(yùn)維自動化實(shí)現(xiàn)-工單實(shí)例

這邊是具體使用的工單實(shí)例場景——新應(yīng)用申請。

有流程審批，流程審批結(jié)束以后，運(yùn)維系統(tǒng)里面做的第一步，應(yīng)用的基本信息插入到應(yīng)用管理系統(tǒng)里面，同時設(shè)備管理系統(tǒng)里面自動的創(chuàng)建分組，分配機(jī)器。

機(jī)器分配完以后去部署環(huán)境，同時添加相應(yīng)責(zé)任人的權(quán)限。這幾個步驟基本上都是全部自動的，有問題的時候會停留在具體工單上面，運(yùn)維人員會做這一塊的重試或者查看工單詳情，看哪一塊出了問題。

集成發(fā)布系統(tǒng)

對于運(yùn)維開發(fā)還有一塊需要關(guān)注的是集成發(fā)布系統(tǒng)。集成發(fā)布系統(tǒng)的功能就是把代碼部署到線上服務(wù)器。

當(dāng)我們把一個應(yīng)用包編譯打包完成以后，需要將這個應(yīng)用包發(fā)布到具體的服務(wù)器，再到應(yīng)用部署發(fā)布完成，經(jīng)過以下幾個步驟：

首先檢查一下環(huán)境完整不完整，發(fā)布系統(tǒng)檢測一下目前機(jī)器上面的部署環(huán)境是否完整。確認(rèn)部署環(huán)境沒有問題后，發(fā)布系統(tǒng)把應(yīng)用包同步到對應(yīng)的服務(wù)器上面。

接下來通過監(jiān)控系統(tǒng)接口關(guān)閉相應(yīng)服務(wù)器上監(jiān)控項；接下來執(zhí)行應(yīng)用目錄下的應(yīng)用啟停腳本，通知 RPC 調(diào)用方或 Web 代理該服務(wù)器即將下線。

暫停一定時間后，再執(zhí)行應(yīng)用啟停腳本中停止指令，停掉 Nginx 和 Web 容器；確認(rèn)應(yīng)用服務(wù)停止后，將應(yīng)用包同步到運(yùn)行目錄里面解壓、啟動應(yīng)用。

啟動應(yīng)用時如何知道應(yīng)用是否啟動成功了呢？通過我們前面定義的，每個應(yīng)用里面上線必須要遵循的規(guī)則自檢的程序來判斷（發(fā)請求/status 檢測）。

如果請求返回 SUCCESS 時，則說明應(yīng)用啟動成功了，否則認(rèn)為失??；確認(rèn)成功后，通知 RPC 調(diào)用方和 WE 代理該服務(wù)器可以正常服務(wù)了。

監(jiān)控系統(tǒng)

還有一塊是監(jiān)控系統(tǒng)，當(dāng)我們應(yīng)用上線完了，應(yīng)用都啟動成功了，把應(yīng)用服務(wù)器狀態(tài)調(diào)整成 Online，這樣可以把監(jiān)控系統(tǒng)自動觸發(fā)針對該應(yīng)用進(jìn)行監(jiān)控。

我們會根據(jù)部署類型，部署不同類型、定義不同的監(jiān)控模板，當(dāng)然業(yè)務(wù)方也可以自定義監(jiān)控項。

全鏈路跟蹤分析

當(dāng)從原來一個單一的應(yīng)用演變成多個應(yīng)用，應(yīng)用之間的業(yè)務(wù)依賴關(guān)系如何進(jìn)行管理，針對這塊需求，我們跟穩(wěn)定性團(tuán)隊共同開發(fā)了一套“全鏈路跟蹤分析系統(tǒng)”。

在我們流量的入口把全鏈路的功能模塊嵌入進(jìn)去，要求所有標(biāo)準(zhǔn)化的應(yīng)用都引用了全鏈路的二方包，流量入口到底端構(gòu)成了整個鏈路，通過這個鏈路分析對應(yīng)的應(yīng)用依賴關(guān)系。

在全鏈路跟蹤分析系統(tǒng)中，可以看到應(yīng)用自身提供的服務(wù)和依賴的服務(wù)，以及各個服務(wù)后端依賴的鏈路。

當(dāng)我們出現(xiàn)問題的時候，在這個系統(tǒng)里面直觀地可以定位到哪一個業(yè)務(wù)出了問題和哪個服務(wù)出了問題。

除了應(yīng)用整體的依賴關(guān)系以外，還可以根據(jù)具體的鏈路分析出來整條鏈路上下游依賴關(guān)系。

這條鏈路的這個請求進(jìn)來以后依次經(jīng)過哪些系統(tǒng)，而且系統(tǒng)與系統(tǒng)的調(diào)用關(guān)系是多少，在全鏈路分析系統(tǒng)里面我們都可以看得到。全鏈路分析系統(tǒng)是我們運(yùn)維這邊比較重要的一個定位排查的系統(tǒng)。

運(yùn)維一站式管理平臺

我們前期做了很多運(yùn)維系統(tǒng)，如應(yīng)用管理的、域名管理的、服務(wù)器管理等，涉及到各個運(yùn)維資源管理。

但這種分系統(tǒng)部署管理會給業(yè)務(wù)開發(fā)帶來問題，查詢一個信息時，需要在不同的系統(tǒng)之間進(jìn)行切換去察看相應(yīng)的信息，這對開發(fā)來說是比較痛苦的。

因此我們目前正在做一站式的運(yùn)維管理平臺，希望以業(yè)務(wù)的維度把所有的運(yùn)維資源都展示在一起，并結(jié)合相應(yīng)的運(yùn)維工。

這一套系統(tǒng)里面分成兩塊：

第一塊是部門維度的信息，我們基于部門可以看這個部門下面所有的業(yè)務(wù)有哪些業(yè)務(wù)以及相應(yīng)的人員，除此之外還可以看到這個部門消耗的資源有哪些。

旁邊這一塊有服務(wù)器利用率統(tǒng)計，里面可以看到整個資源的消耗，這個部門下面有多少個業(yè)務(wù)，每個業(yè)務(wù)消耗的服務(wù)器資源有哪些、利用率是多少。

第二塊應(yīng)用的詳細(xì)信息，應(yīng)用里面會把所有應(yīng)用相關(guān)的資源都定義好，在這里面展示出來。

我們可以在這個平臺里面綜合的看到這個業(yè)務(wù)整體的情況，目標(biāo)是想打造一套 NOOPS 運(yùn)維平臺，當(dāng)然這是基于穩(wěn)定性和安全的情況下，把運(yùn)維操作讓業(yè)務(wù)同學(xué)自主的去完成的，不需要運(yùn)維同學(xué)過多參與，提高開發(fā)的工作效率。

我們的目標(biāo)是 NOOPS，目前正在路上，謝謝大家！

作者：白海強(qiáng)（花名：普智）

簡介：目前在蘑菇街平臺技術(shù)部從事應(yīng)用運(yùn)維體系和其它建設(shè)工作，與團(tuán)隊一起推進(jìn)業(yè)務(wù)應(yīng)用運(yùn)維標(biāo)準(zhǔn)化及自動化系統(tǒng)的建設(shè)。在加入蘑菇街之前在淘寶任職，負(fù)責(zé)淘寶商品詳情等業(yè)務(wù)的運(yùn)維工作。