ITIL - 快速指南

---

---

ITIL - 概述

ITIL 是一個提供端到端服務管理各個方面最佳實踐指南的框架。它涵蓋了人員、流程、產品和合作夥伴使用的完整範圍。

如今，幾乎每家向客戶提供 IT 服務的公司都在實踐 ITIL。

ITIL 中描述的流程、任務和檢查清單並非特定於組織，而是任何組織都可以實施。它為組織提供了一個框架來計劃、實施和衡量 IT 服務。

ITIL 於 1989 年由英國女王文具局 (HMSO) 代表中央通訊和電信局 (CCTA)（現已併入政府商業辦公室 (OGC)）在英國釋出。

為什麼需要 ITIL？

ITIL 幫助業務經理和 IT 經理以有效的方式向客戶交付服務，從而贏得客戶的信任和滿意度。ITIL 發揮有效作用的領域如下所示 -

• IT 和業務戰略規劃

• 整合和協調 IT 和業務目標

• 實施持續改進

• 獲取和留住合適的資源和技能

• 降低成本和總擁有成本

• 證明 IT 的業務價值

• 實現和證明物有所值和投資回報率。

• 衡量 IT 組織的有效性和效率

• 發展業務和 IT 夥伴關係和關係

• 提高專案交付成功率

• 管理持續的業務和 IT 變革

ITIL 版本

ITIL 最初的形式是一套書籍，涵蓋了 IT 服務管理的各個方面。從那時起，ITIL 經歷了許多變化，因此存在許多 ITIL 版本，如下所示 -

ITIL V1

這是 ITIL 的第一個版本，最初包含 31 本書。

ITIL V2（2000 年至 2004 年）

V1 被 7 本書取代，並在 2000 年至 2004 年期間獲得了廣泛的認可。目前，許多國家的許多公司都在採用此版本，並且此版本也已成為公認的版本。

ITILV2（2007 年）

這是先前 ITILV2 的另一個修改和合並版本，稱為 ITIL 的第三版，包含五本核心書籍，涵蓋服務生命週期。ITIL V3 包含26 個流程和 4 個職能。

2011 年，釋出了 2011 版 V3。這是 2007 年釋出的更新版本。

ITIL 出版物

ITIL 核心出版物包括五本手冊：服務策略、服務設計、服務過渡、服務運營和持續服務管理。

ITIL 的優勢

下圖顯示了 ITIL 提供的優勢 -

ITIL V2 與 ITIL V3

ITIL V2 和 ITIL V3 的比較如下表所示 -

ITIL – 術語

在本章中，我們將討論一些 ITIL 的基本術語，這將有助於輕鬆快速地理解本教程。下表包含學習 ITIL 所需的所有基本術語。

ITIL – 服務基礎

本章詳細討論了 ITIL 的服務基礎。

服務

服務是在給定約束條件下實現客戶期望結果，從而為客戶提供價值的一種手段。

服務與產品

下表顯示了服務和產品的比較 -

服務管理

服務管理是指 IT 服務提供管理的各個方面。根據 ITIL，服務管理包含所有組織能力，旨在作為服務為客戶創造增值。

服務管理的目標

服務管理的主要目標是 -

• 使 IT 服務能夠適應組織及其客戶當前和未來的需求。

• 與業務建立和維持良好且響應迅速的關係。

• 有效且高效地利用所有 IT 資源。

• 最佳化交付服務的質量。

• 降低服務交付的長期成本。

實現服務管理

為了實現業務和客戶滿意度，需要執行的關鍵活動如下所示 -

• 在服務級別協議 (SLA) 中記錄、協商和商定客戶和業務質量目標以及責任。

• 定期在客戶反饋和客戶滿意度調查中評估客戶意見。

• IT 人員以客戶和業務為導向，並始終努力使客戶互動儘可能簡單。

• 瞭解 ICT 基礎設施。

• IT 人員定期體驗客戶旅程並採樣客戶體驗。

ITIL – 服務生命週期

ITIL 的完整框架基於服務生命週期。每個生命週期都定義了某些流程以有效地進行服務管理。

服務生命週期有助於增強服務管理方法，並更好地理解其結構。在接下來的章節中，我們將分別討論所有這些生命週期及其流程和職能。

流程和職能

ITIL V3 中包含 26 個流程和 4 個職能。這些流程和職能在後續章節中將結合每個服務生命週期進行詳細討論。

流程

流程定義了策略、標準、指南、活動和工作說明。它接收一些定義的輸入以產生期望的結果。

職能

職能被定義為執行一個或多個流程和活動所需的人員或工具的集合。

ITIL – 服務策略概述

服務策略有助於將服務管理設計、開發和實施為組織能力和戰略資產。它使服務提供商能夠隨著時間的推移，跨越業務週期、行業中斷和領導層變革，始終優於競爭對手。

服務策略包含以下關鍵概念：

• 價值創造

• 服務資產

• 服務提供商型別

• 服務結構

• 定義服務市場

• 開發服務產品

• 財務管理

• 服務組合

• 需求管理

• 投資回報率

戰略評估

在制定服務策略之前，提供商應首先仔細檢視其已有的工作內容。以下問題可以幫助揭示服務提供商的獨特能力：

• 我們哪些服務或服務種類最具特色？

• 我們哪些服務或服務種類利潤最高？

• 我們價值鏈或價值網路中的哪些活動最獨特有效？

戰略評估因素

在戰略評估中發揮重要作用的關鍵因素如下：

價值創造

服務策略定義了一種提供更高價值的獨特方法。根據客戶的需求，服務應包含兩個要素：

• 效用

• 保證

效用

