距離上一次發博客已近10個月了
在轉型產品的路上也探索了半年了
精彩紛呈，千姿百媚，層出不窮，再也沒有其他形容詞能記錄這半年來的心路歷程了
今晚，線上環境出現了第一次的不可逆的大規模的數據型錯誤，記錄下來，以警后世
這是個很長的 Story，簡單的說
現在有個業務系統，主流程如下：
前方市場業務團隊提交 Work Request，后方業務團隊接收到 Work Request后，將其拆分為不同的子任務Task，並交付給不同的人員完成，所有的子Task完成后，Work Request則完成。
現在有個詳細邏輯如下，業務部門要求，Work Request 完成后，在第 N 天，Work Request需要被歸檔，所有Work Request所屬文件需要被刪除，非指定人員不可查看。
收到此需求后，我同業務部門進行了詳細的需求分析，明確了Work Request完成后的定義，即 Work Request 的所有子Task被完成的時候為Work Request 被完成，同時，最后一個Task完成的時間為此Work Request的完成時間。
將此需求轉給開發人員，開發人員進行了開發。具體的操作是，有一張流水表，用於記錄 Work Request的狀態變化，從創建，到被操作，等等，最后一條流水是 完成狀態流水。此由於需要判斷是否是最后一個Task完成才進行記錄。故稍微有一點點的邏輯在里面。
判斷N天后需要被設置為歸檔狀態根據流水表中被完成的流水進行判斷Work Request 完成時間進而進行推斷是否要刪除文件操作。
整個功能由2個開發人員完成，A 同事負責進行Work Request 流水記錄，B同事負責N天后的數據處理，經過一個測試人員C測試於11月份上線
今晚在進行數據檢查時發現。無一個WR被正常刪除文件操作，馬上進行了緊急的問題排查。
經過一系列排查，我們發現，A同事在Work Request 流水記錄的時候，把應該將 Work Request ID記錄在流水表中錯誤的寫入了Task ID。導致整個數據混亂。
詢問了一圈，
A同事表示自己已經在一周前就意識到此bug的存着並寄希望於本次功能上線可以修復數據
B同事表示自己在開發測試的時候使用的是修改數據庫數據，自己造假數據進行開發測試
C同事表示自己在測試階段僅通過修改數據庫數據進行了測試
以上是整個Story並且簡單的說無力吐槽。
反思此次重大事故。
首先是作為此次系統需求負責人，作為此功能，此系統的產品，未對完成的功能進行嚴格的驗收，也只是通過測試人員的反饋以及UAT人員的反饋進行判斷應該無問題並且同意了上線，此屬於不負責任的表現
其次是A同事，我們檢查了代碼，其代碼從最初寫的時候即存着錯誤，未正確的獲取Work Request ID,而是使用Task ID，這是最基本的需求要求都未達到，再發現此問題后，未及時上報進行緊急修復，任由事態發展，期間其反饋說有和Tech Leader反映此情況，暫無法查證是否屬實
再次是B同事，B同事在開發階段造數據無問題，沒毛病，但在聯調階段依舊通過造數據進行檢查判斷，此屬於不嚴謹，不負責的表現
最后是C同事，C同事作為測試工程師，未進行測試用例記錄，未進行最基本的正向流程模擬，通過修改數據庫進行測試，同時回顧的時候，我們發現即使通過修改數據庫也能發現問題，只有在非常粗心大意並且欠缺思考的情況修改數據才能忽略A同事犯的錯誤。但偏偏也被忽略。作為研發部門的最后一道防線，此屬於不嚴謹，不負責的表現
綜上，整個事件過程中，一共有4次機會我們可以去發現並阻止此次事故的發生，但一次機會我們都沒有把握住。有嚴重的失職，有嚴重的不嚴謹，有嚴重的不負責，作為產品，很自責，同時也在不停的提醒自己，以后不允許這樣的事件出現。同時也提醒同事，做事要有責任心。
最近心力憔悴，每天人肉運維，外有業務部門強敵，內有攻城獅困局。
產品這條路，回首看到的都是帶血的腳印