功能上線 3 階段思考框架
不知道大家開發一項功能時，會怎麼思考讓它上線要做的事情？
我個人是使用「功能上線 3 階段思考框架（自稱）」幫助思考功能 1 個上線要做哪些事情，這個框架分為三個階段(如圖)：
- 上線前（黃色）
- 上線中（紅色）
- 上線後（藍色）
上線前的準備通常不外乎是列出研究的項目、開發時程、測試的範圍、準備上線後的驗證程序（例如驗證資料如預期般寫入資料庫）等等。
上線中則可能需要做一些即時監控，例如可以思考在這個階段，我們要注意伺服器的哪些數據可能產生變化，甚至影響服務的穩定性，值得注意的是這階段很容易有新舊並存的情況發生，舉多台後端伺服器為例，通常都是採用 rolling update 的部署方式，所以一定會有部份伺服器是執行新版程式，部分執行舊版的情況，包含 APP, 網頁前端都有這種現象。 上線後則是驗證功能如預期般正常執行，監控一段時間伺服器數據表現，以確定沒有重大問題，又或是發現問題之後可能要執行手動修正或 rollback 的情況。
這 3 個階段的思考框架能夠幫助我，有條理的羅列出我每個階段應該思考/做的工作，盡量確保事情的進行在可控的範圍。 多年的從業經驗告訴我，我們經常在上線後的階段思考不足，包含我自己也都很常會認為上線後就沒我的事了，所以很多時候會忽略執行事後驗證甚至是準備好 rollback 的標準程序，但墨菲定律告訴我們「會出錯的事肯定會有出錯的一天」，在出錯的時候，我們總是意外地毫無準備，所以災難處理才顯得那麼緊張、狼狽、手足無措。
另外，隨著前後端分離技術的盛行，這個思考框架也跟著產生交互作用。
舉後端 API 與前端介面分開上線的情況為例，因為這 2 者是無法達到 100% 的同步部署的，所以在思考框架上會出後端上線後，前端還沒上線完的情況，這時候 API 設計勢必要考慮新舊相容，否則會有部分使用者出現使用上問題，特別是 APP 使用者經常還是使用舊版本的情況，甚至無法做到所有使用者在同一時間都換成新介面，這就需要被考慮進去。
在有交互作用的情況下，個人經驗是最早開始的「上線中」階段與最晚的「上線中」結束這個時間段內，經常會有思考盲區出現，例如後端沒做 API 新舊相容，或是前端沒知會後端就先上線，或是後端爆炸時前端沒有做容錯處理等等，這些意外屢見不鮮，不過這些事情都可以在圖畫出來之後，就會比較好想像有哪些意外會發生。
以上，就是我個人常用的思考框架分享。