效用是客戶從服務的屬性中感知到的，這些屬性對與所需業務成果相關的任務的執行產生積極影響。這是適合目的的。

效用通常以以下方面表示：

• 支援的結果

• 避免的所有權成本和風險

保證

保證確保服務的效用能夠根據需要以足夠的容量、連續性和安全性提供。保證的價值以確定性水平來傳達。

保證通常以服務利用的可用性、容量、連續性和安全性方面來定義。

可用性

它向客戶保證，服務將在商定的條款和條件下可用。

容量

它確保服務將在指定級別支援指定級別的業務活動或需求。

連續性

它確保服務將在重大故障期間繼續支援業務。

安全性

它確保服務提供商提供的服務將是安全的。

服務資產

服務資產有兩種型別，如下所示：

• 資源

• 能力

資源

資源是生產的投入。資源透過管理、組織、人員和知識進行轉換。

能力

能力是指開發和控制生產資源的技能。這些技能基於知識、經驗和資訊。

服務提供商型別

服務提供商可以大致分為以下三種類型：

型別 I - 內部服務提供商

內部服務提供商指的是組織內部的業務職能。行政、財務、人力資源和 IT 服務提供商都屬於內部服務提供商。

型別 II - 共享服務提供商

在這種型別中，IT、人力資源和物流等業務職能被整合到一個稱為共享服務單元 (SSU) 的自治特殊單元中。

型別 III - 外部服務提供商

外部服務提供商指的是第三方服務提供商。它可以提供有競爭力的價格，並透過整合需求來降低單位成本。

策略的四個 P

下面提到的四個 P 識別了服務策略的不同形式，並被視為服務策略的切入點。

視角

它描述了願景和方向，並闡明瞭與客戶互動的商業理念。

定位

它描述了採用明確立場的決定。它表現為在客戶心目中的獨特性。這意味著在與他人相同的領域競爭，但具有對客戶有吸引力的差異化價值主張。無論是向特定型別的客戶提供廣泛的服務，還是成為最低成本的選擇，這都是一種戰略定位。

計劃

計劃描述了“我們如何提供高價值或低成本的服務？”或“我們如何實現和提供我們的專業服務？”

模式

它描述了組織的基本做事方式。

服務策略流程

下圖表達了服務策略中不同的流程及其關係：

策略管理

此流程涉及四個活動：市場定義、產品開發、戰略資產開發以及策略實施準備。

服務組合管理

服務組合定義了服務提供商可以提供的所有服務。它有助於控制整個企業的服務管理投資並積極管理其價值。

業務關係管理

此流程透過確保開發適當的服務來滿足客戶的需求，來處理建立服務提供商與客戶之間良好關係的問題。

需求管理

此流程在服務的消費和交付之間保持平衡。

財務管理

財務管理有助於確定 IT 組織的所有成本。它可以作為三種服務提供商型別（內部、外部和共享服務提供商）的戰略工具。

ITIL – 服務策略角色

有幾個角色負責管理服務策略的不同關鍵方面。本章將詳細討論每個角色。

ITIL – 策略生成

為了獲得積極的結果，服務提供商需要戰略性地規劃其服務。良好的服務策略定義了一種提供更高價值的獨特方法。

服務策略經理是此流程的流程所有者。

服務生成子流程

策略管理包括以下四個活動：

定義市場

有必要對市場上提供的服務進行調查。它清楚地瞭解了現有服務的成本和質量，以及在競爭環境中可以提供哪些新服務。

開發產品

在此，服務提供商開發了一個包含所有對客戶可見且可用的服務的組合。開發服務組合是為了代表所有面向市場的具有約束力的服務投資。

開發戰略資產

它涉及購買新技術、資源和能力，以便為客戶提供低成本和高價值的服務。

衡量和準備策略實施

為了衡量策略的成敗，會衡量所有關鍵成功因素。此外，還會觀察市場上的競爭情況，並相應地調整優先順序。

ITIL – 服務組合管理

服務組合

服務組合包含在整個服務生命週期中參與的所有服務的描述。它還代表了服務提供商在所有客戶和市場空間中做出的承諾和投資。

服務目錄是服務組合的一個子集，包含服務運營階段中當前活動的的服務。我們將在服務設計流程中詳細討論服務目錄。

服務組合管理

服務組合管理確保服務提供商提供合適的服務組合來滿足客戶的需求。

服務組合經理是此流程的流程所有者。

服務組合管理的目的是回答以下問題：

• 客戶為什麼要購買此服務？

• 他們為什麼要從我們這裡購買？

• 定價結構採用什麼形式？

• 我們的優勢和劣勢、優先順序和風險是什麼？

• 我們應該如何運用我們的資源和能力？

子流程

服務組合管理包括以下圖所示的子流程：

定義

此流程的目的是定義服務的期望結果。

分析

此流程的目的是分析擬議的新服務或更改後的服務對服務組合中現有服務的影響。

批准

此流程的目的是將變更提案提交給變更管理，並在授權變更提案後啟動新服務或更改服務的計劃階段。

授權

此流程的目的是傳達決策，分配資源並授權服務。

ITIL – 業務關係管理

本章詳細討論了ITIL中業務關係管理的各個方面。

關係

關係是兩個人或事物之間的聯絡。在業務關係管理的情況下，它是IT服務提供商與業務之間的聯絡，而在配置管理中，它是兩個相互依賴的配置項之間的聯絡。

業務關係管理流程確保服務提供商與客戶之間良好的關係。它通常透過識別、理解和支援客戶的需求來實現，並開發適當的服務來滿足這些需求。

業務關係管理通常包括：

• 管理與管理人員的個人關係

• 為服務組合管理提供輸入

