再流弊的技術，也抵不過一次事故：兼談技術管理

    2015年，業界已經連續出現了幾起大的故障。究其根本緣由，都是不該該的人爲事故。本文從這些大故障提及，主要談及運維管理相關的一些話題。本文的主要內容包括：

1、不太平的互聯網

2、爲何這麼多人爲事故?

1.爲何運維更容易發生事故?

2.規範這麼全，爲何還有事故?

3.都自動化了，爲何還有事故?

4.灰度這麼好，爲何還有事故?

3、怎麼規避人爲事故?

1.選擇合適的人

2.培養安全意識

3.讓專業變成一種習慣

好吧！咱們正式開始。

1、不太平的互聯網

近期獲悉的一些大故障，不只來自於攜程、阿里雲，還有一些影響範圍不是很大，但一樣很是不該該的人爲事故。

901阿里雲故障

阿里雲稱因雲盾升級觸發bug，致使部分服務器的少許文件被系統誤隔離。其已第一時間啓動系統回滾，被誤隔離的文件正在陸續恢復。

 

部分阿里雲用戶表示很受傷。

 

不少微信羣朋友紛紛表示也已中招。從波及面及技術層分析來看(詳見下文)，應該是人爲事故爲主。

528攜程故障

5月底的此次攜程故障，在17小時後才恢復業務。官方更是直言爲「員工錯誤操做致使」。

 

其餘「使人髮指」的故障

包括但不限於：

1.某公司技術人員大白天的給公司計費數據庫服務器更換電源…

2.某銀行總行大型機，關鍵線路接反了…

3.某銀行關鍵交易系統，更新版本時SQL 腳本update 語句沒寫where 條件，而後全部網點信息都被重置…

根據筆者十多年的互聯網從業經驗，重大故障，究其根源，至少60%都是低級人爲事故。真正由於複雜系統問題致使的嚴重故障，很是之少。

2、爲何這麼多人爲事故?

互聯網發展至今，還沒脫離草莽時代。技術上，從最開始的小米加***，到如今逐漸自助化、半自動化，或者利用開源產品修修補補造成本身的系統。

若是說技術上的發展尚可陳詞、有些亮點，那麼對人的管理和重視程度，就更加落後得太多。

 

能夠佐證的是，微信技術社區裏頭，討論技術熱點的文章很是之受追捧；但技術管理類的文章，每每很是被冷落。

究其緣由，仍是在於廣大互聯網技術人員的「手藝人情結」。從我所在的運維行業來看，尤其突出：

你們都是從Linux、Shell 開始學起，很是享受那種敲幾行命令一回車，自動部署多臺服務器的快感及成就感。並誤覺得這就是本身的所有。

技術人員夢想着身懷「絕技」，對Linux系統的某些壓箱底活兒或對某項編程技術的獨門祕籍，自此笑傲人生，並「不爲五斗米折腰」，如認爲公司或領導有讓本身不爽的地方，即刻」瀟灑」遁去。

雖然，這每每驗證了一句話「最有才能的人，每每是最無效的」。

技術人員不肯受束縛，更多很是相信本身，以爲個人技術槓槓的。爲何須要別人來檢查個人工做？我就是完美。

技術負責人每每工做年齡更長，可能經歷過更野蠻生長的時代。

並且不少人潛意識地認爲，技術能夠解決一切問題，但問題是：

　　當系統愈來愈大、自動化和智能化程度愈來愈高，開飛機的人，水平跟不上，怎麼辦?

機器再強大，也須要人來操做。你說是不?

1.爲何運維更容易發生事故?

其實相比運維，開發人員仍是幸福的。開發更多關注功能、怎麼快速交付項目需求便可。程序有Bug?還好啦！後面還有測試在兜底。甚至，Bug  多些也無妨，還能算作測試的績效。

在這個時候，開發是操做人，測試其實是檢查人，兩個崗位互補：

這就是爲何飛機駕駛艙會有兩名飛行員的緣由，即便副駕駛員看上去無所事事的樣子。但，關鍵時候但是能救命的。

