工程師應該如何對待自己的錯誤

繼上次講的管理者如何對待工程師團隊犯錯誤之后，我再說說工程師怎么對待自己的錯誤，

RCA報告制度是我的研發四板斧之一，也是我最為重視的環節，我會和涉及到的所有人一一確認BUG和故障的所有細節，直到我能完全理解并建立因果鏈為止，RCA報告由我撰寫或至少由我修改一直改到我滿意為止，

但很多工程師剛到我的團隊，遇到這種場合，都會有點靦腆，有點扭捏，有點不好意思，還有工程師不愿自曝其丑，總覺得我改都改了，領導這是生氣了嗎，領導你問這么細干啥呀，總想對推理程序一帶而過，

在我這里，允許失敗，允許犯錯，做IT不可能一帆風順，不可能沒有意外，就算內部沒發布沒更新沒問題，外部也會給你當胸一拳，所以我常說“災難隨時會到來”，

“有一種愚蠢的觀點認為，在NASA不允許失敗，”埃隆·馬斯克說，“但在這里（注：指SpaceX），失敗是可以選擇的，如果你沒有把事情搞砸過，說明你的創新能力不夠強，”——Ozan Varol

按這種說法，也不是什么失敗都可以被接受，我對高級別錯誤見獵心喜，反對愚蠢的低級錯誤，尤其是反復犯同一類低級錯誤，

工程師死于什么？

工程師死于聽天由命和漫不經心，

有研究人員對71名外科醫生在10年時間里做過的6500臺心臟手術做了調查分析，他們發現，那些把手術搞砸了的外科醫生會在隨后的手術中表現更差，結果表明這些外科醫生不僅沒有從他們的錯誤中吸取教訓，反而還強化了壞習慣，——Ozan Varol

所以工程師應該有意識地用清晰易懂的證據鏈，論述清楚根本原因，撰寫RCA報告，并廣而告之，讓其他工程師一起從這個錯誤中吸取教訓，把不好的習慣提前消滅，

第一個例子：

曾有產品經理反饋，她多次發現我們的一款App在蘋果手機上會出現打開后首頁選單消失的現象，再次打開后則選單顯示，此問題復現時機不確定，

工程師分析后發現，首頁選單的動態顯示用了一個臨時性方案：由H5資源中的JSON檔案配置，

選單項之所以消失，是因為從網路下載的存盤于沙盒檔案目錄 Library/Cache 中的新H5資源檔案夾丟失了，所以不顯示首頁選單，

網上大多數文章中對這個 Library/Cache 目錄的描述是：程式重啟后并不會丟失資料，只是不會被iCloud同步，而實際上蘋果的檔案中給出的說明是，當設備存盤空間不足時，系統可能會自動洗掉此目錄中的檔案，

本地H5檔案夾丟失后，解壓出來的是App包里的老H5資源，所以下一次打開的時候能顯示首頁選單（只不過是上一個版本的），

工程師找到根本原因之后，明白了兩個道理：

第一條，盡量不要使用臨時方案，迫不得已采用了臨時方案，也要盡早改造為通用方案，別給自己埋雷，

第二條，使用官方相關API時，一定要親自查閱通讀官方原版API DOC，不要道聽途說，不要嚼別人嚼過的饃，

所以他將H5資源從 Library/Cache 目錄，轉移到 Documents 目錄，確保H5資源相關的檔案不會丟失，同時首屏選單，從H5中的JSON控制，改為由服務器統一下發，

我們積攢了數百份翔實的RCA報告，每攢一批RCA就會全員發布，

為了提升從失敗中吸取教訓的能力，NASA在一份名為“飛行規則”的檔案中羅列了人類在航天飛行中犯過的錯誤，這份記錄過去的規則可以為未來提供指導，它匯集了幾十年來的航天失誤和錯誤判斷，讓人們以史為鑒，該檔案記載了自20世紀60年代以來載人航天飛行中出現的數千種例外情況及解決方案，描繪了每次事故的前因后果，并在更宏大的背景下賦予它們意義，為子孫后代保留了這種制度化的知識，有了這本手冊，NASA的員工只要關注新的問題即可，無須做不必要的重復作業，

——Ozan Varol

雖然我不知道一代代工程師有多少人認認真真讀過一遍RCA，但我對每一個案例都印象深刻，每當發生BUG或故障，我都能聯想起歷史上一宗宗相似的案例，為團隊提供思路，

工程師不要覺得那些都是過時的冊子，都是別人犯的錯，我不會犯這些錯誤，但你連是什么錯誤都不知道，你憑什么不會重復犯錯？

第二個例子，

一天業務方反饋說資料大屏里有一個學生的消費趨勢和他的消費明細對不上，

工程師進一步分析其他學生消費資訊發現并不是一個學生資料問題，而是共通性問題，這才發現Kafka集群的目標topic有五個磁區，但消費端只消費了其中三個磁區的資料，這是為什么呢？

原來前不久大資料服務“移山”里的實時訂閱監控告警某topic的消費延遲較大，于是就擴了兩個磁區，但是下游消費者并未感知到磁區的變化，依舊只消費舊的三個磁區資料，造成計算結果偏小，那這又是為什么呢？

