close
經過前述兩個階段之後，組織可以針對識別出的重大風險，進行必要的復原計劃實踐及測試演練，以期實際災害和風險發生之時，可以有效地將組織營運衝擊降到最低。
 
許多人以為 ITSCM 的實踐可以讓組織營運不會間斷，其實並不全然正確。理論上的精神是指：透過 ITSCM 的實踐，可以讓關鍵服務、系統及活動儘可能持續運作，或者是於約定可接受的時間內恢復服務運行。因此，針對關鍵服務去規劃 ITSCM plan，才是合乎成本考量及企業利益的務實做法。筆者觀察許多企業的 BCP，發現部份計劃不是專注於關鍵服務，應需重新考量其適切性。此外，約定可接受的時間，也應於 ITSCM plan 中明確定義(最好獲得顧客同意)，以調配適當資源去支援。

ITSCM plan 中包含了所有活動細節，去確保關鍵服務、設施設備及資源可以維持在組織可接受的持續營運水準之內。除了復原方法的記載之外，也應記錄相互服務的依存關係、測試方法及復原後資料一致性檢驗的步驟。許多組織常將 recovery plan (註一) 誤以為是 ITSCM plan 去替代，其實兩者並不相同；ITSCM plan 的涵蓋範圍是大於 recovery plan 的，它還包含了啟動時間點的判斷、復原方法有效性量測、恢復力(Resilience)的量測和各復原活動規劃的原因，確保各項活動有效地執行，可支援企業的持續營運目標。
 
ITSCM plan 規劃時要有一個重要的概念，就是相關的執行細節要儘可能清楚載明，既使一個不熟悉該服務的人員，可以於緊要時間按照計劃逐一正確執行。例如：核心資料庫的 ITSCM plan，應該把 DB 相關的操作程序、指令文件化，相關的資訊也要正確記載 (如 IP 位置、廠商支援人員連絡方式…等)，緊急情況發生時，若 DBA 人員不在場，也可由一般程式設計師按照文件操作，正確執行 ITSCM plan。
 
許多技術人員在撰寫這類計劃時，常認為有些操作是想當然爾，為了省麻煩就便宜行事，標準作業程序的內容只有當事人看得懂，這會是一個潛在的危機而導致復原方法無法落實，應透過測試、審查或查檢表(checklist)的方式去確認。
 
ITSCM plan 規劃完成後，發佈上應有適當的管理，依循變更管理進行文件上的變更，依循組態管理去嚴禁非授權的任意修改。ITSCM 應確保 ITSCM plan 的最新版本可以於任何時間被相關人員存取，此項要求在 ISO 20000-1:2005 中也是一項應遵循的規範。實務上常見的做法有：文件存放於公司內部公用檔案區、文件多處儲存避免遺失及相關人員皆保留一份文件紙本(最新版)等。

Plan 制定告一段落後，再來就是相關人員權責的劃分，各自扮演好應負責的角色，切實地執行復原演練。當災難發生時，通常組織已無法依正常部門劃分方式去運作，如何在非常時期進行適切的合作，相關的權利義務應於計劃中展現。
一般而言，常見的角色權責劃分至少有三個階層：
(1) 高階管理階層：高層應有整體授權和管控的責任，並負責必要時的決策方向。
(2) 協調小組：負責跨部門、流程的整合協調。
(3) 多個功能取向的復原處理小組：如消防應變組、疾病防護組等。
 
ITSCM plan 應進行測試(testing)，以維持其有效性，若因時空背景客觀環境因素而無法維持有效，應進行計劃更新後再進行測試；測試的方式可依組織的需求不同而自行選擇，如完整測試、部份測試、情節測試等。不過，依筆者觀察經驗，有些企業主只重營運利潤，對於這一類沒有實際收益又浪費時間人力成本的營運持續計劃演練，都抱持著敷衍的心態，只掛名計劃主持人，但實務演練時卻根本不參與任一環節。記得有一個案例，某公司管理代表還拿著消防局的例行檢查記錄，來充當公司的災害復原演練報告，當筆者按演練計劃逐一比對詢問時，該代表無法回答應有的授權及管制權責，顯見該企業並不以為此舉是必要且重要的，這樣的演練在災難發生時，恐怕是無法為組織帶來有效的助益，只是徒具形式。
 
註一：recovery plan 中常見的內容有：政策、啟動判斷、執行準則、參考文件、緊急連絡人(方式)、復原小組成員、復原行動查檢表、復原程序等。
arrow
arrow
    全站熱搜

    sidneyho 發表在 痞客邦 留言(0) 人氣()

    E-mail轉寄