運維就沒這麼幸運了。運維每每苦逼地衝在第一線，手上掌握着的都是生產環境。並且通常狀況下，問責自負，基本上沒有誰來檢查運維的工做。也少有人意識到這是個嚴重問題。

2.規範這麼全，爲何還有事故?

規範是用來「制約」人的，技術是用來「簡化」人的。But，系統再智能也得人來操做，不是麼?

對於人自己，咱們究竟作了哪些事情呢?這是值得捫心自問的。

規範再多，人也能夠束之高閣。因此管理者必定不能以爲規範制度完善了，就已萬事大吉。偏偏相反，放鬆警戒，放鬆對人的管理，放鬆貫徹執行，更大的悲劇可能將要來臨。

規範制度不是技術管理的所有，規範能夠理解爲最低標準，用來杜毫不專業的人去會犯毀滅性錯誤。

規範更可能是「術」，而不是「道」。雖然規範想體現「道」，但畢竟，「指向月亮的手不是月亮」。

重視選人、重視培養人的專業意識，纔是王道。

3.都自動化了，爲何還有事故?

近期這幾起嚴重故障定義爲人爲事故，我想應該沒有多少人反對。

自動化能夠減小人員例行的、重複的登陸服務器的操做，從而減小人爲事故的發生。那麼這又是鬧哪樣呢?

其實恰好相反，人爲事故由於運維自動化平臺的出現，其惡劣影響更是被無限放大。

以前小米加***的時代，你們都登陸服務器進行操做，千百臺服務器各自爲政，想一次性搞癱整個系統，還真的很難。

運維自動化平臺的出現，很好的「解決」了這個問題。畢竟，平臺再智能，也須要人來操做。而過度依賴平臺，反而削弱對人員專業性的培養。

人的關係沒協調好，問題的根源就沒解決。壓死咱們的每每是最後一根稻草。

4.灰度這麼好，爲何還有事故?

有人會說了，咱們公司灰度發佈很是完善，理應能控制各類事故發生。即便有，影響範圍也應該很是之小。

這其實有兩個問題。一則有了灰度發佈，就能夠忽略測試環境了麼?若是模擬環境並不足夠仿真，或沒有在模擬環境充分測試過、直接在生產系統上進行灰度，這個也是很是值得商榷的：

一個朋友說，電信內部作運營，動用了九個機櫃100%模擬生產環境，專門作測試。包括網絡設備版本，也都充分的穩定性測試。

可能根本緣由在於，互聯網行業草根出身，長期野蠻生長，從亂到治，習慣試錯和快速迭代，所以容易亂象叢生。而電信、銀行這些行業，這些從一開始就視安全爲命脈，循規蹈矩，謹小慎微。

還有，重大事故發生時，灰度範圍內的用戶，對他們而言，總歸是無妄之災。憑什麼他們就應該蒙受此等「待遇」呢?他們何罪之有?

他們就理應是」小白鼠「麼?

二則灰度策略，是否合適?版本發佈平臺每每匯聚衆人智慧結晶設計架構而成，但可能沒有定義具體的灰度策略(這不屬於技術範圍，而是業務範圍)。

也就是說，一次更新100臺服務器，仍是一次更新10000臺服務器，是能夠被操做人員手工指定的。

最怕的就是，工具作得很流弊，使用者綜合能力很通常。

使用者若是圖個省事，所謂的灰度發佈，一次性的更新成千上萬臺服務器，那麼工具就不只沒有產生效率，反而變成了幫兇(就像刀磨快了，反而變成殺人利器)。

究其本質而言，灰度其實就是一種制度和意識。是但願經過灰度，喚醒人的安全意識。若是操做人員，不能覺悟到這一點，就是死路一條。

3、怎麼規避人爲事故?

在生產系統上更新版本(特別是若是沒有同等模擬環境的話)，就像在高速公路上換輪胎，各中危險，不一而足，特別是服務了成千上萬臺物理機的大系統而言。

