作者介紹

白海強（花名：普智），目前在蘑菇街平臺技術部從事應用運維體系和其它建設工作，與團隊一起推進業務應用運維標準化及自動化系統的建設。在加入蘑菇街之前在淘寶任職，負責淘寶商品詳情等業務的運維工作。

演講大綱：

1. 蘑菇街技術架構及運維演進
2. 應用運維體系建設思路
3. 應用運維自動化實踐過程

蘑菇街技術架構及運維演進

導購期（2011-2012）

2011年蘑菇街上線時，它的主要業務是分享社群，就是買家買了商品以後，把這個商品分享出來給大家。2012年開始轉型商品導購，早期業務比較簡單，相對裝置比較少，基本上是一套業務程式碼。運維都是由具體的開發同學自己去管理的，根本不需要專業的運維人員。

社交化電商（2015-至今）

2015年整個業務開始發生變化了，集團開始從原來的PHP開發，逐步轉向了Java開發，從原來主站一套單一業務套程式碼拆分成各個子業務系統，整個架構發生改變。流量入口我們分成兩塊，無線端和PC端二塊接入。MWP為無線閘道器。其他PC端的流量通過代理層分發到各個不同的子業務系統，部分系統實現前後端分離服務化，最底層為資料層。從原來業務再新加業務需求，逐漸演變成擁有目前1300多個應用系統。

業務快速發展對我們運維帶來的挑戰：

第一：1300多個應用如何進行管理，這是一個大的問題。不同業務如何區分？業務肯定要部署在具體伺服器上面，不同業務部署不同伺服器，業務和伺服器之間的對應關係如何管理？還有業務部署環境，不同的業務執行的環境有可能存在差異的，所以我們需要把業務與環境之間的對應關係也要管理起來。

第二：早期業務之間可以依賴簡單應用程式碼之間內部的呼叫，拆分演變成應用與應用之間的依賴關係，如何管理業務之間的上下游依賴？如何快速定位排查問題？這對我們排查工具帶來了挑戰和要求。

我們帶著這些問題看一下運維體系建設的思路。

應用運維體系建設思路

運維核心理念

運維工作圍繞這四個主題展開的：

• 穩定性。保證業務穩定快速地發展；
• 成本。成本涉及到兩塊：人力成本和系統資源成本，我們期望以最小的成本創造最大生產價值；
• 效率。運維工作自動化，提高工作效率，減少成本；
• 安全。

我們日常運維工作都是圍繞這四塊展開的，系統建設的時候也是圍繞這四個主題展示；這四塊主題優先等級我個人認為是：安全第一，如果系統存在安全問題，那肯定是第一時間處理；其次是穩定性、成本、效率。以上個人對運維的理解。

應用運維繫統架構

基於運維需求，我們逐步建設起目前的運維體系的架構。從最底層看，第一層基礎的硬體環境，如IDC/伺服器/網路設務。第二層為業務需要的底層基礎服務，如DNS、NTP、YUM源、LVS等；第三層針對這些系統資源管理平臺，虛擬化平臺，DNS管理系統等。上面三層針對業務的，有我們應用管理系統、伺服器管理系統、DBMS等；還有常用的系統，像釋出系統、部署系統之類的。最頂層是開放給業務開發使用的統一運維平臺。這些系統並不是說在我們建設當中一下就能建設好的，而是根據我們日常操作當中運維的需要逐步搭建而成。

應用標準化規範-思路

如果一個系統業務要接入進來，第一步要做的是標準化。按照我們規範進行改造，符合我們要求才能接入進來。不然1300多個應用沒有一個統一接入標準，讓我們去做適配打造運維相關的系統，那是不可能的。我們總體的思路，先標準、後接入，只有按標準改造了，業務開發才能方便地使用我們的運維繫統。

應用標準化規範-範圍

標準化到底要做哪些事情呢？主要分成三塊：

• 基礎環境。基礎環境裡面規範有哪些呢？我們可以分為兩塊：硬體、軟體。硬體我們規範了使用的伺服器硬體配置規格，目前虛擬機器規格分成三類：2核4G記憶體的，4核8G記憶體的，8核16G記憶體的；目前要求都使用的是虛擬機器。軟體方面我們主要規範部署需要的軟體的版本、管理方式和部署目錄；

• 應用配置。這裡規範了應用部署目錄、應用包名和應用配置等。

• 技術架構。規範了業務對基礎元件使用姿勢，如流量接入層、ZK、Kafka等。

