Home | 簡體中文 | 繁體中文 | 雜文 | 打賞(Donations) | 雲棲社區 | OSChina 博客 | Facebook | Linkedin | 知乎專欄 | Github | Search | About

Chapter 38. ITSM (IT Service Management) IT服務管理

ITIL(IT Infrastructure Library)

Table of Contents

38.1. Service Support Set(服務支持系列)
38.1.1. Help Desk / Service Desk
38.1.2. Problem Management(問題管理)
38.1.2.1. 故障樹分析(Fault Tree Analysis,FTA)
38.1.2.2. 因果圖在運維工作中的應用
38.1.2.2.1. 什麼是因果圖
38.1.2.2.2. 為什麼使用因果圖
38.1.2.2.3. 何時使用因果圖
38.1.2.2.4. 何處使用因果圖
38.1.2.2.5. 誰來負責製作因果圖
38.1.2.2.6. 怎樣使用因果圖
38.1.2.2.6.1. www.example.com, img.example.com
38.1.2.2.6.2. acc.example.com, api.example.com
38.1.2.2.6.3. cch.exampel.com, mq.exampe.com, db.example.com
38.1.2.3. 員工手冊
38.1.3. Incident Management(突發事件管理)
38.1.3.1. 突發事件處理流程
38.1.3.2. 事件處理方式
38.1.3.3. 監控的藝術
38.1.3.3.1. 背景
38.1.3.3.2. 概述
38.1.3.3.3. 怎樣監控
38.1.3.3.3.1. 衛星監測
38.1.3.3.3.2. 逐級診斷
38.1.3.3.3.3. 模擬人工
38.1.3.3.3.4. 數據分析
38.1.3.3.3.5. 監控與開發
38.1.3.3.4. 總結
38.1.4. Configuration Management(配置管理)
38.1.5. Change Management(變更管理)
38.1.5.1. 變更方案
38.1.5.2. 回退計劃
38.1.5.3. 變更評估
38.1.5.4. 變更授權
38.1.5.5. 過程記錄
38.1.5.6. 結果回顧
38.1.5.7. 機房遷移
38.1.5.7.1. 拓撲確立
38.1.5.7.2. 存儲規劃
38.1.5.7.2.1. RAID Disk Group 規劃
38.1.5.7.2.2. 檔案系統規劃
38.1.5.7.2.3. 目錄規劃
38.1.5.7.3. 設備上架
38.1.5.7.4. 操作系統初始化
38.1.5.7.5. 伺服器及運行環境
38.1.5.7.6. 部署應用程序
38.1.5.7.7. 監控系統
38.1.5.7.8. 日誌中心
38.1.5.7.9. 測試
38.1.6. Release Management(發佈管理)
38.1.6.1. 發佈類型
38.1.6.2. 發佈規劃
38.1.6.3. 參與人員與職責
38.1.6.4. 範圍與權限
38.1.6.5. 檢測標準
38.1.6.6. 過程和結果
38.1.7. 內部培訓
38.1.8. IT資源管理
38.2. Service Delivery Set(服務實施系列)
38.2.1. Service Level Management(服務水平管理)
38.2.2. Availability Management(可用性管理)
38.2.3. Capacity Management(容量管理)
38.2.4. IT Continuity Management(IT可持續性管理)
38.2.5. IT Financial Management(IT財務管理)
38.2.6.
38.2.7.
(1)服務級別管理
(2)可用性管理
(3)能力管理
(4)服務連續性管理
(5)財務管理
(6)事件管理
(7)問題管理
(8)變更管理
(9)配置管理
(10)發佈管理
	

38.1. Service Support Set(服務支持系列)

38.1.1. Help Desk / Service Desk

桌面支持

Help Desk Software

38.1.2. Problem Management(問題管理)

“問題管理” 是以解決問題為導向,以挖掘問題、表達問題、歸結問題、處理問題為線索和切入點的一套管理理論和管理方法。也可以說,問題管理就是借助問題進行的管理。

問題管理是事件管理的主要出口,在事件管理中無法根本解決的事件、不斷重複的事件、典型或影響範圍過大的事件等,通常由事件管理的負責人在問題管理項目中發起問題,交給問題管理處理。問題管理的根本目的是消除或減少同類事件的發生,通過分析所發生的事件或事件的趨勢,找出根本原因,然後提出解決辦法、解決方案、變通方法、或建議的預防性措施等,來消除或減少事件的再次發生。同時問題管理還可包括主動問題管理和被動問題管理兩個部分,問題管理的活動包括問題的發起、確認和分配、問題調查、已知錯誤確立、提供解決方案、評審、關閉。

