推廣 | 令人窒息的獎品等你―2016最權威的全球開發者調研

【51CTO.com原創稿件】根據蔡格尼克記憶效應，人們總對那些沒完成的任務印象深刻。雖然哥時常將話題岔開到那個“神奇”的云平臺項目，但想必大家還是愿意繼續回到我們整體設計與治理的主路上吧?好，那就讓我們“冷水洗把臉”回來繼續聊系統的日常運維方面吧。

大家還記得曾經看過的那部經典的美劇《越獄》以及殿堂級成長類電影《肖生克的救贖》吧?男“豬腳”們為了“脫獄”都找的是監獄容易出現漏洞的最薄弱的環節。參照來看，我們的系統也有最容易出問題的薄弱環節，就是系統內部的不一致性。這種不一致性的產生一般都是由于系統和服務被“任性”的改動所造成的。憑心而論，一般系統在完成和交付之初甲方十分希望、乙方也非常愿意把系統做得盡可能的完美，但是隨著系統和服務被越來越頻繁的使用，對于其功能和效率的調整和改進的需求也會如寒武紀生命大爆發一般，井噴式的增長。經過多個部門、多種IT角色“簡單而粗暴”的修改后，系統雖不會千瘡百孔、面目全非，但肯定已是今非昔比，且隨時都有不可預料的中斷風險了。

所以說，?？菔癄€的緊守不變是不可能的。那句很有哲理的話怎么說的來著?“唯一不變的只有變化。”不!唯一不變的還有廉哥和大家每周如期而至的這份漫談之心哦。我們的漫談雖然不死板嚴肅，但是很中立的，記住，哥不是神馬Tony老師，從來不會向大家推薦什么廠商或產品的。跑題了，跑題了…那么如何避免持續變更所產生的side effect，實現系統安全性和其易用性的平衡呢?我們還是要依靠管理和控制。

變更管理

馬云曾說過一句話：“陽光燦爛的時候，就要修屋頂。”也就是說在還沒出問題的時候，我們就要考慮到各種變化和調整的應對了。在前幾次漫談中，我們提到的事件、事故和問題流程的最終結果都可能觸發IT服務變更的發生。在企業里，任何變更需求都應當用預定義的流程和工具來規范需求的提交方式并通過自動流轉，做到系統能夠實時記錄以方便日后稽查。

在規范的企業中，變更請求一定要通過變更顧問委員會的審核。而這個委員會成員可以包括企業各種角色的代表，如業務部門用戶，IT管理層，運維人員，供應/外包商等。而且具體人員可根據實際變更請求來動態調整。由變更顧問委員會對請求進行主要的風險評估。評估內容包括：提出人的角色、提出原因、變更時間、變更回報、需要的資源、對其他服務的影響等。很多企業管理者總有心存僥幸心理，覺得頻繁變更請求的審核既耗時又好力，想攢到一段時間后一起擼，然后呢?就沒有然后了。可是歌德老爺子不是說過嗎：“今天做不成的，明天也不會做好，一天也不能夠虛度。”很多改變是時不我待的，消極被動的態度非但維持不了當前的所謂“不變應萬變”，反而會讓IT團隊甚至管理層感覺壓力山大。要知道可能您和“別人家的”健康穩定系統的差別就在這里。

系統的變更往往會引起短暫的服務中斷。而無論是功能性的服務變更請求還是計劃性的服務中斷請求都需要包含：變更程度(普通、標準或緊急)，變更類型(硬件、軟件、網絡、通信設備或文檔相關)，自測風險程度(低、中或高)，影響范圍(全部門范圍、整個企業范圍、多分支機構范圍)，變更進度和實施計劃，所涉及到的配置項數據庫(Configuration Management Data Base，前面幾期有提到過)里的配置項(CI)，結果預期和應急補救預案等。

從安全角度來說，在實施變更之前一定要確立好整個系統的基準線，給系統的當前各種狀態來個“快照”，從而成為變更后參考比對的依據。同時在變更過程中，應做好軟/硬件版本管理。在實際操作中，可以參考如下變更的流程圖。個人認為，套用華為企業的說法，這叫“力出一孔”。

另外，如果涉及到比較復雜或大型的變更，我們在相關的記錄文檔中還應適當的配上能體現變更步驟和涉及范圍的流程圖。這樣不但能有助于理清變更的思路和波及面，還能供變更后或出現其他問題時進行參考和審計所用。