應用標準化規範-內容

接下來看一下具體的標準化定義內容。整個運維標準化體系是我們運維部牽頭搞的。主要是剛才講到的內容，定義了具體我們使用的應用和基礎服務的接入、目錄的規範。旁邊可以看一下應用的管理規範，詳細定義應用名命名規範、應用包名規範、應用目錄、部署目錄等內容，形成檔案，在整個集團各個部門裡面傳達執行。

應用標準化規範文件-例項

我們按照開發語言不同，應用服務對伺服器的部署環境要求也不同；我們先後制定Java版、PHP版、GO版和Node.js版等。每個版本的規範裡面都基本上定義了這些內容：

第一：目錄：基礎軟體部署目錄和版本要求；

第二：應用執行的使用者賬號是什麼、許可權是什麼。

應用標準化規範文件-例項說明

（1）應用啟停指令碼

接下來我們還規範了啟停指令碼，還定義了這個腳本里面傳的引數，可以支援哪些引數，啟動或者重啟。每條指令裡面做什麼事情都進行了說明和規範。

（2）規範應用上線標準

除此之外還定義了一個業務上線之前要遵循的標準，上線的標準和下線的標準。上線之前需要業務方提供標準的自檢功能，要怎麼知道你這個應用是成功還是失敗的，那肯定需要有一個檢測機制告訴我，腳本里面通過這個檢測機制知道這個業務到底是否正常，這是一個強制性的規範。下線也是一樣，上流根據定時檢測指定這個URL，根據訪問結果判斷是否把流量自動地切掉。

標準化文件裡面主要就是規範上述一些內容。這些內容為後面的運維繫統做了規範。我們運維繫統都是基於這個規範來做。

應用運維自動化實踐過程

應用運維核心概念

1300多個應用如何管理？在介紹應用管理之前需要重點介紹一下這幾個概念，這作為蘑菇街應用運維核心概念。

第一：應用名代表在蘑菇街應用系統中具體業務功能，不同的應用名用於區分不同的業務，我們按照一套業務程式碼進行劃分。

第二：應用名分組是管理伺服器的，用來組織管理伺服器的。

兩者之間的關係是什麼？一個應用下面可以對應多個應用分組；這個分組按照什麼維度來劃分的呢？可以根據環境，也可以根據穩定性的要求來拆分的。應用名作為應用運維的核心，運維繫統都以應用名作為資源的組織方式。

應用管理系統

系統裡面主要管哪些內容呢？其中一塊用於管理業務、部門、人員三者之間的關係。

可以看一下這個圖，像這個業務是屬於哪一個部門的，開發者是誰，程式碼review是誰，這個裡面都會維護好。除此之外還會定義這個應用的部署特徵，這個應用部署型別是什麼，這個比較關鍵。後期的運維繫統我們會拿著部署特徵資訊後面做判斷應用於具體操作。應用管理系統中定義裡面每一個欄位在後面運維繫統裡面都會存在一定關聯。

伺服器管理

接下來伺服器管理也有單獨的系統，伺服器管理系統前面說了，分組是作為管理伺服器的，在這一層可以看一下我們整個層次結構分成兩層：部門下面是具體的應用，應用下面是分組。應用分組預設有三個組：DEV代表線下測試環境，PRE代表預發環境，ONLINE代表生產環境。我們在分組上面建立了不同環境的標識；釋出系統或其他運維繫統就可以根據需求按應用的緯度獲取不同環境的機器列表。

同一個應用目前我們只分了三套環境：測試環境、預發環境和線上環境，一般預設對應3個應用分組；但有時基於穩定性考慮，會把線上環境的伺服器拆分成多個應用分組。假如某個應用是為其他應用業務提供基礎服務的；如果呼叫服務不隔離管理的話，很容易出現穩定性的問題，如非核心業務呼叫量過大，導致核心業務呼叫失敗或超時，基於上述問題，我們很容易想到解決方案就是把服務拆分成不同服務叢集，讓核心業務呼叫1個服務叢集，讓非核心業務呼叫另外一個叢集。這個需求RPC服務管理控制檯都可以實現IP與服務關係繫結；根據依賴業務重要程度區分出不同的服務叢集，再根據不同叢集呼叫量需求將伺服器劃到不同的應用分組中進行管理，這個拆分分組是比較好的一個解決方案；

既然RPC這邊已經把服務邏輯分組，那伺服器管理系統中是不是可以不用區分了，伺服器放在同一個應用分組下進行管理，這樣不是更簡單嗎？

