根據(jù)蔡格尼克記憶效應(yīng)，人們總對那些沒完成的任務(wù)印象深刻。雖然哥時常將話題岔開到那個“神奇”的云平臺項目，但想必大家還是愿意繼續(xù)回到我們整體設(shè)計與治理的主路上吧?好，那就讓我們“冷水洗把臉”回來繼續(xù)聊系統(tǒng)的日常運維方面吧。

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

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

變更管理

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

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

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

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

另外，如果涉及到比較復(fù)雜或大型的變更，我們在相關(guān)的記錄文檔中還應(yīng)適當?shù)呐渖夏荏w現(xiàn)變更步驟和涉及范圍的流程圖。這樣不但能有助于理清變更的思路和波及面，還能供變更后或出現(xiàn)其他問題時進行參考和審計所用。

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

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

發(fā)布管理

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

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

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

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

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

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

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