• 確保IT服務提供商滿足客戶的需求

業務關係經理是此流程的流程所有者。

子流程

業務關係管理包括以下子流程：

維護客戶關係

此流程確保服務提供商瞭解客戶的需求，並與新的潛在客戶建立關係。

識別服務需求

此流程確保服務提供商完全理解服務的輸出，並確定是否可以使用現有的服務產品來滿足客戶的需求，或者是否需要建立新的服務。

將客戶註冊到標準服務

此流程處理客戶需求和服務水平協議。

處理客戶投訴

此流程的目標是記錄客戶的投訴，並在需要時採取糾正措施。

監控客戶投訴

此流程的目標是監控客戶投訴的處理狀態。

客戶滿意度調查

此流程的目標是確定未滿足客戶期望的範圍。

ITIL – 需求管理

需求管理是服務策略中一個非常重要和關鍵的流程。它有助於瞭解客戶對服務的需求，以便能夠提供適當的容量來滿足這些需求。

不當的需求管理會導致服務和資源的不當使用。因此，分析客戶的需求是值得的。

需求經理是此流程的所有者。

戰略層級需求管理

戰略需求管理側重於以下兩個重要方面：

業務分析模式（PBA）

PBA是一項極其重要的活動，通過了解客戶如何運營以及他們未來可能需要的需求來實現。

使用者配置檔案

這是使用者顯示的需求模式。它可以是流程、人員或功能。

戰術層級需求管理

在戰術層級需求管理下，我們關注差異化定價。這是一種透過在不同時間對相同的IT服務功能收取不同的費用來支援需求管理的技術。

需求管理中的挑戰

需求管理是服務策略的關鍵流程。在此流程中出現的挑戰如下所示：

• 對客戶需求的分析不當會導致容量的使用不當。過多的容量會產生成本，而不會創造價值。

• 有時需要一定量的未使用的容量來提供服務水平。此類容量透過更高容量帶來的更高保證水平來創造價值。

• 需要制定服務水平協議、預測、計劃，並與客戶緊密協調，以減少需求的不確定性。

• 如果沒有消耗輸出的需求同時存在，則無法進行服務生產。

• 需求的到來也受需求管理技術的影響，例如淡季定價、批次折扣和差異化服務水平

服務包

它有兩個組成部分，如下所述：

核心服務，即客戶願意付費的基本服務。它們為客戶帶來實際價值。

支援服務增強了核心服務的價值主張，即關鍵服務的附加功能。

開發差異化產品

核心服務和支援服務的打包對設計和運營服務有影響。需要確定是標準化核心服務還是支援服務。人們可以透過採用不同的打包方法來實現服務產品相同水平的差異化，如下圖所示。

服務級別包

服務包附帶一個或多個服務級別包（SLP）。每個服務級別包都從客戶的結果、資產和PBA的角度提供明確的效用和保證水平。

業務成果是服務級別包的最終基礎。

ITIL – 財務管理

財務管理涉及服務的會計、預算和收費活動。它根據直接成本和間接成本確定IT組織的所有成本。此流程被所有三種類型的服務提供商使用——內部、外部或共享服務提供商。

財務經理是此流程的流程所有者。

財務管理的好處

以下是財務管理的一些好處：

• 增強決策

• 變化速度

• 服務組合管理

• 運營控制

• 價值獲取和創造

財務管理的關鍵決策

以下決策需要為財務管理決策做出：

成本中心、價值中心或會計中心

確定如何補充資金非常重要。圍繞運營模式的清晰度極大地有助於瞭解必要條件、服務提供成本的可見性和資金，是對企業對IT的信心和認知的良好檢驗。

IT財務週期始於應用於建立輸出的資源的資金，該輸出被客戶識別為價值。反過來，此價值包括再次開始的資金週期。

收費——是否收費

收費模式提供了額外的問責制和可見性。收費應為企業增加價值。

收費模式因計算的簡單性和企業理解它們的能力而異。一些示例收費模式包括以下元件。

名義費用

這解決了是否將分錄記入公司財務系統。在這裡，我們使用了一種雙賬簿方法，其中一個在公司財務系統中記錄成本，而另一個賬簿則保留但不記錄。

第二個賬簿提供了相同的資訊，但反映瞭如果使用替代記錄方法會發生什麼。

分層訂閱

它指的是為服務提供的不同級別的保證和/或效用，所有這些都已定價，並應用了相應的收費模式。

計量使用

在此，需求建模與實用計算功能相結合，以增強對即時使用情況捕獲的信心。

固定或使用者成本

在此，成本除以商定的分母，例如使用者數量。

ITIL – 服務設計概述

服務設計是ITIL不可或缺的一部分。本章將詳細討論這一點。

簡介

服務設計為服務提供了藍圖。它不僅包括設計新服務，還設計對現有服務的更改和改進。

它還讓服務提供商瞭解如何開發和獲取服務管理的設計能力。

平衡設計

服務必須能夠根據動態變化的業務需求進行調整。為此，必須在以下三個因素之間保持平衡：

• 具有所需質量的功能

• 資源，即人員、技術和可用資金

• 時間表

服務設計的方面

服務設計側重於以下方面：

• 旨在滿足業務目標的IT服務。

• 旨在既適合目的又適合使用的服務。

• 計劃實現投資回報的擁有成本。

• 平衡的功能、成本和效能。

• 更穩定和可預測的IT服務。

• 降低潛在風險，從而保護IT服務免受安全威脅。

• 設計技術架構、管理架構和系統管理工具。

• 設計服務、流程、架構和底層元件的測量系統、方法和指標。

• 服務解決方案的設計，包括所有商定的功能需求、資源和能力。

