運維體系研究

1. 概述

運維在IT領域中一個很寬泛的崗位，一般情況運維指的是互聯網運維，隨之互聯技術的革新，對於運維體系也有了新的定義。新型運維和傳統運維分界截然不同，本文將不過多的對新型運維和傳統運維說明以基本運維展開對運維體系的深入研究。
運維，這裏指互聯網運維，通常屬於技術部門，與研發、測試、系統管理同爲互聯網產品技術支撐的4大部門，這個劃分在國內和國外以及大小公司間都會多少有一些不同。（百度百科）運維的工作方向比較多，隨着業務規模的不斷髮展，越成熟的互聯網公司，運維崗位會劃分得越細，如：系統運維工程師、數據庫運維工程師、網絡運維工程師、安全運維工程師、桌面運維工程師、軟件運維工程師、業務運維工程師、CDN運維工程師、IDC運維工程師、存儲運維工程師、硬件運維工程師、遊戲運維工程師。面臨近些年企業對運維人員技能要求的象限化，技術更新快等特點。迫使運維人員不得不學習更多的技能且要有百步穿楊的本領，不僅如此還需要了解自己所處的階段，更需要了解市場的需求，所謂知己知彼。我們在本文對體系做探索梳理，考慮到最佳實踐通用性將着眼點放在運維工作內容、建設思想、技術架構實踐。

1.1. 運維職責

1、保障企業數據安全
2、提供7x24小時業務持續性
3、評估產品需求及發展需求，設計網站架構
4、上線代碼、配合研發搭建環境、調試、測試代碼
5、監控硬件、軟件及各種業務應用
6、配置收集日誌和，根據日誌信息報警及優化系統及服務
7、解決日常問題，如硬件（服務器、交換機、硬件、網絡）、軟件、各類業務服務故障
8、開發運維管理平臺、及運維工具產品，提升服務效率
9、制定運維流程、規範、制度，並有序推進
10、採購服務器、選擇IDC公司、雲產品、CDN等產品。

1.2. 運維技能

常見技能：

• 系統安裝
• Raid陣列
• 初化配置（網絡、內核、iptables、服務、安全）
• 應用部署（LAMP、LNMP…）
• 監控調優（日誌收集分析、流量分析、業務監控）
• 數據備份

技術點：
Linux、shell、python、LVS、Keepalived、HAProxy、Nginx、Apache、Tomcat、MemCache、Redis、MySQL、MongoDB、ELK、Zabbix、Ansible、Cobbler、Kubernetes、Docker、ZooKeeper、Hadoop...

1.3. 運維崗位

運維工程師比程序員（開發者）要少，但運維崗位的頭銜可不少

• 運維實習生
• 系統管理員
• 網絡管理員
• 運維工程師
• IT運維工程師
• Linux運維工程師
• 運維開發工程師
• 應用運維工程師
• 高級運維工程師
• 運維專家
• 運維主管
• 運維經理
• 高級運維經理
• 運維總監

新興的運維頭銜：

• 自動化運維開發工程師
• DevOps運維開發工程師
• 與業務強相關的崗位，如：直播運維工程師、中間件運維工程師

1.4. 運維管理

運維管理不僅是對設備應用的管理，更重要的還要對人進行管理，如何做到理想化、精細化管理可參照管理學的方法論、運維建設思路及行業標準。運維服務體系建設，應包含運維服務制度、流程、組織、隊伍、技術和對象等方面的內容，整合運維服務資源，規範運維行爲，確保服務質效，形成統一管理、集約高效的一體化運維體系，整合運維服務資源，規範運維行爲，確保服務質效，形成統一管理、集約高效的一體化運維體系，從而保障業務、網絡和應用系統安全、穩定、高效、持續運行。運維管理本身包括設備管理、應用/服務管理、數據/存儲/容災管理、業務管理、目錄/內容管理、資源資產管理、信息安全管理和日常工作管理等子系統。