不拆分出應用分組，對於業務訪問是沒有影響的，因為應用分組的作用只是管理伺服器，不會影響線上正常訪問；但是運維繫統是不知道應用業務內部邏輯訪問分組是什麼樣，那些機器屬於同一個服務叢集，操作時需要必須一起操作；如果同一個叢集一起操作的話，那線上的服務就掛完了；所以必須把這個體現出來，管理起來；

應用分組這個管理方式是比較靈活的，可以根據不同業務的特徵建立不同的分組。比如說機房緯度、地域緯度等。分組可以理解為是一個叢集的概念，同一個應用分組下提供服務和服務物件都是相同的。這是伺服器管理這一塊。

應用部署型別模板管理

同一類開發語言開發出來的業務應用對於部署環境依賴大致都是相同的。基於這個特徵，我們基於應用部署型別制定應用部署模板，用於管理同類應用部署伺服器環境的需求。我們基於不同部署型別建立對應的應用部署模板，如Java版、C++、GO等。在這個模板裡面我們定義了：部署的軟體和常規配置檔案等內容。舉個例子，Java開發業應用，一般部署伺服器環境所需要的包括一個JDK，容器我們使用Tomcat，Nginx作為Web代理伺服器；除此之外，我們還有可能需要啟停指令碼和配置檔案，用於保證環境正常執行。

應用基線管理

部署模板的用途用是什麼呢？它主要為應用基線提供服務的。應用基線我們建立的維度按照應用分組維度建立的。

應用基線建立的維度我們是按照應用分組維度來建立的。一般情況下應用基線部署的內容配置都是從部署模板裡面導過來的，基本上都能滿足相應的應用部署環境的需要；當個別應用需要個性化的環境配置或軟體時，我們就可以針對相應的應用分組的應用基線進行修改補充，已滿足業務方的需求；

應用基線產生時間點是在應用申請流程結束後，根據應用申請時選擇的部署型別自動地把應用模板相應配置資訊匯入到該應用下的所有應用分組下面。

應用部署系統

通過前面幾個系統，我們基本上把環境、應用都管理起來了。但如何實現環境的自動化部署？我們建立了應用的部署系統，應用部署系統裡面定義什麼呢？就是我們定義了部署環境的執行步驟。

如第一步，部署安裝軟體；第二步配置檔案；第三步初始化等等。根據我們應用的部署型別建立不同的部署需要執行的步驟，按照定義執行步聚能完整地構建起一個應用的執行環境。

運維工單管理

最後缺一個觸發的場景，能把上面各個相關係統串聯起來的系統。像申請伺服器、擴容，新應用申請，因為這些都是業務開發提出了需求，如何組織在一起，跟我們的環境部署系統組織在一起呢？通過運維工單的方式，需要業務開發提相應的工單，根據不同的工單把我們前面運維的步驟總的綜合在一起。

目前我們工單的範圍比較多，覆蓋了我們運維當中常見的一些運維需求，像伺服器申請、新應用申請之類的。這些步驟裡面，每個工單裡面都包含兩部分：第一部分是流程審批，因為有的人很反對流程，但流程是為了保證穩定性的手段而已。還有一部分是我們的工單，具體做的事情。工單系統裡面是這兩部分組成。

應用運維自動化實現總結

接下來說一下整個過程，當運維開發提交一個工單給我們的時候，假設新應用申請，從新應用裡面根據這個應用裡面定義的內容獲取應用的配置資訊。應用的稽核人員是誰，根據這個稽核人員審批流程通過以後，會獲取對應系統裡面部署的機器列表，根據部署列表拿到以後，把資料傳給應用部署系統裡面部署環境。部署環境裡面，部署哪些軟體、同步哪些配置檔案，這些資料從哪取？從應用基線裡面取。應用基線裡面如果是空的，就從應用模板裡面獲取。當環境部署完成以後或者出了異常以後把具體資訊返回給工單系統，工單系統可以做一次重試任務或者結單。

（1）應用運維自動化實現-工單例項

這邊是具體使用的工單例項場景——新應用申請。有流程審批，流程審批結束以後，運維繫統裡面做的第一步，應用的基本資訊插入到應用管理系統裡面，同時裝置管理系統裡面自動的建立分組，分配機器。機器分配完以後去部署環境，同時新增相應責任人的許可權。這幾個步驟基本上都是全部自動的。有問題的時候會停留在具體工單上面，運維人員會做這一塊的重試或者檢視工單詳情，看哪一塊出了問題。