面向服務的架構

面向服務的架構（SOA）指的是開發獨立可用的服務。SOA 由資訊結構促進組織（OASIS）定義。SOA 透過模組化提供更大的靈活性。

SOA方法的先決條件

實施SOA方法所需的先決條件如下：

• 服務的定義

• 服務之間介面和依賴關係的清晰度

• 服務開發和定義標準的應用

• 使用廣泛的技術和工具。

服務設計流程

下表描述了服務設計中的幾個流程：

ITIL – 服務目錄管理

服務目錄

服務目錄包含客戶願意付費的特定服務的相關資訊。它是一個知識管理工具，允許員工和顧問路由他們對服務的請求和關於服務的請求。

服務目錄是服務組合的一個子集，包含當前處於服務運營階段的活動服務。

服務目錄組成

目錄中的每個服務包含以下元素 -

• 服務的識別標籤

• 服務的描述

• 相關的服務請求型別

• 任何支援或支撐服務

• 允許將其與其他類似服務分組的服務分類或型別

• 所有服務之間以及服務目錄和CMS中的支援元件和配置項 (CI) 之間的介面和依賴關係

• 服務的明確所有權和責任

• 相關成本

• 如何請求服務以及如何交付服務？

• 升級點和關鍵合同

• 服務級別協議 (SLA) 資料

服務目錄方面

服務目錄有兩個方面 -

業務服務目錄

它包含交付給客戶的所有 IT 服務，以及它們與業務部門和依賴於 IT 服務的業務流程之間的關係。

技術服務目錄

它包含交付給客戶的所有 IT 服務，以及它們與支援服務、共享服務、元件和 CI 之間的關係，這些服務和元件對於支援向業務提供服務至關重要。

服務目錄管理流程負責向所有授權人員提供有關所有已協商服務的相關資訊。此流程還負責建立和維護服務目錄，使其包含正確和更新的資訊。

服務目錄經理是此流程的流程所有者。

服務組合或服務目錄的任何更改都需受變更管理流程的約束。

SCM 活動

服務目錄管理中包含的關鍵活動如下 -

• 與所有相關方商定並記錄服務定義。

• 與服務組合管理進行介面，以商定服務組合的內容，以商定服務組合的內容和服務目錄

• 與業務和 IT 服務連續性管理進行介面，瞭解業務部門及其業務流程與業務服務目錄中包含的支援 IT 服務之間的依賴關係

• 結合服務組合，生成和維護服務目錄及其內容

• 與業務關係管理和服務級別管理進行介面，以確保資訊與業務和業務流程保持一致。

ITIL - 服務水平管理

本章詳細介紹了與服務級別管理相關的各個方面。

概述

服務級別管理 (SLM) 處理與具有某種級別策略的現有服務的協商、商定和記錄。

服務級別經理是此流程的流程所有者。

SLM 處理以下兩種協議 -

服務級別協議 (SLA)

它是關於服務提供商提供的服務質量級別的保證的已商定檔案。它存在於服務提供商和客戶之間。

運營級別協議 (OLA)

與 SLA 不同，它是在組織內部達成的協議。

SLM 活動

下圖描述了 SLM 流程中涉及的活動 -

服務級別需求 (SLR) 是服務生命週期服務設計中最早的活動之一。一旦生成服務目錄並商定 SLA 結構，就需要起草 SLR。

目標

SLM 的目標如下 -

ITIL - 容量管理

容量管理 確保有效利用可用資源，並以經濟高效和及時的方式提供未來的容量需求。在服務策略和服務設計階段會考慮容量管理。

它還透過生成和定期升級容量計劃來確保 IT 以最佳和經濟高效的方式進行規模調整。

容量經理是此流程的流程所有者。

容量管理活動

下表描述了容量管理流程中涉及的一些活動 -

目標

容量管理的目標如下 -

容量管理要素

容量管理大體上包括三個組成部分：業務容量管理、服務容量管理和元件容量管理，如下面的圖所示 -

業務容量管理

此子流程處理對未來業務需求的預測和制定計劃。這是透過使用有關各種服務當前資源利用率的現有資料來完成的。

服務容量管理

此子流程處理瞭解 IT 服務的功能、資源使用情況和變化，以確保可以設計適當的服務協議。

元件容量管理

此子流程確保最佳化當前 IT 資源元件（如網路容量、頻寬等）的使用。

容量管理資訊系統 (CMIS)

CMIS 維護資源、商品等的更新資料庫，容量管理中的所有子流程都使用該資料庫。

ITIL – 可用性管理

可用性管理 (AM) 確保 IT 服務滿足商定的可用性目標。它還確保新服務或已更改的服務滿足可用性目標，並且不會影響現有服務。

可用性表示為：（商定的服務時間 - 停機時間）/商定的服務時間

可用性經理是此流程的流程所有者。

目標

以下是可用性管理的目標 -

可用性管理流程

可用性管理流程包含以下關鍵要素 -

• 被動活動

• 主動活動

被動活動

參與運營角色的活動稱為被動活動。諸如監控、衡量、分析和管理所有涉及不可用性的事件、事件和問題等活動屬於被動活動。

主動活動

參與設計和規劃角色的活動稱為主動活動。諸如主動規劃、設計和改進可用性等活動屬於主動活動。

可用性管理流程在以下兩個相互關聯的級別上完成 -

• 服務可用性

• 元件可用性

服務可用性

它處理服務的可用性和不可用性，以及元件可用性和不可用性對服務可用性的影響。

元件可用性

它處理元件的可用性和不可用性。

可用性管理子流程

下圖顯示了可用性管理流程中涉及的子流程 -

識別關鍵業務功能 (VBF)

