ITIL也玩“太極拳”

標籤：style   http   io   問題   ar   管理   .net   設計   

   近期看到一篇老外寫的發行管理的培訓材料，其中把發行管理比喻成中國太極圖中的“陰”，把變 更管理比喻成“陽”，覺得還挺有意思。之所以這麼比喻是因為，他認為“發布”是被動的，接受的，有女性陰柔的一面；而“變更”是主動的，強勢的，有陽剛的 一面。它們組合在一起形成了兩個理想的平衡作用力，來控制IT服務管理中的風險。坦白說，我並不完全認同這種比喻的觀點，可能老外並不完全理解中國文化中 “陰”“陽”的寓意，但這個老外無疑是ITIL領域的專家，因為他深刻瞭解到“變更”和“發布”之間的互相作用力，如何通過兩個流程的配合和互相牽制來控 制公司資訊系統的運營風險。

    在和很多同行交流的過程中，大家似乎對於“發行管理”和“變更管理”在IT服務管理領域的作用和意義有些疑惑。“既然有了變更管理，已經可以控制風險了，為什麼還要需要發行管理？”“發行管理的定位和意義與變更管理有什麼不同？”，“版本要發布之前需要考慮哪些因素？”，“發行管理的策略應該怎麼來定？”“發行管理應該研發隊伍負責，還是營運管理團隊負責？”等。

    這些都是非常好的問題，也是IT營運管理（E8.ITSM）到達了一定的成熟度等級的團隊，才會開始思考這些問題。下面我來和大家分享一下我對這兩個流程的理解，供大家參考。

    變更管理是一個總體的管控流程，它控制和管理所有硬體，軟體，環境，人員，流程，配置，文檔的風險管控流程。只要是投入生產的系統發生任何變化都需要這個流程中的核心審核小組CAB（Change Approval Board）批覆才能進行實施。CAB主要審核的焦點就是這個變更可能對我生產系統帶來的風險和為此變更所付出的成本（國內很多企業的變更管理不太審核成本）。變更管理對於變更可以根據其對生產系統的影響分成若干層級：包括重大變更，較大變更，一般變更，日常變更，緊急變更。每一類變更參與審核的人員，也就是CAB的人員是不同的。重大變更需要CIO甚至CEO來決定，日常變更可以不通過CAB審核，直接做好變更記錄即可。
    發行管理是對軟體，硬體上線相關的一系列活動進行組織和管理，包括髮布策略的制定，發布計劃的制定，發布內容的測試方案設計，通過測試的標準，發布失敗的應急方案，產品發布說明書，發布前使用者的培訓等等。也就是一個產品從研發完計划上生產前這個階段的管理都屬於發行管理的範疇。 一個發布可能是一個變更，也有可能是一組變更構成。例如：一個企業的ERP系統，其發布頻率為1年4次，每次的發布可能會包括100多個維護類的變更。這種發布的管控通過變更流程是無法管理的。

    發行管理和變更管理的組織架構可能在企業裡都是虛擬，發行管理和變更管理的經理通常是固定的，其成員組成有可能是根據項目的不同靈活組建的。發行管理小組成員通常是所發布項目的核心成員，第三方測試團隊組成，營運管理員組成。變更小組的成員，通常由變更相關的技術經理，業務經理組成，還包括可用性管理，容量管理，服務等級管理，事件管理的經理等等，用來審核這個變更可能帶來的影響或者說是風險。

    所以，大家可以發現變更和發布是緊密相關的兩個流程，都是控制系統上線風險的核心管理流程，缺一不可，互相補充。所以從這個意義上來說“陰”“陽”之說，也可以用來形容吧！！（轉帖）