• 方法論：管理學、項目管理、溝通管理、質量管理
• 運維建設：監控、限流、SLA、LB、災備、日誌分析
• 規範性引用文件：
  ITIL3.0
  ISO20000
  ISO9000
  ISO27001
  ITSM（IT服務管理）
  BSM（業務服務管理）
  GB/T 28827.1《信息技術服務運行維護標準》
  GB/T 22080-2016《信息安全管理體系要求》

2. 運維體系

2.1. 運維發展階段

• 運維1.0 石器時代
  這個階段屬於原始蠻荒運維時代，運維工作還是一個模糊的概念，負責從機房、服務器選型，軟硬件初始化，服務上下線，配置監控等，運維和開發之間沒有太明確的分工，基本是遇到什麼問題解決什麼問題。
• 運維2.0 自動化時代
  這個階段基本屬於工具時代，一般運維都是找各種開源或自己寫的腳本工具來輔助日常運維工作。充分體現運維人員對業務的理解程度，一定程度上優化了運維工作。可以建立標準、規範、制度以形成體系。
• 運維3.0 平臺化時代
  這個階段主要是面向服務化統一管理的時代，雲、虛擬化技術的盛行對運維技能要求發生了革新，對運維象現化突出分工變的明確，從單一運維工程師演化出多個頭銜。運維對一套完整的解決方案的需求變得非常強烈。此時運維體系是建立標準、規範、平臺化的最佳實踐。
• 運維4.0 智能化時代
  這個階段已經是一切旨指令的時代，人人旨開發接口管理，統一管理，正是容器技術盛行的時代，對雲技術也產生了翻天腹地的變化。技能要求更是專一化，高標準化。工欲善其事，必先利其器，數據是一切智能運維的根基。當基礎設施固定下來，運維模固定下來，這些模式會把包括可用性、擴容等場景的運維方案包含進來，平滑的把開發加入運維體系架構中。
  

自動化可以提高運維效率、提高系統彈性、降低管理成本、降低人爲風險

2.2. 運維體系框架

企業IT部門面臨越來越複雜的IT基礎設施與架構,以及衆多企業、地域、人員和品牌的管理。提升IT服務能力和業務組織保障能力的關鍵要素在於如何有效管理企業IT部門,充分整合IT部門資源、人員、技術、以及流程,併發揮最佳效力。下面是ITIL/ISO20000/ISO/27001的實踐。

由公安部第三研究所等主辦的我國網絡安全等級保護制度2.0國家標準（簡稱“等保2.0標準”）網絡安全等級保護制度2.0國家標準的發佈，是具有里程碑意義的一件大事，標誌着國家網絡安全等級保護工作步入新時代。下面是ITIL/ISO20000/ISO/27001、等保2.0的設計。

2.3. 運維體系內容

運維體系的組成部分
• 資源管理
• 服務器、虛擬機、網絡設備、存儲、IP/VIP、域名…
• 配置管理
• 系統配置、網絡配置、應用配置、應用分組、SLA級別配置…
• 監控
• 系統監控、網絡監控、應用監控、安全監控、容量監控…
• 應用管理
• 上線、發佈、下線
• 集羣管理
• 擴容、縮容
• 事件管理、變更管理、問題管理、故障管理
• IDC管理、存儲管理、數據庫管理、採購管理

運維體系文件
• 運維文件管理規範
• 信息安全資產管理規範
• 信息安全事件管理規範
• 源代碼安全管理規範
• 配置變更安全管理規範
• 運維流程、制度、標準文件
• 團隊組織、規劃、平臺建設

運維服務流程
• 事件管理、工單管理、問題管理
• 變更管理、配置管理、
• 知識庫管理
• 運維報告管理

2.4. 運維體系建設原則