“問題管理”是在挖掘問題的基礎上,合適地表達問題,正確地解決問題,以此來防範問題演化為危機的一套管理理論和方法。也可以說,問題管理就是借助問題優化管理。

“問題管理”的三要素是挖掘問題、表達問題、解決問題。其中,挖掘問題包括發現問題、分析問題和界定問題,解決問題包括制定解決方案、實施解決方案和跟蹤反饋,表達問題不是獨立的環節,而是體現和融入到挖掘問題和解決問題的每一個環節之中。

問題管理的特點主要有三方面

  1. 一是防患于未然,防止問題演化為危機。問題管理強調“從危機管理到問題管理”,並不是要取代危機管理,而是要以危機管理為主轉向以問題管理為主,做到“以防為主,防消結合”;

  2. 二是發現和解決關鍵問題,過濾假問題,解決真問題;

  3. 三是跨專業、跨部分地分析和解決問題,打通專業管理或部門之間之間的鴻溝;

38.1.2.1. 故障樹分析(Fault Tree Analysis,FTA)

38.1.2.2. 因果圖在運維工作中的應用

38.1.2.2.1. 什麼是因果圖

魚骨圖,又名因果圖,是一種發現問題“根本原因”的分析方法,我們將影響問題的因素與特性,按相互關聯性整理而成的層次分明、條理清楚,並標出重要因素的圖形就叫特性要因圖、特性原因圖。因其形狀如魚骨,所以又叫魚骨圖(以下稱魚骨圖),它是一種透過現象看本質的分析方法。魚骨圖由日本管理大師石川馨先生所發明,故又名石川圖。魚骨圖是一種發現問題“根本原因”的方法,它也可以稱之為“Ishikawa”或者“因果圖”。其特點是簡捷實用,深入直觀。它看上去有些像魚骨,問題或缺陷(即後果)標在“魚頭”外。在魚骨上長出魚刺,上面按出現機會多寡列出產生問題的可能原因,有助于說明各個原因之間是如何相互影響的。

38.1.2.2.2. 為什麼使用因果圖

在運維工作中,我們經常使用 過程中“故障樹分析”,它主要用於出現故障時找到問題的源頭。而因果圖則是保證7*24運維有哪些影響因素。我認為將“故障樹分析”與“因果圖”互補使用更能解決運維中遇到的各種問題。

“因果圖”能未雨綢繆,“故障樹分析”可以亡羊補牢。

38.1.2.2.3. 何時使用因果圖

我認為任何環節都能使用因果圖幫我們我們改善IT運維工作。

38.1.2.2.4. 何處使用因果圖

例如項目的部署先,部署中,部署後等等每個環節。部署前拿出因果圖由為重要。

38.1.2.2.5. 誰來負責製作因果圖

問題總是受到一些因素的影響,我們通過頭腦風暴法找出這些因素,並將它們與影響因素的特性值,整理,分類,層次化。

[Note]Note

我不喜歡開茶話會(中國式會議),參與人員應該每個人在會議前找出問題因素,會議中拿出問題的因素提交給會議主持者,會議目的是將每個人尋找出的影響問題的因素整理成為魚骨圖,而不是在會議上討論找問題因素。

38.1.2.2.6. 怎樣使用因果圖

下面我們提供一個魚骨圖分析案例

上圖我們看到保障系統7*24小時運行有哪些因素印象,網站分為幾個部分組成

網站

  1. www.exampel.com 網站入口,主要是靜態內容,或者已經將動態靜態化。

  2. img.exampel.com 圖片伺服器

  3. acc.example.com, api.example.com 動態伺服器

  4. cch.exampel.com 緩存伺服器, db.example.com 資料庫伺服器

  5. mq.example.com 消息伺服器

我通常給每個伺服器指定一個主機名,有些事DNS解析的,有些事hosts檔案設置例如 cch.example.com, db.example.com 不需要DNS解析。

現在我們分別解釋每個節點與問題的影響因素,這裡僅僅給出的一個簡單的例子,也只能讓你對因果圖有個入門瞭解。

38.1.2.2.6.1. www.example.com, img.example.com

