學習目標

• 1、了解運維的基本概念
• 2、了解企業的運行模式
• 3、了解操作系統發展史以及作用
• 4、掌握虛擬機軟件安裝
• 5、新建虛擬機以及centos系統安裝
• 6、運維規范

一、運維概述

1、運維崗位收入情況（職友集）

2、運維崗位的定義

什么是運維？

在技術人員（寫代碼的）之間，一致對運維有一個開玩笑的認知：運維就是修電腦的、裝網線的、背鍋的崗位。

IT運維管理是指為了保障企業IT系統及網絡的可用性、安全性、穩定性，保障業務的連續性，通過專業技術手段，對計算機網絡、應用系統、電信網絡、軟硬件環境及運維服務流程等進行的綜合管理。

隨著企業數字化轉型升級進程加快，企業IT系統架構越來越復雜，軟件更新迭代越來越快。企業信息化建設使得大量業務和數據需要依靠信息系統來完成，穩定可用的IT系統是企業業務發展的基礎條件，IT運維管理隨之成為企業信息化建設的重要環節。

近年來，因為IT系統突然出現故障導致業務癱瘓甚至造成巨額損失的現象頻出不窮。而大型數據中心由于對系統、數據的高度依賴，IT風險更大，對IT運維管理的重視也就更高。

運維領域經常看到的技術及概念

1）云計算

云服務器是由云服務廠商提供的性能卓越、穩定可靠、彈性擴展的IaaS（Infrastructure as a Service）級別云計算服務。云服務器免去了采購IT硬件的前期準備，讓企業像使用水、電、天然氣等公共資源一樣便捷、高效地使用服務器，實現計算資源的即開即用和彈性伸縮。

2） DevOps

DevOps（Development和Operations的組合詞），它是一組過程、方法與系統的統稱，主要用于促進開發和運營保障團隊之間的協作與溝通，從而提高應用程序和服務的交付響應速度。

DevOps把原本獨立的開發和運營工作融合到一起，運營團隊時刻了解開發人員的進展，并與他們形成互動，共同監控IT業務進展。在運維方面，DevOps可以打通從需求到結果運行的所有環節，以提高業務價值為目標

3） AIOps

2016年，Gartner提出利用AI技術的新一代IT運維，即AIOps（智能運維），可以解決未來企業可能遭遇的因IT故障而導致的業務中斷，AIOps是ITOM的升級和進步，它結合了大數據和機器算法、機器學習技術，通過海量信息的搜集和處理，發現、預測、解決故障，進一步推動了IT運維自動化，減少了人力成本。

4）CI/CD

CI/CD 是一種通過在應用開發階段引入自動化來頻繁向客戶交付應用的方法。CI/CD 的核心概念是持續集成、持續交付和持續部署。作為一個面向開發和運營團隊的解決方案，CI/CD 主要針對在集成新代碼時所引發的問題

5）Docker

Docker 是一個開源的應用容器引擎，通常包括客戶端、守護進程、鏡像、容器，讓開發者可以打包他們的應用以及依賴包到一個可移植的鏡像中，再發布出去。類似于一個集裝箱，可以把貨物規整的擺放起來。

3、運維的誕生

從最早的網管開始，九十年代初期，互聯網欠發達的時候，還少有服務器的概念，電腦價格昂貴，大多數人并不具備在家上網的條件，網吧應運而生。

網吧的電腦、貓等設備需要進行日常維護，于是"網管"崗位應運而生，這就是早期運維的雛形。

4、90年代初網吧圖

5、運維行業背景

① 從行業角度來看，隨著中國互聯網的高速發展(BAT)、網站規模越來越來大、架構越來越復雜，對專職網站運維工程師、網站架構師的要求會越來越急迫，特別是對有經驗的優秀運維人才需求量大，而且是越老越值錢。

② 從個人角度，運維工程師技術含量及要求會越來越高，同時也是對公司應用、架構最了解最熟悉的人，越來越得到重視。

③ 運維工作的相關經驗將會變得非常重要，而且也將成為個人的核心競爭力，優秀的運維工程師具備很好的各層面問題的解決能力及方案提供、全局思考的能力等。

④ 由于運維崗位所接觸的知識面非常廣闊，更容易培養或發揮出個人某些方面的特長或愛好，如內核、網絡、開發、數據庫等方面，可以做得非常深入精通、成為這方面的專家。

⑤ 當前國內外對運維人才的需求非常迫切，運維工程師的薪資也水漲船高，與研發、測試等技術部門持平，甚至超出。

二、企業運行模式

1、鐵三角

鐵三角 = 產品 研發 運維

流程走向：產品設計 → 項目研發 → 項目測試 → 項目上線 → 系統運維

2、部門與部門職責

產品部門（PM、UI、UE，3-5 個）：設計產品的需求，確定需要做的項目的功能和細節問題

研發部門（5-7 個）：根據產品部門/測試部門提供的項目模塊需求進行編程

測試部門（2 個左右即可）：對于研發部門提供的代碼進行運行測試，檢查是否存在bug和一些需要改善的體驗

運維部門（3-4 個）：負責項目環境部署、上線、架構的搭建等等

3、上線與生產

成熟企業中的系統環境：

開發環境： 根據系統要求，設計和搭建系統環境

測試環境：搭建系統環境，實現自動化發布

準生產環境：搭建系統環境，溝通第三方廠商，自動化發布，監控

生產環境：搭建系統環境，溝通第三方廠商，自動化發布，監控，發起持續改進

上線：發布項目的過程，包含準生產上線，生產上線等。內測/公測 → 開服

生產：正式提供對外服務的環境，叫生產環境，需要運維重點關注。

在項目的從無到有的過程中，可以將其分為兩個階段：研發/測試階段、生產運行階段。

運維工作貫穿了開發，測試，生產的各個階段，是其中重要的一環。

4、網站的概念

簡單地說，網站是一種溝通工具，人們可以通過網站來發布自己想要公開的資訊，或者利用網站來提供相關的網絡服務。人們可以通過網頁瀏覽器來訪問網站，獲取自己需要的資訊或者享受網絡服務。

