繼上次講的管理者如何對待工程師團隊犯錯誤之後，我再說說工程師怎麼對待自己的錯誤。
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-