作者介紹

戰學超，青島航空運維經理、高階架構師。曾任職於NEC軟體、海爾B2B平臺鉅商匯，負責企業資料平臺構建、B2B電商平臺數據管理與搭建、企業運維管理平臺搭建。擁有豐富DBA、系統運維架構經驗，熟悉運維管理、資料庫架構、資料平臺搭建、虛擬化、私有云部署、自動化運維等。

我今天要跟大家分享的主題是《中小企業運維管理平臺架構》，這是結合我們青島航空在做運維管理和運營管理平臺時的一些經驗和問題，希望能夠對大家有一定的幫助。

分享大綱：

1. 運維管理思路

2. 運維管理平臺架構

3. 未來展望

一、運維管理思路

在運維的初期，我們更多的是一個救火隊長的角色，每天數不盡的更新發布和問題修改，運維人員每天的工作都很飽和，壓力也很大，是一個比較疲憊的過程。後面我們經過了一個梳理運維流程和整理的步驟，逐漸實現了運維的標準化和流程化，結束運維初期相對混亂的狀態。

在做運維標準化流程化的過程中，最初也會利用指令碼或者程式碼、工具來實現運維自動化的工作，大大減少運維的重複性工作，提高運維的效率；也會結合我們在運維標準化、流程化、自動化中積攢的一些資料，結合自身運維的經驗和一些機器學習演算法，去完成一些智慧化相關的工作。

運維的三大主題是監控、安全和災備，這是圍繞運維的基礎資料來做的，以保證運維基礎資料的穩定。運維週期是從需求開發調研開始的，從開發到測試到上線，這中間借鑑了一些DevOps的思想，也包含了運維人員、測試人員共同維護我們的業務系統，保證業務系統的穩定。

我們做運維管理的時候，始終堅持安全、穩定和高效三個原則，拋棄了這三個原則，之前所做的不管是標準化、流程化，都將為零。通過做運維管理，我們的目的是提高運維質量，降低運維成本。以上就是做運維管理的思路。

二、運維管理平臺架構

下面我將從總體架構、標準化、流程化、基礎資料、監控管理體系、安全、災備管理體系、自動化以及其它一些方面進行簡單分享。

1、總體架構

從下往上，我們首先通過虛擬化、容器化實現了相對基礎的類IaaS平臺，這樣在做上層運維工作時，可以相對少地去關注底層資源。接下來是基礎資料的梳理，基礎資料決定了運維的工作物件和範圍，上層所運作的所有的工作都緊緊圍繞運維基礎資料來的。我們在梳理和整理基礎運維資料的時候，順便完成了運維的標準化和流程化的制定以及實施落地。

基礎資料之上是監控、安全和災備三個管理體系，圍繞基礎資料對運維的基礎資料提供保駕護航。再上面是運維自動化，通過運維自動化將固化的運維工作和流程做了一些自動化的開發，減少了運維重複性的工作，提高了運維效率。隨著運維自動化的發展演變出了一定的問題，例如自動化指令碼越來越多、越來越難管理，我們用的自動化工序也非常多，這時急需一個統一的運維管理平臺，幫助去對去做統一的管理，這是我們運維管理平臺的情況。

我們的運維管理平臺主要是包含使用者管理、專案管理、資料中心和創新管理這一塊的功能。其中運維管理是以專案為基本單位的，所以說下邊做的這種運維自動化和運維標準化的東西是都涵蓋專案管理的。資料中心主要跟基礎資料做一些緊密的結合，為我們做智慧化運維提供基礎資料的支援。創新管理這塊其實主要是想通過創新性的管理來不斷的推進內部的運維技術進步，不斷去嘗試一些相對比較新、比較高效的技術。這是我們的實際工作情況。

2、標準化與流程化

標準化和流程化主要是通過文件的方式梳理以往的一些工作，進行一些文件性的整理，包括資料中心的建設。對於資料中心，我們是有自建的機房的，包括搬遷新機場後的新機房建設(青島19年膠東新機場建立完成，航空公司要進行搬遷)，新機房建設是圍繞國家標準和地方性的標準來進行建立和建設的。然後硬體裝置採購和上下架，這些是硬體相關的東西。

接下來是一個故障排故流程和運維通告，這個幫助運維出現運維故障時，提供一個解決的方式和通報流程。

上面兩行是伺服器的申請、伺服器的部署（包括配置變更等），還有許可權管理。運維服務的申請到運維服務的部署，包括應用的部署等主要是通過這樣一些文件和流程來規範我們日常的運維工作。標準統一了，我們做運維時就相對容易很多。

3、基礎資料管理

