要上線一個系統，或更新一個系統的版本，首先最重要的就是系統穩定度。有些系統比如在銀行，上線後出了問題都是非常緊急的，一但系統上線開放給別人來使用，背後需要考慮的完善，才不會上線之後一直在救火救不完。
底下從底層的Exception的機制、Log的紀錄方式、整體功能的完整性驗證、系統如何維持總是不死的狀態，到最後如果還是發生持續性錯誤如何處理，依序來談談資訊系統上到Production前，需要先考慮到的議題。
底層的Exception機制
最重要就是有錯誤產生就一定要在程式碼有catch到，並請定義好這個狀況搭配的錯誤代碼為何。有時會看到工程師在catch裡面不做任何事情，這是不被允許的，一旦出了問題大家都一頭霧水無法在第一時間了解狀況，影響到處理問題的黃金時間。而設計系統架構時就把錯誤回傳方式定義好，比如以下例子，後端程式只要判斷result為0，就可以知道有錯誤產生，並且讀取errorCode做相對應的處理。
1 2 3 4 | |
Log的紀錄方式
Log最終是要拿來分析的，不管是程式分析還是人眼分析，都需要一個清楚固定的格式，尤其是第一時間往往要靠人眼去分析，這時候Log寫的工整與完整，絕對有助於除錯。一個好的格式必定要包含時間When，是誰Who，發生了什麼事What，錯誤代碼或錯誤訊息。
整體功能的完整性驗證與壓力測試
上線或更版之前，必定要做兩件事，功能性驗證與壓力測試。功能性驗證我常用的做法是寫自動測試，把所有預期狀況都寫成一個case，上線前的版本都要掃過並驗證功能正常。再來壓力測試就是測試針對大量併發連線，大量持續呼叫，服務是不是依然回應正常。
維持總是不死的狀態
服務如果持續回應，但是回應一樣的錯誤怎麼辦？這時候系統要能判讀錯誤並自我修復，比如re-try機制，如果socket連線斷掉等等，系統要能夠自我偵測並且主動重新連線。另一種狀況則是如果系統遇到fatal error，要使用守護進程，讓作業系統保護這個程式，一但偵測到結束訊號，要主動重啟服務。
如果還是發生持續性錯誤如何處理
第一時間要通知維運人員，常見做法是發送Email，並包含足夠的錯誤訊息資訊，如果環境開放一點的可以串接Slack API。因為這個時候已經發生系統沒有考慮到的狀況，才會導致服務停擺。第一時間常是手動重啟系統，再來看Log找錯誤，加入開發排程，緊急的話開一個Hotfix branch出來，修正後把錯誤的狀況寫入文件中把狀況、原因、如何處理寫清楚，避免再次發生。
不斷的進化的過程
如何開發一套系統能在各種狀況下穩定的提供服務，是需要開發團隊透過敏捷開發方式加上完善的文檔與強烈的責任感共同來達成，不是一個容易的目標但一但達成是非常有價值的經驗也能提供很高的自我成就感。以上僅是列出部分議題，還有更多HA機制比如多台互為備援等，等待日後去實踐。