IT運維（IT Ops）人員在組織中扮演著三個關鍵性角色。
他們可以是建筑師、建設者以及出現(xiàn)問題時挽救大局的英雄。他們設想和幫助規(guī)劃數(shù)字環(huán)境，建立這些環(huán)境運行的基礎設施，并在問題變?yōu)槲C之前（和之后）解決這些問題。
正如他們在Geico廣告中所說的那樣，這就是他們所做的。
今天，我想把重點放在IT運維工作的突破性/固性上，特別是預防IT網絡危機并在發(fā)生危機時應對它們的一些瑣碎的事情。基于過去15年處理IT運維變更的經驗，個人覺得IT專業(yè)人員需要注意以下重要事項，以避免網絡危機，或是在危機已經到來時解決危機。
什么發(fā)生了變化？—— 很多的（甚至是大部分的）危機是由于環(huán)境的變化而產生的。在診斷問題時，了解一下最近發(fā)生的其他環(huán)境變化也許會對你有所幫助。如果你不能找到很明顯的直接原因，請花點時間來詢問： 最近發(fā)生的可能導致該問題的原因是什么？這在解決遠程問題時特別有用，因為你不可能看到發(fā)生的所有事情。
例如，如果服務器停止響應，首先要檢查服務器，確保服務器沒有掛起或宕機，硬盤空間足夠并已連接到網絡等。如果你無法在服務器本身找到原因，那么是時候擴大搜索范圍并查看其他在近期發(fā)生的變化了。
在故障期間，網絡連接往往會揭露自身問題。檢查你的項目管理系統(tǒng)或更改日志，以查看網絡上最近發(fā)生了哪些變化?？赡苁怯捎谂渲迷阱e誤的路由器、交換機或防火墻后面，導致你無法訪問服務器。也可能是有人意外地刪除了服務器的DNS記錄或更改了路由路徑。問題可能發(fā)生在其他地方，你看到的只是癥狀，而不是導致問題發(fā)生的根源。
有計劃地避免附帶損害 —— 當你在一個地方進行變更時，卻在另一個地方發(fā)生了意想不到的問題，沒有比這更令人沮喪的了。一個附帶損害的例子可能是置換出一臺服務器，結果卻發(fā)現(xiàn)它敲出了一個夜間傳輸，因為傳輸?shù)陌踩院蜋C器的硬件認證相關聯(lián)，改變硬件就改變了硬件鍵。避免附帶損害的關鍵是在作出變更之前做好功課并盡可能多地確定相關功能。深入了解并識別任一相關功能，并對你的計劃作出必要調整。
列一個變更清單 —— Atul Gawande在他的著作《清單宣言（Checklist Manifesto）》中談到如何運用清單來提高我們正確、安全和可靠地傳遞信息的能力。 IT 運維人員經常會使用記憶、培訓和直覺來進行關鍵性的工作。當他們不按順序執(zhí)行或是跳過某些步驟執(zhí)行時往往會出現(xiàn)問題。我非常支持在進行網絡變更時使用清單，以確保成功并能避免危機。一個好的清單可以幫助你在變更過程中計劃并正確實施這些步驟。
預備步驟 - 在作出更改之前需要做些什么？哪些服務器或設備需要被down或調整？需要通知誰？
進程中的步驟 - 在更改過程中必須執(zhí)行哪些步驟？需要修改哪些配置？
驗證變更是否奏效 - 您如何確定變更是否奏效。你應該檢查哪些項目？應使用哪些數(shù)據來進行驗證？
應急程序 - 如果形勢轉壞，應該使用什么策略來緩解？你的應急策略是什么？
恢復步驟 -如何才能撤銷為實施更改所做的預備步驟？（這一步必須得到重視，因為它往往可以避免引發(fā)另一個危機。）
清單不一定要很長，但是要深入、準確和適用。個人覺得，使用清單是網絡變更成功的關鍵。如果你對此有興趣，可以查看我之前寫的文章《IT項目實施時使用清單的8個理由》。
“一次只做好一件事”原則 —— 我個人的原則是：一次只做一項主要的網絡更改。如果只做一處變更，那么即便出現(xiàn)問題，你也只面臨一個危機。如果兩個或兩個以上的變更同時出問題，那就是另外一回事了，就造成了多重危機。一次執(zhí)行數(shù)個更改，卻只有一部分網絡down掉，這聽起來很誘人，但是請不要這么做。這種冒險行為并不值得。
要清楚你所處的位置 —— 位置感知（position awareness） - 當IT人員誤以為自己是在測試系統(tǒng)上工作，然后抹去了一個生產系統(tǒng)，這絕對是最可怕的自我傷害。一個最好的例子就是IT經理在刷新QA數(shù)據庫的時候，意外地清空了生產數(shù)據庫，因為他在錯誤的機器上。通常在使用遠程桌面程序時會出現(xiàn)這些錯誤，因為你可能在無意中連接到了錯誤的機器。在工作開始之前，一定要確保你在正確的機器上，即便只是執(zhí)行一個hostname命令那么簡單。在它首次制止你連接到錯誤的機器上的時候，你會感激你自己。
上述都是一些在變更管理指南中并未提及或僅是簡單提及的實用性步驟。這些步驟很簡單，但是可以幫助你應對意外的IT運維危機或是防止產生危機。
