日常問題：上線確認

作為開發，手頭沒事的時候，擔心自己沒參與大專案，年終沒產出。而真正需求到來的時候，卻是狂風暴雨一般，密集且時間緊迫。在緊鑼密鼓996之後，終於迎來了上線。但這一天不太順利。

背景

xxx正式上線。上線前，方案強調要開發把所有設定都給到他，他要確認下。當時覺得有問題，開發的設定幹嘛要給到他們。

開始正式驗證資料的時候，第一個介面就404了。於是所有人都突然黑人問號了。客戶心情瞬間不信任了。問這邊啥情況。這邊說需要調查。出問題模組的小組正在開會。又說不是變更時間段，要晚上9點後才可以做變更。客戶當場不幹了。於是老闆們都加入了會議。

壓力之下，問題還需要一步步定位。半小時後確認是香港代理節點沒設定轉發。原方案設計是北美存取香港，香港代理到深圳。深圳這邊倒是都設定好了。結果忘記香港代理設定了。

很快問題修復。流程可以繼續驗證了。但客戶的信任出現了裂痕，他認為我們的系統不敢完全相信。之所以要各種設定方案，測試方案，就是前期合作中也多次出現過問題。所以客戶在要求提供各種開發相關的資料，以此來證明我們做好了。這才明白為啥業務方會要我們開發設計的細節設定了。

後續還有更多流程，更多設定。於是大家自己也不敢保證沒問題了。又開始拉著checklist檢查清單挨著對。網路也挨著ping telnet。颱風天，還是搞到很晚。

回家後，同事接到電話要求第二天8點前到公司，因為有個功能是早上8點的。提前做好準備。然後他也想再確認下設定有沒有問題。於是發現該服務sftp請求的地址網路不通。又是黑人問號臉。好像是沒有開牆？於是，大晚上打值班的運維電話讓幫忙開通網路。

第二天，他很早到公司。8點了，檢視具體情況，截圖實際驗證結果。

結果，說內容不對。

客戶也發現問題了。

現在也不知道檔案是誰放上去的。

最後確定是測試環境的檔案。沒查出個結果。

負責檔案的小組說，早就是讓xxx客戶改密碼了，他們沒改。問客戶，客戶說他們沒放檔案。而我們這邊也都說沒。也沒辦法調查，因為機器環境在客戶那裡。

還好之前有設計異常方案，通過其他渠道修改了檔案設定。至於檔案究竟是誰放的，我們只能猜測是客戶自己的人搞的。但他們否認，我們也無法舉證。只能繼續驗證了。

中午去肯德基吃飯。吃到一半，打電話過來。xxx報錯了。於是趕緊排隊等電梯回去檢視。測試根據報錯，確認是建立人欄位超長了(還好把錯誤一路傳到了前端)。看下設定，資料庫表中建立人欄位長度是10位？哦，當時可能按工號設計的，結果使用者是外國人，拿手機號當做使用者名稱了。

打電話給運維，改。

改的時候也有點曲折，客戶現場等，問需要多久，開發回方案說5分鐘，方案回客戶10分鐘。結果6分鐘的時候，開發還沒改好指令碼。著急的時候越容易出錯，他自己在寫sql。我旁邊看著，想，如果是我，我會用工具修改生成sql後，複製。

在客戶催了2遍後，改完了。然後流程回滾，重新驗證。(還好，之前設計的方案支援錯誤中斷回滾，否則只能運維改資料了)

到這裡，還沒驗證完，但是，陸陸續續出現不少問題了。

最後，上線方案要設計驗證方案。總不能拿客戶當測試。破裂的信任，要想修好，需要付出更多的努力。