[[401912]]

 如果針對工程師團(tuán)隊犯的每一個錯誤都錙銖必究，以罰代管，那也就不需要這種管理團(tuán)隊了。罰，誰不會罰？！管，你會嗎？！

一.犯錯誤是什么狀態(tài)？

干活的才會犯錯，不干活當(dāng)然不會犯錯。

2002年我剛做技術(shù)總監(jiān)，依托于微軟的COM+服務(wù)做分布式服務(wù)治理，面向全國提供一項移動數(shù)據(jù)企業(yè)級服務(wù)，每天就像坐在火山口，如履薄冰如臨深淵。

你說我有沒有責(zé)任心？肯定是有的。每天都在上下班路上閉著眼復(fù)盤代碼和架構(gòu)（那時候C++程序是基于COM+和MSMQ服務(wù)的松散耦合多服務(wù)多節(jié)點協(xié)同模式），腦海中就像《后翼棄兵》里一樣打開了一屏屏代碼和日志的視圖上下翻動，絞盡腦汁想有什么可以優(yōu)化的地方，還有哪些地方可能會引發(fā)內(nèi)存泄漏或線程安全。

你說我有沒有壓力？當(dāng)然有啊?？謶趾徒箲]伴隨著我，讓我懼怕聽到短信告警聲和電話鈴聲。手機(jī)里常備一條上行短信指令，隨時隨地準(zhǔn)備上行短信，遠(yuǎn)程重啟核心服務(wù)。

你說我態(tài)度端不端正？非常端正。服務(wù)有隱患，我特別愿意承認(rèn)，特別愿意改。我曾經(jīng)說過，實事求是，是工程師團(tuán)隊的最低道德要求。但在沒有更先進(jìn)的架構(gòu)級解決方案出現(xiàn)之前（比如十年后出現(xiàn)的Redis、Dubbo、Docker等史詩級解壓作品），我只能在原有方案基礎(chǔ)上修修補(bǔ)補(bǔ)。

有此親身體會， 我遇事都是相信除了極個別人之外絕大多數(shù)工程師都是榮譽(yù)感很強(qiáng)的，也是非常不愿意看到事故發(fā)生的，更會在第一時間開動腦筋定位和解決問題，用不著領(lǐng)導(dǎo)催。

二.如果換成是我，我會犯這個錯誤嗎？

有一次線上嚴(yán)重漏測造成了比較大的影響，我該責(zé)怪誰呢，產(chǎn)品、研發(fā)、測試？

我把這個項目的測試用例拿出來仔細(xì)看了一遍，把測試用例評審會議紀(jì)要又都翻出來看了一遍。最后我的結(jié)論是， 如果把最后的看門人換成是我 ，我編寫的測試用例，還與產(chǎn)品和研發(fā)都評審了幾輪測試用例，在這種情況下也沒有能查缺補(bǔ)漏提前發(fā)現(xiàn)，那說明只能亡羊補(bǔ)牢，補(bǔ)上測試用例，用測試用例來確保每次更新迭代都能復(fù)核這個路徑。還能怎么辦？

態(tài)度有問題嗎？

態(tài)度有問題，可以處罰。

態(tài)度如果沒有問題，那就是能力有問題。

能力有問題，那也是領(lǐng)導(dǎo)的管理問題。

板子應(yīng)該打到領(lǐng)導(dǎo)的屁股上，要么是領(lǐng)導(dǎo)沒有預(yù)見性，要么是領(lǐng)導(dǎo)沒有輸出工具，要么是領(lǐng)導(dǎo)沒有培訓(xùn)到位。

領(lǐng)導(dǎo)沒有預(yù)見性怎么辦？換領(lǐng)導(dǎo)啊。預(yù)見性這種東西，真的是天賦。

沒有輸出工具怎么辦？亡羊補(bǔ)牢為時未晚，趕緊總結(jié)方法論，全面自動化。