VBF 指的是由 IT 服務支援的關鍵業務要素。記錄所有 VBF 對於提供更好的業務對齊和重點至關重要。

為可用性設計

儘管在提供高可用性解決方案以滿足嚴格的高可用性需求時會產生額外成本，但仍有必要為那些支援更關鍵 VBF 的服務提供高可用性。

服務故障分析 (SFA)

服務故障分析旨在 -

• 提供一種結構化方法來識別導致使用者服務中斷的原因。

• 評估可用性不足發生的位置和原因。

• 透過生成一組用於實施或作為活動計劃輸入的改進措施來提高 IT 服務的整體可用性。

ITIL – 服務連續性管理

ITSCM 確保在任何災難發生時 IT 服務的連續性。它還評估我們需要保護服務資產的保險水平，以及從災難中恢復的手稿。

IT 服務連續性經理是此流程的流程所有者。

目標

下圖顯示了 ITSCM 的幾個目標 -

ITSCM 流程

ITSCM 流程包括四個階段 - 啟動、需求和策略、實施和持續運營。

啟動

它包括政策制定、定義範圍和參考條款、專案計劃和資源分配。

需求和策略

它包括業務影響分析、風險評估。

實施

它包括執行風險降低措施、恢復選項安排、測試和計劃。

持續運營

它包括教育和意識、ITSCM 計劃的變更控制、持續測試。

ITIL – 資訊安全管理

資訊安全管理 (ISM) 確保組織資料和 IT 服務的機密性、真實性、不可否認性、完整性和可用性。它還確保合理使用組織的資訊資源並適當地管理資訊安全風險。

資訊安全經理是此流程的流程所有者。

當滿足以下條件時，資訊安全被認為是滿足的 -

• 資訊僅由授權人員觀察或披露

• 資訊完整、準確並受到保護，防止未經授權的訪問（完整性）

• 資訊在需要時可用且可用，並且提供資訊的系統能夠抵抗攻擊並從故障中恢復或防止故障（可用性）

• 企業之間或與合作伙伴之間開展的業務交易以及資訊交換都應具備可信賴性（真實性和不可否認性）。

ISM 安全策略

ISM 安全策略需要涵蓋所有安全領域，並且應恰當、滿足業務需求，幷包含下圖所示的策略。

ISM 框架

ISM 流程

下圖展示了資訊安全管理 (ISM) 的完整流程。

ISM 框架中的關鍵要素

ISM 框架涉及以下關鍵要素：

控制

控制要素的目標是：

• 建立組織架構，以準備、批准和實施資訊安全策略。

• 分配責任。

• 建立和控制文件。

計劃

此要素的目的是根據對組織需求的理解，設計和推薦適當的安全措施。

實施

此關鍵要素確保到位適當的流程、工具和控制，以支撐安全策略。

評估

評估要素的目標是：

• 定期稽核 IT 系統的技術安全性。

• 監督和檢查對安全策略以及 SLA 和 OLA 中安全要求的遵守情況。

維護

維護要素的目標是：

• 改進例如 SLA 和 OLA 中指定的安全協議。

• 改進安全措施和控制的實施。

預防

此關鍵要素確保防止發生安全事件。此類預防性安全措施需要控制訪問許可權、授權、識別和身份驗證以及訪問控制等措施才能有效。

減少

它處理可能發生的任何潛在損害的最小化。

檢測

儘快檢測到任何安全事件非常重要。

壓制

此措施用於防止安全事件再次發生。

糾正

此措施確保儘可能修復損害。

ITIL – 供應商管理

供應商管理處理維護供應商和合作夥伴之間的良好關係，以確保高質量的 IT 服務。

供應商經理是此流程的流程所有者。

目標

下圖顯示了供應商管理的幾個目標。

供應商管理流程

下圖顯示了供應商管理中包含的若干活動。

供應商管理流程涉及以下活動：

• 實施和執行供應商策略。

• 維護 SCD。

• 供應商和合同評估與選擇。

• 供應商和合同分類及風險評估。

• 合同審查、續簽和終止。

• 合同的制定、協商和達成協議。

• 維護標準合同、條款和條件。

• 合同爭議解決的管理。

• 分包供應商的管理。

• 服務和供應商改進計劃的達成協議和實施。

ITIL – 服務過渡概述

服務過渡管理新服務或已更改服務的過渡。它確保對服務管理流程的所有更改都以協調的方式執行。

目標

服務過渡的目標如下：

服務過渡的好處

服務過渡有助於改進以下幾個方面：

• 快速適應新需求。

• 合併、分拆、收購和服務轉移的過渡管理。

• 業務更改和釋出的成功率。

• 業務更改和釋出的成功率。

• 新服務和已更改服務的服務級別和保證的預測。

• 對更改期間業務和治理要求合規程度的信心。

• 實際與估計的差異以及改進的計劃和預算。

• 業務客戶員工的生產力。

• 在元件退役時及時取消或更改軟體和硬體的維護合同。

• 瞭解更改期間和更改後的風險水平。

服務過渡流程

服務過渡涉及的流程如下：

ITIL – 專案管理

過渡計劃與支援（專案管理）處理規劃資源以在預測的成本、時間和質量估算範圍內部署主要版本。

專案經理是此流程的流程所有者。

目標

下圖描述了專案管理流程的幾個目標。

服務過渡策略考慮以下幾個方面來組織服務過渡和分配資源：

• 服務過渡的目的、目標和任務。

• 服務過渡框架。

• 上下文，例如服務客戶、合同組合。

• 標準。

• 參與過渡的組織和利益相關者。

• 人員。

• 方法。

• 里程碑時間表。

• 財務需求。

