本文主要介紹運維體系與架構的設計規(guī)劃，這將引導我們從一個高屋建瓴的角度去考慮如何組織運維團隊，如何規(guī)劃運維架構，用什么構建起運維架構，以及如何開展運維工作。
圖1-1本文將會引入很多簡明的運維實踐示例來形象直觀的告訴大家如何構建起運維體系。通過學習本文內容將會使我們具備規(guī)劃與構建整個IT運維體系架構的知識和能力。
運維體系是運維的基礎和核心。通過運維體系的構建及完善，使我們的運維做到穩(wěn)定可靠，準確完備，規(guī)范科學。從某種角度來看，系統(tǒng)運維體系可以用一個四面體來描述(如圖1-1所示)，包括四大方面：人、事、物、流程標準。
從人、事、物、流程這四個方面便可以很好地將運維體系進行解構，它們彼此互相作用，共同構建了一個完整實用的運維體系。下面列舉了這四個方面各自的含義及相關內容。
人：例如完善崗位職責與職業(yè)發(fā)展、提高團隊技術水平、完善技能分享與培訓、完善團隊績效考核、規(guī)范工作行為規(guī)范等。目的是要建成一支工作高效、技術水平高、團結穩(wěn)定、有職業(yè)素養(yǎng)的運維團隊。
事：例如做好日?；A運維工作，保障好生產(chǎn)業(yè)務運行。不斷探索新的運維理念與技術，探索優(yōu)化系統(tǒng)架構。具體可以分為幾大塊，例如運維流程管理，資源架構規(guī)劃，應急與故障處理，監(jiān)控與優(yōu)化，安全與防護，項目及日常工作，等等。目的是要明白運維做什么正確的事，怎么正確地做事，做事有章法，穩(wěn)定高效能。
物：主要是如何管理好系統(tǒng)運維所涉及的各種資源。例如機房環(huán)境、辦公設備、服務器、網(wǎng)絡設備、操作系統(tǒng)、應用軟件、工具等各種軟硬件資源。目的要使各類資源配置管理妥當，清楚資源屬性，知道從哪來，現(xiàn)在哪，要去哪。使得物盡其用，物有所值，安置妥當。
流程標準：運用流程標準將上述要素(人、事、物)有機地結合，有序科學地流轉、高效穩(wěn)定地運行。例如資源規(guī)劃與采購，各種標準規(guī)范、項目規(guī)范、軟硬件配置部署規(guī)范、安全制度、工作交接，等等。
就上述四大方面，下文繼續(xù)展開論述，當然也僅是一些內容的列舉，畢竟具體到每個企業(yè)組織，其運維工作內容可能會大同小異。
1.1團隊人員規(guī)劃
1.1.1崗位職責劃分
一個優(yōu)秀企業(yè)(組織團隊)的核心競爭力其實說到底就是人。合適的人在合適崗位上正確地干正確的事情——這就是核心競爭力。一個好的運維團隊也是如此，人在運維體系中就是核心，好的運維團隊能夠有效地、高質量地、相對低成本地發(fā)揮各個運維元素的功效，達到更完美的運維效能。
對于運維崗位劃分，很多企業(yè)大同小異，一般都是以保障業(yè)務生產(chǎn)穩(wěn)定高效運行為目的，根據(jù)自身企業(yè)發(fā)展需要劃分崗位。小微企業(yè)可能沒有專門的運維人員及崗位設置，稍大的一些企業(yè)也可能由其他崗位人員(如開發(fā)人員)兼職運維人員，發(fā)展到中小型企業(yè)后往往就會設置專門的運維崗位人員從事日常維護工作。對于中大型企業(yè)一般都會有專門的運維團隊從事專業(yè)的運維工作，而且不僅僅是運維，還包括運維開發(fā)。
隨著運維的發(fā)展，運維崗位也逐漸細分很多種，各個企業(yè)崗位設置與職責也不盡相同，但崗位工作內容大同小異。大致有如下崗位：系統(tǒng)管理員、數(shù)據(jù)庫管理員、網(wǎng)絡管理員、機房環(huán)境管理員、運維開發(fā)工程師、應用運維工程師、服務管理工程師、安全審計工程師、架構師等。
有了崗位設置及專職人員，然后就會產(chǎn)生人力職業(yè)發(fā)展、技能培訓、績效考核等一系列問題，這些問題往往即相互聯(lián)系又各成一體。
如下是某企業(yè)的崗位職責劃分示例：
- 崗位(一級分類)通用職責要求是系統(tǒng)管理每個崗位都應履行的職責。
- 崗位(二級分類)專項職責是針對每一項工作崗位的職責要求。
- 崗位(三級分類)專人職責是針對每一個人設置的各自不同的具體職責。每個人在執(zhí)行通用職責的基礎上同時履行各自的專項專人職責。
崗位(一級分類)通用職責示例通用職責如表1-1所示。
表1-1
續(xù)表
崗位(二級分類)專項職責示例如下是系統(tǒng)管理崗位工作示例：
表1-2
續(xù)表
1.1.2崗位交接示例
因人員的短期離崗(以及離職)會給運維的穩(wěn)定性、安全性、經(jīng)驗傳承、資料留存、以及團隊穩(wěn)定等眾多方面產(chǎn)生一系列影響,運維工作中的故障隱患很大比例來自于崗位交接。因此運維工作的崗位交接是個重要的事情，表1-3是崗位交接制度示例。
表1-3
續(xù)表
1.1.4技能培訓
不同的企業(yè)，對人力的培訓也各有方式，輕重不同，內容有別。有的企業(yè)注重以老帶新，有的企業(yè)注重個人自學，有的企業(yè)注重內部交流，有的企業(yè)注重外部培訓。培訓往往也與崗位發(fā)展、財務狀況、績效考核、獎懲福利等相互關聯(lián)。
從培訓的途徑來看，培訓主要分為內訓和外訓兩種方式。
內訓：
由公司人力部門(或其他某部門)組織的培訓，包括外請其他公司專家、公司內部講師(一般都是有經(jīng)驗特長的內部員工)。
外訓：
(1)由公司出資金為員工提供外部的培訓(員工個人申請培訓內容、培訓機構、價格。經(jīng)公司審批后即可外訓)。
(2)公司簽訂的部分合同中附帶有一些培訓。
(3)由公司組織聯(lián)系到其他單位參觀交流。
(4)由其他廠商邀請的技術大會、峰會等。
(5)由公司組織選拔資助少量員工直接到其他單位實地鍛煉學習。
(6)由公司選拔資助少量員工參加一些脫產(chǎn)或不脫產(chǎn)的繼續(xù)教育學習。
1.1.5績效考核示例
有人對應崗位做相應的工作，自然而然會有績效問題，也因此也會產(chǎn)生績效考核相關制度。
運維考核的難度在于如何定義KPI關鍵業(yè)績指標、如何定性與量化，每個企業(yè)單位內部都不一樣，需要根據(jù)自身環(huán)境定制基線。
考核的方式多種多樣?？梢园凑諘r間分為周考核、月考核、季度考核、年終考核。也可以按照KPI等關鍵因素進行考核。也可以從上下級人為主觀考核。也可以由評審委員會考核。
表1-6是某運維部門考核標準示例。
1.2體系架構相關事宜規(guī)劃
運維要做的事情，實在太多了。說復雜，復雜得沒有人能說明白，列舉全面。說簡單，倒也簡單：運維工作就是支持生產(chǎn)運行，是成本中心，一般不直接產(chǎn)生利潤。目的就是運行保障生產(chǎn)設備軟硬件正常運行，讓內外部用戶滿意度。
運維要做的事情與崗位職責內容密切聯(lián)系，可能有了運維要做的事情需求，因此設置了崗位和人員，但也有因為有了這個崗位的人，因此創(chuàng)造了一些運維事情。這有點“雞生蛋、蛋生雞”的邏輯。
1.2.1 運維系統(tǒng)架構
每個公司的IT環(huán)境，不論大小復雜度，總會有個系統(tǒng)架構層次。有了這個架構體系，那所有的運維事情大體都圍繞著這個系統(tǒng)架構上的每個元素及整體進行運維保障工作。運維架構從某種角度可以劃分為如下兩種：商業(yè)封閉式系統(tǒng)架構(IOE架構)與開源系統(tǒng)架構。
1. 商業(yè)封閉式系統(tǒng)架構(IOE架構)
典型的即以使用IOE(IBM、Oracle、EMC)產(chǎn)品軟硬件為主要元素的系統(tǒng)架構。IOE架構以縱向擴展為特點，通過增加CPU、內存、擴展柜、冗余備件等方式來提高處理能力及穩(wěn)定性。該架構的處理能力主要取決于單臺(套)設備(系統(tǒng))的最大擴展能力，很難通過增加設備(系統(tǒng))數(shù)量來增加處理能力，換句話說該架構很難通過擴大集群規(guī)模的方式來解決問題。隨著縱向擴展的規(guī)模增大，其實施技術難度、管理復雜度以及隱患風險都會正比例大幅上升?；贗OE架構的典型企業(yè)如：金融業(yè)、電信業(yè)，交通運輸業(yè)。IOE典型的系統(tǒng)架構如圖1-2所示。
圖1-2
上述IOE型系統(tǒng)架構。其服務器多使用小型機、大型機(還有以往的中型機)，數(shù)據(jù)庫系統(tǒng)往往會使用Oracle，存儲則多使用知名品牌的中高端存儲陣列、帶庫等設備。服務器與存儲之間多使用SAN存儲網(wǎng)絡。這些服務器、存儲等硬件本身往往就是雙冗余的，線路連線也都是雙冗余的，而且設備性能指標往往非常好，例如一臺普通中端的Power 7系列服務器可以輕松劃分出若干個系統(tǒng)分區(qū)或者一二十個虛擬機系統(tǒng)。
2. 開源系統(tǒng)架構
典型的即以使用廉價PC服務器，開源產(chǎn)品技術為主要元素的系統(tǒng)架構。開源系統(tǒng)架構以橫向擴展，分布式部署為特點。通常通過往集群中增加單機設備資源解決存儲空間、性能以及穩(wěn)定性問題，其集群規(guī)?？梢孕〉絻扇_PC服務器組成，也可以大到上萬臺PC服務器集群。對于數(shù)據(jù)庫，可以通過分布式集群方式解決數(shù)據(jù)庫擴展性的問題。另外非結構化數(shù)據(jù)庫及分布式文件系統(tǒng)在處理非結構化數(shù)據(jù)的存儲與使用方面也很靈活方便。基于開源系統(tǒng)架構的典型企業(yè)如：以BAT(百度、阿里、騰訊)為代表的眾多互聯(lián)網(wǎng)企業(yè)，開源系統(tǒng)架構如圖1-3所示。
圖1-3
上述開源系統(tǒng)架構中使用了CDN和反向代理以提高網(wǎng)站性能。例如我們的服務器可能部署在北京，對于北京及周邊用戶來說訪問是較快的，而對于遠離北京的用戶訪問則感覺較慢，因為數(shù)據(jù)傳輸時間比較長。對于這種情況，常常使用CDN解決，CDN將數(shù)據(jù)內容緩存到運營商(或自建CDN)的機房，用戶訪問時先從最近的CDN機房獲取數(shù)據(jù)，這樣大大減少了網(wǎng)絡訪問的路徑。
對于反向代理，當用戶請求達到時首先訪問反向代理，反向代理服務器將(Varnish)緩存的數(shù)據(jù)返回給用戶，如果沒有沒有緩存數(shù)據(jù)才會繼續(xù)走應用服務器獲取，這也減少了獲取數(shù)據(jù)的成本。當然對于海量訪問請求，或者龐大集群架構，則就需要分多層、綜合運用上述負載均衡以及代理(反代理)，同時可能需要引入zookeeper等功能以協(xié)調(服務)任務調度。
關于去IOE問題，本文簡單闡述如下。
近年來開源技術的迅猛發(fā)展，以及國內外政策環(huán)境共同作用，引發(fā)了一場去IOE的風潮。他們使用低廉的軟硬件產(chǎn)品代替昂貴高門檻的IOE產(chǎn)品，搭建起自主開放的開源系統(tǒng)架構。之所以出現(xiàn)“去IOE”運動，其中原因總結概述如下幾條：
(1)自“棱鏡門事件”之后，國家強烈意識到數(shù)據(jù)安全的重要性，大力提倡產(chǎn)品設備國產(chǎn)化與自主研發(fā)，這正與“去IOE”觀點不謀而合，上下一致。
(2)近年來，云計算、大數(shù)據(jù)等新興IT技術的蓬勃發(fā)展，促使眾多行業(yè)開始往更加開放靈活的開放系統(tǒng)架構轉型。這對于傳統(tǒng)的IOE架構而言，其定制與擴展靈活性有限，往往是擅長于集中式架構的管理，而很難應對大規(guī)模集群，分布式存儲計算。
(3)在購買成本方面，以IOE為代表的商業(yè)產(chǎn)品價格昂貴(動輒上百萬元)，PC服務器相對廉價(通常幾萬元)。在部署與管理方面，IOE產(chǎn)品的學習掌握門檻偏高，而開源系統(tǒng)環(huán)境相對容易搭建與管理。另外IOE產(chǎn)品技術相對商業(yè)封閉，不易掌握。
基于上述一些原因，去IOE應時而生。當然具體到自身企業(yè)是否要去IOE，這需要慎重考慮，適合自身發(fā)展需要的系統(tǒng)架構就是好的架構。去IOE過程，其實是系統(tǒng)架構的更新?lián)Q代，產(chǎn)品的更新?lián)Q代，運維理念的更新?lián)Q代，運維人員的更新?lián)Q代，知識體系的更新?lián)Q代，等等。因此如果冒然去IOE，可能既不會降低成本，也不會提高效率，更不會穩(wěn)定架構。如下列舉幾點“去IOE”要考慮的因素：
- 自身業(yè)務是否真正需要大數(shù)據(jù)、云計算以及分布式這種海量運維體系。
- 是否已經(jīng)考慮好系統(tǒng)架構、運維理念、人員、知識更新?lián)Q代的方案。
- 自身的研發(fā)實力儲備是否夠解決大量開源產(chǎn)品的坑坑洼洼，并有實力搭建開源系統(tǒng)架構。
- 是否有足夠的資金應對“去IOE”轉型中的成本，例如從硬件高成本轉向人力技術高成本。
去IOE只是給予我們一些最佳實踐與選擇路子，但去IOE技術門檻較高，一般企業(yè)很難復制。從目前發(fā)展來看，IOE架構與非IOE架構仍將長期并存。一時間很難找到一些能夠完美替代以IOE為代表的成熟(且普適)產(chǎn)品方案。
1.2.2運維工作層次分類示例
例如《海量運維、運營規(guī)劃》(作者：唐文)一書，作者很有觀點地概括了運維要做的事情，他以質量、效率、成本為核心，從運營規(guī)劃、管理、流程/規(guī)范、系統(tǒng)/平臺、監(jiān)控、告警、安全、優(yōu)化、考核等幾個維度來闡述運維工作，如圖1-4所示。
圖1-4
另外也可以從邏輯框架的層次來分類運維工作要做的事情。如下借鑒美團的分享者(唐君毅、邱劍、朱晏)關于企業(yè)運維的觀點，運維框架可以概括為五橫三縱。
從橫向來看，自底向上分為五個層次：
- 物理層：包括機房網(wǎng)絡、硬件設施相關工作。如采購招投標工作、機房實施工作、機房環(huán)境(強弱電、照明、通風、網(wǎng)絡布線、溫濕度等)，各種設備上下電與維修工作等。
- 系統(tǒng)層：包括操作系統(tǒng)、虛擬化、云計算等一系列系統(tǒng)環(huán)境所涉及的部署、配置、優(yōu)化等工作。
- 服務層：包括Webserver、緩存、代理、數(shù)據(jù)庫等所涉及的軟件應用的部署、配置、優(yōu)化等工作。
- 邏輯層：包括業(yè)務邏輯、數(shù)據(jù)流。這一層的主要工作是發(fā)布和變更。
- 應用層：包括用戶可見部分。所有前端平臺，主要涉及與前端用戶交互或提供信息(服務)的平臺。比如前端網(wǎng)站、各種新媒體平臺的維護與監(jiān)控。
從縱向來看，有三部分工作，對上述五個層次是通用的：
- 監(jiān)控：從物理層到服務層的監(jiān)控和報警都是運維來跟進、響應的。對于邏輯層和應用層，一般由運維提供監(jiān)控API的規(guī)范，開發(fā)人員自己創(chuàng)建監(jiān)控項、設定報警規(guī)則、進行增刪改查。
- 安全：建立部署統(tǒng)一的安全接入平臺，所有線上的人工操作都需要登陸跳板機，每個人有獨立的登陸帳號，所有線上操作都有審計日志。更多的安全工作由專門的信息安全組負責。
- 流程：早期基于Jira做了一些簡單的流程，但需要改進。現(xiàn)在正在針對比較集中的需求，開發(fā)相應的流程控制系統(tǒng)，方向也是自動化、自助化。從業(yè)務部門申請VM資源，到業(yè)務擴容的整個流程，未來可以在Web界面上通過很簡單的操作實現(xiàn)，也提供服務化的API，方便其他業(yè)務平臺進行集成。以期實現(xiàn)虛擬化覆蓋全業(yè)務線。
1.3基礎設施相關物資規(guī)劃
做飯要有材米油鹽，打仗要有彈藥武器。干運維，也要有一系列軟硬工具。什么算是運維工作的工具，恐怕這個也沒有明確定義。運維所涉及的工具物品，有看的見的，也有看不見的;有摸得著的，也有摸不著的。這里簡單概括一下運維工作會用到的各種軟硬件、工具、設施。
1.3.1機房基礎設施環(huán)境示例
如下列舉的是機房基礎設施環(huán)境相關要素，如表1-7所示。機房不論大小，基本上都會涉及到如下幾大主要工程(系統(tǒng))。
續(xù)表
1.3.2服務器產(chǎn)品示例
對于大多數(shù)企業(yè)通常是采購現(xiàn)有品牌(也有些企業(yè)是定制設備)，產(chǎn)品示例如表1-8所示。
1.3.3 存儲設備示例
存儲設備示例如表1-9所示。
1.3.4 操作系統(tǒng)示例
操作系統(tǒng)示例如表1-10所示。
1.3.5 常用軟件示例
常用軟件示例如表1-11所示。
續(xù)表
1.4運維流程標準規(guī)劃
將上述要素(人、事、物)有機地結合，有序科學地流轉、高效穩(wěn)定地運行，就得靠科學合理的流程，如各種規(guī)章制度、流程標準。
流程就好比珠寶上的穿繩，就好比一個人的思想，就好比社會法律規(guī)范。流程是一個企業(yè)的流水線，是企業(yè)的行為規(guī)范，是企業(yè)制度與文化的組成部分。合理的流程規(guī)范像血液，能讓部門穩(wěn)定高效地運轉，這是企業(yè)專業(yè)與否的重要組成部分。
運維工作到底有多少流程，這個無法窮舉，就好比一個人的思想到底有多少，因人而異，因時而異。關于IT服務運營流程，ITIL流程在全球享有盛名，ITIL為企業(yè)的IT服務管理實踐提供了一個客觀、嚴謹、可量化的標準和規(guī)范，這在后續(xù)章節(jié)做專題介紹。本文主要列舉運維工作中一些常見流程規(guī)范。
1.4.1商務流程
商務公開招標流程示例：
商務公開招投標大致流程如下所示：
采購啟動 → 需求確認 → 委托招標上報 → 簽訂委托協(xié)議 → 標書準備(采購部門技術標書準備，商務部門組織商務標書準備，標書合并)→ 提交標書 → 專家評審意見反饋 → 公開招標上報 → 公開招標 → 招標結果上報 → 商務談判 → 合同簽訂上報 → 簽訂采購合同
1.4.2運維制度流程
一、項目管理制度示例：
以下簡要介紹項目開展與實施相關制度流程
1、 執(zhí)行集團和公司的項目管理規(guī)定。
2、 項目范圍為公司和部門下達的各類項目。
3、 每年10月底之前，部門結合公司下達的任務和部門的生產(chǎn)需求，研究討論制定部門下一年度的項目計劃，完成項目建議書(含目標、范圍、完成時間、費用估算等)
4、 每年12月底之前，針對部門下一年度的項目計劃，通過任命和競聘相結合的方式產(chǎn)生各項目經(jīng)理。部門和項目經(jīng)理應根據(jù)項目建議書中項目目標、范圍、時間要求等內容，并根據(jù)人員的實際情況，在10個工作日內，組建項目團隊，提交可行的驗收標準、項目計劃、管理章程
5、 項目的實施流程主要分為一、啟動項目呈批件;二、可行性分析和技術方案形成階段;三、方案完善階段;四、提交啟動商務呈批件;五、提交商務談判說明和啟動商務呈批件;六、商務談判過程;七、提交合同簽訂呈批件階段;八、到貨驗收階段;九、試運行階段;十、項目驗收階段。
6、 原則上產(chǎn)品供應商的選擇不少于3家，如果產(chǎn)品唯一那么集成商或代理商選擇不少于3家。
二、需求處理流程規(guī)定示例
需求提出者在ITSM系統(tǒng)流程中向職責對應團隊小組提出需求，承接團隊對需求進行分析處理，處理流程示例如下圖1-5。
圖1-5
三、故障處理制度流程示例：
1. 故障來源于客戶報告、值班人員巡查、監(jiān)控系統(tǒng)監(jiān)控、日常例行檢查等。
2. 根據(jù)故障對用戶的影響程度，對故障進行如下分類：
嚴重故障：生產(chǎn)系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡性能嚴重降低，應用系統(tǒng)運行緩慢，工具軟件不可用，機房供配電系統(tǒng)發(fā)生故障等對生產(chǎn)安全運行存在嚴重隱患，開發(fā)、測試、災備、應急系統(tǒng)不可用，或對用戶使用產(chǎn)生嚴重影響的故障。
重大故障：生產(chǎn)系統(tǒng)(含子系統(tǒng))、數(shù)據(jù)庫、應用系統(tǒng)不可用、網(wǎng)絡中斷、機房供配電系統(tǒng)停止運行等影響生產(chǎn)安全、無法保障用戶使用的故障。
一般故障：生產(chǎn)系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡、機房供配電系統(tǒng)、工具軟件等告警或運行狀態(tài)不正常，開發(fā)、測試、災備、應急系統(tǒng)發(fā)生問題，且不影響用戶正常使用的故障。
故障癥候：生產(chǎn)系統(tǒng)(含子系統(tǒng))、數(shù)據(jù)庫、應用系統(tǒng)有故障癥候，報故障代碼或故障消息，或者對生產(chǎn)正常運行存在易患， 并可在一定時限內解決的故障。
3. 當故障發(fā)生在工作時間內，由故障發(fā)現(xiàn)者通知崗位工程師，崗位工程師依據(jù)《工作上報批準規(guī)范》進行信息通報上級經(jīng)理，將故障記錄填寫到ITSM的事件流程中，并負責故障處理。各級經(jīng)理決定通知相關崗位和客戶的范圍和方式。當故障發(fā)生在非工作時間，由值班人員按照《電話值班管理規(guī)定》通知電話值班工程師處理，并在隨后的一個工作日內記錄在ITSM服務管理系統(tǒng)中，電話值班工程師依據(jù)《工作上報批準規(guī)范》進行上報上級經(jīng)理，由科室經(jīng)理決定通知相關崗位和客戶的范圍和方式。
4. 故障受理人負責故障處理，當需要服務商工程師到現(xiàn)場時，故障受理人聯(lián)系服務商工程師，并陪同服務商工程師進行故障處理。當故障持續(xù)時間較長需要輪換故障處理人員時，要做好故障處理交接工作，并將前期處理情況和過程以文字形式交接給接續(xù)人員，并通報科室經(jīng)理，接續(xù)人員繼續(xù)承擔處理故障職責。
5. 上級經(jīng)理跟蹤下級故障處理過程。
6. 故障處理完畢后，由故障處理人員通知上級經(jīng)理，告知故障已經(jīng)解決，并由經(jīng)理決定通知相關崗位和客戶的范圍和方式，最后故障處理人員或運維主管將ITSM中的事件流程中的故障記錄填寫完整。
7. 需要升級到問題的故障轉入問題流程，后續(xù)按照《問題管理規(guī)定》處理。
四、應急(演練)管理流程示例：
制定應急管理流程的目的是為了在發(fā)生應急事件時，各相關生產(chǎn)部門能根據(jù)流程對應急事件進行通報、指揮、處理和協(xié)調，最大限度地降低事件所帶來的不利影響，使得應急事件能夠得到有效的管理應急管理流程示例如下圖1-6：
圖1-6
1.4.3安裝配置標準
1.4.4 安全制度
隨著物聯(lián)網(wǎng)、云計算、大數(shù)據(jù)、移動網(wǎng)絡等高新技術引領信息發(fā)展的新高潮，政治經(jīng)濟的復雜性，使得現(xiàn)在及未來信息安全愈發(fā)至關重要。也因此信息安全運維也至關重要。本小結僅作示例，后續(xù)章節(jié)將再單獨介紹信息安全。
1.5運維知識體系規(guī)劃
綜上所述，不論是傳統(tǒng)的運維體系還是互聯(lián)網(wǎng)運維體系，兩者之間并非涇渭分明，而是難分難解。不同行業(yè)背景的運維，雖有各自的差異，但運維大環(huán)境與趨勢是一致的?？梢灶A想未來一段時間，運維趨勢具有如下特點：
- 傳統(tǒng)IT運維與互聯(lián)網(wǎng)IT運維仍將長期并存。
- 傳統(tǒng)運維方式與基于云計算的運維方式將長期并存。
- 公有云與私有云及混合云運維局面將長期并存。
- 基于業(yè)務場景的運維仍將是運維價值觀方向。
- 完全閉源的生態(tài)環(huán)境和完全開源的生態(tài)環(huán)境是兩個極端，更多的IT生態(tài)是混合狀態(tài)。
- 運維部門將由傳統(tǒng)的IT成本中心向IT服務中心、價值輸出中心、利潤輸出中心轉變。
- 研發(fā)、運維及業(yè)務之間的邊界也并非黑白分明，DevOps的理念逐步深入各行業(yè)。
這里從一個架構高度看待和規(guī)劃運維。正如前文所述，我們從人、事、物、流程這四個方面共同構建了一個完整實用的運維體系。如下將基于上述理論給出一套整體示例。
人員事情軟硬件物資流程規(guī)范產(chǎn)品技能知識點舉例
【本文為51CTO專欄作者“韓曉光”的原創(chuàng)稿件，轉載請通過51CTO聯(lián)系作者獲取授權】
戳這里，看該作者更多好文
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