擴展：了解網站的分類根據網站所用編程語言分類：例如ASP/PHP/JSP網站等；根據網站的用途分類：例如門戶網站、行業網站、娛樂網站等根據網站的功能分類：例如單一網站（企業網站）、多功能網站（網絡商城）等根據網站的持有者分類：例如個人網站、商業網站、政府網站、教育網站等根據網站的商業目的分類：營利型網站（企業/行業網站）、非營利性型網站（政府網站/教育網站）根據網站的面向終端的分類：Web網站（電腦端或PC端）和 WAP網站（手機端）

5、網站運行模式（重點）

從上圖中可以看出如果一個網站項目需要正常的運行，則需要的前提條件有：

① 域名（方便用戶記憶）

② 需要對域名和ip 的關系進行關聯（DNS 服務器）

③ 服務器

④ 服務器的項目運行環境

6、幾個重要概念

① 服務器

就是給用戶提供服務的機器（電腦）。服務器可以分為四大類：塔式服務器、機式服務器、刀片服務器、柜式服務器。

問題一：普通臺式機/筆記本能否充當服務器來使用？

標準的回答：如果從提供服務的實現角度來考慮的話的確是可以，但是如果要想穩定、高效的提供服務，則在這個角度考慮家用電腦和筆記就無法取代服務器地位。

家用臺式機/筆記本從系統角度來看，一般都會使用Windows 系統（易用），并不適合作為服務器來使用。

家用臺式機/筆記本硬件和專門的服務器相比標準不統一。

問題二：服務器有哪些特性？

高性能特性 標準化統一特性。

② IP地址

形式ipv4（常見）、ipv6（不考慮）。Ipv4 形式：x.x.x.x，x 有取值范圍（第1 位x取值1-223，從第二位開始0-255）。由于資源有限為了保證全球這么多臺電腦都可以使用，ip 可以分為公網/外網ip 和私網/內網ip 地址。

0.0.0.0，表示任意地方，anywhere…

③ 域名

就是在瀏覽器地址欄中輸入的那一串字母和數字的組合，例如：www.baidu.com，這個就是域名，域名主要是方便用戶記憶。

問：www.baidu.com 這個域名是幾級的域名？二級域名，看域名的級別只要看有幾個"."，日常所說的注冊域名指的是注冊頂級域名（一級）】

④ 公網

www（萬維網），全世界都可以互相訪問的網。

⑤ 局域網

局域網/內網/私網：在某個單元內部（家庭/教室/公司）能夠進行互相訪問的網絡，紅色警戒游戲對戰平臺。

7、服務器的重要結構組成

家用電腦組成： CPU、主板、內存條、顯卡、硬盤、電源、風扇、網卡、顯示器、機箱、鍵盤鼠標等等。

1）CPU

CPU是電腦的大腦，如下圖所示：

CPU發展史：

32 位CPU：最大的內存尋址地址2^32，大約4G的大小。

聊聊2的32次方怎么算？

1T = 1024GB 1GB = 1024MB 1MB = 1024KB 1KB = 1024B

2^32B = 2^32 /1024/1024 /1024 = 4GB

2）內存

內存也是電腦必需組件之一。

計算機是一個商鋪：CPU相當于人，內存相當于倉庫。商品必須上架才能顯示。

3）風扇

4）電源

5）硬盤

硬盤的作用：存儲數據。

硬盤可以分為機械硬盤、固態硬盤。

6）主板

主要的作用：

自身包含了一些集成電路，負責各個不同的功能和數據通信。

主板上有很多空的插槽，插槽的作用在于擴展外部的硬件設備。

三、操作系統概述

1、計算機發展史

第一臺計算機是1946 年2 月14 日誕生日，第一臺名稱ENIAC。體積一間屋子的大小，重量高達28t。

第一代：1946 – 1958 => 12 年 （電子管）

第二代：1958 – 1964 => 6 年 （晶體管）

第三代：1964 – 1970 => 6 年 （集成電路）

第四代：1970 – 至今 （大規模集成電路）

2、計算機組成

CPU、內存、風扇、硬盤、顯示器、主板、電源、聲卡、網卡、顯卡、鼠標、鍵盤等

3、計算機資源（重點）

計算機資源分為2 部分：硬件資源、軟件資源

硬件：一般硬件是指計算機的物理組成，由真實（看得見，摸得著）的設備組成的

軟件：軟件一般是指應用程序，應用程序程序是由開發人員去按照編程語言的特定的規則去

編寫的程序。除了上述的應用程序之外，操作系統也屬于軟件資源的范疇，它屬特殊的軟件。

問題：為什么在打開一個應用程序之后（吃雞游戲），當玩家在敲擊鍵盤和移動鼠標的時候里

面人物會有對應的行為表現呢？

答：用戶敲擊鍵盤/移動鼠標（硬件操作） → 硬件的驅動（軟件資源） → 操作系統（軟件） → 硬件支持（cpu） → 操作系統（軟件） → 驅動（顯卡驅動） → 顯示在屏幕上（硬件）

所以由此可知，操作系統是軟件資源與硬件資源之間的橋梁。

4、操作系統

常見操作系統有：Windows、MacOS、Unix/Linux。

Windows：其是微軟公司研發的收費操作系統（閉源）。

Windows 系統體系分為兩類：用戶操作系統、Server 操作系統。

用戶操作系統：win 95、win 98、win NT、win Me、win xp、vista、win7、win8、win10。

MacOS：其是由蘋果公司開發的一款收費（變相收費，買電腦送系統）操作系統。該系統從

終端角度來看分為：watch OS、IOS、MacOS。其表現突出的地方：底層優化實現的很好、安

全性要更加高點（閉源）。

Linux：Linux 是目前全球使用量最多的服務器操作系統（開源）。其體系很強大，其分支有

很多（數不勝數），其目前主要的分支有：redhat（紅帽）、Debian、烏班圖（ubuntu）、CentOS

等等。其在世界范圍最大的使用分支是安卓。

閉源：不開放源代碼，用戶是沒有辦法看到軟件的底層實現（閉源≠收費）。

開源：表示開放源代碼（開源≠免費）。

5、為什么需要Linux操作系統

問題：windows 既然可以使用傻瓜式的方式進行操作，例如使用ctrl c 表示復制，ctrl v 表示粘貼等，為什么還需要使用/學習Linux 系統？

① 性能問題，Windows 服務器操作系統不如Linux 高；

② 穩定性問題：

底層架構：Linux 更加穩定，其開機時間可以達到好幾年不關機；