（2）整合釋出系統

對於運維開發還有一塊需要關注的是整合釋出系統。整合釋出系統的功能就是把程式碼部署到線上伺服器。當我們把一個應用包編譯打包完成以後，需要將這個應用包釋出到具體的伺服器到應用部署釋出完成經過以下幾個步驟：

首先檢查一下環境完整不完整，釋出系統檢測一下目前機器上面的部署環境是否完整。確認部署環境沒有問題後，釋出系統把應用包同步到對應的伺服器上面；接下來通過監控系統介面關閉相應伺服器上監控項；接下來執行應用目錄下的應用啟停指令碼，通知RPC呼叫方或Web代理該伺服器即將下線；暫停一定時間後，再執行應用啟停指令碼中停止指令，停掉Nginx和Web容器；確認應用服務停止後，將應用包同步到執行目錄裡面解壓、啟動應用。

啟動應用時如何知道應用是否啟動成功了呢？通過我們前面定義的，每個應用裡面上線必須要遵循的規則自檢的程式來判斷（發請求/status檢測）。如果請求返回SUCCESS時，則說明應用啟動成功了，否則認為失敗；確認成功後，通知RPC呼叫方和WE代理該伺服器可以正常服務了。

（3）監控系統

還有一塊是監控系統，當我們應用上線完了應用都啟動成功了，把應用伺服器狀態調整成Online，這樣可以把監控系統自動觸發針對該應用進行監控。我們會根據部署型別，部署不同型別定義不同的監控模板，當然業務方也可以自定義監控項。

（4）全鏈路跟蹤分析

當從原來一個單一的應用演變成多個應用，之間的業務依賴關係如何進行管理，針對這塊需求，我們跟穩定性團隊共同開發了一套“全鏈路跟蹤分析系統”。在我們流量的入口把全鏈路的功能模組嵌入進去，要求所有標準化的應用都引用了全鏈路的二方包，流量入口到底端構成了整個鏈路，通過這個鏈路分析對應的應用依賴關係。

在全鏈路跟蹤分析系統中，可以看到應用自身提供的服務和依賴的服務，以及各個服務後端依賴的鏈路；當我們出現問題的時候，在這個系統裡面直觀地可以定位到哪一個業務出了問題和哪個服務出了問題。

除了應用整體的依賴關係以外，還可以根據具體的鏈路分析出來整條鏈路上下游依賴關係，這條鏈路的這個請求進來以後依次經過哪些系統，而且系統與系統的呼叫關係是多少，在全鏈路分析系統裡面我們都可以看得到。全鏈路分析系統是我們運維這邊比較重要的一個定位排查的系統。

（5）運維一站式管理平臺

我們前期做了很多運維繫統，如應用管理的、域名管理的、伺服器管理等，涉及到各個運維資源管理。但這種分系統部署管理給業務開發會帶來問題，需要一個資訊以後，需要在不同的系統之間進行切換去察看相應的資訊，這對開發來說是比較痛苦的。因此我們目前正在做一站式的運維管理平臺，希望以業務的維度把所有的運維資源都展示在一起，並結合相應的運維工。

這一套系統裡面分成兩塊：第一塊是部門維度的。我們基於部門可以看這個部門下面所有的業務有哪些業務以及相應的人員，除此之外還可以看到這個部門消耗的資源有哪些。旁邊這一塊有伺服器利用率統計裡面可以看到整個資源的消耗，這個部門下面有多少個業務，每個業務消耗的伺服器資源有哪些、利用率是多少。

第二塊應用的詳細資訊，應用裡面會把所有應用相關的資源都定義好，在這裡面展示出來。我們可以在這個平臺裡面綜合的看到這個業務整體的情況。目標是想打造一套NOOPS運維平臺，當然這是基於穩定性和安全的情況下，把運維操作讓業務同學自主的去完成的，不需要運維同學過多參與，提高開發的工作效率。

我們目標是NOOPS，目前正在路上，謝謝大家！

Q&A

1：內部Ops平臺已經成型了。我想問一下PE蘑菇街這邊的歷程，現在是怎樣的？

A1：蘑菇街前期PE主要是負責業務穩定性這一塊，資源分配、環境管理這一塊。慢慢的iPaas這個平臺上線，日常運維工作逐步減少後，以後我們PE會更多關去心使用伺服器資源使用率和成本。

文章來自微信公眾號：DBAplus社群