沒有培訓(xùn)到位怎么辦？從這一刻開始，認(rèn)認(rèn)真真逐字逐句地死磕RCA報告制度，讓每一次錯誤變成有意義的共同記憶。

如果這些都做了，那追究責(zé)任的話，也只能“壓實”分管領(lǐng)導(dǎo)的“主體責(zé)任”了。

三.技術(shù)歸零 管理歸零

出了事故，處罰誰？

罰基層員工？

罰部門主管？

罰分管高管？

罰之前先搞清楚目的。

罰是為了不再發(fā)生，對吧？

可在IT生產(chǎn)上，往往是你要是知道這么會死你就不會死，往往是死了才知道原來還有這種死法～

面對錯誤，有兩種領(lǐng)導(dǎo)。

第一種，成功領(lǐng)導(dǎo)。成功領(lǐng)導(dǎo)會問你還需要什么資源支持，喜歡從錯誤中吸取教訓(xùn)，舉一反三，構(gòu)筑內(nèi)功，絕不再犯。

第二種，普通領(lǐng)導(dǎo)。而普通領(lǐng)導(dǎo)則既不能技術(shù)歸零“定位準(zhǔn)確、機(jī)理清楚、問題復(fù)現(xiàn)、措施有效、舉一反三”，也不能管理歸零“過程清楚、責(zé)任明確、措施落實、嚴(yán)肅處理、完善規(guī)章”，反正就是員工你不對，你錯了，你疏忽大意，你搞砸了，你要對此負(fù)全部責(zé)任。

有一年在一個重要節(jié)日的晚高峰，我們的驗券核心服務(wù)突然出現(xiàn)嚴(yán)重超時問題，不僅僅是我，連業(yè)務(wù)方都派了代表蹲守在排查人的旁邊，大眼瞪小眼，你看我我看你，但是經(jīng)過了兩個多小時的排查，各種服務(wù)重啟無效，代碼看了一個遍，始終找不到問題原因。在排除了所有的不可能之后，無論剩下的多么難以置信，那就是真相。終于發(fā)現(xiàn)是偶然間把測試環(huán)境的 MySQL 數(shù)據(jù)庫端口號配置帶上了線。因為測試環(huán)境的服務(wù)器資源緊張，所以驗券的核心數(shù)據(jù)庫 MySQL 端口號不是默認(rèn)的 3306，但兩三年來他們一直如此，測試環(huán)境和生產(chǎn)環(huán)境就是不一樣，從未因此出錯。這回把錯誤的端口帶上去之后，生產(chǎn)環(huán)境的驗券組件連接數(shù)據(jù)庫超時之后進(jìn)入了另一個業(yè)務(wù)邏輯（這段邏輯還包在一個C++庫里，多年都未動過，所以第一時間沒有懷疑到這里），倒是也能驗券，但損失了等待超時的時間，從而讓商家無法容忍。

怎么辦？

后來我要求研發(fā)協(xié)作平臺必須實現(xiàn)一個特性： 上線的時候必須做到一包（注：打包的包）到底，一鏡 （注：鏡像的鏡） 到底 。具體指的是，一個代碼分支對應(yīng)的一個包（或鏡像），可以流經(jīng)測試環(huán)境，直接上生產(chǎn)環(huán)境，一路穿行，全程無需手工干預(yù)，無需手工改配置文件，無需重新打包。 一鏡到底，就要求配置與代碼分離，與環(huán)境有關(guān)的配置不能存儲在工程的配置文件里。

我再也不相信測試通過后的二次打包。一次兩次上線可能不出錯。一千次一萬次上線呢？一鏡到底是保證我們不再次死于非命的保命良方。而且系統(tǒng)即流程，要把這個最佳實踐做實到系統(tǒng)里。

四.小結(jié)

言而總之，總而言之一句話，壓實分管領(lǐng)導(dǎo)的主體責(zé)任，同時讓災(zāi)難成為團(tuán)隊的寶貴財富而不僅僅是罰款和心理負(fù)擔(dān)。