韓曉光：系統運維體系架構規劃

作者：韓曉光 2017-04-19 09:25:04

本文主要介紹運維體系與架構的設計規劃，這將引導我們從一個高屋建瓴的角度去考慮如何組織運維團隊，如何規劃運維架構，用什么構建起運維架構，以及如何開展運維工作。

圖1-1本文將會引入很多簡明的運維實踐示例來形象直觀的告訴大家如何構建起運維體系。通過學習本文內容將會使我們具備規劃與構建整個IT運維體系架構的知識和能力。

運維體系是運維的基礎和核心。通過運維體系的構建及完善，使我們的運維做到穩定可靠，準確完備，規范科學。從某種角度來看，系統運維體系可以用一個四面體來描述(如圖1-1所示)，包括四大方面：人、事、物、流程標準。

從人、事、物、流程這四個方面便可以很好地將運維體系進行解構，它們彼此互相作用，共同構建了一個完整實用的運維體系。下面列舉了這四個方面各自的含義及相關內容。

人：例如完善崗位職責與職業發展、提高團隊技術水平、完善技能分享與培訓、完善團隊績效考核、規范工作行為規范等。目的是要建成一支工作高效、技術水平高、團結穩定、有職業素養的運維團隊。

事：例如做好日常基礎運維工作，保障好生產業務運行。不斷探索新的運維理念與技術，探索優化系統架構。具體可以分為幾大塊，例如運維流程管理，資源架構規劃，應急與故障處理，監控與優化，安全與防護，項目及日常工作，等等。目的是要明白運維做什么正確的事，怎么正確地做事，做事有章法，穩定高效能。

物：主要是如何管理好系統運維所涉及的各種資源。例如機房環境、辦公設備、服務器、網絡設備、操作系統、應用軟件、工具等各種軟硬件資源。目的要使各類資源配置管理妥當，清楚資源屬性，知道從哪來，現在哪，要去哪。使得物盡其用，物有所值，安置妥當。

流程標準：運用流程標準將上述要素(人、事、物)有機地結合，有序科學地流轉、高效穩定地運行。例如資源規劃與采購，各種標準規范、項目規范、軟硬件配置部署規范、安全制度、工作交接，等等。

就上述四大方面，下文繼續展開論述，當然也僅是一些內容的列舉，畢竟具體到每個企業組織，其運維工作內容可能會大同小異。

1.1　團隊人員規劃

1.1.1　崗位職責劃分

一個優秀企業(組織團隊)的核心競爭力其實說到底就是人。合適的人在合適崗位上正確地干正確的事情——這就是核心競爭力。一個好的運維團隊也是如此，人在運維體系中就是核心，好的運維團隊能夠有效地、高質量地、相對低成本地發揮各個運維元素的功效，達到更完美的運維效能。

對于運維崗位劃分，很多企業大同小異，一般都是以保障業務生產穩定高效運行為目的，根據自身企業發展需要劃分崗位。小微企業可能沒有專門的運維人員及崗位設置，稍大的一些企業也可能由其他崗位人員(如開發人員)兼職運維人員，發展到中小型企業后往往就會設置專門的運維崗位人員從事日常維護工作。對于中大型企業一般都會有專門的運維團隊從事專業的運維工作，而且不僅僅是運維，還包括運維開發。

隨著運維的發展，運維崗位也逐漸細分很多種，各個企業崗位設置與職責也不盡相同，但崗位工作內容大同小異。大致有如下崗位：系統管理員、數據庫管理員、網絡管理員、機房環境管理員、運維開發工程師、應用運維工程師、服務管理工程師、安全審計工程師、架構師等。

有了崗位設置及專職人員，然后就會產生人力職業發展、技能培訓、績效考核等一系列問題，這些問題往往即相互聯系又各成一體。

如下是某企業的崗位職責劃分示例：

崗位(一級分類)通用職責要求是系統管理每個崗位都應履行的職責。
崗位(二級分類)專項職責是針對每一項工作崗位的職責要求。
崗位(三級分類)專人職責是針對每一個人設置的各自不同的具體職責。每個人在執行通用職責的基礎上同時履行各自的專項專人職責。

崗位(一級分類)通用職責示例通用職責如表1-1所示。

表1-1

續表