運維體系的建設應該從大環境考量，結合企業實際情況去繁從簡，從“容易使用、容易管理”的先後順序，由重到輕的依次解決客觀存在的問題，以便最大程度的加快運維體系的建設的目標。
• 以完善的運維服務制度、流程爲基礎。爲保障運行維護工作的質量和效率，應制定相對完善、切實可行的運行維護管理制度和規範，確定各項運維活動的標準流程和相關崗位設置等，使運維人員在制度和流程的規範和約束下協同操作。
• 以先進、成熟的運維管理平臺爲手段。通過建立統一、集成、開放並可擴展的運維管理平臺，實現對各類運維事件的全面採集、及時處理與合理分析，實現運行維護工作的智能化和高效率。
• 以高素質的運維服務隊伍爲保障。運維服務的順利實施離不開高素質的運維服務人員，因此必須不斷提高運維服務隊伍的專業化水平，纔能有效利用技術手段和工具，做好各項運維工作。

2.5. 運維體系建設之人員

運行維護隊伍建設
• 隊伍組建：針對目前信息系統IT資源現狀以及對技術支持的需求，組成各類別維護人員的專家隊伍，集中的開展運行維護工作。
• 人員管理：對各級運行維護人員尤其是高級運行維護人員的管理，應制定一套切實可行的管理辦法，包括人員配置、職責劃分、人才庫建立、人員培訓、人員考覈、人員待遇等。通過科學的管理辦法和有效的激勵機制，充分調動各級運行維護人員的工作積極性和責任心，爲做好信息系統運行維護工作打好基礎。

2.6. 運維體系建設之技術

工單系統、知識庫、監控系統、發佈系統、任務系統
參考資料《運維體系建設介紹PPT》如下圖：

自動化設計（git/svn代碼查看模塊、jek×××集成打包模塊、docker倉庫操作模塊、k8s編排模塊、cmdb資產管理模塊、安全審覈模塊、運維服務模塊、日誌監控模塊、網絡安全模塊、權限模塊）

3. 運維實踐

3.1. 運維架構

高性能設計
• 以用戶爲中心，提供快速的網頁訪問體驗。主要參數有較短的響應時間，較大的併發處理能力，較高的吞吐量，穩定的性能參數。
• 可分爲前端優化，應用層優化，代碼層優化，存儲層優化。
• 前端優化：網站業務邏輯之前的部分；
• 瀏覽器優化：減少Http請求數，使用瀏覽器緩存，啓用壓縮，Css Js位置，Js異步，減少Cookie傳輸；
• CDN加速，反向代理；
• 應用層優化：處理網站業務的服務器。使用緩存，異步，集羣；
• 代碼優化：合理的架構，多線程，資源複用（對象池，線程池等），良好的數據結構，JVM調優，單例，Cache等；
• 存儲優化：緩存，固態硬盤，光纖傳輸，優化讀寫，磁盤冗餘，分佈式存儲（HDFS），NOSQL等；

高可用架構
大型網站應該在任何時候都可以正常訪問。正常提供對外服務。因爲大型網站的複雜性，分佈式，廉價服務器，開源數據庫，操作系統等特點。要保證高可用是很困難的，也就是說網站的故障是不可避免的。

參考資料《小團隊如何從零搭建一個自動化運維體系》如下圖：

大型網站架構目標

• 高性能：提供快速的訪問體驗。
• 高可用：網站服務一直可以正常訪問。
• 可伸縮：通過硬件增加/減少，提高/降低處理能力。
• 安全性：提供網站安全訪問和數據加密，安全存儲等策略。
• 擴展性：方便的通過新增/移除方式，增加/減少新的功能/模塊。
• 敏捷性：隨需應變，快速響應。

大型網站架構模式