人爲事故的出現每每不是個例，是長期積累的結果，單我的爲事故每每也只是呈現了問題的冰山一角而已。人爲事故，是必然而非偶然。

想要有機會完全的解決人爲事故，建議從以下幾方面着手。

1.選擇合適的人

選好人，每每能作到事半功倍，反之亦然。

管理學的重要原則之一是發揮人的優點，儘可能不要嘗試着去改變一我的。特別是對於一線生產系統的操做崗位(其實很是重要)而言，找到合適的人，比什麼都重要。

運維的首要工做職責是穩定性。所以須要找性格老實、謹小慎微的人來作更加合適。性格毛糙，甚至容易「幻聽」的人，明顯不合適，畢竟，「常在河邊走，哪能不溼鞋」。

爲何非得要讓二把刀來開飛機呢?

德才兼備是正途。這裏所謂的才就是技術，德是人的德行、行爲和意識。道和德是相通的，運維人員的意識加強了，綜合能力提升了，規範了，是能夠避免一些問題的。

這裏順序很重要，直接從規範切入，每每是失敗的開始。須要首先提升意識水平，而後順勢而爲。而不是生猛切入。

2.培養安全意識

「對運維操做要有敬畏之心」。這句話應該做爲警世恆言，掛在每個運維人員的心頭。

腦子裏牢記安全意識，比死記硬背規章制度更重要(固然，首先須要有規章制度)。

運維制度及規範體系的最大意義在於，控制死角可能的影響。每一次事故，都是一個盲點、一個死角又被發現的過程。運維最難之處在於，不可能作到沒死角。

規範制度確定落後於問題。爲了規範而規範不是目的，根據訴求控制風險的規範，纔是有意義的。

誠然，「安全沒有捷徑，該踩的雷都會踩到。」但這不是藉口，不是免死金牌。同理，用技術來保障技術，也是不可取的。

讓每個運維人員腦海裏都緊繃着安全這根弦，比什麼都重要。畢竟，死角永遠都存在。只能用未知來解決已知，而不是反之。

3.讓專業變成一種習慣

先哲亞里士多德曾說：「人的行爲老是一再重複。所以，卓越不是單一的舉動，而是習慣。」

單次的刺激沒法造成習慣，單次過猛的刺激，只會造成恐懼，變得畏手畏腳。

專業是否變成一種習慣，每每更多取決於管理者。由於管理者更能分清楚，哪些是重要緊急，哪些是不重要不緊急。專業首先應該是管理者的一種習慣，而後時時傳遞不鬆懈。

管理者應該選對人，而後對於有重大操做權限的人員，常常性的溫習各種故障、事故，採起各類辦法，讓員工時刻具有安全意識，真正認識到責任重大。

「警鐘常鳴」，各類震撼人心的模擬演練、演習和培訓，也必不可少。

須要樹立檢查人機制，創建一個好的團隊工做習慣，「結對運維」：

沒有檢查崗，單槍匹馬作事情，平時還好，在狀況複雜時，我的情緒波動和精神壓力均可能很是大，容易錯誤決策，或使出「昏招」。

另外補充說下：對於公有云而言，若是參與雲保險，這對於終端用戶而言也是幸事。畢竟雲廠商的賠償，即便100倍又能多少呢?業務的損失，若是由第三方保險公司來作些承當，應該更好。

路漫漫其修遠兮，吾將上下而求索。謹以此句，和天下運維同仁共勉。一塊兒加油。

如何一塊兒愉快地發展

「高效運維」公衆號(以下二維碼)值得您的關注，做爲高效運維繫列微信羣(國內領先的運維垂直社區)的惟一官方公衆號，每週發表多篇乾貨滿滿的 原創好文：來自於系列羣的討論精華、運維講壇精彩分享及羣友原創等。「高效運維」也是互聯網專欄《高效運維最佳實踐》及運維2.0官方公衆號。

重要提示：除非事先得到受權，請在本公衆號發佈2天后，才能轉載本文。尊重知識，請必須全文轉載，幷包括本行及以下二維碼。