崗位(二級分類)專項職責示例如下是系統管理崗位工作示例：

表1-2

續表

1.1.2　崗位交接示例

因人員的短期離崗(以及離職)會給運維的穩定性、安全性、經驗傳承、資料留存、以及團隊穩定等眾多方面產生一系列影響,運維工作中的故障隱患很大比例來自于崗位交接。因此運維工作的崗位交接是個重要的事情，表1-3是崗位交接制度示例。

表1-3

續表

1.1.4　技能培訓

不同的企業，對人力的培訓也各有方式，輕重不同，內容有別。有的企業注重以老帶新，有的企業注重個人自學，有的企業注重內部交流，有的企業注重外部培訓。培訓往往也與崗位發展、財務狀況、績效考核、獎懲福利等相互關聯。

從培訓的途徑來看，培訓主要分為內訓和外訓兩種方式。

內訓：

由公司人力部門(或其他某部門)組織的培訓，包括外請其他公司專家、公司內部講師(一般都是有經驗特長的內部員工)。

外訓：

(1)由公司出資金為員工提供外部的培訓(員工個人申請培訓內容、培訓機構、價格。經公司審批后即可外訓)。

(2)公司簽訂的部分合同中附帶有一些培訓。

(3)由公司組織聯系到其他單位參觀交流。

(4)由其他廠商邀請的技術大會、峰會等。

(5)由公司組織選拔資助少量員工直接到其他單位實地鍛煉學習。

(6)由公司選拔資助少量員工參加一些脫產或不脫產的繼續教育學習。

1.1.5　績效考核示例

有人對應崗位做相應的工作，自然而然會有績效問題，也因此也會產生績效考核相關制度。

運維考核的難度在于如何定義KPI關鍵業績指標、如何定性與量化，每個企業單位內部都不一樣，需要根據自身環境定制基線。

考核的方式多種多樣。可以按照時間分為周考核、月考核、季度考核、年終考核。也可以按照KPI等關鍵因素進行考核。也可以從上下級人為主觀考核。也可以由評審委員會考核。

表1-6是某運維部門考核標準示例。

1.2　體系架構相關事宜規劃

運維要做的事情，實在太多了。說復雜，復雜得沒有人能說明白，列舉全面。說簡單，倒也簡單：運維工作就是支持生產運行，是成本中心，一般不直接產生利潤。目的就是運行保障生產設備軟硬件正常運行，讓內外部用戶滿意度。

運維要做的事情與崗位職責內容密切聯系，可能有了運維要做的事情需求，因此設置了崗位和人員，但也有因為有了這個崗位的人，因此創造了一些運維事情。這有點“雞生蛋、蛋生雞”的邏輯。

1.2.1 運維系統架構

每個公司的IT環境，不論大小復雜度，總會有個系統架構層次。有了這個架構體系，那所有的運維事情大體都圍繞著這個系統架構上的每個元素及整體進行運維保障工作。運維架構從某種角度可以劃分為如下兩種：商業封閉式系統架構(IOE架構)與開源系統架構。

1. 商業封閉式系統架構(IOE架構)

典型的即以使用IOE(IBM、Oracle、EMC)產品軟硬件為主要元素的系統架構。IOE架構以縱向擴展為特點，通過增加CPU、內存、擴展柜、冗余備件等方式來提高處理能力及穩定性。該架構的處理能力主要取決于單臺(套)設備(系統)的最大擴展能力，很難通過增加設備(系統)數量來增加處理能力，換句話說該架構很難通過擴大集群規模的方式來解決問題。隨著縱向擴展的規模增大，其實施技術難度、管理復雜度以及隱患風險都會正比例大幅上升。基于IOE架構的典型企業如：金融業、電信業，交通運輸業。IOE典型的系統架構如圖1-2所示。

圖1-2

上述IOE型系統架構。其服務器多使用小型機、大型機(還有以往的中型機)，數據庫系統往往會使用Oracle，存儲則多使用知名品牌的中高端存儲陣列、帶庫等設備。服務器與存儲之間多使用SAN存儲網絡。這些服務器、存儲等硬件本身往往就是雙冗余的，線路連線也都是雙冗余的，而且設備性能指標往往非常好，例如一臺普通中端的Power 7系列服務器可以輕松劃分出若干個系統分區或者一二十個虛擬機系統。

