ITIL-IT運維管理-概述
ITIL-IT運維管理-概述
概述
IT服務管理（ITSM）是一套幫助企業對IT系統的規劃、研發、實施和運營進行有效管理的方法，是一套方法論。ITSM起源於ITIL（IT Infrastructure Library，IT基礎架構標準庫），ITIL是CCTA（英國國家電腦局）於1980年開發的一套IT服務管理標準庫。它把英國在IT管理方面的方法歸納起來，變成規範，為企業的IT部門提供一套從計劃、研發、實施到運維的標準方法。
中文名 IT服務管理 外文名 ITService Management
專家的研究和大量企業實踐表明，在IT專案的生命週期中，大約80%的時間與IT專案運營維護有關,而該階段的投資僅佔整個IT投資的20%,形成了典型的“技術高消費”、“輕服務、重技術”現象。
ISO 20000，即"資訊科技服務管理體系標準"，是面向組織機構的IT服務管理標準，目的是提供建立、實施、運作、監控、評審、維護和改進IT服務管理體系（ITSMS）的模型。ISO20000是國際標準化組織設立的國際標準
一 術語解釋
-
- ITIL生命週期（待完善）
服務戰略(Service Strategy): 指導如何設計、開發和實施服務管理，包括組織能力及戰略資產。
服務戰略為組織在設計、開發和實施服務管理從組織能力和戰略資產兩個戰略角度來提供指導。該部分內容提出了服務管理實踐過程中整個服務生命週期的策略、指南和過程。服務戰略是服務設計、服務轉換、服務運營和服務改進的基礎，它的主題包括了市場開發、、內部和外部的服務提供、服務資產、服務目錄，
服務設計(Service Design)：指導設計服務及服務管理流程
服務設計描述了對服務及服務管理過程設計和開發的知道，它包括將戰略目標轉變成服務投資組合和服務資產的原則和方法，服務設計的範圍不僅限於新的服務，它還包括為保持和增加客戶價值而實行服務生命週期過程中必要的變更和改進，服務的連續性，服務水平的滿足，以及對標準，規則的遵從性。它指導組織如何開發設計服務管理的能力。
服務轉換(Service Transition): 指導將新的或變更的服務引入生產環境
服務轉換為如何將新的或變更的服務轉換到運營過程中有關能力的開發和改進的指導，服務戰略需求通過服務設計進行編碼，而服務轉換則是探討如何將這種編碼有效匯入到服務運營的體系中，與此同時，還應控制失敗的風險和服務的中斷。
服務運營(Service Operation)：
服務運營包含了在服務運營方面的實踐，它對如何達到服務支援和交付的效果與效率，確保客戶與服務供應商的價值提供了指導，並最終通過服務運營實現戰略目標。
事件管理(Incident Management)
問題管理(Incident Management)
持續服務改進(Continual service Improvement):
服務改進為創造和保持客戶價值而用更優化的服務設計、轉換和運營提供指導。它結合了質量管理、變更管理和能力改進方面的原則、實踐和方法。組織要學會在服務質量、運營效率和業務連續性方面的不斷提高和改進意識。此外，它還為改進所取得的成就與服務戰略、服務設計和服務轉換之間如何建立關聯提供指導，為基於戴明環(PDCA)形成計劃性變更的閉環反饋系統的建立提供思路。
二服務戰略(Service Strategy)
如何設計、開發和實施服務管理的指導，不僅僅是從組織能力角度，同時也考慮戰略資產
服務戰略流程︰活動組合管理、財務管理、需求管理
目的，幫助組織具備戰略思考方式，使用戰略資產，幫助組織將服務管理轉換為戰略資產。
年終的時候創作什麼價值，IT運維的價值。
服務組合管理
包含了三個分類
·服務管道（Service Pipeline):建議或者開發中
·服務目錄（Service Catalog）:線上或者可以部署
·退役服務（Retired Service)
服務組合管理（Service Portfolio Management，SPM)
·負責管理服務組合的流程
職責包括
·在生命週期中，將服務作為一個產品來管理
·圍繞服務目錄來協調和關注組織
·與業務關係經理（Business Relationship Manager ,BRM-業主）合作
·作為服務及服務目錄的主題相關專家
財務管埋
預算（Budgeting )
會計核算(Accounting )
收費（Charging)
需求管理-一定要深入熟悉業務
影響客戶需求的活動
滿足這些需求的能力儲備
2.1 學習心得
IT運維要緊跟業務，為業主提供，業務培訓和指導，才能離不開你，創造價值。
三 服務設計(Service Design)
負責設計新的或者變更的服務，引入生產環境，包括架構、流程、政第及文件。
主要有以下管理
服務目錄管理
供應商管理
服務級別管理
能力管理
可用性管理
資訊保安管理
IT服務連續性管理
服務設計的範圍
新的或者變更的服務
服務管理系統和工具，尤其是服務組合（包括服務目錄）
技術架構與管理系統
必要的流程
度量方法和度量指標(Measurement methods and metrics)
3.1 服務目錄
服務目錄-運維管理SLA服務
服務目錄組織提供給客戶服務的成文資訊，可以明確能提供服務的專案。SLA服務級別協議是指提供服務的企業與客戶之間就服務的品質、水準、效能等方面所達成的雙方共同認可的協議或契約。
3.2 供貨商管理
供應商管理流程的目的是管理供應商以確保服務的無縫銜接和服務質量。服務提供者能調動供應商資源來運營部分流程和服務，或者提供服務元件(如硬體和軟體）。
3.3 服務級別管理
SLA服務級別協議是指提供服務的企業與客戶之間就服務的品質、水準、效能等方面所達成的雙方共同認可的協議或契約。
服務級別管理
·協商SLA
·確保滿足SLA
·確保所有IT服務管理流程、OLA及基礎合同對於服務
級別目標是合適的
. SLM監控和報告服務級別，儲存階段性客戶回顧
3.3.1服務級別管理術語
SLA（Service Level Agreement）服務級別協議，是指提供服務的企業與客戶之間就服務的品質、水準、效能等方面所達成的雙方共同認可的協議或契約。
服務級別協議(Service Level Agreement, SLA)
·IT服務提供者和客戶之間的協議
·描述IT服務
·證明服務級別目標
·明確IT服務提供者和客戶的職責
一個單獨的SLA可能覆蓋多個IT服務或者多個客戶
服務級別需求（Service Level Requirement， SLR)
·客戶對IT服務的需求
·基於業務目標
·用於協商服務級別目標
·清除差的服務
·改進IT和客戶之間的關係
服務級別目標(Service Level Target )
。一個SLA的交付文件
·基於服務級別需求（SLR)
·保證IT服務設計滿足目標
·支援合同(UC)
·IT服務提供方與外部供應商就某一特定服務專案的提供與支援所簽訂的協議
·操作級別協議（Operational Level Agreement, OLA)
IT服務提供者和同一組織中另一部分之間的協議
·支援IT服務提供者為客戶提供服務
·定義提供的貨物或者服務
·舉例:服務檯和一個解決事故的支援組
3.4 可用性管理
可用性Availability：是指一個元件或一種服務在設定的某個時刻或某段時間內發揮其應有功能的能力。總時間-故障時間/總時間 99.9%，99.99%
99.9 = 8760 * （100-99.9）%= 8760 * 0.001 = 8.76小時
99.99 = 8760 * 0.0001 = 0.876小時 = 0.876 * 60 = 52.6分鐘
99.999 = 8760 * 0.00001 = 0.0876小時 = 0.0876 * 60 = 5.26分鐘
可靠性Reliability:是指IT基礎架構可以無間斷運作的能力，它主要取決於單個IT元件的可靠性和IT基礎架構的整體恢復能力。有些裝置出場就有可靠性，比如說，硬碟是質保3年。
主要是兩個指標
1 MTBF：平均故障間隔時間，具體是指bai產品從一次故障du到下一次故障的平均時zhi間，是衡量一個產品的可靠性指標。
2 首次故障時間
可維護性Maintainability
可服務性Serviceability
目的
·提供與服務和資源相關的所有可用性事宜的管理
·保證所有提供的服務的可用性級別被滿足
·滿足或者超過當前及未來業務可用性的需求
3.5 能力管理
能力管理，保證IT服務和IT基礎設施的能力足以達到服務級別目標，考慮提供IT服務需要的所有資源。
為保證系統在運維階段能夠得到有效的執行、維護和更新，在專案由實施團隊交由運維團隊運維的過程中，實施團隊需要根據專案運維需要進行有針對性的技能、知識的系統培訓，完成系統能力交接，使運維團隊成員掌握專案相關知識，並且能夠勝任該專案的運維工作，達到能獨立解決運維過程中所出現的各類系統相關問題。
3.6資訊保安管理
資訊保安是指為資料處理系統而採取的技術的和管理的安全保護，保護計算機硬體、軟體、資料不因偶然的或惡意的原因而遭到破壞、更改、顯露。保證組織資產、資訊、資料及IT服務的機密性、完整性及可用性。資訊保安管理過程應確保資訊保安控制措施能保護資訊資產，同時，新的和變更的服務的設計與轉換應考慮資訊保安需求。
四 服務轉換ST(Service Transition )
通俗的說，基於設計的方案或者開發的環境， 平穩的落實到生產的環境。
服務轉換(Service Transition )
·通過管理變更和風險來定義高質量服務
·包括的流程︰變更管理，服務資產和配置管理，釋出和部署管理。
4.1 變更管理
4.1.1 理解變更和風險
變更管理
·控制所有變更的生命週期
·在最少的中斷下實現有收益的變更
Goals（目的）
響應客戶業務變更需求，實現價值最大化，減少事故、業務中斷和返工
·響應業務和IT需求變更，使得服務和業務需求一致
價值
·提高可靠性和業務連續性，對任何組織的成功和生存而言都是最基本的。
變更管理推動業務，通過
·確定優先順序並相應業務和客戶變更建議
·實現變更滿足客戶認可的服務需求，同時優化成本
·減少失敗的變更，以及服務中斷，缺點和返工
·按照時間表及時提供變更
·在服務生命週期中跟蹤變更
·提供更好的質量、時間和變更成本的估算
有沒有應急預案和回退方案。
4.1.2 定義變更的範圍
4.1.3 變更管理流程
RFC變更請求-變更管理始終要和配置管理同步，目前也是很欠缺的。
4.2 資產和配置管理
服務資產與配置管理
·配置管理:負責維護配置項的資訊，（我的理解初級就是文件，知識管理）
·資產管理︰負責在整個生命週期中跟蹤財務價值及所有權
4.2.1 配置管理元件
·配置管理資料庫(Configuration management Database CMDB)
·用於在整個生命週期中儲存配置記錄的資料庫
·儲存CI的屬性，及其與其它CI的關係
·配置管理系統( Configuration Management System ,CMS)
·工具及資料庫的集合，用於管理配置資料
·被所有IT服務管理流程引用
4.3 釋出和部署管理
·釋出管理和部署管理的職責
·釋出管理
·負擊將版本轉移到測試和現場環境，包括計劃和控制
·確保現場環境的版本以及釋出的元件版本
·版本(Release )
硬體、軟體、文件流程及其它元件的集合，用於實現一個或多個批准的IT服務變西，該並更作為—個賣體來管理、測試和部醬
·部署
負責將新的或者變更的硬性、軟體、文件、流程等移動到生產環境的活動
4.3.1 釋出管理
最少要有系統部署說明，系統更新說明。
4.3.2 測試管理
儘量和生產環境一致
4.3.3 部署管理
回退計劃
手動備份資料
對變更的配置保留證據
應急方案
備件
應急響應預案
逐步更新—生產環境小範圍測試後—再大面積升級。
4.4 知識管理
·確保有正確的資訊，幫助決策和運營支援
·確保組織在整個服務生命週期中可以通過可靠的、安全的資訊、資料來改進決策管理
·知識管理貫穿整個服務生命週期。服務轉換中對知識
管理僅作基本概念的講解
知識管理在服務轉換中尤為重要，原因是轉換時需要相應的知識來保障。
業務價值
舉例說明成功的轉換以來知識管理:
·使用者，幫助臺等理解新的換變更的服務包括對於錯誤的知識有助於幫助他們各自的崗位工作。
·瞭解服務的使用包括之前版本。
·在轉換的同時建立可接受級別的風險和信任級別。例如度量，正確理解和響應測試結果，並確保它們。
·知識管理是一種資產，個人或團隊可以共亨資料，資訊和知識。
五服務運營(Service Operation)
為有效和高效地完成服務支援和服務提供，確保客戶和服務提供者的利益提供指導方針
包括的流程:事件管理、事故與問題管理、請求實現、訪問管理、
包括的職能:服務檯、技術管理、IT運營管理、應用管理
5.1 服務檯
IT服務檯可實現高效的IT運維管理，大大提高IT運維效益和降低風險成本，整體把控IT資源、優化資源配置，規範運維管理流程，每一個事件可記錄、跟蹤、統計。
服務檯是支援IT運維服務的核心功能，與各個流程聯絡密切。所有使用者都要通過服務檯進行諮詢、報修、投訴等操作，服務檯負責為使用者解答相關問題和需求、為使用者派遣現場工程師、處理使用者投訴、記錄統計工程師工作量等。
5.2 IT運營管理
運營控制(Operations Control)
監視和監控IT基礎設施中的事件和運營活動
控制檯管理、應用狀態、備份恢復、效能維護活動等
裝置管理(Facilities Management)
管理物理的IT環境
資料中心、恢復中心、伺服器、儲存、網路、供電、空調等
5.3 技能管理
複雜事故處理、解決方案/構架
提供技術專家意見，負責IT基礎設施的技術管理
小組
部門
團隊
角色
IT感礎設施相關的技術知識和經驗管理人
提供實際的資源，來支援IT服務管理生命週期
目標
幫助計劃、實施和維護穩定的技術架構
文件
技術文件
-技術手冊
-管理手冊
-使用者手冊
維護計劃
角色
技術經理團隊Leader
技術分析師/架構師
5.4 事件管理與問題管理
事件管理的宗旨是最短時候恢復故障，從而將故障的損失降到最低，在此前提下儘可能滿足服務的要求。
當緊急故障得以處理，資訊中心就會轉而進入問題管理的層面，以便找到故障發生的原因，從而改變頻於應付突出事故的局面。
與事件管理的根本區別就在於，事件管理目的在於恢復企業生產，而問題管理在於找出IT故障的根本原因，制定解決方案，防止類似故障的再次發生。
六 運維交接
6.1 瞭解業務-第一步
6.2 瞭解系統架構-第二步
跟開發聊聊業務架構，瞭解所使用的技術，為什麼使用，以及好處。最好讓其準備PPT能演講下，如果不行讓其發發文件看看也是好的，梳理以下幾點
瞭解各專案業務架構設計，及拓撲圖
大流量場景業務
目前存在的業務瓶頸
有無歷史遺留落後設計
有無應用最新技術及為什麼這樣選擇
在這裡只是瞭解，運維跟研發是會一直合作的，因此後面可以帶著問題再找到相關負責人
6.3 運維相關-第三步
這裡就涉及到我們的主要工作了，瞭解運維的方式，技術棧等等，列了如下
瞭解閱讀運維文件，一般有wiki（知識庫），因此可以先看看大致瞭解，但不是所有wiki都有章有法，多數還是很亂
瞭解當前運維資產，伺服器、網路、資料庫等相關運維資源情況
瞭解當前運維方式，如人肉、指令碼、自動化等等，看看當前處於哪個階段
瞭解當前運維技術棧，畢竟運維技術、工具更新快，且多又雜，不一定都接觸過
瞭解線下線上釋出流程，是否自動化
瞭解各業務部署的運維架構
瞭解目前運維安全方面的防護
瞭解和開發測試運營等合作方式
減少踩坑風險
相信很多人如果接手其他人的工作時，前面都是比較痛苦的，因為其他人的工作方式、理念等都跟自己或多或少都有出入，就運維而言，自己當前的技術能力如果與接手的運維工作階段(如自動化程度較高)有出入，則很難快速著手，比如工作中沒有一定的標準、規範會導致很混亂，或者即使有標準規範，但執行得不理想。又或者工作中都靠口頭相傳，沒有很好的文件記錄，因此想要快速，首先自身的技術需要有一定的基礎，其次就是努力熟悉了，這裡我主要是提出幾點減少踩坑坑的方法
1.做好記錄
如果跟人交接，則一定要做好記錄，這點非常重要，因為人在短時間內接收一大堆東西是非常容易忘記的，俗話說的好，好記性不如爛筆頭，最重要的是自己記錄的過程也會形成一種記憶，可以回想當時為什麼這樣記錄幫助回憶，另外很多wiki上找不到的考運維間口頭相傳的更要記錄
2.標準與非標準
現在運維DEVOPS理念很火，但其實好些團隊做得並不完全，有些地方做了標準化，有些地方又保留了老的，導致運維過程中，有些自動化了有些還是人肉，這些需要好好區分開來，否則很容易出故障，當然後續是一定優化這樣的不良運維
3.熟悉各業務所在伺服器
首先運維自己也要熟悉產品相關的業務，當我們業務出問題時，才能第一時間處理，比如某個頁面打不開，那麼是什麼域名，什麼業務，可能在哪些地方出故障，我們也要第一時間知道這些業務在哪些伺服器上面，這樣才能方面運維排查問題，所以要熟悉業務和伺服器間的拓撲圖
4.熟悉各個服務程序的啟動停止方法
在運維裡面流行一句話，沒有什麼是重啟解決不了的，雖然不那麼準確，但是運維工作中，的確有很多時候的故障是可以通過重啟來快速恢復業務的，那麼我們不同的服務程序如何重啟一定要優先了解熟悉並記錄，才能做到更快速的管理程序
5.熟悉各個服務的檔案配置路徑、日誌路徑
運維工作中總會有變動，故障等，當需要修改配置檔案，以及檢視日誌時，如果我們不熟悉則會查詢許久，因此在交接過程中這些也一定要記錄下來，才能快速處理運維需求及故障
6.熟悉瞭解各個伺服器的開機啟動項
開機啟動或者有哪些還沒有加入開機啟動的程序一定要注意，有時候伺服器宕機了程序沒有啟動，就影響了業務，因此要去了解如chkconfig、/etc/rc.local裡面的內容及未新增的
7.熟悉好釋出流程
跟運維及其他部門瞭解程式碼釋出平臺、流程等，這是經常用到的，問問有無哪些需要運維經常配合的，還有一些歷史遇到的一些問題
8.瞭解以往故障
對以前運維中發生的故障如果有記錄那就最好去了解，看看當時的故障表現及處理方法，如果沒有記錄，也可以詢問同事瞭解
9.對不熟悉的技術棧先淺嘗
運維技術工具眾多，我們一般不會每一種都瞭解，如果接手的剛好有較多自己不熟悉的，可以先了解，然後知道怎麼重啟管理程序以及檢視日誌排查問題即可，等有富餘時間了再逐漸深入學習，這樣才不會消耗大量的時間在一些不熟悉的事情上面
10.優先深入理解核心業務
要跟運維開發測試運營產品等了解哪些是非常核心的業務，是不可容忍停機停服的，這些是我們重點關注並且需要非常熟悉的，需要很仔細的對待交接，千萬不能馬虎
11.搞好關係
沒錯啦，無論是交接還是去了解學習，一定要跟同事們打好關係，可以適當的請客吃飯幾次，這點非常重要，因為在交接的時候，有些坑如果對方不說，你不一定看得到。所謂害人之心不可有，防人之心不可無，大家相處融洽，其樂融融，相信在交接的時候也更願意將經驗之談奉上，說不定還能多學習些運維知識，提升自己技術水平，還交個朋友，何樂而不為
6.4 運維交接文件
《需求說明書》 詳細描述系統的功能性需求和非功能性需求，包含相應的需求質量屬性等。 高
《系統概要/設計/整合設計說明書 》包括總體技術架構、系統邏輯與物理拓撲圖功能、實現、模組組成、功能流程圖、函式介面、資料字典、整合等軟體開發需要考慮的各種問題。 高
《資料字典》 高
《測試報告》 中
《使用手冊》 系統/產品簡介、功能列表、功能描述和解釋、功能操作等。 高
《部署文件》 高
《常見問題處理說明》 高
《運維手冊》 系統維護手冊應說明系統的.總體技術架構、系統邏輯與物理拓撲圖、系統裝置詳細組成清單、系統軟硬體部署方案和步驟(特別是須準確說明配置引數要求和關鍵步驟）系統依賴的後臺伺服器﹑網路、資料庫等的可用性與效能要求，以及日常維護任務及要求 。 高