影響的因素主要是web伺服器,IP地址,80連接埠,防火牆設置,DNS 解析等等

38.1.2.2.6.2. acc.example.com, api.example.com

除了web伺服器,IP地址,80連接埠,防火牆設置,DNS 解析。他的影響因素包括

PHP版本,PHP擴展,PHP配置檔案

38.1.2.2.6.3. cch.exampel.com, mq.exampe.com, db.example.com

影響的因素是防火牆,連接埠,資料庫同步等等...

38.1.2.3. 員工手冊

  • 郵箱配置,初始密碼

  • 開發環境配置

  • 版本庫地址

38.1.3. Incident Management(突發事件管理)

38.1.3.1. 突發事件處理流程

38.1.3.2. 事件處理方式

很多人順着簡單而直接的“事件 > 反應 > 結果” 連鎖行為來反應。

遇有狀況發生,第一時間不加思索地反映,造成的結果不但於事無補甚至造成二次故障。

這種不由自主或未經過思考的反映有時會導致災難性的後果。

更好的選自是:

			
事件 -> 結果 -> 反應
			
			

說白了就是,遇事想清楚在動手不遲。

38.1.3.3. 監控的藝術

38.1.3.3.1. 背景

每個企業都意識到監控工作的重要性,但80%企業的監控工作仍然處在監控的初級階段。

什麼是初級階段呢?

  1. 被動監控,故障發生運維人員永遠不是第一個發現故障的人
  2. 監控IP地址與TCP連接埠,很多時候HTTP 80連接埠正常接受請求,但WEB伺服器不能正常工作。
  3. 人肉監控(人肉運維),採用人海戰術,桌面擺放很多顯示器,甚至投影儀,要求監控者盯着各種儀表板界面,制定各種工作流程以及KPI考核監控人員。
  4. 人肉測試,要求監控人員每間隔幾分鐘人工操作一次,以確認系統正常工作,例如(沒15分鐘登陸一次,下一筆頂單,做一次支付等等)。
  5. 萬能的重啟,定其重啟所有的伺服器。

什麼是中級階段呢?

  1. 報警:手機短信更靠譜,因為手機隨身攜帶(郵件不算,郵件到達速度慢,各種因素不穩定)
  2. 監控服務:探測服務的可用性,而不是僅僅監控連接埠,注意我是指私有協議的監控(HTTP,SMTP,FTP,MySQL 不算在內)
  3. 故障分析:通過日誌與調試工具分析軟件BUG,指導開發人員改善軟件質量,使其故障不會再次發生,達到不用restart重啟方式解決故障
  4. 半自動化測試

什麼是高級階段呢?

  1. 我認為高級階段是監控與災備系統打通融合一體。
  2. 除此之外監控與開發密切相關,在開發階段需要為監控數據採集做鋪墊,每開發一個新功能就要想到未來這個功能是否需要監控,怎樣監控。
  3. 數據前期採集與數據挖掘非常重要,監控不僅能做軟件與硬件的性能分析,還能提供決策支持,這裡又涉及了BI。
  4. 除了監控,另一個息息相關的是自動故障轉移,有興趣可以看看我的其他文章 http://netkiller.github.io/journal/

監控從初級向中繼再到高級,是轉被動到主動,從人工到自動化。

監控不應該侷限在硬件與服務,還應該延伸到業務領域。

38.1.3.3.2. 概述

你在百度上搜索監控多半是一些開源或商業軟件的安裝配置指南。這些文章中會告訴你怎樣監控CPU、內存、硬碟空間以及網絡IP地址與連接埠號碼。

開源軟件無非是 Nagios, Cacti, Mrtg, Zibbix ..... 這些軟件在我的電子出書《Netkiller Monitoring 手札》中都有詳細說明安裝與配置方法。

商業軟件也有很多如 SolarWinds, Whit's Up,PRTG ......

所有的伺服器,網絡設備,監控你都做了,那麼按照我上面的監控分級,你處于監控的那個階段?

38.1.3.3.3. 怎樣監控

監控都有哪些手段跟方式呢?

38.1.3.3.3.1. 衛星監測

中心衛星站為中心站點向外放射,通常是通過IP地址訪問遠程主機,實施監控,常用方法是SNMP,SSH,以及各種Agent(代理),方式是請求然後接收返回結果,通過結果判斷主機狀態。

			
      Monitor Server
            |
