我今天要跟大家分享的主題是《中小企業(yè)運維管理平臺架構(gòu)》，這是結(jié)合我們青島航空在做運維管理和運營管理平臺時的一些經(jīng)驗和問題，希望能夠?qū)Υ蠹矣幸欢ǖ膸椭?/div>
分享大綱：
1.運維管理思路
2.運維管理平臺架構(gòu)
3.未來展望
一、運維管理思路
在運維的初期，我們更多的是一個救火隊長的角色，每天數(shù)不盡的更新發(fā)布和問題修改，運維人員每天的工作都很飽和，壓力也很大，是一個比較疲憊的過程。后面我們經(jīng)過了一個梳理運維流程和整理的步驟，逐漸實現(xiàn)了運維的標準化和流程化，結(jié)束運維初期相對混亂的狀態(tài)。
在做運維標準化流程化的過程中，最初也會利用腳本或者代碼、工具來實現(xiàn)運維自動化的工作，大大減少運維的重復性工作，提高運維的效率；也會結(jié)合我們在運維標準化、流程化、自動化中積攢的一些數(shù)據(jù)，結(jié)合自身運維的經(jīng)驗和一些機器學習算法，去完成一些智能化相關(guān)的工作。
運維的三大主題是監(jiān)控、安全和災備，這是圍繞運維的基礎數(shù)據(jù)來做的，以保證運維基礎數(shù)據(jù)的穩(wěn)定。運維周期是從需求開發(fā)調(diào)研開始的，從開發(fā)到測試到上線，這中間借鑒了一些DevOps的思想，也包含了運維人員、測試人員共同維護我們的業(yè)務系統(tǒng)，保證業(yè)務系統(tǒng)的穩(wěn)定。
我們做運維管理的時候，始終堅持安全、穩(wěn)定和高效三個原則，拋棄了這三個原則，之前所做的不管是標準化、流程化，都將為零。通過做運維管理，我們的目的是提高運維質(zhì)量，降低運維成本。以上就是做運維管理的思路。
二、運維管理平臺架構(gòu)
下面我將從總體架構(gòu)、標準化、流程化、基礎數(shù)據(jù)、監(jiān)控管理體系、安全、災備管理體系、自動化以及其它一些方面進行簡單分享。
1、總體架構(gòu)
從下往上，我們首先通過虛擬化、容器化實現(xiàn)了相對基礎的類IaaS平臺，這樣在做上層運維工作時，可以相對少地去關(guān)注底層資源。接下來是基礎數(shù)據(jù)的梳理，基礎數(shù)據(jù)決定了運維的工作對象和范圍，上層所運作的所有的工作都緊緊圍繞運維基礎數(shù)據(jù)來的。我們在梳理和整理基礎運維數(shù)據(jù)的時候，順便完成了運維的標準化和流程化的制定以及實施落地。
基礎數(shù)據(jù)之上是監(jiān)控、安全和災備三個管理體系，圍繞基礎數(shù)據(jù)對運維的基礎數(shù)據(jù)提供保駕護航。再上面是運維自動化，通過運維自動化將固化的運維工作和流程做了一些自動化的開發(fā)，減少了運維重復性的工作，提高了運維效率。隨著運維自動化的發(fā)展演變出了一定的問題，例如自動化腳本越來越多、越來越難管理，我們用的自動化工序也非常多，這時急需一個統(tǒng)一的運維管理平臺，幫助去對去做統(tǒng)一的管理，這是我們運維管理平臺的情況。
我們的運維管理平臺主要是包含用戶管理、項目管理、數(shù)據(jù)中心和創(chuàng)新管理這一塊的功能。其中運維管理是以項目為基本單位的，所以說下邊做的這種運維自動化和運維標準化的東西是都涵蓋項目管理的。數(shù)據(jù)中心主要跟基礎數(shù)據(jù)做一些緊密的結(jié)合，為我們做智能化運維提供基礎數(shù)據(jù)的支持。創(chuàng)新管理這塊其實主要是想通過創(chuàng)新性的管理來不斷的推進內(nèi)部的運維技術(shù)進步，不斷去嘗試一些相對比較新、比較高效的技術(shù)。這是我們的實際工作情況。
2、標準化與流程化
標準化和流程化主要是通過文檔的方式梳理以往的一些工作，進行一些文檔性的整理，包括數(shù)據(jù)中心的建設。對于數(shù)據(jù)中心，我們是有自建的機房的，包括搬遷新機場后的新機房建設(青島19年膠東新機場建立完成，航空公司要進行搬遷)，新機房建設是圍繞國家標準和地方性的標準來進行建立和建設的。然后硬件設備采購和上下架，這些是硬件相關(guān)的東西。
接下來是一個故障排故流程和運維通告，這個幫助運維出現(xiàn)運維故障時，提供一個解決的方式和通報流程。
上面兩行是服務器的申請、服務器的部署（包括配置變更等），還有權(quán)限管理。運維服務的申請到運維服務的部署，包括應用的部署等主要是通過這樣一些文檔和流程來規(guī)范我們?nèi)粘５倪\維工作。標準統(tǒng)一了，我們做運維時就相對容易很多。
3、基礎數(shù)據(jù)管理
- CMDB
這里分為幾大部分。首先是CMDB，這個跟傳統(tǒng)的ITIL有一些不同的地方，我們的CMDB以產(chǎn)品線為主線，每個產(chǎn)品線下包含很多項目，而每個項目里也有很多的服務，每個服務會有不同的應用在上面跑。這些服務，或者說這些應用，都跑在我們的虛擬機或者容器上，而這些虛擬機和容器又分布在不同的物理機上，到了物理機這一層也就到了資產(chǎn)管理這塊。
資產(chǎn)管理這塊主要是我們的一些硬件，包括網(wǎng)絡設備和物理機等。通過產(chǎn)品線和生產(chǎn)管理，把日常運維的一些對象去做定義，另外我們也把項目和項目之間的依賴關(guān)系，包括物理硬件之間的依賴關(guān)系都做了統(tǒng)一的梳理，這樣的話，當某一個節(jié)點出現(xiàn)問題時，對它所帶來的影響會有一個比較全面的認識。
供應商環(huán)節(jié)，因為我們屬于民航業(yè)，有一些供應商涉及得比較多，所以把供應商單獨拿出來做管理，主要是供應商的一些信息和合同。這樣做的好處便是，當問題比較難以解決時，通過統(tǒng)一的供應商管理，可以快速查到對應的供應商信息。
- 重要數(shù)據(jù)和日志
重要數(shù)據(jù)主要是針對我們的數(shù)據(jù)庫的數(shù)據(jù)。日志也不用多說，是很重要的信息，包括系統(tǒng)日志應用日志、數(shù)據(jù)庫日志、設備日志包括硬件設備的日志，目前我們在逐步完善硬件設備的日志，因為它要對接很多不同的協(xié)議，相對復雜。
- 知識庫
知識庫主要是事件庫和問題庫，事件庫記錄了日常所做的運維事件，當運維事件短時間內(nèi)無法解決，需要通過開發(fā)做一些變更時，我們便將這個事件升級為問題，并通過問題庫來跟蹤運維事件變更所帶來的具體進展情況。經(jīng)典案例庫和解決方案庫主要是對于運維遇到的一些經(jīng)典問題的解決方法，包括系統(tǒng)的經(jīng)典的部署方法、解決方案等，我們都做了一些統(tǒng)一的記錄或存儲，當有新的系統(tǒng)要部署時，也是可以通過這樣查閱解決方案以及經(jīng)典案例，快速得到部署的方法。文檔庫主要是存儲了我們在標準化和流程化時做的一些文檔，去做一些存儲，其中也有一些版本是管理相關(guān)的東西。這是運維的基礎數(shù)據(jù)。
接下來是安全、災備、管理三個主題講一下。
4、監(jiān)控管理體系
首先是監(jiān)控。監(jiān)控的目標是通過內(nèi)外部的多套監(jiān)控去實現(xiàn)一個相對立體化的監(jiān)控體系，根據(jù)系統(tǒng)的優(yōu)先級將所有的系統(tǒng)和我們的硬件去做一個監(jiān)控。另外就是監(jiān)控的維度，首先第一個維度是覆蓋所有系統(tǒng)和軟硬件；其次是監(jiān)控維度，包括應用系統(tǒng)可用性，數(shù)據(jù)庫運行狀態(tài)，網(wǎng)絡狀況等；第三個維度是全部時間，主要是我們會對監(jiān)控的歷史數(shù)據(jù)做一個存儲，包括過去一些系統(tǒng)或者是服務器信息的狀態(tài)和當前的狀態(tài)。這里其實也是為我們做智能化運維提供了一些歷史性的數(shù)據(jù)。
下面列舉一下我們當前監(jiān)控的一個情況。首先是機房和硬件的監(jiān)控，機房監(jiān)控我們主要依賴在機房建立初期供應商提供的機房環(huán)境監(jiān)控系統(tǒng)進行監(jiān)控。硬件監(jiān)控的話，我們采購不同的硬件都有各自的監(jiān)控方式，我們也做一些整合和整理，爭取形成統(tǒng)一的硬件監(jiān)控。虛擬機和容器監(jiān)控主要是監(jiān)控虛擬機或容器的狀態(tài)和可能性等。網(wǎng)絡監(jiān)控主要是用以監(jiān)控網(wǎng)絡運行狀態(tài)。這里也會有系統(tǒng)、數(shù)據(jù)庫以及一些應用和業(yè)務的監(jiān)控。監(jiān)控用到的工具主要是一些開源的工具，其中Lepus是監(jiān)控數(shù)據(jù)庫，Zabbix監(jiān)控我們的操作系統(tǒng)等，我們也會根據(jù)實際情況去開發(fā)我們自己的監(jiān)控腳本。通過多種監(jiān)控方式和工具多維度監(jiān)控我們的運維對象，這是監(jiān)控體系的情況。
5、安全、災備管理體系
安全和災備是比較難以分割的兩個主題，我們的災備方案也是為了系統(tǒng)或數(shù)據(jù)安全不丟失。
- 災備管理
大概的思路，首先是兩地三中心+云這樣的經(jīng)典方式，搭建同城的實時同步，異地延遲同步的方式作為我們?yōu)膫浞桨傅闹黧w，當然我們也將一些數(shù)據(jù)不太敏感的資源、備份數(shù)據(jù)逐漸放到云上進行備份。
災備管理的手段主要是高可用+備份，對每一個系統(tǒng)和物理硬件都做一些高可用的方案，去避免單點故障。另外在做高可用的同時也建立備份機制，包括數(shù)據(jù)備份、文件備份、底層虛擬機和容器備份等，這樣既有高可用也有備份，最大強度保證了系統(tǒng)的可用性。
此外，這個備份也要有一套獨立的備份方案驗證模塊，是為了驗證我們之前所做的這些備份的可用性和準確性。因為如果沒有定時驗證備份是否可用的話，當真出現(xiàn)故障時，我們可能不太敢直接把這種備份用到生產(chǎn)上去。
最后還有一個應急預案管理，這個主要是緩解一些災難性故障時的應急措施，這樣做的好處就是當出現(xiàn)重大問題，且短時間難以恢復，包括備份不太可用時，我們會按照應急預案進行處理。應急預案也會有定期演練的過程，以此保證應急預案和實際情況的結(jié)合。
- 安全管理體系
安全管理是一個比較大的主題，這里簡單說一下我們的體系思路。首先是安全依據(jù)，主要有法律法規(guī)、行業(yè)背景和公司需求，包括《網(wǎng)絡安全法》，民航也有自身的網(wǎng)絡安全管理體系。根據(jù)這些依據(jù)去制定安全策略，同時依賴于安全技術(shù)幫我們做一些安全操作，這樣可通過安全策略、安全管理、安全技術(shù)、安全操作來保證我們的安全性。具體落地方面，我們主要有防火墻、IPS、WAF等安全設備。
著重介紹一下我們的UMS賬戶管理模塊，很多系統(tǒng)是公司內(nèi)部人員使用的，比如當人員離職時，首先在OA體現(xiàn)出來，如果管理人沒有及時關(guān)注這個人員，極有可能他離職了，這個賬戶還存在的。但通過UMS這個模塊跟OA系統(tǒng)打通，人員離職時對他業(yè)務系統(tǒng)的帳號做及時的清理，保證了賬號隨同人員離職一起銷毀，避免數(shù)據(jù)泄露的。
6、運維自動化
首先是關(guān)于服務器的申請、操作系統(tǒng)的安裝、服務申請，然后服務自動部署等。接著去做一些發(fā)布，發(fā)布的申請、變更的申請等，這些都是大家在做運維自動化的時候幾乎都會去做或是實現(xiàn)的工作。除此之外，這里著重跟大家介紹一下我們的一個關(guān)于資源申請評估指導和資源利用報告的情況。
我們的資源申請評估指導主要結(jié)合了自身經(jīng)驗，根據(jù)系統(tǒng)的行業(yè)請求和系統(tǒng)情況來以及壓力測試的結(jié)果參考等制定了一個相對比較科學的資源申請情況。當有一個新的需求要去申請我們資源時，我們會根據(jù)資源申請評估指導里面的算法，預估出他的系統(tǒng)變化量，自動計算出一個比較科學的硬件資源。資源利用報告呢，是我們定期對所有的服務器（包括虛擬機）所做的一個資源利用的情況，這樣根據(jù)我們的資源利用報告去做一些服務器的資源性變化和處理，確保我們的硬件資源是最大的利用率。
另外，我們做運維自動化時，也包括了我們架構(gòu)的自動診斷、壓力測試、自動巡檢和故障自動診斷等功能。
說一下架構(gòu)自動診斷，不知道大家有沒有這樣的情況，公司里經(jīng)常遇到上線比較著急的一些系統(tǒng)，但是上線運營一段時間以后，跟開發(fā)人員一溝通，發(fā)現(xiàn)這是很重要的系統(tǒng)，可當時上線比較匆忙沒有做任何高可用方案，如果沒有及時溝通，很可能這個重要的系統(tǒng)一直在單節(jié)點運行。為了規(guī)避這種情況，我們的架構(gòu)自動診斷是通過開發(fā)人員可能在申請新的系統(tǒng)上線時，會做系統(tǒng)等級的填寫，這個架構(gòu)自動診斷會根據(jù)系統(tǒng)的等級，結(jié)合系統(tǒng)線上的情況，如果缺少備份和只是單節(jié)點，它會自動提醒，讓我們的運維人員及時搭建架構(gòu)，避免重要系統(tǒng)的單點故障。
截止到目前，平心而論，我們現(xiàn)在的運維自動化是處于一個尷尬狀態(tài)，因為之前花了大量的時間，研究了大量的工具，包括寫了大量的腳本實現(xiàn)運維自動化，但結(jié)合Docker容器化時，我們發(fā)現(xiàn)腳本、服務器的安裝和服務部署（包括一些發(fā)布）等會有比較大的顛覆。當我再去建一個容器時，我直接從私有倉庫中拉取，發(fā)布時也是鏡像更新，并不是我們之前所做的去寫一些腳本，或者去做一些發(fā)布。結(jié)合現(xiàn)狀，我們現(xiàn)在在逐漸結(jié)合Docker，包括之前做的運維自動化工作，逐漸改變運維自動化的情況。
7、其它
經(jīng)過了標準化、流程化，包括自動化之后，我們已經(jīng)積攢了很多自動化的腳本等，管理起來相對復雜，東西也比較多。這時我們需要一個自身的運維管理平臺來去做統(tǒng)一的管理。
目前我們的運維管理平臺大致包括四個功能：
1.數(shù)據(jù)管理：數(shù)據(jù)管理主要是組織用戶權(quán)限和績效考核的功能。
2.項目管理：即運維管理，運維管理以項目管理為單位工作，跟開發(fā)工作相結(jié)合。我們公司在逐漸推進以項目為單位定義運維工作并且與開發(fā)項目管理結(jié)合起來共用一套系統(tǒng)，這樣我們運維的項目周期以開發(fā)的需求分析為起點，可加深我們運維對系統(tǒng)的理解，也會更好地幫助運維人員做線上的運維和運營工作。
3.數(shù)據(jù)中心：工作也好項目也好，實際上都通過數(shù)據(jù)的方式進行展示和分析，我們力圖通過用數(shù)據(jù)衡量運維的質(zhì)量情況，后面我們也會逐漸利用數(shù)據(jù)中心為我們的自動化運維做一些改變。
4.創(chuàng)新管理：主要還是想以創(chuàng)新驅(qū)動技術(shù)進步，提高運維質(zhì)量，比如我們在運維管理中逐步實現(xiàn)Docker容器化的操作，去做一些智能化運維的實踐，以此幫助我們做一些運維工作和技能的提高。
三、未來展望
首先是DevOps、SRE。我們將聯(lián)合業(yè)務、開發(fā)、測試、運維共同推進DevOps的進步，因為我們是相對傳統(tǒng)的行業(yè)，很難立即全面推動DevOps或SRE這一步，還是需要一個循序漸進的過程。
第二步是智能化運維，我們目前做的主要是一些故障的自動處理，例如像一些日志空間的自動釋放、常見問題的自動處理等，這是相對初步的實踐。
接下來我們也會結(jié)合自身運維的實際情況，對內(nèi)部做一些智能化運維的技術(shù)性研究，但智能化運維對業(yè)務人員的技術(shù)要求是比較高的，而青島招人又很難，怎么辦？其實我們做DevOps時，已經(jīng)跟開發(fā)、測試建立了一個相對比較好的關(guān)系，所以我們可以依賴于開發(fā)來做一些技術(shù)性的指導，結(jié)合自身的運維經(jīng)驗來逐漸推進智能化運維的一些工作。
然后私有云和混合云這一塊，我們之前已經(jīng)實現(xiàn)了虛擬化和容器化，接下來我們將逐漸利用OpenStack或K8s完成私有云相關(guān)的架構(gòu)和操作，爭取通過云服務降低我們的IT成本。
最后Serverless，不知道我的理解跟大家的是不是一樣，我們的實踐是將內(nèi)部現(xiàn)在大概十多套的系統(tǒng)用戶管理模塊去做一個服務的統(tǒng)一抽取，當再有一個新的系統(tǒng)要上線時，我們不需要再去單獨開發(fā)這樣一套用戶管理系統(tǒng)，而是直接接到這套用戶管理系統(tǒng)的用戶管理這樣一個平臺上，也是提高了一定的程度。通過構(gòu)建多套系統(tǒng)的公用模塊進行函數(shù)開發(fā)，實現(xiàn)系統(tǒng)直接調(diào)用。這跟微服務似乎有點相似。
運維這幾年的發(fā)展其實有很多的技術(shù)不斷的融進，我們始終堅持著安全、穩(wěn)定和高效三大原則，沒有這三大原則我們上面做的所有的操作全都是零。這是我今天的分享，謝謝大家！
Q&A
Q1：總體架構(gòu)設計時用了哪些開發(fā)工具，用的都是開源的嗎？
A1：目前很多都是開源的，除了有幾套應用是跑在Weblogic，我們大部分是Tomcat，我們目前也在將一些商用的Weblogic、Oracle等遷移至開源替代產(chǎn)品中去，降低IT成本。數(shù)據(jù)庫主要以MySQL和Oracle為主，Oracle主要是核心的系統(tǒng)在用。至于像我們這種監(jiān)控和管理，也是開源性的工具多，例如監(jiān)控主要是Zabbix和自定義腳本進行監(jiān)控。安全這一塊的話，相對比較多的是一些商業(yè)產(chǎn)品，例如我們的防火墻或者WAF應用防火墻，安全方面主要還是以商業(yè)產(chǎn)品為主。開源的安全產(chǎn)品，我們目前也在測試，但由于團隊的技術(shù)所限，沒有太大的精力去研究開源的安全產(chǎn)品也沒有決心去生產(chǎn)使用。
大概的簡圖如下：
注：統(tǒng)一任務調(diào)度使用tbschedule，消息隊列使用ActiveMQ，分布式文件服務器使用的fastDFS。接下來我會寫單獨一篇文章詳細介紹我們的系統(tǒng)架構(gòu)，敬請期待。
Q2：你們現(xiàn)在用K8s用到什么程度了，多大規(guī)模？
A2：K8S我們目前正在技術(shù)研究和測試階段，主要在測試環(huán)境進行了一些試用。K8S還是Mesos來管理編排我們的容器，目前都在測試中。
其實今天也是想聽一下大家對于Docker結(jié)合當前的情況做一些溝通。談到Docker大家可能會有一個疑問，用了Docker之后會不會把之前的虛擬化拋棄掉？我們公司目前做的虛擬化是拋棄不掉的，因為我們有一些服務、應用部署在Windows服務器上，包括我們的Oracle架構(gòu)也是在這上面。到目前為止還沒有聽說有公司在Docker跑RAC的一些架構(gòu)。所以未來相對比較長的時間，我們公司還是虛擬化和容器化是并存的情況，算是一個逐漸轉(zhuǎn)型吧�；仡^Docker生產(chǎn)集群搭建完畢，投入使用一段時間后，再跟大家做詳細的分享。
Q3：請問你們在Docker上的總體驅(qū)動、整個場景規(guī)劃，用K8s都做的話可能有一些缺點，所以你們整個集團是如何在調(diào)研K8s落地的？目前大家都想用K8s，但真的技術(shù)落地時，確實很多困難。
A3：說到k8s這塊，生產(chǎn)中并沒有做k8s的推廣和實踐，剛剛也說了我們目前正在進行技術(shù)調(diào)研。由于我們在青島新機場會開一個新的數(shù)據(jù)中心，以此為契機，進行容器化技術(shù)和集群的研究和實踐，爭取在新數(shù)據(jù)中心實現(xiàn)內(nèi)部高效的運維服務，通過新技術(shù)降低成本。這里也希望有生產(chǎn)經(jīng)驗的同學能夠多分享一下生產(chǎn)的經(jīng)驗，我們好提前學習。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標題：一個可供借鑒的中小企業(yè)運維管理平臺架構(gòu)樣本
本文網(wǎng)址：http://www.oesoe.com/html/solutions/14019321450.html
本文轉(zhuǎn)自：e-works制造業(yè)信息化門戶網(wǎng)
本文來源于互聯(lián)網(wǎng)，拓步ERP資訊網(wǎng)本著傳播知識、有益學習和研究的目的進行的轉(zhuǎn)載，為網(wǎng)友免費提供，并盡力標明作者與出處，如有著作權(quán)人或出版方提出異議，本站將立即刪除。如果您對文章轉(zhuǎn)載有任何疑問請告之我們，以便我們及時糾正。聯(lián)系方式：QQ：10877846 Tel：0755-26405298。（請勿發(fā)郵件，由于垃圾郵件眾多，有可能會被當作垃圾郵件處理掉，同時現(xiàn)在很用郵件處理事務了，郵件處理時效期為3天，如急件請直接QQ聯(lián)系。）
相關(guān)文章
