產品經理歷險記-1-記錄一次事故

距離上一次發博客已近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次機會咱們能夠去發現並阻止這次事故的發生，但一次機會咱們都沒有把握住。有嚴重的失職，有嚴重的不嚴謹，有嚴重的不負責，做爲產品，很自責，同時也在不停的提醒本身，之後不容許這樣的事件出現。同時也提醒同事，作事要有責任心。

最近心力憔悴，天天人肉運維，外有業務部門強敵，內有攻城獅困局。

產品這條路，回首看到的都是帶血的腳印