2019年08月09日，上海受台風利奇馬的影響，晚間狂風大雨。
臨下班，合作渠道WB在微信群里報告線上生產事故問題：趕快扒日志看記錄，日志顯示一切正常，看不出bug在哪里，WB聲稱並未接收到我方CI的回調請求。晚七點多，肚子已經餓了，給WB說，看日志CI沒啥問題，先撤了。
在出公司大樓經過一個拐角的時候，隱隱感覺這情形代碼里的配置項會不會有問題，心里很是忐忑，冒雨又折回。重新打開電腦，再捋一遍代碼的時候，bug像一道匕首直刺心頭：卧槽，這個路徑竟然還是測試環境 的路徑！項目組是公司敏捷開發團隊，每周五都會有生產版本發布，趕快給負責版本控制的同事打招呼，等一下，搭個順風車。
在確定了配置路徑有問題之后：亟待明確的是服務間調用是走內網還是走外網，要不要NG轉發，走不走esb，是不是要申請通信權限。簡單描述一下WB的該次請求：WB請求CI的NG--------》NG轉發到CI的Mule服務----------》Mule服務調用Gateway----------》Gateway轉發至應用微服務Application ---------》Application服務響應之后執行異步回調Mule服務---------》Mule服務請求WB接口地址 。中間涉及的防火牆和權限就暫且忽略，目前的問題點是：Application服務響應之后執行異步回調Mule服務，這個Mule服務內部接口地址規范是什么，會負責系統維護的同事一番確認后，決定走內網Mulef5，這個時間點負責維護配置中心的同事已經下班了，當務之急硬編碼的方法先上了。
九點多回到家，覺得有必要復盤一下為什么會遺留這種bug，2018年11月份進入CI公司的敏捷開發團隊。剛入司時對敏捷開發基本不了解，后來才發現這是一種近乎流水線的開發模式。作為開發可以說是一個不停機的多線程，從一個合作業務開發要介入需求溝通、網絡申請、防火牆權限申請、配置維護、數據維護、多環境測試聯調、線上支持。每天被各種合作群微信轟炸，有時候盯着開發文檔和需求分析文檔去盤問需求的正確性 ，有時候也不得不去應答一些需求和業務上的問題，開發思路很容易中斷。對於單個的合作渠道追求對接速度快，省略了各種文檔和單元測試，缺少代碼的復核和管理。快速迭代，線上支持，這種公司層面的情況是短期沒辦法改善的，在這種工作模式下，應該梳理出標准的工作流程模式，嚴格按照流程模式在上線之前去復核，才能避免易忽視的小問題。
以WB案例來說：
階段一：談合作階段
前期CI分公司業務人員與WB達成合作意向，確定合作產品方向。
階段二：談需求階段
CI需求人員介入，通過溝通和場景分析，參考WB合作接口文檔，分析CI接口映射關系、業務字段關聯，草擬一份需求分析文檔供開發測試用。
階段三：方案確定階段
此階段開發人員已經開始開發，開發對需求分析文檔中的一些問題會和WB方開發和CI方需求及業務人員確認，此階段開發人員主要解決加密解密、加簽驗簽，測試環境申請。CI業務人員明確WB合作方案和WB合作機構信息，CI業務人員同步方案和機構信息至測試系統。
階段四：開發者開發階段
此階段大致分三板塊：第一，Mule開發；第二，應用開發；第三，配置項維護。
階段五：測試聯調階段
此階段開發負責環境雙方網絡權限，Ng轉發路徑，Api訪問權限的開通，相關數據維護。測試人員介入進行本地測試，本地測試通過，WB方介入聯調。
階段六：生產環境准備階段
測試環境和生產環境在網絡權限和防火牆控制有很大差別，主要是權限和參數維護。應按流程梳理各個環節權限是否開通，各參數和WB提供生產參數是否有出入。確認無誤，進行上線。