ITIL大補帖(7)談服務的變更與發行管理

當IT發生事件時，為了排除對服務的影響，資訊部門通常會重新設定系統參數、安裝軟體或者更新硬體設備等，這便是一種「變更」的活動。

變更的目的在於提供更有品質的服務，但諷刺的是原本處於一種穩定運行的系統，在變更活動之後，反而不穩定，甚至產生無法彌補的傷害。

為了避免變更對SLA造成影響，在執行前應適當地評估，以了解是否能夠達到期望的目標。

變更作業
假設一家提供IT服務的公司，在與客戶簽訂SLA的要求之後，這家公司試圖在不影響SLA的情況下，改變服務方式以降低成本。為滿足此目標，必須將服務的活動逐一展開，找出可以變更的細節，並評估是否能夠達到降低成本的目的。

變更及發行都會影響1個或是1個以上的建構項目（Configuration Item），若要妥善管理變更及發行活動，就必須了解有哪些建構項目會受到變更及發行活動的影響。

將IT服務範圍內的主要組成（含軟、硬體）、關鍵技術，或特殊功能等項目，考量專案及工程管理的需求，經過資訊部門的選擇、評估、認定而發布列入管制者，即可稱為建構項目。

為了能夠滿足不同作業及管理要求，通常會將建構項目分為必須要建立基準（Baseline）的「基準建構項目」，以及與僅做版本管理的「版本管理建構項目」兩種建構項目分類。一般而言，基準建構項目需循正式的變更管制程序才能變更，而版本管理建構項目可允許彈性的變更方法。

留下記錄，避免緊急變更發生的機率
變更管理程序的設立主要是為了確保變更事項，在對服務品質衝擊最小、風險最低，及效率最高的條件下被執行。變更活動又分為「常態變更」及「緊急變更」2種，依據變更的需求及條件的不同，作法也不相同。

常態變更沒有即時性要求
此類的活動屬於計畫的一部分，沒有即時性的要求，可以依循企業常態性的變更程序，包括需求說明、影響評估、可行性分析、審查與核准、執行與結果評估等活動。

以必勝客為例：「接到訂購電話後，30分鐘以內將Pizza送至顧客手上，否則Pizza免費贈送。」的運作模式。我們假設必勝客的競爭對手也推出相同的服務，這就迫使必勝客需改變服務模式，以維持有利的競爭態勢。

改變，無可避免的會影響到服務程序、活動與資源，如何確保改變後的服務模式，能夠比以前更具競爭力，即需要規畫與管理。

緊急變更仍應留下記錄
例如病毒事件，冗長的常態變更管理程序，並不符合這種緊急狀況的服務要求。資訊部門通常會立即執行緊急變更作業，盡快使服務恢復至正常的水準。由於時間迫切，有些作業無法遵循正常程序執行，必須跳過某些活動。

即便是緊急，但變更時，仍必遵循事先約定的原則，變更過程留下必要的記錄，提供後續評估所需的資訊。如同圖一所示，變更之後通常會有一段服務不穩定的時間，為了掌握不穩定期可能持續的期間，緊急變更作業完成之後，資訊部門必須執行必要的評估作業，檢討緊急變更的根本原因，以降低後續發生的機率，避免發生無法掌控的事件。

發行作業
發行作業的目的，是針對1個或1個以上的資訊系統，或服務變更作業的發行活動，實際執行及追蹤，使變更的結果能夠被發行至真實作業環境上。一個發行活動可能牽涉到多個客戶、供應商或是營運活動。

在執行資訊系統、基礎建設、服務與文件的發行時，所有相關的變更都應納入發行計畫中，例如營運過程、支援文件及服務水準協議變更。為了確保發行活動失敗時，系統能夠恢復到發行前的狀態，所有發行的服務或是建構項目必須能追溯到發行前的狀態，而且只有經過適當測試和核准的版本，才能夠被部署到運行環境。

在發行前，建立發行計畫是確保成功的關鍵。如同變更作業一般，發行作業也有發行的頻率與型式的差異：

計畫性發行
許多企業會在年初時，規畫今年度或是未來幾年的發行活動，包括要執行哪些發行活動、原因、時機、相關配合資源、發行方法及期望結果等。例如微軟會在幾年前便宣佈未來發布新產品的時間點，或是既有產品的更新計畫，這便是計畫性發行活動。

非計畫性發行
在服務的過程中，可能會發生許多非計畫性的發行活動，這裡所指的「非計畫性發行的活動」並不是說沒有計畫的執行發行活動，而是指意料之外的發行活動。例如，這幾年許多合併案產生的資訊系統合併作業、因應業務爆發性成長的容量緊急擴充活動，便是屬於非計畫性發行作業。

評估結果，了解成效
發行計畫至少會包含下列幾種敘述：不成功時，撤銷或補救的方法，以及發行所期望解決的問題或是已知錯誤。要能夠評估發行活動是否滿足期望的目的，發行之後必須執行評估作業。由於不同的發行活動，需要不同的時間週期，才能評估發行結果。因此在發行前，必須要就評估的時間及方法取得共識。

以最近幾年常見的資訊安全導入活動為例，許多公司為了使IT系統得到更安全的保護，添購一些資安設備，但卻無法評估IT系統是否更安全，便形成一種資源的誤用。

另外，在軟體產業常看到許多公司在改善流程時，增加自動化的工具，但是工具買完之後，多數的情況是放在架子上，問題依舊沒有解決。

「變更」與「發行」兩者通常會伴隨發生。當企業規畫導入ITIL或是ISO/IEC 20000 ITSM時，如果因為不同人員對於變更與發行的定義有所不同，而無法建立變更與發行作業程序時，筆者建議跳脫這種不必要的用語爭論，投入時間在設法避免變更及發行活動的失敗上。