工程師探究之后發現，FlinkKafkaConsumer配有動態感知磁區變化的開關（flink.partition-discovery.interval-millis），打開開關后，便可以動態感知磁區變化，就不用重啟消費端了，由于實時計算動態感知有性能損耗，所以官方默認是關閉的，從性能和資源利用率及我們實際情況綜合考慮，也不需要開啟動態感知引數，以后如果磁區調整變多，會打開這個開關的，就不用統一重啟所有消費者了，工程師得到的教訓是，對于商業產品涉及的集群，任何與其相關變化調整要做方案評估再操作，不可太隨意，

當我與一些企業高管談論失敗時，他們中的一些人認為：如果失敗是可以容忍的，那么失敗的次數就會成倍增加，失敗意味著犯錯，而犯錯是需要追責的，這些高管認為，如果不對責任方做出處罰，最終就會培養出一種“失敗也無所謂”的企業文化，允許失敗的存在，這些想法與幾十年來的研究結果格格不入，——Ozan Varol

這也就是我上一篇文章所抨擊的企業高管，

你完全可以創造一種環境，允許聰明人失敗，且讓他們不自鳴得意，你可以允許人們承擔高質量的風險，但你也可以設定高標準，你用不著容忍那些草率的失敗——所謂草率的失敗，指的是因為心不在焉而反復犯同樣的錯誤或反復失敗，你可以獎勵那些“聰明人的失敗”行為，懲罰表現不佳的人，當你正在打造那些可能會失敗的東西時，必須要接受一些無法避免的錯誤，人們不應該為聰明的失敗承擔責任，而應該為沒有從中學到經驗承擔責任，——Ozan Varol

在這種環境下，那些仍然不愿意公開談論失敗的工程師，那些仍然對“總結經驗教訓”敷衍潦草的工程師，注定將一事無成，

這其中的奧秘，是一種叫“心理安全”的東西：

1995年的一項研究發現，每一位住院病人的用藥錯誤次數達到了1.4次，在這些錯誤中，大概有1%的病人得了并發癥，身體受到傷害，哈佛商學院教授埃德蒙森決定深入挖掘原因，她派一名助理研究員去醫院實地觀察醫療團隊的做法，該助理發現，較好的醫療團隊并沒有犯更多的錯誤；相反，他們只是上報了更多的錯誤，

這些團隊擁有開放的氛圍，員工認為探討錯誤的做法是安全的，他們更愿意與他人分享失敗的經驗，并積極努力減少失敗，所以他們的表現更為優秀，

埃德蒙森把這種氛圍稱為心理安全，用埃德蒙森的話來說，心理安全是指“在實作雄心勃勃的績效目標程序中，沒有人會因為犯錯、提問或求助而受到懲罰或羞辱”，

研究表明，心理安全能促進創新，當人們可以暢所欲言，提出挑釁性的問題和半成型的想法時，挑戰現狀就變得更容易了，心理安全也提升了團隊學習能力，在心理安全的環境中，若上司提出可疑要求，雇員就會提出質疑，而不是一味地服從命令，在埃德蒙森的研究中，表現最好的醫院團隊是由一位身先士卒、極其平易近人的護士長領導的，她積極地促進開放式環境的形成，在接受采訪時，護士長說她的團隊允許在“一定程度上犯錯”，而“非懲罰性的環境”對發現和解決錯誤至關重要，在該團隊作業的護士們證實了護士長的話，一位護士指出，“這里的員工更愿意承認錯誤，因為護士長會幫助你”，在這個團隊中，護士們勇于為自己的錯誤承擔責任，正如護士長所說的那樣，“護士們往往會因為犯錯而自責，她們對自己的要求比我任何時候對她們的要求都嚴格得多”，

表現最差的兩個醫療團隊則有著截然不同的氛圍，在這兩個團隊中，犯錯意味著受懲罰，一位護士稱，她曾卷入一起醫療事故中，在給一名病人抽血時，她不小心傷到了病人，護士長立刻對她進行“審判”，護士回憶說：“簡直太丟臉了，仿佛我是兩歲大的孩子似的，”另一位護士說“醫生們喜歡擺架子”，如果你犯了錯，“他們恨不得把你的腦袋擰掉”，還有一位護士稱，犯錯后的感覺就像是“被叫進校長辦公室”，結果，如果發生用藥錯誤，護士們會故意掩蓋訊息，免受短期的尷尬和痛苦，然而這種做法忽略了保持沉默的長期后果，即病人因為用錯藥而受傷或死亡，反過來，這種環境會形成惡性回圈，那些表現最差、最需要改進的團隊也最不可能上報錯誤；而如果錯誤沒有上報，團隊便無法改進，

我相信每一位對職場高度和人生高度有所追求的工程師都不會愿意置身于那種沒有心理安全的團隊環境，一旦你偶然間加入了一個愿意明確承諾支持“聰明人的失敗”和善意的風險承擔行為的團隊，請珍惜它，因為真的不多見，

-END-

標籤：其他

上一篇：可視化前端編程平臺(LowCode or NoCode)

下一篇：工程師應該如何對待自己的錯誤