• 分層：一般可分爲，應用層，服務層，數據層，管理層，分析層；
• 分割：一般按照業務/模塊/功能特點進行劃分，比如應用層分爲首頁，用戶中心。
• 分佈式：將應用分開部署（比如多臺物理機），通過遠程調用協同工作。
• 集羣：一個應用/模塊/功能部署多份（如：多臺物理機），通過負載均衡共同提供對外訪問。
• 緩存：將數據放在距離應用或用戶最近的位置，加快訪問速度。
• 異步：將同步的操作異步化。客戶端發出請求，不等待服務端響應，等服務端處理完畢後，使用通知或輪詢的方式告知請求方。一般指：請求——響應——通知 模式。
• 冗餘：增加副本，提高可用性，安全性，性能。
• 安全：對已知問題有有效的解決方案，對未知/潛在問題建立發現和防禦機制。
• 自動化：將重複的，不需要人工參與的事情，通過工具的方式，使用機器完成。
• 敏捷性：積極接受需求變更，快速響應業務發展需求。

3.2. 運維實戰

實戰目的將以最快、最全面的思路建設高可用、高性能、自動化生產環境。提高網站的訪問速度，容錯性，冗餘性。

準備相關工作
預估PV、帶寬
服務器、IDC、CDN選型
批量安裝系統（cobbler）
初始化系統（服務器時間同步、SSH-KEY打通、計算機命名、設置DNS、設置環境變量文件、優化內核參數、配置yum源、建立統一目錄、部署統一應用、）
安全基線（關閉不啓用的服務、ssh安全策略、密碼策略、創建Ops操作用戶、設置sudo文件權限、設置歷史命令、刪除不必要的用戶、日誌審計）
後續相關工作
自動化工具推送
代碼上線部署
灰度發佈
業務監控報警
日誌收集分析

實驗拓撲圖

• 物理拓撲
  

• 邏輯拓撲
  

• 數據走向
  用戶請求動態資源時，通過LB（Master）將用戶請求分發給後端的動態服務器，動態服務器接受請求並轉發給php處理，php到共享存儲中查找動態內容處理請求，將響應報文發送給動態服務器，由動態服務器將響應報文發送回LB，最後再發給用戶。
  用戶請求動態資源時，通過LB（Master）將用戶請求分發給後端的靜態服務器，靜態服務器接受請求，到共享存儲中查找靜態內容處理請求，由靜態服務器將響應報文發送回LB，最後再發給用戶。

• 環境配置
  

• 實驗需求
  使用Keepalived實現高可用
  LB(LVS、HAproxy、Nginx)實現負載均衡
  Lamp(Lnmp)+wordpress實現動靜分離的資源請求
  使用手動更新發布，支持熱部署
  灰度發佈
  故障回滾
  自動監控

3.3. 常見架構方案

一般架構應該先做功能切割再做LB，數據同步很麻煩。小規模建議拆分，不建議直接分佈式。好的架構是通過迭代演變過來的，不是直接設計出來的。
單機升級--->系統拆分--->技術達到上線--->就選擇分佈式架構

Lnmp + wordpress 單臺
wordpress代碼發佈：目錄有多種方式1.單目錄、2.多目錄、3、共享目錄（rsync）

• 單目錄方式，代碼發佈沒有問題顯示正常

• 多目錄方式，代碼發佈有問題顯示不正常

Nginx 配置文件如下圖：

• 共享目錄方式，代碼發佈沒有問題顯示正常

• 方式一：使用共享存儲的方式，將代碼統一存放掛載至共享目錄
• 方式二：使用rsync同步目錄的方式，將代碼目錄文件同步更新
• 方式三：使用軟鏈接的方式，將代碼目錄文件同步更新

Lamp + wordpress 多臺（分離）
wordpress代碼發佈：apache和php分離的架構，代碼放在不同主機上

構建分離式LAMP(LNMP)有兩個問題：
•應用程序如wordpress，需要在apache(nginx)和php兩臺服務器上安裝，浪費空間
•用戶上傳的文件，如圖片無法顯示，因爲上傳的文件是被放到PHP上，而客戶端
訪問讀取時在apache上找不到
注意: apache服務器和php服務器的網站目錄結構需要保持一致。

•解決方案：1.使用同步機制，如rsync+inotify，同步web和php服務器；2.使用共享存儲，如NFS；3.對程序進行二次開發

4. 運維解決方案

4.1. 應急響應