規劃單個服務過渡

服務過渡計劃描述將釋出部署到測試環境所需的任務和活動。最佳實踐是從經過驗證的服務過渡模型中部署服務過渡計劃。

服務過渡計劃還包括

• 要管理的問題和風險。

• 要執行的活動和任務。

• 里程碑、移交和交付日期的時間表。

• 每個階段的員工配備、資源需求、預算和時間範圍。

• 提前期和應急措施。

要點

• 需要擁有與較低級別計劃（如釋出計劃、構建計劃和測試計劃）相關的整合過渡計劃。

• 最佳實踐是將多個釋出和部署作為一項計劃進行管理，並將每個部署執行作為一個專案。

審查計劃

在開始釋出或部署之前，需要驗證計劃並提出以下問題：

• 計劃是否已獲得所有相關方（例如客戶、使用者、運營和支援人員）的同意和授權？

• 計劃是否包含釋出日期和可交付成果，並參考相關的變更請求、已知錯誤和問題？

• 服務設計是否發生了重大變化，以至於不再適用？

• 是否已識別出業務環境的潛在變化？

• 需要使用它的人員是否瞭解並具備使用它所需的技能？

• 是否已考慮對成本、組織、技術和商業方面的影響？

• 是否已評估對整體服務和運營能力的風險？

• 服務釋出是否在 SDP 和過渡模型解決範圍之內？

ITIL – 變更管理

簡介

IT 服務中的變更是指伺服器配置的啟用、停用或升級。

所有更改都需要在最大程度地減少 IT 服務中斷的情況下實施。

變更管理流程在實施更改時處理以下方面：

• 研究更改的不利影響並將其降至最低。

• 建立和維護變更管理流程。

• 防止環境中發生未經授權的更改。

• 維護所有更改的記錄。

• 所有更改的實施後審查。

變更管理團隊並不實施變更，而是由技術團隊實施。變更管理團隊僅審查和批准更改。

變更經理是此流程的流程所有者。

要點

• 變更經理是批准更改並關閉更改的人員。他還檢查更改是否達到了預期結果。

• 變更協調員提出變更請求。

• 變更協調員必須在實施後報告 (PIR)中傳送更改後的螢幕截圖。

目標

變更管理流程的目標如下所示：

變更管理的七個 R

這些是必須針對所有更改回答的七個問題。它有助於評估更改的影響以及對服務的風險和收益。

變更請求 (RFC) 是關鍵資訊來源，也是以下更改活動的催化劑：

• 建立和記錄。

• 審查。

• 評估和評估。

• 授權。

• 計劃

• 協調。

• 審查。

• 關閉。

每個 RFC 都將遵循適合更改性質和型別的特定更改模型。

更改模型

如下所述，基本有三種更改模型：

標準更改模型

此模型用於預授權的重複性、低風險且經過充分測試的更改。

普通更改模型

在此模型中，任何更改都必須經過某些步驟，例如評估、授權和變更諮詢委員會 (CAB) 同意，然後才能實施。

緊急更改模型

此更改模型處理恢復失敗的高可用性服務故障所需的高度關鍵的更改。

變更諮詢委員會 (CAB) 是一個授權更改並協助變更管理評估和確定更改優先順序的機構。

服務資產和配置管理

資產概述

資產是指具有財務價值並附帶折舊率的事物。它具有成本，組織將其用於資產價值計算。

它對提供服務沒有直接影響。任何事物，例如伺服器、建築物、黑莓手機、交換機、路由器等，都屬於資產。

配置項 (CI)

配置項是服務資產的一個子集，對提供服務具有直接影響。所有對生產有影響的伺服器、網路、應用程式都稱為配置項。

建築物是資產，但不是 CI。文件是 CI，而不是資產。

因此，服務資產和配置管理 (SACM)處理維護所有資產和 CI 的最新且經過驗證的資料庫，這些資料庫也提供給其他服務管理流程。

配置經理是此流程的流程所有者。

SACM 使用配置管理系統 (CMS)，其中包含一個或多個配置管理資料庫 (CMDB)。

CI 型別

CI 分為六類，如下面的圖表所示：

服務生命週期 CI

服務生命週期 CI 清晰地展示了：

• 服務

• 如何交付服務？

• 預期哪些收益？

• 服務成本。

服務 CI

服務 CI 指的是：

• 服務模型。

• 服務包。

• 釋出包。

• 服務資源資產。

• 服務能力資產。

組織 CI

組織 CI 位於組織內部，但獨立於服務提供商。

內部 CI

由各個專案交付的 CI 稱為內部 CI。

外部 CI

外部 CI 指的是外部客戶需求和協議、供應商的釋出以及外部服務。

介面 CI

這些 CI 必須能夠跨服務提供商介面 (SPI) 提供端到端服務。

配置管理系統 (CMS)

SACM 使用配置管理系統 (CMS)，其中包含一個或多個配置管理資料庫 (CMDB)。資料庫包含與 CI 相關的資訊，例如供應商、成本、購買日期、許可證和維護合同的續訂日期以及其他相關文件，如 SLA 等。

配置項還有其他屬性，例如：

• 唯一識別符號

• CI 型別

• 名稱/描述

• 供應日期

• 位置

• 狀態

• 許可證詳細資訊

• 相關文件主資料

• 相關軟體主資料

• 歷史資料

• 關係型別

• 應用程式 SLA

• 服務資產和配置流程

SACM 流程包含以下五個活動：

• 管理和計劃

• 配置識別

• 配置控制

• 狀態核算和報告

• 驗證和審計

所有上述活動都在下圖中描述：

ITIL – 釋出和部署管理