開源：因為開源，人人都可以看到源代碼，就可以為其提供自己的補丁，補丁可以提高 穩定性和安全性；

③ 安全性問題：

Linux 操作系統，相對于windows 操作系統要更加安全；

④ 遠程管理方面：

Windows 不及Linux 操作高效。

⑤ 服務器價格昂貴的，需要對資源進行充分利用，充分把計算機資源用到項目上（訪問并發、性能），而不是把資源浪費在圖形化界面或者方便程度上；

四、Linux發展史

1、Linux 起源

##

2、Linux 的含義

狹義：由Linus 編寫的一段內核代碼。

廣義：廣義上的Linux 是指由Linux內核衍生的各種Linux發行版本。（CentOS、Ubuntu）

注意：以后提及到的Linux 都是廣義上的Linux

3、Linux特點

開放性（開源）、多用戶、多任務、良好的用戶界面、優異的性能與穩定性

多用戶多任務：

單用戶：一個用戶，在登錄計算機（操作系統），只能允許同時登錄一個用戶；

單任務：一個任務，允許用戶同時進行的操作任務數量；

多用戶：多個用戶，在登錄計算機（操作系統），允許同時登錄多個用戶進行操作；

多任務：多個任務，允許用戶同時進行多個操作任務；

Windows 屬于：單用戶、多任務。

而Linux系統則屬于：多用戶、多任務。

4、Linux分支(Linux衍生版：Linux廠商基于Linux內核)

分支：Linux 分支有很多，現在比較有名的redhat、ubuntu、debian、centos（Community Enterprise Operating System）、suse 等等。

中國Linux系統：紅旗（Redflag）、麒麟、深度OS

CentOS6.9

CentOS7.5

五、Linux系統安裝

1、Linux系統安裝方式

目前安裝操作系統方式有2 種：真機安裝、虛擬機安裝。

真機安裝：使用真實的電腦進行安裝，像安裝windows 操作系統一樣，真機安裝的結果就是替換掉當前的windows 操作系統；

虛擬機安裝：通過一些特定的手段，來進行模擬安裝，并不會影響當前計算機的真實操作系統；

如果是學習或者測試使用，強烈建議使用虛擬機安裝方式。

2、虛擬機概念

什么是虛擬機？

虛擬機，有些時候想模擬出一個真實的電腦環境，礙于使用真機安裝代價太大，因此而誕生的一款可以模擬操作系統運行的軟件。

虛擬機目前有2 個比較有名的產品：vmware 出品的vmware workstation、oracle 出品的virtual Box。

3、虛擬機的安裝

第一步：雙擊打開VMware安裝程序

第二步：進行下一步安裝

第三步：同意許可協議，單擊下一步

第四步：根據需要決定是否需要更改軟件的安裝位置（建議放置于除C盤以外任意盤符下）

第五步：更改成功后，單擊確定，下一步繼續安裝：

注意：所有軟件的安裝目錄最好在安裝的時候是空的

第六步：用戶體驗設置，如下圖所示，單擊下一步繼續安裝

第七步：快捷方式設置，單擊下一步繼續安裝。單擊安裝按鈕、安裝結束后，單擊完成按鈕

注意事項：最重要的地方，在安裝完之后需要檢查，檢查虛擬機軟件是否有安裝2 個虛擬網卡

Windows7與Windows10可能顯示網絡名稱有所不同，但是底部虛擬機網絡是一致的。

4、Linux系統環境部署

Linux系統版本選擇：CentOS7.6 x64，【鏡像一般都是CentOS*.iso文件】

問題：為什么不選擇最新版的8 版本？

7.x 目前依然是主流

7.x 的各種系統操作模式是基礎

官網：https://www.centos.org/ ，從官網下載得到的鏡像文件：

Centos7.6版本下載地址：

http://vault.centos.org/7.6.1810/isos/x86_64/CentOS-7-x86_64-Everything-1810.iso

第一步：新建虛擬機，點擊"文件"菜單，選擇"新建虛擬"選項，選擇"自定義"點擊下一步：

第二步：選擇兼容性，默認即可，選擇鏡像文件的時候選擇"稍后安裝操作系統"，單擊下一步：

第三步：設置虛擬機的名稱（名稱將會后期出現在左側）和設置虛擬系統的安裝位置

第四步：CPU設置，提示：根據自身電腦配置選擇CPU設置，一般默認即可，1*1

第五步：分配虛擬機內存

第六步：選擇虛擬機網絡類型，默認選擇NAT即可。

NAT：配置好之后windows 即可和虛擬機進行互相通信，但是教室內的其他同學是訪問不了的，只有自己可以訪問虛擬機中的操作系統。

橋接：配置好之后其他同學也可以訪問你的虛擬機操作系統。

第七步：后續默認的步驟，直接下一步，安裝完畢后，單擊完成：

5、CentOS系統安裝配置

第一步：選擇CentOS系統安裝鏡像【*.iso文件】

第二步：開啟虛擬機，進行系統安裝

特別注意：如果在啟動時候出現下述錯誤，則說明電腦沒有開啟cpu 的虛擬化，如果需要開啟，則需要重啟計算機，并且在開啟的時候進入主板的BIOS 設置開啟虛擬化，然后保存設置重啟電腦：

第四步：選擇安裝centos7（通過↑ 或 ↓方向鍵進行選擇），確認后，按下回車

第五步：等待一會兒后，將彈出歡迎使用CENTOS 7的界面，選擇中文，簡體中文（中國），點擊繼續

第六步：在安裝信息摘要界面，點擊軟件安裝，進入軟件選擇界面

第七步：在軟件選擇界面，選中左側GNOME Desktop，勾選右側所有項目，點擊完成，回到安裝信息摘要界面。

點擊INSTALLATION DESTINATION

進入磁盤配置頁面，直接點Done，不需要做其他更改，只是確認使用自動分區

第八步：點擊開始安裝

第九步：進入安裝進度頁面

第十步：點擊ROOT密碼，進入密碼設置頁面，輸入兩次ROOT賬戶的密碼，例如1234。第一次點擊完成，會提示Too short，密碼太短，再點擊一次完成，確定使用簡單密碼。（生產環境要設置足夠復雜的密碼）

第十一步：回到安裝進度頁面，顯示已經設置了ROOT密碼，等待安裝完成即可。