• CMDB

這裡分為幾大部分。首先是CMDB，這個跟傳統的ITIL有一些不同的地方，我們的CMDB以產品線為主線，每個產品線下包含很多專案，而每個專案裡也有很多的服務，每個服務會有不同的應用在上面跑。這些服務，或者說這些應用，都跑在我們的虛擬機器或者容器上，而這些虛擬機器和容器又分佈在不同的物理機上，到了物理機這一層也就到了資產管理這塊。

資產管理這塊主要是我們的一些硬體，包括網路裝置和物理機等。通過產品線和生產管理，把日常運維的一些物件去做定義，另外我們也把專案和專案之間的依賴關係，包括物理硬體之間的依賴關係都做了統一的梳理，這樣的話，當某一個節點出現問題時，對它所帶來的影響會有一個比較全面的認識。

供應商環節，因為我們屬於民航業，有一些供應商涉及得比較多，所以把供應商單獨拿出來做管理，主要是供應商的一些資訊和合同。這樣做的好處便是，當問題比較難以解決時，通過統一的供應商管理，可以快速查到對應的供應商資訊。

• 重要資料和日誌

重要資料主要是針對我們的資料庫的資料。日誌也不用多說，是很重要的資訊，包括系統日誌應用日誌、資料庫日誌、裝置日誌包括硬體裝置的日誌，目前我們在逐步完善硬體裝置的日誌，因為它要對接很多不同的協議，相對複雜。

• 知識庫

知識庫主要是事件庫和問題庫，事件庫記錄了日常所做的運維事件，當運維事件短時間內無法解決，需要通過開發做一些變更時，我們便將這個事件升級為問題，並通過問題庫來跟蹤運維事件變更所帶來的具體進展情況。經典案例庫和解決方案庫主要是對於運維遇到的一些經典問題的解決方法，包括系統的經典的部署方法、解決方案等，我們都做了一些統一的記錄或儲存，當有新的系統要部署時，也是可以通過這樣查閱解決方案以及經典案例，快速得到部署的方法。文件庫主要是儲存了我們在標準化和流程化時做的一些文件，去做一些儲存，其中也有一些版本是管理相關的東西。這是運維的基礎資料。

接下來是安全、災備、管理三個主題講一下。

4、監控管理體系

首先是監控。監控的目標是通過內外部的多套監控去實現一個相對立體化的監控體系，根據系統的優先順序將所有的系統和我們的硬體去做一個監控。另外就是監控的維度，首先第一個維度是覆蓋所有系統和軟硬體；其次是監控維度，包括應用系統可用性，資料庫執行狀態，網路狀況等；第三個維度是全部時間，主要是我們會對監控的歷史資料做一個儲存，包括過去一些系統或者是伺服器資訊的狀態和當前的狀態。這裡其實也是為我們做智慧化運維提供了一些歷史性的資料。

下面列舉一下我們當前監控的一個情況。首先是機房和硬體的監控，機房監控我們主要依賴在機房建立初期供應商提供的機房環境監控系統進行監控。硬體監控的話，我們採購不同的硬體都有各自的監控方式，我們也做一些整合和整理，爭取形成統一的硬體監控。虛擬機器和容器監控主要是監控虛擬機器或容器的狀態和可能性等。網路監控主要是用以監控網路執行狀態。這裡也會有系統、資料庫以及一些應用和業務的監控。監控用到的工具主要是一些開源的工具，其中Lepus是監控資料庫，Zabbix監控我們的作業系統等，我們也會根據實際情況去開發我們自己的監控指令碼。通過多種監控方式和工具多維度監控我們的運維物件，這是監控體系的情況。

5、安全、災備管理體系

安全和災備是比較難以分割的兩個主題，我們的災備方案也是為了系統或資料安全不丟失。

• 災備管理

大概的思路，首先是兩地三中心+雲這樣的經典方式，搭建同城的實時同步，異地延遲同步的方式作為我們災備方案的主體，當然我們也將一些資料不太敏感的資源、備份資料逐漸放到雲上進行備份。

災備管理的手段主要是高可用+備份，對每一個系統和物理硬體都做一些高可用的方案，去避免單點故障。另外在做高可用的同時也建立備份機制，包括資料備份、檔案備份、底層虛擬機器和容器備份等，這樣既有高可用也有備份，最大強度保證了系統的可用性。

此外，這個備份也要有一套獨立的備份方案驗證模組，是為了驗證我們之前所做的這些備份的可用性和準確性。因為如果沒有定時驗證備份是否可用的話，當真出現故障時，我們可能不太敢直接把這種備份用到生產上去。