釋出和部署管理包括計劃、設計、構建、測試和在生產環境中部署新的軟體和硬體元件。透過部署正確的版本來維護生產環境的完整性非常重要。

釋出經理是此流程的流程所有者。

要點

• 釋出單元是指應一起釋出的 IT 基礎設施的一部分。

• 在釋出包中，每個軟體包都依賴於組中其他軟體的效能。

目標

釋出和部署管理確保：

• 更快、更經濟地交付變更，並最大程度地降低風險

• 成功且按計劃部署釋出包。

• 新服務或更改後的服務能夠交付商定的服務要求。

• 有知識轉移，使客戶和使用者能夠最佳化其服務使用，以支援其業務活動。

• 對生產服務、運營和支援組織的意外影響降至最低。

• 客戶、使用者和服務管理人員對服務過渡實踐和輸出感到滿意。

為給定型別的釋出定義適當的釋出包型別非常重要。

下圖說明了釋出包的示例：

釋出和部署管理流程

釋出和部署管理流程中包含的活動包括：

釋出管理支援

它為釋出的部署提供指導和支援。

釋出計劃

此流程的目標是將授權變更分配給釋出包。它還定義了釋出的範圍。

釋出構建

此流程處理構建釋出，並確保所有元件都已準備好進入測試階段。

釋出部署

此流程的目標是在生產環境中部署新發布，併為終端使用者和操作人員安排培訓。

早期生命週期支援

此流程的目的是在釋出部署後的初始階段解決運營問題。

釋出關閉

此流程處理在驗證活動日誌和 CMS 內容是否最新後關閉釋出。

ITIL – 服務和驗證測試

概述

有必要積極維護測試環境，以確保部署的釋出滿足客戶的期望，並驗證 IT 運營是否能夠支援新服務。

測試經理是此流程的流程所有者。

下圖描述了透過生命週期中的服務過渡階段進行服務測試的示例。

ITIL – 服務運營概述

服務運營確保根據 SLA 高效有效地提供服務。它包括監控服務、解決事件、滿足請求和執行運營任務。

要點

• 服務運營包括五個流程和四個職能。

• 服務運營處理用於交付服務的日常活動和基礎設施。

• 服務運營是所有設計和過渡計劃得到執行和衡量的地方。

• 從客戶的角度來看，服務運營是實際價值體現的地方。

服務運營流程

服務運營包括總共五個流程，如下表所述：

服務運營職能

服務運營包含四個職能，如下圖所示：

服務檯

服務檯是第一個也是唯一的聯絡點。它在客戶滿意度方面發揮著至關重要的作用。它協調終端使用者和 IT 服務提供商團隊之間的活動。它還擁有記錄的請求並確保這些請求的關閉。

服務檯有四種類型：

中央服務檯

在這種情況下，只有一箇中央服務檯。

本地或分散式服務檯

它成本較高，但更靠近使用者。難以管理和維護。

虛擬服務檯

它成本非常高，並且導致快速處理。

專業服務檯

它包括專門的熟練員工來處理特定查詢。

IT 運營管理

此功能負責管理組織的日常運營活動

技術管理

技術管理人員包括負責管理整體 IT 基礎設施的技術專業知識。

應用程式管理

應用程式管理負責在整個服務生命週期中管理應用程式和軟體。

ITIL – 事件管理

概述

事件定義為可檢測到的事件，對 IT 服務的交付具有意義。事件由配置項 (CI) 或監控工具建立。

事件管理確保所有 CI 持續監控，並定義一個流程來對這些事件進行分類，以便在需要時採取適當的措施。

IT 運營經理是此流程的流程所有者。

事件管理可以應用於以下方面：

• 配置項 (CI)

• 安全性

• 環境條件（例如火災和煙霧探測）

• 正常活動（例如跟蹤應用程式的使用或伺服器的效能）

• 軟體許可證使用情況監控，以確保合法許可證的使用和分配

監控工具有兩種型別，如下所述：

主動監控工具監控 CI 的狀態和可用性。任何偏離正常操作的情況都會傳達給相應的團隊以採取行動

• 被動監控工具檢測和關聯 CI 生成的操作警報或通訊。

事件管理流程

事件管理流程是自描述的，如下圖所示：

好處

以下是事件管理的幾個好處：

• 它有助於在早期階段檢測事件。因此，可以在發生任何服務中斷之前將事件分配給相應的團隊。

• 它消除了對昂貴且資源密集型監控的需求。

• 它還可以應用於一些服務管理流程，例如可用性管理或容量管理。當狀態發生變化時，它會自動生成訊號，使相應的團隊能夠執行早期響應。

• 由於它是自動化的，因此提高了效率。

事件管理和請求履行

概述

事件定義為 IT 服務中的任何中斷。事件可以透過服務檯或透過從事件管理到事件管理工具的介面來報告。

事件管理處理事件處理，並確保儘快恢復 IT 服務。

事件經理是此流程的流程所有者。

事件模型

總有一些事件不是新的。它們可能會在一段時間內再次發生。因此，最好預先定義模型來處理此類事件。

事件模型應包括：

• 處理事件時應採取的步驟

• 應按時間順序採取這些步驟，並定義任何依賴關係或並行處理。

• 職責——誰應該做什麼

• 操作完成的時間範圍和閾值

• 升級程式；應該聯絡誰以及何時聯絡

• 任何必要的證據儲存活動

事件管理流程

下圖顯示了事件發生時應採取的幾個標準步驟：

事件記錄

所有事件都應完全記錄並加蓋日期/時間戳。

事件分類

稍後檢視事件型別/頻率以確定趨勢以用於問題管理時非常重要。

事件優先順序

它處理事件的嚴重性——低、中或高。