第十二步：安裝完成后，右下角會出現重啟按鈕，點擊重啟

第十三步：重啟之后，來到初始設置頁面，點擊license information

第十四步：勾選我同意許可協議，點擊左上角完成，回到初始設置頁面

第十五步：網絡和主機名，創建用戶都不用操作，直接點擊右下角完成配置

第十六步：進入到歡迎頁面，點擊前進

第十七步：輸入頁面，默認漢語，點擊前進

第十八步：隱私，位置服務，默認開啟，點擊前進

第十九步：時區，在對話框中輸入shanghai，會自動聯想出對應時區，點擊右上角前進。

第二十步：在線賬號，選擇跳過

第二十一步：全名任意填寫，用戶名默認和全名一致，此處的用戶名，是一個普通的賬戶，區別于ROOT賬戶。點擊前進。

第二十二步：填寫密碼，注意需要包含數字，字母，特殊字符，此處密碼是前面創建的itheima這個賬戶的密碼

6、安裝后配置

為了試驗方便，取消centos的屏幕鎖定

點擊桌面右上角的電源標志，在彈出菜單下方，點擊設置按鈕

選擇左側的Power（電源）按鈕，右側選擇Never（從不），這樣Centos就不會每五分鐘自動鎖屏了，方便大家操作。

注意：自動鎖屏是出于安全考慮，工作環境盡量不要關閉。

選中后，直接點擊右上角關閉即可，系統會自動保存配置

六、運維規范

1.1 運維不簡單

前陣子，跟一個項目經理溝通能否提前半天將變更申請提交過來時，這位項目經理很不理解的問我，“你們運維不就是在生產環境部署個程序這么簡單的工作嗎？你們又不懂程序，評審不出什么吧？”。

運維多年，對運維的這類認識聽過很多，它反映了企業里不同的組織團隊對運維的認識往往僅限于一些簡單操作性的工作，比如生產應用系統在故障時的重啟、應用變更時敲敲命令、平時增刪改查數據，或者是辦公室和電有關的所有軟硬件的使用問題等等。

那么如何理解運維呢？百度百科對運維的解釋為：企業 IT 部門采用相關的方法、手段、技術、制度、流程和文檔等，對IT 軟硬運行環境(軟件環境、網絡環境等)、IT 業務系統和 IT 運維人員進行的綜合管理。從百度百科的解釋看，運維崗位需要一個綜合性的技術與管理能力，需要掌握大量的方法論與技術棧。

運維狹義“運維技術與資源”可以定義為“監、管、控”，技術與資源主要是支撐運維/運營的質量、效率、成本的平衡。以下簡單摘錄了運維的一些能力要求：

• 運維規范的落地：以ITIL、ISO20000、ITSS.1等方法論，結合外部監管及內部規范的落地；
• 監管機構的要求落地：理解、快速響應、落地監管機構的管理要求；
• 基本保障：配置、監控、應用發布、資源擴容、事件、問題等；
• 基礎能力：網絡、服務器、操作系統、數據庫、中間件、JVM、應用等基本使用與調優；
• 業務服務能力：SLA，服務臺、業務咨詢、維護、經驗庫、等支持能力；
• 可用性管理能力：巡檢、業務系統連續性、可用性，基礎架構及應用系統的高可用、備件冗余資源；
• 風險、安全管理能力：操作、審計、監管風險，漏洞、攻擊管控；
• 故障管理能力：事件、問題管理水平與能力；
• 持續交付能力：應用變更、基礎資源、辦公服務交付能力；
• 主動優化能力：架構優化、性能響應效率、客戶體驗等
• 應急演練：架構高可用、突發事件、業務故障的架構、方案、文檔、人員熟練程度等
• 業務支撐：數據維護、數據提取、參數維護等；
• 運行分析能力：容量、性能、可用性分析等；
• 運營能力：促進業務痛點的發現與解決、客戶及業務業務體驗等；
• 成本控制：更好的評估人力、硬件、帶寬、軟件，節省成本；
• 運維開發：運維自動化工具的建設，運維開發能力的培養；
• 其它

不同的企業需要運維的能力會有不同的擴展，同進上述能力要求每一點擴散出來都將是一個復雜的技術棧，比如“基礎能力”中的LINUX操作系統的內核關系圖（摘自互聯網見，圖1.1），或再深入一些關于mysql優化（摘自互聯網見，圖1.2），需要運維人員對技術能力深度的要求。

講到這，肯定會有人說上述的技術棧的能力要求通常是由于某個運維組織的仍處于專家式運維，自動化程度不夠高導致。

的確，理論上所有運維操作性、命令的工作都可以整合為經驗，并通過自動化落地實現，現在互聯網企業對外都宣稱自動化在運維工作覆蓋面很高，己經開始邁向智能化，AIOps，甚至提出了NoOps的解決方案。

關于這些互聯網企業的自動化對日常運維工作真實的覆蓋面暫時無法考究，但以我的經驗看，至少金融企業的自動化覆蓋面還有很長的路要走，且肯定還會很大一部份工作很難自動化，畢竟工作類型太多，在有限的投入上只能集中力氣去做投入產出比更高的運維自動化。

這里再以一個運維工具思維導圖（圖1.3）簡單列示一些常規的運維操作，可以看出其實很難有一套能解決所有運維操作的工具平臺。

所以我覺得，隨著業務要求越來越高、規模越來越大、監管要求越來越高，縱使外部如何宣稱自動化、智能化對運維人員經驗、技術、管理能力替代，金融企業內的運維還需要認清實際情況，結合企業的整體戰略定位，強調運維團隊在運維管理與技術能力的廣度與深度，再有側重、有先后的實現自動化水平。

在未來一段時間里，金融企業的運維崗位仍是一個復雜的、綜合性技能的工作崗位。

1.2運維之痛

近年來，隨著運維技術的快速發展，各行業的運維水平在得到了較大的提升同時，運維圈的分享也越來越開放，從國外google的SRE理念，到國內新技術領跑者騰訊游戲的藍鯨、織云，以及借助于各種運維專題的公眾號、運維大會有大量的互聯網、傳統企業的運維組織進行分享。

1.2.1組織之痛