當生產中心出現故障導致業務中斷時，需啓動應急響應預案，快速定位問題，解決問題，恢復業務；避免業務中斷造成損失。
參考資料《運維制度及流程》如下表：

4.2. 業務連續性

BCP（業務持續性計劃）在DRP的基礎上增加了風險分析、業務影響分析、業務恢復預案、恢復策略與方案和人員架構組織保障的內容，它面向企業關鍵業務持續、有效動作是災難事故的預防和反應機制。
BCM（業務持續性管理）又把BCP的外延內容擴大到了緊急時間的應急相應處理、危機通訊與危機公關、災難事件應急響應處理和供應鏈或關聯單位的危機管理，它面向企業潛在的風險，考慮內部風險控制及外部利益相關單位，建立一個完善的機制預防或減少損失。

4.3. 災備

DRP（災難恢復計劃）的核心是IT的備份和恢復，還包括圍繞IT備份與恢復的災難恢復資源，災備中心的運營管理和切換、重續運行與回退預案几部分內容，它面向信息系統及所支持的業務功能，從災難造成的故障或癱瘓狀態恢復到可接受狀態。

5總結

1、通過對運維整個體系的概述對技架構我們要根據用戶訪問的路線，來考慮用戶訪問習慣，從而決定架構的部署；畫出邏輯架構圖，標記出數據包的走向
2、要有分析業務的能力，按照業務把應用進行對應如：在線交易、在線社交、在線遊戲、在線視頻、在線瀏覽
3、對架構知識有清晰的思路
架構分析--》業務壓力模擬和計算---》帶寬、網絡設備、服務器、安全設備選型---》搭建測試環境---》壓力模擬測試---》上線----》後續維護（監控、壓力下的調試）
• 如果不做靜態化
用戶--》分發層---》應用層---》數據庫---》數據庫存查詢緩存---》結果返回給應用服務器---》返回給用戶。
• 做了靜態化（被查詢訪問過的結果頁面會被自動生成靜態化文件，存在靜態服務集羣）
用戶---》分發層（判斷被訪問頁面哪些是靜態）---》靜態/應用層服務器

靜態化：所有被訪問頁面的結果，生成一個單一的文件，存儲在文件系統層
靜態資源：靜態內容，客戶端從服務器獲得的資源的表現形式與原文件相同
動態資源：程序文件，需要在服務器執行之後，將執行的結果返回給客戶端

4、自動化ansible playbook

- host: 
  vars:
  remote_user: 
  tasks:
    -
    -
  variables:
    -
  handlers:
    -

安裝php爲例：

 - hosts: webapp
  remote_user: root
  gather_facts: no
  tasks:
    # 安裝epel源
    - name: install epel-release repo
      yum: name=epel-release state=present
    # 安裝remi源
    - name: install remi-release repo
      yum: name=http://rpms.famillecollet.com/enterprise/remi-release-7.rpm state=present
    # 安裝php5.6
    - name: install php
      yum: name={{ item }} state=present enablerepo=remi enablerepo=remi-php56
      with_items:
       - php
       - php-fpm
       - php-devel
    # 開啓php-fpm服務
    - name: start php-fpm
      service: name=php-fpm state=started enabled=yes
    # 複製index.php文件到網站根目錄
    - name: copy index.php
      copy: src=index.php dest=/u01/www/nginx/html/index.php
      notify: restart nginx
    # 重啓nginx

  handlers:
    - name: restart nginx
      service: name=nginx state=restarted

注意：ansible具有冪等性，因此會自動跳過沒有變化的部分，即便如此，有些代碼爲測試其確實沒有發生變化的時間依然會非常地長。還有一個問題當第一次執行成功了，再下一次不小心改錯配置文件，一般情況是不容易發現的，所以一定要看執行過程驗證結果。
錯誤配置如下：restartedd多寫了一個d

# vim roles/lbsrvs/handlers/main.yml

報錯信息如下

