【51CTO專稿】最近，很多讀者朋友都在反映IT工作的執行難度正變得越來越低。也許與十年前比起來，如今的IT部門確實擁有更加龐大的輔助工具陣營與技術支持，但情況是否真的與大家的感受相同呢？今天我們就來聊聊這個話題。
目前，我們已經完全能夠以自動化方式進行服務器實例的創建與管理、部署復雜應用程序框架等工作。坐在自己的臺式機面前、鼠標點擊幾下，服務器故障排查就此順利實現。就在不久之前，這類維護工作還普遍需要我們搬動服務器機架、手動安裝操作系統、親自跑到數據中心、完成復雜的布線及網絡配置等等。從這個角度來看，IT工作已經變得更清閑、更安逸。
然而隨著時間的推移，我們發現只有不斷對方案進行調整或改進，才能真正做到對管理流程、常見任務及工作負載的簡化。要知道，技術事務的復雜性并沒有降低——事實上當下的IT系統比以往任何時候都更復雜——我們只能說現在的技術人員從體力勞動中解脫了出來、也不必應付太多簡單重復的枯燥任務。我們一直在將IT基本原理向抽象層面推進，努力把每項工作都變成日常管理鏈中的一環。這就要求從業人員在規劃方面做出更多嘗試，而初期投入的一切精力也確實很快帶來效率及成本方面的顯著回報。
虛擬化技術自然是實現這種進步的深層驅動力，如今不僅服務器引入了虛擬化，就連存儲系統、應用程序也與虛擬化掛上了鉤——甚至網絡也在VMware的VXLAN等產品的幫助下正式邁向虛擬化時代?？傮w來說，這些組件的創建及部署工作對技術人員的業務水平提出了更高要求，同時也給日常管理與維護工作帶來了極大便利。我們不必再為IT基礎設施的規劃與重建工作費心勞力，但項目初期的建設難度與投資金額相比過去則有了大幅度提高。
不過毫無疑問，IT工作并沒有變得更“簡單”。
日常操作的難度顯著降低，許多問題甚至可以由普通員工“自助”解決，然而我們仍然被牢牢束縛在技術領域的各種疑難雜癥及意外狀況之上。一方面，我們很可能遇上一周前發生的AWS宕機等突發問題。這是一種負面影響很難快速清除的破壞性事態，感知度非常高（尤其是非IT人員），而且顯然是由人為失誤及規劃缺失所造成。世界范圍內的一切自動化體系都無法有效解決這類故障，相反自動化程度越高、對于源頭設施的依賴性也越強，這進一步導致了后果的嚴重性。相信Amazon會在很長一段時間內籠罩在這次事故的陰影當中。
接下來，我們再看看像Mina Naguib最近所遭遇的特殊問題。我上周專門為此撰寫了評述文章，因為這應該被當作一個典型范例，指導經驗豐富、技能嫻熟的管理員們如何準確發現并糾正在合理狀況下本不應該出現的狀況。無論是否符合邏輯，大家都應該抱著最壞的預期對基礎設施中的所有層面進行故障排查。
1. 拒絕。這是一種偶然性很強的問題，故障幾乎不可能重現，它涉及互聯網中最穩定也最可靠的協議之一。理論上講這類問題根本不應該發生。
2. 憤怒。 在利用一切合理思路進行故障分析及排除之后，問題仍然存在。這時挫敗感恐怕已經不足以形容管理者的心情了。
3. 交涉。即使是最有經驗的IT大師，偶爾也會希望能以一部分犧牲換來故障的快速解決。如果問題憑空出現、暫時無法做出理性解析，大多數技術人員往往需要為自己爭取更多處理時間，借以完成監控及一致性檢測。
4. 悲觀。 這種情緒不一定會給技術人員本身帶來影響，但在我親身經歷的許多實例中，負面反應往往會立刻感染管理層及其它一些與IT并不沾邊的同事。他們開始放棄幫助管理員解決問題的努力，反而持觀望態度或者粗暴地認為事情已無法挽回——一旦這種情緒占了上風，問題很可能永遠得不到根本解決，甚至嚴重打擊企業員工的士氣。
5. 接受。這種態度可以被視為IT問題解決或者陷入悲觀的分水嶺。事實上IT部門在面對問題時根本就不應該涉及接受或者不接受，這是我們的工作，無論如何都必須成功修復。即使修復工作的效果在質量和可靠性方面還有待商榷，但面對問題選擇放棄抵抗的家伙只能說根本不具備基本的職業操守。這不是什么選擇題，我們必須搞定、工作必須繼續。
Mina就遇上了非常少見的TCP失效故障，該問題是由網絡服務供應商造成的，可以說與受影響的用戶并無直接關系。某臺路由器中的固件代碼有bug、或者某個接口損壞最終導致了悲劇的發生，只有通過堅持不懈的關注、努力與精心調試，才能將這類罕見問題扼殺在萌芽狀態。
這種故障就絕不是技術人員能簡單通過點擊鼠標或瀏覽社區就能解決的，絕大多數新手管理員甚至根本無法發現或者做出回應?？傊琁T工作絕不簡單，而這樣的挑戰就是難題的集中體現。
在公眾的印象中，IT工作似乎變得更容易、更順暢、更快速甚至更具時尚感，但實際上每一位技術工作者仍然需要拿出十幾年甚至幾十年磨練技能、積累經驗、努力工作。業務所帶來的壓力已經從過去的物理層面轉變成現在的邏輯層面，但身為IT人士，我們自己清楚這份責任比以往任何時候都更重大、更關鍵。