2. 開源系統架構

典型的即以使用廉價PC服務器，開源產品技術為主要元素的系統架構。開源系統架構以橫向擴展，分布式部署為特點。通常通過往集群中增加單機設備資源解決存儲空間、性能以及穩定性問題，其集群規模可以小到兩三臺PC服務器組成，也可以大到上萬臺PC服務器集群。對于數據庫，可以通過分布式集群方式解決數據庫擴展性的問題。另外非結構化數據庫及分布式文件系統在處理非結構化數據的存儲與使用方面也很靈活方便。基于開源系統架構的典型企業如：以BAT(百度、阿里、騰訊)為代表的眾多互聯網企業，開源系統架構如圖1-3所示。

圖1-3

上述開源系統架構中使用了CDN和反向代理以提高網站性能。例如我們的服務器可能部署在北京，對于北京及周邊用戶來說訪問是較快的，而對于遠離北京的用戶訪問則感覺較慢，因為數據傳輸時間比較長。對于這種情況，常常使用CDN解決，CDN將數據內容緩存到運營商(或自建CDN)的機房，用戶訪問時先從最近的CDN機房獲取數據，這樣大大減少了網絡訪問的路徑。

對于反向代理，當用戶請求達到時首先訪問反向代理，反向代理服務器將(Varnish)緩存的數據返回給用戶，如果沒有沒有緩存數據才會繼續走應用服務器獲取，這也減少了獲取數據的成本。當然對于海量訪問請求，或者龐大集群架構，則就需要分多層、綜合運用上述負載均衡以及代理(反代理)，同時可能需要引入zookeeper等功能以協調(服務)任務調度。

關于去IOE問題，本文簡單闡述如下。

近年來開源技術的迅猛發展，以及國內外政策環境共同作用，引發了一場去IOE的風潮。他們使用低廉的軟硬件產品代替昂貴高門檻的IOE產品，搭建起自主開放的開源系統架構。之所以出現“去IOE”運動，其中原因總結概述如下幾條：

(1)自“棱鏡門事件”之后，國家強烈意識到數據安全的重要性，大力提倡產品設備國產化與自主研發，這正與“去IOE”觀點不謀而合，上下一致。

(2)近年來，云計算、大數據等新興IT技術的蓬勃發展，促使眾多行業開始往更加開放靈活的開放系統架構轉型。這對于傳統的IOE架構而言，其定制與擴展靈活性有限，往往是擅長于集中式架構的管理，而很難應對大規模集群，分布式存儲計算。

(3)在購買成本方面，以IOE為代表的商業產品價格昂貴(動輒上百萬元)，PC服務器相對廉價(通常幾萬元)。在部署與管理方面，IOE產品的學習掌握門檻偏高，而開源系統環境相對容易搭建與管理。另外IOE產品技術相對商業封閉，不易掌握。

基于上述一些原因，去IOE應時而生。當然具體到自身企業是否要去IOE，這需要慎重考慮，適合自身發展需要的系統架構就是好的架構。去IOE過程，其實是系統架構的更新換代，產品的更新換代，運維理念的更新換代，運維人員的更新換代，知識體系的更新換代，等等。因此如果冒然去IOE，可能既不會降低成本，也不會提高效率，更不會穩定架構。如下列舉幾點“去IOE”要考慮的因素：

自身業務是否真正需要大數據、云計算以及分布式這種海量運維體系。
是否已經考慮好系統架構、運維理念、人員、知識更新換代的方案。
自身的研發實力儲備是否夠解決大量開源產品的坑坑洼洼，并有實力搭建開源系統架構。
是否有足夠的資金應對“去IOE”轉型中的成本，例如從硬件高成本轉向人力技術高成本。

去IOE只是給予我們一些最佳實踐與選擇路子，但去IOE技術門檻較高，一般企業很難復制。從目前發展來看，IOE架構與非IOE架構仍將長期并存。一時間很難找到一些能夠完美替代以IOE為代表的成熟(且普適)產品方案。

1.2.2　運維工作層次分類示例