前面講過，在企業內部其它團隊對運維的認識通常是簡單操作，出故障時才會找的同團隊，隨著信息技術的發展與業務的發展，運維組織痛點越來越明顯，企業內對運維組織的不滿的聲音越來越多，反思一下原因，分外部客觀因素和內部因素。

1）外部客觀因素

在當前大數據時代，金融企業的運維面臨業務規模的不斷擴大，業務競爭越來越激烈，監管要求越來越高，數據中心的規模也越來越高，大量新技術、開源架構的引入取代了傳統穩定的系統架構等等因素影響。

• 運維組織的角色：絕大部份運維組織都是一個成本部門，企業對運維組織的重視程度通常不如開發組織，更不用說是前臺業務部門。這方面造成了運維部門的規模通常增長很慢，以 Google 為例，在《Google SRE 運維解密》一書中提到，由于Google的數據中心規模急劇擴大，系統越來越復雜，而運維人員規模又跟不上，所以他們的運維組織采用組建 SRE 的運維開發團隊實現自救。
• 業務對運維服務質量的要求：越來越多的金融業務己從線下走到線上， 為了贏得更多用戶的青睞，一方面，業務要求更多、體驗更佳的業務性能；另一方面業務對應用發布的交付速度有了更高的要求。前者會產生更復雜的系統設計，后者需要更高效的應用發布支持，兩者都會對系統響應效率、穩定性帶來影響。
• 外部監管要求：長期以來，為了防范金融風險，監管機構對金融企業保持強監管的方式，十九大之后，監管對金融企業的信息技術的穩定性、規范性有增無減。在強監管下，信息系統的穩定性有了進一步保證，但也給運維組織帶來更高的要求，客觀上也加大了工作量，并由于規范流程帶來的工作效率的下降。
• 業務并發要求：用戶量的增加，營銷活動不斷推出，需要系統具備更高的并發處理能力要求，企業不斷引入大量分布式、開源架構替代傳統相對成熟穩定的架構來滿足業務需要，這些變化都給運維能力帶來挑戰。
• 數據中心規模增大：數據中心的多中心建設，云化，去IOE，分布式架構的引入使得應用系統規模成倍的增大。

2）內部因素

網上有一個調查數據，在整個運維成本的分配中，軟硬件和網絡設備的維護成本占 30%，維護服務成本占30%，內部運維人力成本則占了40%。

這里的人力成本包括現在維護、培訓、流失與引入等成本，如果將維護服務成本也納入到人力成本之上，則人力這一塊的成本將上升為70%，影響這個人力成本的因素主要有：

• 運維能力模型：ITIL、ISO20000、ITSS.1是運維領域中比較成體系化的方法論（目前更為火爆的 DevOps 更傾向于是一種思路），其中只有ITSS.1提出了運維能力模型的概念，但在量化運維人員具體能力的實際操作上也比較難落地。也就是說你很難評價一個運維人員如何做才是做得優，如何是中，如何差，這些評價通常比較主觀，這也客戶觀影響了運維人員不斷增加技能、優化工作效率的動力。
• 運維規范化：組織擴大到一定規模，以口口相傳的傳授，結合個體責任心、工作習慣為主的方式容易出現操作風險，且無法進行量化績效管理，管理規范無法落地。
• 運維精細化程度：組織通常是從縱向職能型的方式形成，這種方式能培養全能型、經驗豐富的專家式人才，這些專家式人才利用經驗能快速解決職責下的常規問題，且效率比較高，適合小型的組織。
• 隨著組織的不斷壯大，面對的問題越來越復雜，技術要求越來越多，一方面很多人不能滿足這種專家式人才的要求；一方面也會產生很多重復性的工作；同時對于人員流失帶來的影響比較大。這時候就需要將縱向工作精細化，再輔助橫向人員對工作進行持續的優化。
• 運維目標：運維的目標往往以被動式的目標為主，被動處理故障、被動解決問題、被動提供應用交付、被動節省成本等，這種被動式的運維目標導致計劃性工作不夠，缺乏持續不斷的自我優化，主動提高效率、質量，降低成本，并由運維向主動運營目標去轉變。
• 自動化能力：IT軟硬件體量龐大，且增長迅速，手工操作的機器任務太多；運維數據越來越多；故障定位越來越難，人工經驗依賴高；監控手段不夠及時、全面；應用發布、資源交付效率低下；沒有主動的容量、性能分析、體驗分析能力……這些都是常見的一些痛點。
• 個體之痛作為運維組織中的運維人員同樣面臨不少痛點，有來自工作時間、工作壓力、學習壓力、職業發展等等，以下簡單羅列：
• 7*24小時制的工作時間：運維人員的節假日是不完整的，通常節假日需要運維值班保障或在家通過VPN遠程操作、或和家人團聚時還遠程指導進行故障應急；運維人員上班時間不同普通工作，為了不影響業務，應用發布、基礎設施變更、演練等工作都會放到晚上，對客的業務系統還可能要安排到深夜。這種隨時可能發生，隨處理可能要處理的工作狀態是其它行業所不具備的痛點。
• 高度壓力的工作：“如履薄冰”很好的形容了運維的工作狀態，因為任務一個生產操作都可能對業務帶來影響，所以運維的操作必須十分謹慎。同時在運維故障處理過程中，運維人員需要面臨著來自業務、客戶、開發、領導的各層的壓力下，冷靜的完成故障處理，是一個高壓的工作狀態。
• 被動的工作：經常會有人形容運維就是一個“消防員”的工作，也就是被動救火的工作，這個形容很貼切，在缺乏一些主動分析、優化、預測性的工作的背景下，運維組織的大部份工作是以被動為主，是負責應急救火、打掃戰場、負責收尾的那群默默的人。
• 對工作的認識：運維的人通常會認為自己就是一個背鍋的角色，開發程序問題、硬件問題、系統軟件問題、業務需求問題都需要運維去解決，而且這些問題對可用性的影響還要運維來承擔，這是運維特有的痛點。
• 職業壓力：運維工作一方面主要是和機器或系統軟件打交道，所以相對于開發、項目管理等IT崗位，轉型機會的面比較窄；同時，運維崗位中重復操作性的工作占比多，如缺乏引導容易讓運維人員產生麻木的狀態，失去持續改善的動力；另外，前面也提到運維需要掌握的技能和管理理念很多，對于運維人員的學習能力要求很高。

1.3 自救

