[[401912]]

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

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

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

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

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

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

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

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

二.如果換成是我，我會(huì)犯這個(gè)錯(cuò)誤嗎？

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

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

態(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ǔ)牢為時(shí)未晚，趕緊總結(jié)方法論，全面自動(dòng)化。

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

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

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

出了事故，處罰誰？

罰基層員工？

罰部門主管？

罰分管高管？

罰之前先搞清楚目的。

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

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

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

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

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

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

怎么辦？

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

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

四.小結(jié)

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