事件診斷

服務檯分析師必須在使用者通話時進行初步診斷，並嘗試發現事件的全部症狀，並確定到底出了什麼問題以及如何糾正它。

事件升級

事件升級的各個方面如下：

功能升級

當發現服務檯無法解決事件或服務檯的目標時間已過時，必須立即升級事件以獲得進一步的支援。

分層升級

當事件性質嚴重或“調查和診斷”花費的時間過長時，會進行分層升級。

調查和診斷

它包括以下活動：

• 瞭解到底出了什麼問題。

• 瞭解事件的時間順序

• 確認事件的全部影響

• 識別可能觸發事件的任何事件

• 搜尋以前類似的事件

解決和恢復

需要識別、應用和測試潛在的解決方案。

事件關閉

在關閉事件之前，服務檯應詢問使用者是否滿意並同意關閉事件。

請求履行

服務請求指的是使用者的需求。這些請求可以與小的更改、更改密碼、安裝其他軟體應用程式、請求資訊等有關。

事件是計劃外的事件，但服務請求可以計劃。

要點

• 根據組織通常擁有的服務請求數量，通常可以組建一個專門的團隊來履行這些請求。

• 對於經常重複的請求，可以設計一個預定義的模型來履行這些請求。

ITIL – 問題管理

在 ITIL 中，問題被定義為一個或多個事件的未知原因。

問題管理確保識別問題並執行根本原因分析。它還確保最大程度地減少重複事件並防止問題發生。

問題經理是此流程的流程所有者。

要點

• 問題管理包括診斷事件根本原因並確定這些問題的解決方法所需的活動。

• 當在根本原因分析後解決問題時，它就成為已知錯誤。

• 問題管理還在名為已知錯誤資料庫 (KED)的系統中記錄有關問題的資訊。

問題管理包括以下兩個流程：

• 響應式問題管理作為服務運營的一部分執行。

• 主動式問題管理在服務運營中啟動，但通常作為持續服務改進的一部分推動

問題管理流程

下圖描述了問題管理中涉及的活動：

問題檢測

可以透過以下方式檢測問題：

• 技術支援小組對事件進行分析。

• 使用警報工具自動檢測基礎設施或應用程式故障，以自動引發事件，這可能會揭示問題管理的必要性。

• 供應商發出的通知，說明存在必須解決的問題。

問題記錄

問題應完全記錄，幷包含以下詳細資訊：

• 使用者詳細資訊

• 服務詳細資訊

• 裝置詳細資訊

• 優先順序和分類詳細資訊

• 最初記錄的日期/時間

問題分類

為了追溯問題的真正性質，必須以與事件相同的方式對問題進行分類。

問題優先順序

必須以與事件相同的方式對問題進行分類，以確定從基礎設施的角度來看問題有多嚴重。

解決方法

這是克服困難的臨時方法。解決方法的詳細資訊應始終記錄在問題記錄中。

提出已知錯誤記錄

必須提出已知錯誤並將其放入已知錯誤資料庫以供將來參考。

問題解決

找到解決方案後，必須將其應用並記錄在問題詳細資訊中。

問題關閉

在關閉時，應執行檢查以確保記錄包含所有事件的完整歷史描述。

重大問題審查

應審查以下內容：

• 正確完成的事情

• 做錯的事情

• 將來可以做得更好的是什麼

• 如何防止再次發生

ITIL – 訪問管理

概述

訪問管理處理授予授權使用者訪問許可權，同時阻止未授權使用者訪問許可權。

訪問經理是此流程的流程所有者。

要點

• 訪問管理也稱為“許可權管理”或“身份管理”。

• 訪問管理流程由技術和應用程式管理功能執行。

• 訪問管理可以透過服務檯的服務請求啟動

業務價值

訪問管理透過以下方式為業務增加價值：

• 員工擁有執行其工作所需的適當訪問許可權

• 能夠稽核服務的使用情況並追溯服務的濫用情況。

• 對服務的受控訪問確保組織能夠更有效地維護其資訊的機密性。

訪問管理流程

訪問管理中涉及的活動不言而喻，如下面的圖表所示：

CSI 概述

持續服務改進 (CSI) 處理為提高服務質量而採取的措施，從過去的成功和失敗中吸取教訓。其目的是透過識別和實施改進以適應不斷變化的業務需求，使 IT 服務與不斷變化的需求保持一致和重新一致。

目標

持續服務改進的幾個目標如下：

• 審查和分析每個生命週期階段的改進機會。

• 審查和分析服務級別達成結果。

• 在不犧牲客戶滿意度的情況下提高交付 IT 服務的成本效益。

• 識別和實施單獨的活動以提高 IT 服務質量。

• 確保使用適用的質量管理方法來支援持續改進活動

支援 CSI 的活動

支援 CSI 的活動不會自動發生，因此需要在能夠處理責任並擁有適當許可權來推動事情發生的 IT 組織內部擁有這些活動。以下是支援持續服務改進的活動。

CSI 流程模型

CSI 中涉及的步驟不言而喻，如下面的圖表所述：

收益視角

在討論 CSI 的結果時，以下四個收益視角需要考慮：

改進

這是將服務的當前狀態的結果與之前的結果進行比較。

好處

這是透過實現改進獲得的收益。

投資回報率

它是收益與實現該收益所花費的金額之間的差額。

投資價值

它是透過建立收益而創造的額外價值，包括非貨幣或長期成果。

ITIL – 服務報告

服務報告處理根據服務級別生成和交付關於成就和趨勢的報告。

最佳實踐是根據與客戶商定的格式、內容和頻率生成報告。

下圖描述了服務報告流程的整體流程：