1.3.1 SRE

SRE這個名詞最早是從《Google SRE 運維解密》一書中獲得，全稱是Site Reliability Engineering，翻譯過來就是：站點可靠性工程師。

Google 對 SRE 的職責描述為：確保站點的可用，為了達到這個目的，一方面他需要對站點涉及的系統、組件熟悉，也要關注生產運行時的狀態，為此，他需要自開發并維護很多工具和系統支撐系統的運行，比如自動化發布系統，監控系統，日志系統，服務器資源分配和編排等。SRE是一個綜合素質很高的全能手，如果對他的能力進行分解主要有三塊：

• 熟悉系統架構與運行狀態：SRE需要懂服務器基礎架構、操作系統、網絡、中間件容器、常用編程語言、全局的架構意識、非常強的問題分析能力、極高的抗壓能力（以便沉著高效地排障），他們還需要懂性能調優理論。為了保證系統架構的高可用，SRE甚至會有意識的破壞自己的系統，以提高系統可用性。
• 熟悉運維涉及的管理方法：SRE需根據企業自身發展需要，清楚運維涉及的各項工作的流程方法論，比如故障處理、應用發布、可用性管理等等，SRE十分重視運維流程的持續改善，比如對故障的追根溯源，懷疑一切的方式持續改進。
• 運維開發 產品經理：SRE 在運行保障過程中的手段更加自動化，更高效，這種高效來源于自動化工具、監控工具的支撐，且他們還需要是這些工具的主要開發者，他們要不斷優化和調整，使整個工具箱使起來更加得心應手。為此SRE有一個50%的理念，就是50%用于日常保障，50%用于項目性的工作，這個項目性的工作主要體現在運維開發與運維產品經理的角色。
• 運維開發關于運維開發的理解主要體現在運維工具層面，不同的組織有不同的理解，通常有三類：
• 完全自建：運維開發團隊利用開源技術結合自身需要進行一定的二次開發，這種方式在互聯網企業比較流行，具體的成效大小與何時能起來收效與對這個運維開發團隊的整體規劃或資源投入有關；
• 外購開發資源或工具產品：運維開發團隊主要是結合企業痛點承擔產品經理的角色，設計、跟進、推廣工具，這種方式常出現在傳統的企業，尤其適用于投入運維開發人員比較少的企業，這種方式是投入收效快，但是對外部資源依賴比較大，不利于后續持續建設；
• 外購與自建相結合：運維開發團隊在整個工具體系下，針對部份組件選擇性的引入一些成熟的工具體系，同時要求這類成熟的工具需要開放一定的接口或源碼支持，對于一些與公司個性強的環節采用自研的方式。這種方式目前逐漸被運一些傳統企業，比如金融企業所接受。

總的來說，不管選用上面哪一種方式，運維開發團隊都應該有一個整體、統一的一體化工具建設規劃，并在建設過程中始終保持對運維工具體系的掌控能力，并在工具體系的上層為其它運維人員提供簡易的、可創造性的“開發能力”，比如所見即所得的工具可視化、可定制的運維報表、拖拉拽方式的流程及腳本組件的拼裝等運維開發方式。

1.3.3 DevOps

1.3.3.1 DevOps 概述

DevOps 一詞的來自于 Development 和 Operations 的組合，突出重視軟件開發人員和運維人員的溝通合作，通過自動化流程來使得軟件構建、測試、發布更加快捷、頻繁和可靠，他是一種方法論，包含一套基本原則和實踐，工具是為有效落實這套方法論提供支持。

在軟件全生命周期管理過程中，包括開發，構建，測試，發布，運營，在這個全生命周期管理過程中出現了開發組織與運維組織的部門墻，這是因為開發組織關注需求的實現，希望盡快實現變更；運維組織關注系統運行穩定，而變更又往往是生產應用不穩定的原因。

DevOps 方法論的出現主要是為了解決這個協作問題，以讓軟件交付更加高效，質量更高，生產端更加敏捷，生產運行過程中的問題能更加高效的反饋到開發，形成一個全生命周期的閉環。隨著業務對運維交付能力的時效性要求越來越高，運維組織面臨“吃力不討好”的問題：

• 吃力：花費大量時間在應用部署的操作性工作中。這部份部署變更包括新功能的上線以及修復功能BUG兩方法。
• 不討好：操作性的工作越來，帶來的操作風險越大，有這樣一個統計，如果手工運行5條命令的情況下，成功部署的概率就已跌至86%；如需手工運行55條命令，成功部署的概率將跌至 22%；如需手工運行100條命令，成功部署的概率將趨近于0（僅2%）。

DevOps 鼓勵軟件開發者和IT運維人員之間所進行的溝通、協作、集成和自動化，借此有助于改善雙方在交付軟件過程中的速度和質量。側重于通過標準化開發環境和自動化交付流程改善交付工作的可預測性、效率、安全性，以及可維護性。

1.3.3.2運維實踐中的DevOps

可以從工具鏈、組織文化、自動化、敏捷看板等角度講DevOps，比如在目前比較活躍的 DevOps36計中，基本覆蓋了運維領域很大的一塊：

從 DevOps 的落地效率來看，需要將 DevOps 進行聚焦，聚焦到交付能力上，這方面，行業里比較標準化的評估是去年底由中國信息通信研究院，聯合一些互聯網企業、運維社區，以及一些金融、傳統企業聯合進行編制的 DevOps 標準（券商行業中華泰參加了編制）。

從這個能力模型公布出來的一些介紹看，標準對 DevOps 范圍比較克制，主要以交付能力來分解敏捷開發、持續交付、技術運營、應用架構、組織架構，這和最早的 DevOps 能力環比較吻合：

從運維的交付場景看，主要是資源交付與應用交付，其中資源交付以IAAS、PAAS云的建設為主，通過云管平臺的工具鏈將基礎設施、網絡、硬件、虛擬化、容器、運行中間件等系統軟硬件交付能力自動化，并通過CMDB整合DevOps能力環之上的應用場景，實現資源的快速交付。

資源交付能力主要在于IAAS、PAAS層的云平臺標準化、自動化、平臺擴展性等方面的建設程度。