說到文檔化記錄，大家應該都有過這樣的體驗，當我們的智能手機上的APP裝了太多時，其實每次我們要找某個需要的APP并不是認真看其圖標的樣子或下面的名稱，而是從顏色及其圖案上迅速判斷和定位到的。因此記錄文檔中，我們可以事先規定好用不同顏色來定義不同類型的變更，從而便于我們從龐復的記錄中一眼認出或篩選出需要查看的記錄。

總所周知，這是一個“快魚吞慢魚”的快節奏時代，很多企業的IT決策者腦子里想著馬化騰的那句“小步、快跑、迭代、試錯”而嘴里念叨著“沒時間解釋，快上車”不斷發布新的產品和服務功能。這種積極的態度是值得肯定和采取的，但是如果不想在發布之后收獲莫名的抱怨或是看到老板及用戶的那張張撲克臉的話，必要的管控定會為你的“爆款新品”保駕護航。

發布管理

在企業運營過程中，往往新的或是需要變更的IT服務是以項目實施的形式進行發布的。常規發布的過程包括：發布策略的制定與規劃，回退計劃，分發與安裝，試運行，測試與驗收，用戶支持與培訓。

其中，在發布策略制定階段我們要多考慮采取分時間和空間的實施計劃。如一季度在亞洲區各分公司實施，二季度在歐洲洲區各分公司實施。在充分控制好兼容性的情況下做好新舊系統的共存。一旦發現新系統有影響到其他現有IT服務的時候，可以讓用戶根據回退方案退回到舊系統應急完成，從而給消除影響爭取了時間。比如說新的郵件系統出于安全性考慮，無法讓用戶發送超級鏈接，但這并不是所有用戶都能馬上接受并轉變的。這就需要有個用戶行為漸變的過程。

而在分發階段應注意自動與手動互補。無疑，自動分發IT服務(特別是軟件)可以保持發布的一致性，且突破了時間和空間的限制，一定程度上減輕了IT人員手動安裝的時間和重復勞動。但對于一些自動發布過程中的錯誤勘測，場景判斷以及其他方法的嘗試，如某個系統的補丁包，手動安裝的優勢就很明顯。因此企業一般應采取“自動在先，手動攻堅”的互補模式。

在安裝階段應注意“推/拉結合”。“推”是指IT服務由總部服務器推送到各個用戶終端電腦上，因為帶有一定的強制性，所以一般適用于普遍使用且重要的服務。而“拉”是指各個用戶終端電腦從總部服務器獲取IT服務(特別是軟件)。如病毒簽名庫的升級包，可以讓用戶在覺得個人業務不急迫的情況下從總部“拉”過來，而不會影響到其他應用程序的運行速度。當然也有些用戶從來不去主動“拉”，這就需要“推/拉結合”了，即對于在規定的一段時間周期后總部勘測到沒有進行“拉”操作的用戶，就會強制性的“推”送過去進行安裝。是不是感覺有點像時下流行的“推塔”游戲?至少我覺得有點像。

在驗收階段，IT部門除了確保只有正確的、被授權的和經過測試的軟/硬件版本才能部署到實際的運營環境以外，還應該注意及時更新配置項數據庫(有提到了哦)，特別是已知錯誤知識庫的建立。該知識庫應當運用普通用戶所容易理解的語言來描述問題/錯誤的狀態且避免重復。在內容更新方面，IT部門除了自我維護外，還需定期從軟/硬件供應商的知識庫接口收集和導入。已知錯誤知識庫里的相關突出內容可以在新的服務發布前夕向全體用戶公示，從而合理控制好用戶在使用中的期望值和體驗度。此外，相應的技術支持和用戶培訓也是服務發布所必不可少的環節。

總的說來，這次跟大家分享的兩個治理和控制方面，是大家工作中經常遇到，理論上也比較容易明白的。正所謂“望遠鏡能幫你看清前進的目標，卻不能縮短要走的路程。”所以真正踐行還是需要一個長期堅持的過程。

有周圍小伙伴們贊賞我每周一篇的毅力，其實告訴大家吧，哥一直在堅持120法則。我不但在每周固定7天時間上乘以120%，也就是提前8到9天做下一篇漫談的準備;我還時常和我的朋友圈里的大神們交流，將對每期漫談的期望值設定為100分，那么我就力爭做到120分的水平。夠勵志吧?要不你也加入我們的朋友圈，大家群聊唄?

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】

【編輯推薦】