本文由 伯樂在線 - dimple11 翻譯， 劉唱 校稿。未經許可，禁止轉載！
英文出處： Zachary Kuhn。歡迎加入 翻譯組。
上周我和同事們簡單地聊了聊我們工作中搞砸的那些事兒。如今早已不再犯那些錯了，所以想起過去就覺得很好笑。但是笑歸笑，其實當時犯的這些錯讓我們受益頗深。
分享自己犯錯的經歷至關重要，能讓別人從中吸取經驗教訓，而且可能讓他們工作起來更上手。我在這兒記錄了幾條自己最近犯的錯。
為什麼有那麼多生產資料庫被誤刪？
幾個月之前，Reddit 上發了一篇文章，寫的是一個入門級開發人員在上班第一天就誤刪了生產資料庫。我們看到類似這種有人犯了特大的、不可磨滅的錯誤的文章，都不免心生畏懼。我們意識到自己並不是沒可能犯那種錯——大多數時候都是懸崖勒馬。
我在干第一份工作的時候，有一個高級資料庫管理員在上班第一天就誤刪了生產資料庫，這種例子簡直比比皆是。工作團隊用一周前舊的資料庫備份幫他彌補了過失，讓他保住了工作。如今十年過去了，都仍用這件事拿他開涮。
今年年初有天早上，我被叫去調查一個客戶生產中出現的問題。他們本來要針對一小部分用戶進行產品的 β 測試，但是他們的網站首頁突然什麼都顯示不出來了。我猜想可能是系統有 bug 或者有漏洞所致。
我登錄進生產機器，調出資料庫，發現 articles 表是空的。OK，這證實了網頁顯示空白的情況。
用戶表裡面還是有用戶的，這就奇怪了，所以我們丟了所有的 articles，但起碼他們的測試用戶仍有他們的賬號，我們可以解釋說是這是個測試版，而且這種事情時有發生。
接下來一會兒我就犯迷糊了。我記不清楚自己乾了什麼，我認為自己不會蠢到在控制台窗口輸入了刪除表中用戶的指令，可情況就是這樣——現在既沒有 articles 表，也沒有用戶表。我呆坐著，感覺有點震驚。
然後我的大腦高速運轉，開始想辦法修復問題。我真的刪掉用戶表了嗎？是的。我們運行備份資料庫了嗎？沒有。該怎麼向客戶解釋呢？我不知道。
我記得自己去找了項目經理，坐在她旁邊解釋事情發生的經過，articles 表中沒有數據了，所以網站看上去是空的。哦對了，我還誤刪了用戶表。現在他們需要重新邀請所有的用戶——如果他們還能想清楚用戶都有誰的話。哎呀。
我回到自己的座位上，感覺深受挫敗。
但是我覺得事情有些蹊蹺，我們怎麼可能一開始就丟了所有的 articles 表呢？於是我繼續深究下去，一方面是因為難以接受這個結果，一方面是想挽回顏面。之後過了一小會兒，我注意到了關鍵問題。
伺服器上還有另外 5 個資料庫，其中一個的名字和我正在看的那個資料庫的名字非常相似。
我一檢查，發現 articles 都在裡面，用戶表也完好無損。事實證明是因為配置發生變化，無意間讓它變成了生產資料庫，導致網站指向了全新的資料庫。我在裡面看到的那些用戶呢？種子數據罷了。
真是如釋重負！一早上神經緊繃、胃酸翻湧，搞得我渾身不適，但好在我們「修復」了所有的數據，並且找到了問題真正的癥結所在，沒有提前宣布誤刪資料庫的壞消息。
這個小插曲讓我們受益良多，最簡單的一個就是：現在我們總是在給資料庫做備份……這可能是我們開發人員最有效的胃藥。
總趕進度，卻從來趕不上進度
我最近所犯的另一個突出 錯誤沒那麼戲劇化，實際上是由一個個小錯誤最終累積造成了大麻煩。
我們項目開發的一大挑戰就是時間緊張（但也不全是？）
第一次開會時，我們一致覺得項目需要的時間比我們能夠拿出來的時間多了一倍。從項目一開始，截止日期就步步緊逼，所以我們三下五除二就通過了認證環節，以便進入客戶真正關心的功能環節。
我只是之前在一個單頁 app 中落實了一次認證，但仍然沒有徹底理解 app 各部分是如何協調的。
盡己所能用最快的速度把 app 趕出來，就是大錯特錯，我漏掉了一些非常重要的東西：
用戶在登陸後，是通過 cookie 來加載的，但是我的 app 頁面沒有給加載提供等待時間，而是根據事件順序來決定先後的，所以伺服器會回覆說你沒有權限。這種錯誤很少見，而且很難再出現，因為大多數情況下事件都是按照正確的順序來完成的。 而且認證環節也從不檢查用戶令牌是否失效，如果你不經常訪問網站，當發現了沒法登上網站後，就需要註銷登錄再重新登進去。 令牌應該在每次發起請求時都進行更新，但我從來都沒有時間去理解這些規則。所以這裡又產生了時間問題。如果我們一次同時發出幾種請求，收到的回覆取決於他們到來的順序，那將來發送請求用到的令牌就是錯的。
我們卯足勁趕進度，但最終所用的時間還是要比給定的時間多一倍。區別就是我們開發出的 app 裡面漏洞更多了，然後甚而要花更多的時間對漏洞進行追蹤和修復。
工作中的失誤讓我尷尬不已，在大家面前感到十分羞愧，因為我把一切都搞砸了。
我要說一點：從那之後，我開始花時間學習認證機制，現在已經理解了 OAuth,、JWT、刷新令牌和失效。我仔細閱讀了許多庫里別人寫的認證代碼，而且建立了基於幾種不同語言版本和框架的認證流程。
失敗是成功之母
這是每次失敗的經歷給予我的啟發。只要你願意學習，幾乎每次這樣的經歷都會讓你從中受益。
如果人能夠從錯誤中吸取教訓，那麼就會有所進步。如果一個隊員是第一次犯錯，我儘量不會對他表現出不滿態度，他們往往已經知道自己把事情搞糟了。
但我也努力不去苛責那些總是犯錯、屢教不改的人，他們也需要被同情。
對待犯錯，如果你能夠做到這四點，那麼就會不斷進步：
對曾經犯過的錯誤可以自嘲一番 從中吸取經驗教訓 在之後努力為自己正名 和他人分享，讓他人也能從中獲益。
關於犯錯的寶貴价值，我留給你們一則名人軼事：20 世紀初期，IBM 的總裁托馬斯·J·沃森遇到了一位因為多次決策錯誤讓公司損失慘重的員工，當問及是否要開除這個員工時，沃森答道：
「不，我剛剛花了 60 萬美元培訓了他，我怎麼會讓其他人僱傭他來獲得他的經歷呢？」
你過去犯過哪些有意思的錯？來一起分享吧！
英文出處： Zachary Kuhn。歡迎加入 翻譯組。
上周我和同事們簡單地聊了聊我們工作中搞砸的那些事兒。如今早已不再犯那些錯了，所以想起過去就覺得很好笑。但是笑歸笑，其實當時犯的這些錯讓我們受益頗深。
分享自己犯錯的經歷至關重要，能讓別人從中吸取經驗教訓，而且可能讓他們工作起來更上手。我在這兒記錄了幾條自己最近犯的錯。
為什麼有那麼多生產資料庫被誤刪？
幾個月之前，Reddit 上發了一篇文章，寫的是一個入門級開發人員在上班第一天就誤刪了生產資料庫。我們看到類似這種有人犯了特大的、不可磨滅的錯誤的文章，都不免心生畏懼。我們意識到自己並不是沒可能犯那種錯——大多數時候都是懸崖勒馬。
我在干第一份工作的時候，有一個高級資料庫管理員在上班第一天就誤刪了生產資料庫，這種例子簡直比比皆是。工作團隊用一周前舊的資料庫備份幫他彌補了過失，讓他保住了工作。如今十年過去了，都仍用這件事拿他開涮。
今年年初有天早上，我被叫去調查一個客戶生產中出現的問題。他們本來要針對一小部分用戶進行產品的 β 測試，但是他們的網站首頁突然什麼都顯示不出來了。我猜想可能是系統有 bug 或者有漏洞所致。
我登錄進生產機器，調出資料庫，發現 articles 表是空的。OK，這證實了網頁顯示空白的情況。
用戶表裡面還是有用戶的，這就奇怪了，所以我們丟了所有的 articles，但起碼他們的測試用戶仍有他們的賬號，我們可以解釋說是這是個測試版，而且這種事情時有發生。
接下來一會兒我就犯迷糊了。我記不清楚自己乾了什麼，我認為自己不會蠢到在控制台窗口輸入了刪除表中用戶的指令，可情況就是這樣——現在既沒有 articles 表，也沒有用戶表。我呆坐著，感覺有點震驚。
然後我的大腦高速運轉，開始想辦法修復問題。我真的刪掉用戶表了嗎？是的。我們運行備份資料庫了嗎？沒有。該怎麼向客戶解釋呢？我不知道。
我記得自己去找了項目經理，坐在她旁邊解釋事情發生的經過，articles 表中沒有數據了，所以網站看上去是空的。哦對了，我還誤刪了用戶表。現在他們需要重新邀請所有的用戶——如果他們還能想清楚用戶都有誰的話。哎呀。
我回到自己的座位上，感覺深受挫敗。
但是我覺得事情有些蹊蹺，我們怎麼可能一開始就丟了所有的 articles 表呢？於是我繼續深究下去，一方面是因為難以接受這個結果，一方面是想挽回顏面。之後過了一小會兒，我注意到了關鍵問題。
伺服器上還有另外 5 個資料庫，其中一個的名字和我正在看的那個資料庫的名字非常相似。
我一檢查，發現 articles 都在裡面，用戶表也完好無損。事實證明是因為配置發生變化，無意間讓它變成了生產資料庫，導致網站指向了全新的資料庫。我在裡面看到的那些用戶呢？種子數據罷了。
真是如釋重負！一早上神經緊繃、胃酸翻湧，搞得我渾身不適，但好在我們「修復」了所有的數據，並且找到了問題真正的癥結所在，沒有提前宣布誤刪資料庫的壞消息。
這個小插曲讓我們受益良多，最簡單的一個就是：現在我們總是在給資料庫做備份……這可能是我們開發人員最有效的胃藥。
總趕進度，卻從來趕不上進度
我最近所犯的另一個突出 錯誤沒那麼戲劇化，實際上是由一個個小錯誤最終累積造成了大麻煩。
我們項目開發的一大挑戰就是時間緊張（但也不全是？）
第一次開會時，我們一致覺得項目需要的時間比我們能夠拿出來的時間多了一倍。從項目一開始，截止日期就步步緊逼，所以我們三下五除二就通過了認證環節，以便進入客戶真正關心的功能環節。
我只是之前在一個單頁 app 中落實了一次認證，但仍然沒有徹底理解 app 各部分是如何協調的。
盡己所能用最快的速度把 app 趕出來，就是大錯特錯，我漏掉了一些非常重要的東西：
用戶在登陸後，是通過 cookie 來加載的，但是我的 app 頁面沒有給加載提供等待時間，而是根據事件順序來決定先後的，所以伺服器會回覆說你沒有權限。這種錯誤很少見，而且很難再出現，因為大多數情況下事件都是按照正確的順序來完成的。 而且認證環節也從不檢查用戶令牌是否失效，如果你不經常訪問網站，當發現了沒法登上網站後，就需要註銷登錄再重新登進去。 令牌應該在每次發起請求時都進行更新，但我從來都沒有時間去理解這些規則。所以這裡又產生了時間問題。如果我們一次同時發出幾種請求，收到的回覆取決於他們到來的順序，那將來發送請求用到的令牌就是錯的。
我們卯足勁趕進度，但最終所用的時間還是要比給定的時間多一倍。區別就是我們開發出的 app 裡面漏洞更多了，然後甚而要花更多的時間對漏洞進行追蹤和修復。
工作中的失誤讓我尷尬不已，在大家面前感到十分羞愧，因為我把一切都搞砸了。
我要說一點：從那之後，我開始花時間學習認證機制，現在已經理解了 OAuth,、JWT、刷新令牌和失效。我仔細閱讀了許多庫里別人寫的認證代碼，而且建立了基於幾種不同語言版本和框架的認證流程。
失敗是成功之母
這是每次失敗的經歷給予我的啟發。只要你願意學習，幾乎每次這樣的經歷都會讓你從中受益。
如果人能夠從錯誤中吸取教訓，那麼就會有所進步。如果一個隊員是第一次犯錯，我儘量不會對他表現出不滿態度，他們往往已經知道自己把事情搞糟了。
但我也努力不去苛責那些總是犯錯、屢教不改的人，他們也需要被同情。
對待犯錯，如果你能夠做到這四點，那麼就會不斷進步：
對曾經犯過的錯誤可以自嘲一番 從中吸取經驗教訓 在之後努力為自己正名 和他人分享，讓他人也能從中獲益。
關於犯錯的寶貴价值，我留給你們一則名人軼事：20 世紀初期，IBM 的總裁托馬斯·J·沃森遇到了一位因為多次決策錯誤讓公司損失慘重的員工，當問及是否要開除這個員工時，沃森答道：
「不，我剛剛花了 60 萬美元培訓了他，我怎麼會讓其他人僱傭他來獲得他的經歷呢？」
你過去犯過哪些有意思的錯？來一起分享吧！
收藏