至暗時刻——記某項目的悲慘經歷

最近作了個項目，上線以後依次發現了三個線上bug，簡直是我入職以來史無前例之事。感受真的要被開除了。在此還原下整個項目的歷程，但願能記錄項目管理中失誤的點，從而再也不次出現錯誤。

1. 項目背景

1.1 參與者

1.2 項目時間線

• 4月13日 項目需求預討論，定下了插件合做方A開發UI渲染，我方提供數據支持和上報的邏輯。
• 4月17日 決定與廣告商C方的應用邏輯，定下了經過referer肯定廣告來源的方案。
• 5月25日 A方人員變更，廣告被無限期延期，A方同時提出改版廣告渲染邏輯，由我方提供廣告組件庫，全面接盤廣告渲染的方案。
• 5月30日 我方開發完成。A方臨時有更高優先級需求，沒有時間排期，聯調時間被一拖再拖。
• 6月1日 C方接入聯調，發現C方服務器是http連接，referer方案被迫改成url參數方案。C方一直想跑通全鏈路聯調，可是由於廣告後臺測試服務器不支持外網訪問，測試鏈路一直不通，必需要用截單方式。雙方交流困難。
• 6月7日 AB方初步聯調完成，廣告初步展現，可是A方還要改造廣告相關插入邏輯。另外C方繼續溝通緩慢，BC方聯調完成，可是BD雙方還要聯調
• 6月11日 A方仍是沒有排期，計劃6月15-20日聯調
• 6月15日 AB方聯調完成，C方仍是開發中
• 6月20日 BD雙方聯調完成，約定6月21日上線
• 6月21日 C方發如今某些機型上返回文案過長會被隱藏，臨時修改，致使上線時間改成6月25日
• 6月25日 A方拖到晚上才上線，並且同時上線了手Q 70%-90%灰度和微信應用直達兩個終端兩個需求，B方沒有意識到這兩個需求會產生衝突，上線後手Q流量暴降，線上回退
• 6月26日 B方緊急修復了手Q邏輯，A方從新上線，上線後發現廣告沒法點擊，經查是CGI跨域，再次回退。
• 6月27日 發現線上有IOS低版本廣告圖片展現不出來，經查是css兼容問題，再次上線。

2 項目中出現的問題

產品側：

• 多方合做時間點沒有把控好，持續時間太長，拖掉了全部buff時間

開發側：

• 沒有進行全鏈路測試就匆忙上線了

項目的質量永遠是第一位的，上線以後回退仍是趕不上時間點。要儘可能進行全鏈路測試，充分明確全鏈路測試的必要性。

• 沒有進行總體的謹慎的思考，未了解到多端衝突的問題

項目開發前就要仔細考慮會影響的狀況，儘管此次手Q和微信的衝突更多的是須要A方的同窗提醒。可是最好也能考慮到

• 項目中的問題沒有引發警醒

曾考慮到會有跨域問題，可是沒有去確認，也沒有及時提醒測試同窗注意。而測試同窗由於要截單的緣故，在fiddler裏設置了跨域頭，略過了這個問題。

H5前端的幾個經典坑：跨域，緩存和兼容性

把fidder截單加上判斷條件，防止其餘跨域被忽略。

static function OnBeforeResponse(oSession: Session) {
        if (m_Hide304s && oSession.responseCode == 304) {
            oSession["ui-hide"] = "true";
        }
        // 添加跨域條件
        if (oSession.host.Contains("news.ssp.qq.com")) {
         oSession.oResponse["Access-Control-Allow-Origin"] =  "http://test.view.inews.qq.com";
         oSession.oResponse["Access-Control-Allow-Credentials"] = true;
        }
    }

• 測試同窗提出過兼容問題，可是沒有引發足夠的重視

測試同窗口頭提過某個機型上廣告圖片沒有展現的問題，確認過是否必現，可是錯誤的將必現聽成了偶現（我勒個去，這也能聽錯？！）因此覺得是網絡慢的緣由，沒有引發重視。

結果是flex引發子節點height:100%失效，致使圖片的高度永遠是0，這個問題如今只會在IOS10及如下的機型上出現，PC和Android（4.3以上）都表現良好。

仍是要測試同窗嚴格提測試單，同時重視測試同窗提出的任何一個疑點。

3 總結

這件事情上，我總結了一下項目是否要出現問題的特徵：

1. bug單上一個bug也沒有
2. 項目嚴重延期
3. 合做方衆多且聯調困難
4. 全部人都對項目有盲目的樂觀

只要有以上的狀況，項目多半是有問題沒有測試到的。此次的責任主要在我，沒有提早作好預警。想我剛入職的時候，老leader反覆和我說：作項目未慮勝先慮敗，作以前先想一想哪裏最容易出錯。怎麼幹了這麼多年，反而忘記了這個告誡。仍是太不當心了。

從業4年，沒這麼慘過，回退一次都算事故，他妹的回退了兩次，上線了三次，實在是慘絕人寰……

而後我扔掉了個人小豬佩奇，換了個新玩偶，但願能帶來好運吧

4 後記

2018-06-29日 20:30分 我在開車去往杭州的高速上，微信羣裏又叫起來了，說是有一個線上bug，會致使廣告商C方沒有點擊數據。我獲得這個消息的時候，我就在想，要是真的是個人鍋，否則辭職算了。原本歡度週末的心情瞬間變得異常的糟糕，可是我又轉念一想，線上出事故總比出車禍強。而後在嘉興服務區，我強勢接管了剛開了一小半的bug排查溝通會，當時的想法也很簡單，死就死的有尊嚴一點——確實由於出了太多的事，已經不敢隨意的甩鍋了。謝天謝地，最後是廣告後臺D的問題。

沒想到還有不少小夥伴關注了這篇文章並給了我安慰，謝謝。這些都是自由水啊，說明其實項目管理也是你們在平常工做中很關注的一個點。針對這個問題，正文中還少提了幾個點：

4.1 技術影響力的塑造

其實項目出現了不少問題，我最難過的，是技術影響力的崩塌。建一座大廈可能須要幾年，毀掉它只要一瞬間。咱們用了大半年的時間，剛剛培養了一點技術影響力，就在此次被摧毀的一乾二淨，並且這個後遺症可能還要延續好久。這也是我爲何萌生辭職念頭的緣由。真的很難過。

4.2 分分這個項目的鍋

事情也過去幾天了，這時候再來分鍋應該算是心平氣和了吧。首先，全部人都有鍋，這是確定的。

開發做爲技術方案的具體實現者，佔大鍋也沒問題。測試同窗也有鍋，可是鑑於新入職，開發同窗又強勢，擔鍋比例應該適當減小。產品同窗在時間點把控、項目統籌上要承擔主要責任。