Chapter 08 - ITIL Practices

本章目標

看完本章後，你應該可以回答：

ITIL practice 是什麼，為什麼不是單純流程？
Incident、Problem、Change、Release、Deployment 差在哪裡？
Service Desk、Service Request、Monitoring and Event、Service Level、Continual Improvement 各自解決什麼問題？
PM / Developer / DevOps 如何把 practices 對應到 Jira、GitHub Actions、AWS、production incident？
考試遇到 practice 題目時怎麼抓關鍵字？

一句話

Practices 是組織完成特定工作的能力集合，包含人、流程、工具、資訊、partner、知識和工作方式；它們不是孤立 SOP，而是會一起支援 product and service value。

核心概念

Practice 不是 Process

Process 是「工作怎麼流動」。Practice 是「組織要完成某件事所需要的整體能力」。

一個 Incident Management practice 可能包含：

on-call role
incident priority rule
Slack / Teams incident channel
monitoring and alerting
runbook
escalation path
客戶 communication
post-incident review
improvement backlog

所以 practice 不是一張流程圖，也不是一個 Jira ticket type。

Incident Management

Incident 是未預期的服務中斷或服務品質下降。Incident Management 的重點是盡快 restore service，降低對 business 和 user 的影響。

例子：

text

核心服務 timeout
        ↓
CloudWatch alarm
        ↓
on-call engineer investigates
        ↓
rollback / hotfix / traffic mitigation
        ↓
service restored
        ↓
incident communication and review

考試關鍵字：

unplanned interruption
degraded service quality
restore service
minimize impact

Problem Management

Problem 是一個或多個 incident 的根本原因或潛在原因。Problem Management 的重點是找出原因、降低再次發生的可能性或影響。

Incident 和 Problem 的差異：

text

Incident:
核心 API 現在 timeout，先恢復服務。

Problem:
為什麼每週五晚間核心 API 都 timeout？根因是 DB index、connection pool、gateway latency，還是 retry storm？

考試關鍵字：

root cause
recurring incidents
known error
workaround
prevent recurrence

Change Enablement

Change Enablement 的目標不是阻止 change，而是讓 change 更安全、更快速、更可追蹤，並控制 risk。

工作例子：

text

GitHub PR
        ↓
code review
        ↓
CI test
        ↓
risk assessment
        ↓
deployment approval / automated gate
        ↓
rollback plan

Change 類型可以先用三種理解：

Standard change：低風險、已知、可重複，例如例行設定更新
Normal change：需要評估與授權，例如 core API 重要改動
Emergency change：為了處理緊急狀況，例如 production hotfix

考試關鍵字：

assess risk
authorize change
enable beneficial change
reduce negative impact

Release Management

Release Management 關心的是讓新的或變更後的 service / feature 能被使用，並對 stakeholder 傳達 release 的內容、時機和影響。

Release 不等於 deployment。

text

Deployment:
把新版本放到 production environment。

Release:
讓使用者、客服、營運、客戶真的知道並能使用新能力。

例子：React checkout 新版上線

deployment 完成：CloudFront 已更新
release 完成：使用者看到新版流程，客服知道新版錯誤訊息，PM 追蹤成功率

Deployment Management

Deployment Management 關心的是把新的或變更的 component 移到 controlled environments。

例子：

deploy Java service to ECS
deploy React build to S3 / CloudFront
apply DB migration
update Lambda function
promote container image from staging to production

考試關鍵字：

move components
controlled environments
hardware / software / documentation / process component

Service Desk

Service Desk 是 service provider 和 users 之間的溝通入口。它不是「低階客服」，而是使用者支援、事件回報、請求入口和資訊流的重要節點。

例子：

使用者問操作是否成功
客戶問資料修正請求狀態
客服回報大量服務問題
Service Desk 把高頻問題整理給 PM 和 engineering

Service Request Management

Service Request 是使用者提出的標準請求，不一定代表服務壞了。

例子：

申請客戶後台帳號
要求重寄處理完成通知
申請報表匯出權限
請求修改通知 email