例如《海量運維、運營規劃》(作者：唐文)一書，作者很有觀點地概括了運維要做的事情，他以質量、效率、成本為核心，從運營規劃、管理、流程/規范、系統/平臺、監控、告警、安全、優化、考核等幾個維度來闡述運維工作，如圖1-4所示。

圖1-4

另外也可以從邏輯框架的層次來分類運維工作要做的事情。如下借鑒美團的分享者(唐君毅、邱劍、朱晏)關于企業運維的觀點，運維框架可以概括為五橫三縱。

從橫向來看，自底向上分為五個層次：

物理層：包括機房網絡、硬件設施相關工作。如采購招投標工作、機房實施工作、機房環境(強弱電、照明、通風、網絡布線、溫濕度等)，各種設備上下電與維修工作等。
系統層：包括操作系統、虛擬化、云計算等一系列系統環境所涉及的部署、配置、優化等工作。
服務層：包括Webserver、緩存、代理、數據庫等所涉及的軟件應用的部署、配置、優化等工作。
邏輯層：包括業務邏輯、數據流。這一層的主要工作是發布和變更。
應用層：包括用戶可見部分。所有前端平臺，主要涉及與前端用戶交互或提供信息(服務)的平臺。比如前端網站、各種新媒體平臺的維護與監控。

從縱向來看，有三部分工作，對上述五個層次是通用的：

監控：從物理層到服務層的監控和報警都是運維來跟進、響應的。對于邏輯層和應用層，一般由運維提供監控API的規范，開發人員自己創建監控項、設定報警規則、進行增刪改查。
安全：建立部署統一的安全接入平臺，所有線上的人工操作都需要登陸跳板機，每個人有獨立的登陸帳號，所有線上操作都有審計日志。更多的安全工作由專門的信息安全組負責。
流程：早期基于Jira做了一些簡單的流程，但需要改進。現在正在針對比較集中的需求，開發相應的流程控制系統，方向也是自動化、自助化。從業務部門申請VM資源，到業務擴容的整個流程，未來可以在Web界面上通過很簡單的操作實現，也提供服務化的API，方便其他業務平臺進行集成。以期實現虛擬化覆蓋全業務線。

1.3　基礎設施相關物資規劃

做飯要有材米油鹽，打仗要有彈藥武器。干運維，也要有一系列軟硬工具。什么算是運維工作的工具，恐怕這個也沒有明確定義。運維所涉及的工具物品，有看的見的，也有看不見的;有摸得著的，也有摸不著的。這里簡單概括一下運維工作會用到的各種軟硬件、工具、設施。

1.3.1　機房基礎設施環境示例

如下列舉的是機房基礎設施環境相關要素，如表1-7所示。機房不論大小，基本上都會涉及到如下幾大主要工程(系統)。

續表

1.3.2　服務器產品示例

對于大多數企業通常是采購現有品牌(也有些企業是定制設備)，產品示例如表1-8所示。

1.3.3 存儲設備示例

存儲設備示例如表1-9所示。

1.3.4 操作系統示例

操作系統示例如表1-10所示。

1.3.5 常用軟件示例

常用軟件示例如表1-11所示。

續表

1.4　運維流程標準規劃

將上述要素(人、事、物)有機地結合，有序科學地流轉、高效穩定地運行，就得靠科學合理的流程，如各種規章制度、流程標準。

流程就好比珠寶上的穿繩，就好比一個人的思想，就好比社會法律規范。流程是一個企業的流水線，是企業的行為規范，是企業制度與文化的組成部分。合理的流程規范像血液，能讓部門穩定高效地運轉，這是企業專業與否的重要組成部分。

運維工作到底有多少流程，這個無法窮舉，就好比一個人的思想到底有多少，因人而異，因時而異。關于IT服務運營流程，ITIL流程在全球享有盛名，ITIL為企業的IT服務管理實踐提供了一個客觀、嚴謹、可量化的標準和規范，這在后續章節做專題介紹。本文主要列舉運維工作中一些常見流程規范。

1.4.1　商務流程

商務公開招標流程示例：

商務公開招投標大致流程如下所示：

采購啟動 → 需求確認 → 委托招標上報 → 簽訂委托協議 → 標書準備(采購部門技術標書準備，商務部門組織商務標書準備，標書合并)→ 提交標書 → 專家評審意見反饋 → 公開招標上報 → 公開招標 → 招標結果上報 → 商務談判 → 合同簽訂上報 → 簽訂采購合同