如果第一次執行成功，而第二次 # vim roles/lbsrvs/handlers/main.yml 不小心改錯。
則不會報錯，因爲沒有觸發執行所以看不出roles/lbsrvs/handlers/main.yml 有問題。

5、運維過程中遇到問題的排錯思路
第一步首先要檢查服務存活

第二步telnet檢查網絡影響
第三步外部因素如系統負載、應用BUG、網絡問題、域名解析

下面我們舉例說明一下，如lnmp分離構建，nginx 調用 php-fpm報錯問題
502 Bad Gateway

# tailf /var/log/nginx/error.log 查看日誌報錯如下

1）看到表面的報錯信息大部分人會想到googel、baidu一下，但是即使你上網查到了相關資料但未必是你最需要，因此有良好基礎是最關鍵的。
2）我們需要檢查相關服務是否存活，通過排查沒問題。
3）下面就是對問題的深度研究，需要理解正確的架構模型、服務間的調用關係、分析相關DEBUG日誌、網絡抓包分析，配置文件參數，TCP連接隊列等。針對此問題經判斷確認架構模型無問題；那麼服務間調用是fastcgi協議，經分析不是協議特性的問題；再次展開分析，php-fpm默認是不打開子進程的日誌輸出的，手動打開：php-fpm的debug日誌。

# vim /etc/php-fpm.d/www.conf
catch_workers_output = yes
# systemctl restart php-fpm

telnet php-fpm的9000端口發現Connection closed by foreign host.

通過tcpdump抓包分析我們發現報文中有rst標誌位，首先會想到是網絡問題，網絡相關配置參數都需要注意，由其是在生產環境高併發的業務中。

# tcpdump -nn -vvv -s 1500 -i ens33 dst port 9000 and src 192.168.200.201 -w /tmp/php-fpm_502

接着打開php-fpm錯誤日誌，發現確實是主機權限問題，調用IP不在訪問列表內
# tailf /var/log/php-fpm/error.log

通過檢查配置文件發現竟然配置成0.0.0.0會出現問題，由此證明了運維工作是一個小心小心再小心，謹慎謹慎再謹慎，仔細仔細再仔細，容不得一點馬虎不光是配置錯誤的問題還有對影響問題要考慮全面，從安全角度看就不應該出現未受權訪問的問題，設置權限太寬泛固然很不好的習慣，不管是測試還是生產一定要有良好的習慣與標準。
# vim /etc/php-fpm.d/www.conf

最後針對php-fpm配置文件問題除了語法錯誤外就是需要對服務器性能做指標計算（單臺cpu、內存、io大小、網絡），設置合理的參數值即可。

• 注意：Nginx有兩份fastcgi配置文件，舊的「fastcgi_params」和新的「fastcgi.conf」，它們沒有太大差異，後者比前者多了一行「SCRIPT_FILENAME」
  使用舊的fastcgi_params的方式，不推薦此方式

  /scripts$fastcgi_script_name;       需要改模板
  /var/www/foo$fastcgi_script_name;   硬編碼的方式
  $document_root$fastcgi_script_name; 可以使用
  include        fastcgi_params;

推薦方式

fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
include             fastcgi.conf;

4）因此其它因素中出現的問題大家未必一樣，但整體解決問題的思路是一樣的，那麼我們就不過對此進行闡述了,希望今後在踩坑的過程中能夠幫到大家。

6、大規模自動化運維
• 1000臺物理機怎麼管理
• 1000臺容器機怎麼管理
先把ip密碼對應寫到一個文件裏然後你遍歷hosts 關聯那個文件對應的密碼

這是一個值得深入研究學習的話題，我們在此僅是對相關技術點進行一下羅列，今後會有專項的技術博客推出，敬請關注。隨着流量變大，使用動靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC 等方式不斷提升網站的穩定性。面對更大的流量時，通過垂直拆分、服務化、反向代理、開發框架（站點/服務）等等，不斷提升高可用。在面對上億級的更大流量時，通過中心化、柔性服務、消息總線、自動化（迴歸，測試，運維，監控）