Incident vs Service Request：

text

Incident:
核心功能壞了。

Service Request:
使用者要求重寄處理完成通知。

Monitoring and Event Management

Monitoring 是持續觀察 service 狀態。Event 是偵測到的狀態變化或訊號。這個 practice 幫助團隊早點發現異常、判斷影響、觸發 response。

AWS 例子：

CloudWatch Alarm
ALB 5xx rate
Lambda error count
RDS CPU / connection count
success rate
synthetic monitoring

考試關鍵字：

observe service
detect events
alert
response trigger

Service Level Management

Service Level Management 確保 service quality 的目標、承諾和實際表現被定義、追蹤、溝通和改善。

常見概念：

SLA：service provider 和客戶之間的 agreement
SLO：內部或外部的 service level objective
KPI / metric：衡量實際表現

例子：

API availability 99.9%
P1 incident 15 分鐘內初回應
狀態查詢 95% 在 2 秒內完成

Continual Improvement

Continual Improvement 是持續讓 products、services、practices、processes 和工作方式變好。

例子：

Sprint retrospective action item
post-incident improvement
reduce alarm noise
improve rollback time
update chatbot knowledge base
simplify service request workflow

關鍵點：改善不是大型專案才做，也不是考完證照才做。它應該嵌在 daily work 裡。

PM 視角

PM 不需要把每個 practice 都當成部門流程，但要知道哪種情境該找哪個能力。

線上服務情境：

text

核心服務中斷:
Incident Management

固定尖峰時段反覆 timeout:
Problem Management

要 hotfix:
Change Enablement

新功能正式開放給使用者:
Release Management + Deployment Management

使用者問服務處理結果:
Service Desk / Service Request Management

CloudWatch alarm:
Monitoring and Event Management

客戶要求 99.9% availability:
Service Level Management

postmortem action items:
Continual Improvement

PM 的價值是把 practices 串起來，不是讓每個 ticket 各自漂流。

Developer / DevOps 視角

Developer / DevOps 日常工作幾乎都和 practices 有關。

text

GitHub PR:
Change Enablement

GitHub Actions deploy:
Deployment Management

Release note:
Release Management

CloudWatch alarm:
Monitoring and Event Management

PagerDuty alert:
Incident Management

RCA:
Problem Management

SLO dashboard:
Service Level Management

Retrospective action:
Continual Improvement

工程常見誤解是把「工具動作」當成 practice 本身。GitHub Actions 是工具；Deployment Management 是讓 deployment 可控、可追蹤、可回復的能力。

AWS 對照

AWS 不是 ITIL practice，但 AWS 服務可以支援很多 practices。

AWS / Tooling	可能支援的 practice
CloudWatch Alarm	Monitoring and Event Management
CloudWatch Logs / X-Ray	Incident Management, Problem Management
CodePipeline / GitHub Actions	Deployment Management
Systems Manager Change Manager	Change Enablement
AWS Health Dashboard	Monitoring and Event Management
RDS Performance Insights	Problem Management
AWS Support	Supplier Management / Incident support
Service Quotas / autoscaling metrics	Capacity and performance related practices

重點：工具只支援 practice，不等於 practice 已成熟。沒有 role、runbook、decision rule、feedback loop，工具再多也不會自動創造 value。

實務對照

假設使用者面向的核心服務 timeout。

text

1. Monitoring and Event Management:
CloudWatch 發現 error rate 上升。

2. Incident Management:
on-call 進 incident channel，先 restore service。

3. Change Enablement:
判斷要 rollback、hotfix，或調整設定。

4. Release / Deployment Management:
把修復移到 production，並讓相關 stakeholder 知道。

5. Service Desk:
客服取得統一說法，回覆使用者與客戶。

6. Problem Management:
事後找 root cause，避免重複發生。

7. Service Level Management:
檢查 downtime 是否影響 SLA / SLO。

8. Continual Improvement:
補 alarm、runbook、test、architecture improvement。

這就是 practice 的現實用法：不是一個一個背，而是理解它們如何一起處理 service value。