最後還有一個應急預案管理，這個主要是緩解一些災難性故障時的應急措施，這樣做的好處就是當出現重大問題，且短時間難以恢復，包括備份不太可用時，我們會按照應急預案進行處理。應急預案也會有定期演練的過程，以此保證應急預案和實際情況的結合。

• 安全管理體系

安全管理是一個比較大的主題，這裡簡單說一下我們的體系思路。首先是安全依據，主要有法律法規、行業背景和公司需求，包括《網路安全法》，民航也有自身的網路安全管理體系。根據這些依據去制定安全策略，同時依賴於安全技術幫我們做一些安全操作，這樣可通過安全策略、安全管理、安全技術、安全操作來保證我們的安全性。具體落地方面，我們主要有防火牆、IPS、WAF等安全裝置。

著重介紹一下我們的UMS賬戶管理模組，很多系統是公司內部人員使用的，比如當人員離職時，首先在OA體現出來，如果管理人沒有及時關注這個人員，極有可能他離職了，這個賬戶還存在的。但通過UMS這個模組跟OA系統打通，人員離職時對他業務系統的帳號做及時的清理，保證了賬號隨同人員離職一起銷燬，避免資料洩露的。

6、運維自動化

首先是關於伺服器的申請、作業系統的安裝、服務申請，然後服務自動部署等。接著去做一些釋出，釋出的申請、變更的申請等，這些都是大家在做運維自動化的時候幾乎都會去做或是實現的工作。除此之外，這裡著重跟大家介紹一下我們的一個關於資源申請評估指導和資源利用報告的情況。

我們的資源申請評估指導主要結合了自身經驗，根據系統的行業請求和系統情況來以及壓力測試的結果參考等制定了一個相對比較科學的資源申請情況。當有一個新的需求要去申請我們資源時，我們會根據資源申請評估指導裡面的演算法，預估出他的系統變化量，自動計算出一個比較科學的硬體資源。資源利用報告呢，是我們定期對所有的伺服器（包括虛擬機器）所做的一個資源利用的情況，這樣根據我們的資源利用報告去做一些伺服器的資源性變化和處理，確保我們的硬體資源是最大的利用率。

另外，我們做運維自動化時，也包括了我們架構的自動診斷、壓力測試、自動巡檢和故障自動診斷等功能。

說一下架構自動診斷，不知道大家有沒有這樣的情況，公司裡經常遇到上線比較著急的一些系統，但是上線運營一段時間以後，跟開發人員一溝通，發現這是很重要的系統，可當時上線比較匆忙沒有做任何高可用方案，如果沒有及時溝通，很可能這個重要的系統一直在單節點執行。為了規避這種情況，我們的架構自動診斷是通過開發人員可能在申請新的系統上線時，會做系統等級的填寫，這個架構自動診斷會根據系統的等級，結合系統線上的情況，如果缺少備份和只是單節點，它會自動提醒，讓我們的運維人員及時搭建架構，避免重要系統的單點故障。

截止到目前，平心而論，我們現在的運維自動化是處於一個尷尬狀態，因為之前花了大量的時間，研究了大量的工具，包括寫了大量的指令碼實現運維自動化，但結合Docker容器化時，我們發現指令碼、伺服器的安裝和服務部署（包括一些釋出）等會有比較大的顛覆。當我再去建一個容器時，我直接從私有倉庫中拉取，釋出時也是映象更新，並不是我們之前所做的去寫一些指令碼，或者去做一些釋出。結合現狀，我們現在在逐漸結合Docker，包括之前做的運維自動化工作，逐漸改變運維自動化的情況。

7、其它

經過了標準化、流程化，包括自動化之後，我們已經積攢了很多自動化的指令碼等，管理起來相對複雜，東西也比較多。這時我們需要一個自身的運維管理平臺來去做統一的管理。

目前我們的運維管理平臺大致包括四個功能：

1. 資料管理：資料管理主要是組織使用者許可權和績效考核的功能。
2. 專案管理：即運維管理，運維管理以專案管理為單位工作，跟開發工作相結合。我們公司在逐漸推進以專案為單位定義運維工作並且與開發專案管理結合起來共用一套系統，這樣我們運維的專案週期以開發的需求分析為起點，可加深我們運維對系統的理解，也會更好地幫助運維人員做線上的運維和運營工作。
3. 資料中心：工作也好專案也好，實際上都通過資料的方式進行展示和分析，我們力圖通過用資料衡量運維的質量情況，後面我們也會逐漸利用資料中心為我們的自動化運維做一些改變。
4. 創新管理：主要還是想以創新驅動技術進步，提高運維質量，比如我們在運維管理中逐步實現Docker容器化的操作，去做一些智慧化運維的實踐，以此幫助我們做一些運維工作和技能的提高。