1.4.2　運維制度流程

一、項目管理制度示例：

以下簡要介紹項目開展與實施相關制度流程

1、執行集團和公司的項目管理規定。

2、項目范圍為公司和部門下達的各類項目。

3、每年10月底之前，部門結合公司下達的任務和部門的生產需求，研究討論制定部門下一年度的項目計劃，完成項目建議書(含目標、范圍、完成時間、費用估算等)

4、每年12月底之前，針對部門下一年度的項目計劃，通過任命和競聘相結合的方式產生各項目經理。部門和項目經理應根據項目建議書中項目目標、范圍、時間要求等內容，并根據人員的實際情況，在10個工作日內，組建項目團隊，提交可行的驗收標準、項目計劃、管理章程

5、項目的實施流程主要分為一、啟動項目呈批件;二、可行性分析和技術方案形成階段;三、方案完善階段;四、提交啟動商務呈批件;五、提交商務談判說明和啟動商務呈批件;六、商務談判過程;七、提交合同簽訂呈批件階段;八、到貨驗收階段;九、試運行階段;十、項目驗收階段。

6、原則上產品供應商的選擇不少于3家，如果產品唯一那么集成商或代理商選擇不少于3家。

二、需求處理流程規定示例

需求提出者在ITSM系統流程中向職責對應團隊小組提出需求，承接團隊對需求進行分析處理，處理流程示例如下圖1-5。

圖1-5

三、故障處理制度流程示例：

1. 故障來源于客戶報告、值班人員巡查、監控系統監控、日常例行檢查等。

2. 根據故障對用戶的影響程度，對故障進行如下分類：

嚴重故障：生產系統、數據庫、網絡性能嚴重降低，應用系統運行緩慢，工具軟件不可用，機房供配電系統發生故障等對生產安全運行存在嚴重隱患，開發、測試、災備、應急系統不可用，或對用戶使用產生嚴重影響的故障。

重大故障：生產系統(含子系統)、數據庫、應用系統不可用、網絡中斷、機房供配電系統停止運行等影響生產安全、無法保障用戶使用的故障。

一般故障：生產系統、數據庫、網絡、機房供配電系統、工具軟件等告警或運行狀態不正常，開發、測試、災備、應急系統發生問題，且不影響用戶正常使用的故障。

故障癥候：生產系統(含子系統)、數據庫、應用系統有故障癥候，報故障代碼或故障消息，或者對生產正常運行存在易患，并可在一定時限內解決的故障。

3. 當故障發生在工作時間內，由故障發現者通知崗位工程師，崗位工程師依據《工作上報批準規范》進行信息通報上級經理，將故障記錄填寫到ITSM的事件流程中，并負責故障處理。各級經理決定通知相關崗位和客戶的范圍和方式。當故障發生在非工作時間，由值班人員按照《電話值班管理規定》通知電話值班工程師處理，并在隨后的一個工作日內記錄在ITSM服務管理系統中，電話值班工程師依據《工作上報批準規范》進行上報上級經理，由科室經理決定通知相關崗位和客戶的范圍和方式。

4. 故障受理人負責故障處理，當需要服務商工程師到現場時，故障受理人聯系服務商工程師，并陪同服務商工程師進行故障處理。當故障持續時間較長需要輪換故障處理人員時，要做好故障處理交接工作，并將前期處理情況和過程以文字形式交接給接續人員，并通報科室經理，接續人員繼續承擔處理故障職責。

5. 上級經理跟蹤下級故障處理過程。

6. 故障處理完畢后，由故障處理人員通知上級經理，告知故障已經解決，并由經理決定通知相關崗位和客戶的范圍和方式，最后故障處理人員或運維主管將ITSM中的事件流程中的故障記錄填寫完整。

7. 需要升級到問題的故障轉入問題流程，后續按照《問題管理規定》處理。

四、應急(演練)管理流程示例：

制定應急管理流程的目的是為了在發生應急事件時，各相關生產部門能根據流程對應急事件進行通報、指揮、處理和協調，最大限度地降低事件所帶來的不利影響，使得應急事件能夠得到有效的管理應急管理流程示例如下圖1-6：