常見誤解

誤解 1：Incident Management 等於找 root cause

Incident 的第一優先通常是 restore service。Root cause 分析更偏向 Problem Management。

誤解 2：Release Management 等於 Deployment Management

Deployment 是移動 component。Release 是讓新能力可被使用，包含溝通、準備、使用者影響和 value realization。

誤解 3：Change Enablement 是拖慢工程速度

好的 Change Enablement 會依風險調整控制，讓 change 更快、更安全，而不是一律加重 approval。

誤解 4：Service Desk 只是接電話

Service Desk 是使用者與 service provider 的入口，也能提供早期問題訊號和改善素材。

誤解 5：Monitoring 有 alarm 就夠

Alarm 必須接上 event handling、incident response、runbook、ownership 和 improvement，才真的有 value。

Interview Angle

可能被問：

What is the difference between incident and problem?
What is the difference between release and deployment?
How do you handle a production outage from an ITIL perspective?
How do you design change enablement for a DevOps team?
How do monitoring and continual improvement connect?

回答方向：

用 production example 回答
先 restore service，再做 root cause
change enablement 要 risk-based
release 是 value to users，deployment 是 technical movement
monitoring 要接 incident 和 improvement

Exam Tips

Practice 題目通常靠關鍵字判斷。

題目線索	最可能的 practice
restore service、unplanned interruption	Incident Management
root cause、recurring incident、known error	Problem Management
risk assessment、authorize、change control	Change Enablement
make new service / feature available to users	Release Management
move component to controlled environment	Deployment Management
user contact point、communication	Service Desk
standard user request、access、information request	Service Request Management
detect events、alert、monitor status	Monitoring and Event Management
SLA、SLO、service quality target	Service Level Management
ongoing improvement、retrospective、post-incident action	Continual Improvement

考試陷阱：

現在服務壞了，先 incident，不是 problem。
deploy 成功不代表 release 成功。
service request 不是 incident。
monitoring 發現問題不等於已處理 incident。
continual improvement 不只在專案結束後才做。

Summary

ITIL Practices 是把 Value System 和 Lifecycle 落地的能力集合。對 Technical PM 來說，最重要的是分清楚 incident、problem、change、release、deployment、service request，並知道 monitoring、service desk、service level、continual improvement 如何一起支援 service value。實務上，你不需要把 practices 當成 bureaucracy，而是把它們當成 production service 能穩定運作的共同語言。

References

Quiz

請見 Chapter 08 Quiz。

Chapter 08 - ITIL Practices ​

本章目標 ​

一句話 ​

核心概念 ​

Practice 不是 Process ​

Incident Management ​

Problem Management ​

Change Enablement ​

Release Management ​

Deployment Management ​

Service Desk ​

Service Request Management ​

Monitoring and Event Management ​

Service Level Management ​

Continual Improvement ​

PM 視角 ​

Developer / DevOps 視角 ​

AWS 對照 ​

實務對照 ​

常見誤解 ​

誤解 1：Incident Management 等於找 root cause ​

誤解 2：Release Management 等於 Deployment Management ​

誤解 3：Change Enablement 是拖慢工程速度 ​

誤解 4：Service Desk 只是接電話 ​

誤解 5：Monitoring 有 alarm 就夠 ​

Interview Angle ​

Exam Tips ​

Summary ​

References ​

Quiz ​

Chapter 08 - ITIL Practices

本章目標

一句話

核心概念

Practice 不是 Process

Incident Management

Problem Management

Change Enablement

Release Management

Deployment Management

Service Desk

Service Request Management

Monitoring and Event Management

Service Level Management

Continual Improvement

PM 視角

Developer / DevOps 視角

AWS 對照

實務對照

常見誤解

誤解 1：Incident Management 等於找 root cause

誤解 2：Release Management 等於 Deployment Management

誤解 3：Change Enablement 是拖慢工程速度

誤解 4：Service Desk 只是接電話

誤解 5：Monitoring 有 alarm 就夠

Interview Angle

Exam Tips

Summary

References

Quiz