-------------------------------
  |         |           |
[Web]    [Mail]    [Database]
			
			

以監控伺服器為中心,星型散射連接其他監控節點,沒有什麼優點,缺點是Web跟Mail節點的通信沒有監控

38.1.3.3.3.2. 逐級診斷

一級一級的向下探測,尋找故障點,需要在各個節點埋探針。

			
      Monitor Server
              |
-------------------------------      
  |           |             |
  V           V             V
  |           |             |
[Web] ---> [Cache] ---> [Database]
  \                         ^
   `------------------------|			
			
			

首先監控伺服器跟星型拓撲一樣監控,再讓Web節點去訪問Cache節點然後返回監控結果,以此類推,讓Cache節點訪問Database, 讓Web訪問Database節點。

將所有業務邏輯都逐一模擬一次,任何一個環節出現問題,立即發出警告。

38.1.3.3.3.3. 模擬人工

這裡主要監控服務是否可用,可以檢查軟件的工作情況,涉及測試環節。

通過自動化測試工具輔助監控,例如模擬滑鼠點擊,鍵盤輸入,可以監控圖形界面程序與網頁程序。

Windows 監控可以通過 Windows Automation API實現,通過程序控制,能夠模擬人工操作軟件,實現操作匹配返回結果實現自動化監控

Web頁面監控的方案就太多了,比較經典的是Webdriver衍生出的各種工具Selenium - Web Browser Automation最為出名。我通過這個工具模擬用戶操作,例如用戶註冊,登陸,發帖,下單等等,然後匹配返回結果實現自動化監控與報警

38.1.3.3.3.4. 數據分析

通過數據分析,將故障消滅在故障發生前。舉一個例子,開發人員忘記設置redis 時間,雖然程序一直完好工作,但redis內存不斷增長,總一天會出現故障。

我們通過採集redis狀態信息,分析一段時間內數據變化發現了這個問題。

38.1.3.3.3.5. 監控與開發

談到監控很多人認為這是運維的事情,實則不然,不懂運維的測試不是好開發。

開發過程中需要考慮到監控,例如Nginx的status模組, MySQL的show status命令, Redis的info命令,都是為監控預留的。那麼你開發的程序是否考慮到了監控這塊呢?

你可以通過日誌形式或者管道,再或者Socket將程序的運行狀態提供給監控採集程序。

38.1.3.3.4. 總結

好的監控的能讓你對系統瞭如指掌,做到心裡有數。有數據才好說話。

38.1.4. Configuration Management(配置管理)

38.1.5. Change Management(變更管理)

38.1.5.1. 變更方案

38.1.5.2. 回退計劃

38.1.5.3. 變更評估

38.1.5.4. 變更授權

38.1.5.5. 過程記錄

38.1.5.6. 結果回顧

38.1.5.7. 機房遷移

總結一下5年前的工作,在不寫下來自己都快忘光了,工作關係現在已經不涉及運維這塊的工作。

38.1.5.7.1. 拓撲確立

首先制定伺服器拓撲圖,拓撲圖應該有兩套,一套是物理拓撲圖,另一套是基于業務的虛擬拓撲圖。

物理拓撲圖包含機櫃,機位,例如防火牆,核心交換機,機櫃交換機,伺服器,存儲等等他們之間的物理關係。如果是雲主機也許標註出來。

接下來分配IP地址以及服務連接埠號

最後製定虛擬拓撲圖,是各種服務間的關係圖,由IP地址和連接埠組成,標住出他們之間的關係。

38.1.5.7.2. 存儲規劃

什麼東西放在什麼地方,怎麼規劃空間等等。

38.1.5.7.2.1. RAID Disk Group 規劃

根據不同用途使用不同的RAID,這主要跟IO密集都與數據安全性有關。

Virtual Disk 技術很有用,我使用這種技術兩RAID劃分為兩個設備,一個用來安裝操作系統,另一個用於數據存儲,方便系統重做。

SSD 機械故障為零,整體故障率低於傳統硬碟。我通常做RAID0用與負載均衡場景。

38.1.5.7.2.2. 檔案系統規劃

我通常使用btrfs,LVM/EXT4已經過時。

/ 分區EXT4 安裝操作系統,swap 分區不一定是內存2倍,因為現在的伺服器都是8~16GB,OS很少能使用到交換分區,但是像Oracle這樣強制交換分區為內存兩倍。

其餘所有空間分區格式化為btrfs mount 到 /srv 目錄,在通過子卷(subvolume)分配給各個應用。

[Tip]Tip
子卷(subvolume) 有個特點是不能rm -rf 刪除子卷的,也起到一定的安全性。
38.1.5.7.2.3. 目錄規劃

以Tomcat為例

Tomcat 的虛擬機功能基本沒用,因為需要升級需要頻繁啟動,會影響其他業務,所以採用每個項目一個實例的方式。

			
/srv/apache-tomcat/ 是Tomcat目錄
/srv/apache-tomcat/www.netkiller.cn 每個實例一個目錄
/srv/apache-tomcat/other.netkiller.cn
			
			

以PHP為例

/srv/php-7.0.0
ln -s /srv/php-7.0.0 /srv/php
			

通過 /srv/php 符號連結可以任意切換PHP版本

代碼目錄與伺服器目錄分開

			
/www/netkiller.cn/www.netkiller.cn
/www/netkiller.cn/other.netkiller.cn
			
			
38.1.5.7.3. 設備上架

按照物理圖譜圖,對應機位安裝設備,連結網綫,整理機櫃。

注意強弱電分離,以免強電磁場干擾弱電。以Dell系列伺服器為例,電源通常在右邊,網口在中間左邊,這樣電源走機會右側理綫架,網綫走左側理綫架。

我通常每個機櫃放兩台千兆交換機,一台放在機櫃最頂端,通過10GB萬兆乙太網連結至核心交換機,走核心業務數據;另一台放在機櫃最底端,負責其他次要業務,例如遠程控制口,資料庫備份等等。

上電,接通電源,開機。觀察機櫃的電壓/電流變化。

38.1.5.7.4. 操作系統初始化

安裝操作系統,系統裁剪,內核優化,時區設置,配置history格式(記錄每條發出命令的時間點),TCP棧優化

安裝自動化運維客戶端,監控客戶端

38.1.5.7.5. 伺服器及運行環境

通過腳本或者自動化運維工具按照並配置。

安裝各種伺服器軟件如 nginx, apache-httpd, apache-tomcat ......

軟件運行環境,例如Java,PHP, Node.js, Ruby, Python ......

安裝資料庫,配置複製策略,備份計劃

38.1.5.7.6. 部署應用程序

配置管理員通過虛擬拓撲提供的IP地址,連接埠號以及運維提供的賬號密碼配置應用程序。

然後部署應用程序到遠程伺服器

38.1.5.7.7. 監控系統

應用程序部署完畢後不要急着測試,可能很多IP地址以及連接埠不通,這時候測試只能是頻繁報BUG。

我們先讓將監控系統建立起來,監控所有伺服器IP地址與連接埠,以及各種應用服務監控。

硬件監控: 溫度監控,風扇監控,RAID卡監控,內存監控,PCI設備監控...

操作監控:負載,CPU,內存,用戶登陸監控,磁碟空間監控,網絡流量監控,TCP/IP狀態監控,進程數量,綫程監控,殭屍進程,進程退出...

伺服器監控:連接數,綫程數,進程數,內存開銷,節點狀態...

日誌監控:如果監控到日誌中出現某些關鍵次,發出警報。

服務監控:HTTP,SMTP,POP,AJAX/JSON,XML

38.1.5.7.8. 日誌中心

所有的日誌應該實時同步到日誌中心,便于開發與測試人員實時觀察伺服器的狀態

38.1.5.7.9. 測試

當我們看到監控系統報表中的各種伺服器都暢通無阻時就可以進行驗收測試,測試的時候需要關注監控系統的表徵圖,與日誌中心的日誌變化。

安全測試:硬件防火牆規則,伺服器防火牆規則,SSL證書,伺服器版本號隱藏,操作系統權限檢查

壓力與性能測試

業務功能測試

38.1.6. Release Management(發佈管理)

38.1.6.1. 發佈類型

發佈的類型主要包括德爾塔發佈(Delta Release)、全發佈(Full Release)和包發佈(Package Release)三種

38.1.6.2. 發佈規劃

38.1.6.3. 參與人員與職責

38.1.6.4. 範圍與權限

38.1.6.5. 檢測標準

38.1.6.6. 過程和結果

38.1.7. 內部培訓

團隊培訓,指定培訓計劃等

38.1.8. IT資源管理