通宵的網頁服務上版經驗

今年6月，上半年開發的專案驗收進入尾聲，接著就是正式更新到線上環境替換掉現有的服務了。

一般來講，為了避免影響使用者操作以及產生客訴，較小的版本更新會挑晚上或假日時間，當更新範圍較大，預期需要比較多的時間，甚至不確定時長的時候，會提前發出公告：「本服務將於O月O日(五) 18:00~20:00暫停服務」並且在這段時間關閉對外連線，再根據更新情況決定要延後或提前開放時間。

而這次更新是用全新的程式替換掉原本正在運作的程式，包含資料庫種類、結構，甚至防火牆設定都有修改，因此還需要其他部門的配合，甚至與我方服務有關聯的服務商也需要確認換上新版程式之後他們的服務是否正常，比一般的大型更新範圍更廣，因此公告的停止對外公開時間從星期五當天的晚上十點到星期天的中午十二點，理想上在這段時間內完成更新以及確認就算大功告成。

「雖然說時間是這樣定的，但是我們當然堅持不了那麼久，如果一切順利的話大概早上十點就該完成了吧。」前輩是這樣說的。

事實上，如果星期六中午之前沒完成的話，我個人也是挺困擾的。

為了確保晚上的活力，星期五白天不用上班，晚上七點再到公司集合就行。

在前幾天，團隊內部就訂好了當天的執行步驟以及分工。在新的機器上安裝程式並修改設定檔、將控制外部連線導向到哪些機器的導連伺服器設定檔換掉、確定防火牆設定、更換網站憑證的資料與格式......像是這類的項目都已經列好由誰執行，應該在幾點前完成等資訊了。

由我負責執行的部分在事前先收集了可能的執行步驟，以及需要使用到的資料，在執行過程中再記錄實際實行的步驟，以及當下的執行進度。
這點是我個人的習慣，讓其他人得以掌握我的執行狀況，也能幫我記住執行方法，以後可以參考。

過了十點開始把舊資料庫的資料倒出，搬移到新資料庫上，重啟新的機器連接到新的資料庫，確認連線狀況以及其他設定正常，都完成就可以開始測試了。
(雖然這段說起來很容易，但是受到資料量以及其他因素影響，實際啟動完成可以測試已經是三點之後了。)

由於這次更新的目的是更換程式裡的邏輯，並維持原本輸入輸出的資料格式，因此串接服務商須要確認的項目就只有「他們連接舊服務的方式，是否也能正常連上新服務，而且拿到一樣的資料？」

聽起來是很簡單的工作，但是期間發現的問題比想像中的多更多。

關於這種規則沒對齊舊程式的錯誤，最容易想到的發生原因就是我們這些工程師寫程式時沒有看清楚規格文件或舊程式邏輯導致，但實際上為了當天的更新正常，除了認真確認程式邏輯之外，寫完程式後通常會用自己想得到的情境簡單測試過，確認是否正常。

舉個例子是我開發的某個功能，舊程式邏輯有段邏輯：「取得輸入欄位『status』的值，如果不存在就取輸入欄位『Status』的值。」就差一個開頭大寫的字母，為了配合各種可能使用的服務商，我在新版程式也相容了這種規格。

然而人的想像力是有限的，我只能保證把接觸到、考慮過會出事的情況做處理，還有多少意外會發生完全無法預測。

許多情況是超出文件規範，連接舊程式的時候文件指明要用A方法連接，但是當時的服務商發現BCD方法也能連的上，因此就這麼用了。到我們的新版程式照著文件規範只接受A方法連接，然後服務商們就來靠北了，「以前這樣都沒問題現在就不行了，是不是你們程式有問題？」
照著說明書操作有那麼不容易嗎？當時的服務商工程師？？

當然不只是服務商的錯，舊程式的開發商也大有問題，這不是「為什麼他們要設定可以收BCD方法的連線？」而是「他們使用的技術如果沒特別限制別說是BCD，EFG來了也會收。」
明明是2020年開發的程式，為什麼比我在公司新人訓寫的，超過五年沒更新的題目，使用的技術還要落後啊？？

以上抱怨歸抱怨，問題還是要解決的。服務連不上無法正常運作，該由誰調整呢？答案是改起來比較快的人，也就是我們這些正在上版中的工程師。

這不是「怎麼樣才是對的」，而是「怎麼樣才能看起來是對的」，服務商來不及改又需要在時間內修正提供服務，只好由我們修改程式，暫時遷就這些奇怪的用法(有些直到這篇文章打字的當下依然在遷就中)，後續再請服務商修正為標準規格。

修正的期間天就亮了。

我個人也有過幾次通霄的經驗，但像這樣全程處理工作認真動腦到天亮還真是第一次。大約到了七點的時候，我的精神非常好，完全不想睡覺，但是同時清楚的認知到自己的思考速度越來越慢，理解力越來越差，同事拿著菜單來問要點什麼早餐還花了大約5秒才認知到菜單是什麼並開始閱讀。

最後團隊在星期六的下午四點左右解散，之後申請的加班除了加班費之外還有額外獎金和一天的補休，雖然還不錯但是這種奇妙的狀態還是不要體驗太多次比較好，感覺會變笨。

要說從這次經驗得到什麼心得，首先是每個環節都應該多準備一些意外情況的發想和處理方式，後續也把這些事記錄下來，作為事後檢討和未來其他專案的參考，知道之前的做法和發生的問題再實際改進，如果公司內有系統的整理這些經驗絕對會很有幫助。

另一項是寫程式的時候真的要分清楚該做和不該做的事，每一次修改到底會使整個專案變好還是變糟，程式的規格和文件的規格應該要相等而不是抱持著「反正只要照著文件是正常的就好」而讓程式功能大於等於文件，接手的人真的很痛苦，常常會對程式邊看邊罵喔。