應用的快速交付比資源交付更為復雜，應用交付涉及全鏈路的整合，鏈路上的節點越多落地的難度越大，因為它不僅涉及技術，還涉及理念的認同與聚焦。應用交付能力要實現，最簡單的技術棧工具需要CMDB、應用發布工具、應用版本庫、監控工具，上述工具對內要與云平臺對接，對外要提供接口給開發、測試工具。

當然如開發、測試也能和運維使用同一套發布工具、應用版本庫則效果更好，不過，實際實施過程中組織之間還是會有不少沖突，比如開發關注源代碼版本管理，測試、運維關注運行版本的管理，需各個組織共同付出共建技術鏈。

1.3.4 運營

關于運維圈里運營的概念，以轉型口號喊得比較多，我對運維當中的運營有業務運營與技術運營兩個維度的理解。業務運營是通過功能優化或工具開發等方式解決業務工作痛點，或通過運行分析發現影響業務開展的因素，并推動相關的優化，最終提升業務能力。技術運營則主要從技術角度去降低IT成本，提升IT服務質量與效率。具體的實施內容可以考慮如下：

從上述概括可以看出，當前運維里面的運營，與運維數據密切相關，需要基于運維大數據平臺來提升運營質量。

為了進一步說明運營，這里舉兩個例子：

1）理論：

優锘科技CEO的陳傲寒在2016年寫過一篇文章《IT：從運維到運營》，雖然己過去1年多，仍是我讀過最好的一篇。全文從企業、運維組織角度出發分析什么是運維、什么是運營，再將運營分解到不同角色上的理解與落地的方向，全文均是干貨，值得通讀，這里只列出一個思維導圖。

2）實戰

去年參加了一場騰訊QQ關于 DevOps 的培訓，對于它們提到的一個自救方式的運營手段很有印象。那就是在騰訊QQ逐漸被微信團隊替代過程中，QQ技術運維團隊是如何通過各種方式去為企業帶來效益，比如他們通過運維分析，得到如何更加合理的使用帶寬、資源，大大減少了公司在基礎設施方面的投入。

在金融企業中，也同樣有很多空間可以去嘗試，比如分析業務痛點，為業務提供快速的策略性的工具來替代重復操作性的業務操作；通過運維數據分析，發現客戶體驗方面的痛點，推動業務功能的優化等等。

1.3.5 AIOps

AIOps這個詞最早是在2016年由Gartner提出（當然國內很多廠商也提出它們早幾年也提出了這個理念）。

AIOps是Algorithmic IT Operations的縮寫，是基于算法的IT運維，即通過使用統計分析和機器學習的方法處理從各IT設備、業務應用、運維工具收集的數據，從而加強增強運維自動化能力，以便更快、更有效、更全面的實現自動化效果。

Gartner通過使用圖1中的圖解釋了AIOps平臺的工作原理.AIOps有兩個主要組件：大數據和機器學習。它需要從孤立的IT數據中移除，以便將大量數據平臺內的觀察數據（例如監控系統和作業日志中發現的數據）與參與數據（通常在故障單，事件和事件記錄中找到）相結合。

然后針對組合的IT數據實施全面的分析和機器學習（ML）策略。期望的結果是持續的見解，通過自動化產生持續的改進和修復。AIO可以被認為是核心IT功能的持續集成和部署（CI / CD）。

• 廣泛和多樣化的IT 數據源：如日志類的設備日志、系統日志，應用日志、運維操作日志；指標類的監控性能指標、事件。
• 具備針對海量數據處理與分析的運算平臺，能夠從現有的IT數據生成新的數據和元數據、計算和分析還消除噪音，識別模式或趨勢，隔離可能的原因，揭示潛在問題，并實現其他IT特定目標。
• 算法，充分利用IT領域的專業知識，更適當，高效的處理數據。
• 機器學習，從根據算法分析的輸出和引入系統的新數據自動更改或創建新的算法。
• 可視化，以易于消費的方式向IT行動提供洞察和建議，以促進理解和行動。
• 自動化，其使用分析和機器學習產生的結果自動創建和應用響應或改進已識別的問題。

1.3.5 AIOps 與自動化的關系

AIOps很火，所以對AIOps和自動化做了一些對比。暫以一句話作個區別：AIOps 是基于對運維數據（日志類、指標類數據等）的機器學習，進一步解決自動化成本高或無法解決的問題，屬于運維自動化的優化，細化一下區別有：

• 概念：
• 狹義的自動化則提運維“監、管、控”的工具。AIOps是將AI技術應用到IT運維領域，需要有學習、類人交互、主動決策的特征。
• 實現思路：
• 自動化往往以過程為導向，AIOps則以目標為導向，通過對數據進行學習，得到如何實現目標。
• 門檻高度：
• 自動化手段有豐富的落地解決方案，適合作為替代標準化的運維操作性工作，即“面”的問題。AIOps目前仍處起步階段，不是適合替代現有的自動化，而是應該用于解決自動化不能解決或解決成本很高的問題，即“點”的問題。
• 如何整合：
• AIOps并非是要取代現有的自動化運維體系，而是賦予現有體系智能。AIOps就要“學習，了解”自動化工具，并且更好的“使用”這些工具，這個過程就是深度集成，它的核心是對這些工具API的自主認知和自主使用。

雖然行業內的智能運維理念十分火熱，但實際落地成效上還主要處于研究階段。從運維工具技術解決方案的角度看，對于智能的解讀也有差別，如果將智能的特點解讀為具備”模擬人，具備自學習，能夠從數據中獲取知識，進而進行預測/決策“來判斷是否智能，智能是自動化的一個輔助手段，自動化才是終態。

建立在這個認識下，我們首先需要通過自動化手段解決痛點，提高工作效率，控制風險；利用運維數字化的建設為運維智能化提供數據、數據計算的能力；在自動化、數字化水平得到一定程度后，再通過人工智能的技術去解決自動化手段解決起來費力或無法解決的局部問題，讓自動化具備智能的水平。

1.4 體系

1.4.1 運維的可持續改進

在管理領域，戴明推出的PDCA循環可以解釋運維體系需要具備的可持續改進的能力條件。PDCA循環為四個階段，即計劃（plan）、執行（do）、檢查（check）、調整（Action），即在實際工作開展過程中，把各項工作按照作出計劃、計劃實施、檢查實施效果，然后將成功的納入標準，并不斷循環改進的過程。