三、未來展望

首先是DevOps、SRE。我們將聯合業務、開發、測試、運維共同推進DevOps的進步，因為我們是相對傳統的行業，很難立即全面推動DevOps或SRE這一步，還是需要一個循序漸進的過程。

第二步是智慧化運維，我們目前做的主要是一些故障的自動處理，例如像一些日誌空間的自動釋放、常見問題的自動處理等，這是相對初步的實踐。

接下來我們也會結合自身運維的實際情況，對內部做一些智慧化運維的技術性研究，但智慧化運維對業務人員的技術要求是比較高的，而青島招人又很難，怎麼辦？其實我們做DevOps時，已經跟開發、測試建立了一個相對比較好的關係，所以我們可以依賴於開發來做一些技術性的指導，結合自身的運維經驗來逐漸推進智慧化運維的一些工作。

然後私有云和混合雲這一塊，我們之前已經實現了虛擬化和容器化，接下來我們將逐漸利用OpenStack或K8s完成私有云相關的架構和操作，爭取通過雲服務降低我們的IT成本。

最後Serverless，不知道我的理解跟大家的是不是一樣，我們的實踐是將內部現在大概十多套的系統使用者管理模組去做一個服務的統一抽取，當再有一個新的系統要上線時，我們不需要再去單獨開發這樣一套使用者管理系統，而是直接接到這套使用者管理系統的使用者管理這樣一個平臺上，也是提高了一定的程度。通過構建多套系統的公用模組進行函式開發，實現系統直接呼叫。這跟微服務似乎有點相似。

運維這幾年的發展其實有很多的技術不斷的融進，我們始終堅持著安全、穩定和高效三大原則，沒有這三大原則我們上面做的所有的操作全都是零。這是我今天的分享，謝謝大家！

Q&A

Q1：總體架構設計時用了哪些開發工具，用的都是開源的嗎？

A1：目前很多都是開源的，除了有幾套應用是跑在Weblogic，我們大部分是Tomcat，我們目前也在將一些商用的Weblogic、Oracle等遷移至開源替代產品中去，降低IT成本。資料庫主要以MySQL和Oracle為主，Oracle主要是核心的系統在用。至於像我們這種監控和管理，也是開源性的工具多，例如監控主要是Zabbix和自定義指令碼進行監控。安全這一塊的話，相對比較多的是一些商業產品，例如我們的防火牆或者WAF應用防火牆，安全方面主要還是以商業產品為主。開源的安全產品，我們目前也在測試，但由於團隊的技術所限，沒有太大的精力去研究開源的安全產品也沒有決心去生產使用。

大概的簡圖如下：

注：統一任務排程使用tbschedule，訊息佇列使用ActiveMQ，分散式檔案伺服器使用的fastDFS。接下來我會寫單獨一篇文章詳細介紹我們的系統架構，敬請期待。

Q2：你們現在用K8s用到什麼程度了，多大規模？

A2：K8S我們目前正在技術研究和測試階段，主要在測試環境進行了一些試用。K8S還是Mesos來管理編排我們的容器，目前都在測試中。

其實今天也是想聽一下大家對於Docker結合當前的情況做一些溝通。談到Docker大家可能會有一個疑問，用了Docker之後會不會把之前的虛擬化拋棄掉？我們公司目前做的虛擬化是拋棄不掉的，因為我們有一些服務、應用部署在Windows伺服器上，包括我們的Oracle架構也是在這上面。到目前為止還沒有聽說有公司在Docker跑RAC的一些架構。所以未來相對比較長的時間，我們公司還是虛擬化和容器化是並存的情況，算是一個逐漸轉型吧。回頭Docker生產叢集搭建完畢，投入使用一段時間後，再跟大家做詳細的分享。

Q3：請問你們在Docker上的總體驅動、整個場景規劃，用K8s都做的話可能有一些缺點，所以你們整個集團是如何在調研K8s落地的？目前大家都想用K8s，但真的技術落地時，確實很多困難。

A3：說到k8s這塊，生產中並沒有做k8s的推廣和實踐，剛剛也說了我們目前正在進行技術調研。由於我們在青島新機場會開一個新的資料中心，以此為契機，進行容器化技術和叢集的研究和實踐，爭取在新資料中心實現內部高效的運維服務，通過新技術降低成本。這裡也希望有生產經驗的同學能夠多分享一下生產的經驗，我們好提前學習。

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