將這個思路引入到企業的運維體系中則是針對企業業務發展的需求，制定運維體系的整體發展目標，通過不斷改進的措施提高運維工作效率、控制風險，以達到高效、更優化的資源配置，進而推動業務的發展。要做到運維體系的可持續改進，需要做到以業務導向，整體布局；組織、流程、工具三位一體；不斷審視優化。

1）P：以業務導向、整體布局

運維的最根本作用是保障IT數據的連續性，這里的IT數據包括業務，以及反映業務的數據，或者換句話可以表達為：網絡不斷、系統不癱、數據不丟。隨著業務對IT系統依賴程度越來越高，運維又會承擔更高的期望，也就是運維向運營的轉化，這就需要從業務角度去不斷完善運維，以促進業務為大目標，要明白“IT for IT”是為了更好的“IT for Business”。

有了這個目標，那我們的運維體系的構建就需要與企業業務的發展保持同步，要讓運維體系具備可持續改進的能力。

另外，可持續改進的過程不應該是大拐彎的方式進行改進，而應該不斷的小調整，這就需要確保首先要建立一個整體、全局的運維體系，對運維各項工作做一個整體的規劃，把眼光看得更遠，往往可以更好的把控當前。

2）D：組織、流程、工具的三位一體

可持續改進的運維體系需要讓運維的組織、流程、工具三位一體的作用，比方說：提高工作效率，需要組織的專業化分工、流程的標準化、工具的自動化配合作用；推動業務的發展，既需精細化運維分析、業務服務、運營等維度的工作資源投入，也需要有工具的建設來減少操作性的工作來釋放人力，需要工具提供更高效的數據來源。

這里說的組織主要是從運維人力資源的分工、團隊建設、工作目標導向、運維KPI等；流程是指以成熟的運維方法論為主體，結合企業和外部監管的規章制度、企業業務發展需要，而落地的標準化工作方法；工具既包括狹義運維的“監、管、控”，也包括運營體系所需要數字化、智能化的工具平臺。

3）C A : 不斷審視優化

在實際工作過程中，審視檢查的過程很容易被忽略，但實際上最大的收獲可能就來自于這個總結、歸納的過程中，這也是可持續改進的運維體系的關鍵所在。比方說，運維組織可以考慮在必要環節增加橫向的優化團隊；運維流程也需要定期對流程的落地進行分析，并對規章制度進行查漏補缺、刪減不合理的流程規范、調整無法執行的規范要求；工具的建設要不斷的分析工具的使用覆蓋率，如何提高覆蓋率，分析是否提高了運維的效率，還是帶來了反作用等分析，并不斷調整優化工具的建設。

1.4.2 轉型思路

在提出可持續的運維體系前，我們先歸納一下運維組織常見的運維痛點，以提出運維轉型的思路，再看看如何構建一個可持續改進的運維體系來支撐運維轉型。前面的運維之痛中提到了“救火”、“背鍋”、“低價值”、”重復操作“等標簽，我們歸納下己有特點再看轉型：

1）特點

• 被動救火式，以被動保障業務系統運行，日常計劃性工作容易被打斷、擱置；
• 問題驅動式，以系統可用性、可靠性、業務請求等問題驅動運維工作；
• 操作運維，重復性、操作類點主要工作量的運維模式；
• 經驗式運維，由人工經驗驅動的運維模式，尤其是一些經驗豐富的老員工的離職在短期內會對運維質量帶來一定的沖擊。

2）轉型

• 從被動救火式向主動精細化轉型，專業化分工、主動分析，主動優化，驅動開發，促進DEVOPS的落地；
• 從問題驅動向價值驅動轉型，以企業業務發展目標為主線，業務體驗、服務滿意度、促進業務更好發展；
• 從操作運維向運維開發轉型，通過為運維人員提供運維開發平臺，降低運維開發門檻，快速落地一些緊迫的運維工具，降低操作性、重復性的運維工作；
• 從依靠經驗向智能化驅動運維轉型，結合數據分析、知識庫、機器學習技術促進運維智能化。

1.4.3 構建運維體系

上二節提到運維體系以業務導向，整體布局，組織、流程、工具三位一體，不斷審視優化的建設思路，也提出了”主動精細化“、”價值驅動“、”運維開發“、”智能化運維“的轉型目標，我們再將這些思路分解到組織、流程、工具的建設中，并歸納為：三大建設，十個文化的實踐方法：

• 組織建設：專業化、精細化、運營化

我們將運維實施主體運維組織理解為組織，理想情況下，優秀的組織應該具備有合適的工作、合適的時間、合適的人、合適的行為四個要素組成。即組織要結合企業實際發展方向，制定符合企業、運維組織、個人發展的工作內容，并選擇具備合適的知識、技能、認知、能力的人去完成工作，去實際個人的自我價值。

前面也提到，目前的運維織是一個被動保障業務系統運行，日常計劃性工作容易被打斷、擱置的工作，這種工作狀態下的運維組織往往工作效率不高、容易出現操作風險。為了讓運維組織具備可持續改進的能力，需要提高運維組織的工作效率，我們需要將運維工作專業化，整合通用性、操作性的工作，提高工作效率，在釋放運維人員工作量后，引導運維人員有計劃、可量化的去做更多分析類、優化類、業務運營的主動性工作。

• 流程建設：標準化、可視化、可量化

大部份運維組織會以內部企業積累的規章制度、外部監管機構的監管要求為基礎，依照ITIL、ISO20000、ITSS.1、DevOps的方法論中的一個或多個組合的方式開展運維工作。這些規章制度、監管要求、方法論的整合、落地、持續改進的過程即為流程建設的過程。

流程建設首先需要標準化流程，要先梳理好己有的流程制度，約定工作的流轉方式，再通過可視化將流程整合在日常工作中，最后通過流程落地數據的分析與工具建設，持續改善提高流程落地的效率，控制操作風險。

• 工具建設：自動化、數字化、智能化、服務化

工具的建設也以可持續改進的思路構建，以整合存量資源、引入成熟或開源技術為主，建立一體化的運維工具體系，通過體系化的思路實現運維工具（“監、管、控”）的互聯互通，有序建設，實現自動化運維，全面控制風險、提高工作效率、釋放人力；通過建立運維數據分析平臺，實現數字化運營，提供運維數據集中與治理、主動分析的能力；在數字化運營的基礎上通v