擔任產品經理這三年，從無到有製作的三個產品共賣出四千多萬。而這三年，產品的改版更是達到20多個版本，並且灑在二十幾家客戶機房內。
底下分享一些實務經驗：
- 如何保持可維運性
- 如何降低維運成本
- 如何規劃實作時需注意的地方
1.如何保持可維運性
平時紀錄要收集好
很多時候意見被反應到產品經理這邊，第一時間是沒有辦法立刻決定要怎麼做，平時實在太忙，需要一個記錄軟體把所有的需求給記錄下來，像我自己是用PivotTracker平時把意見先建立到列表，等排定的時間到了再一同看全部需求，且將這段時間維運、建置、使用者到維護的反饋，來決定哪些需求要排定下來。如果沒有這種ICE BOX來收集寶貴的回饋，是一定會忘記的。
2.如何降低維運成本
改版原則：讓現場更新人員好做事，降低後續維運成本
依照我產品的特性，因都在客戶端機房內所以作業環境是沒有網路，且需要人員實際到場。在這嚴苛環境中，改版需盡可能輕鬆且有標準SOP，以利現場作業能順利完成，不然損耗的是寶貴的人力資源，因此改版最重要的一點就是要讓第一線人員好做事。
要有一套標準的升版SOP
在規劃上要有一套標準的升版SOP，這仰賴架構規劃與程式設計師在一開始就把這件事情納入考量，有看過一些系統於每次更新版本時要做的事情都不一樣，為一些該版本特殊的tip需做，甚至全部都是tip。當然特殊tip有時無法避免，但應該降到最低，怎麼做下一步就會說。
在工具上可採用Docker把運行環境打包其來，讓環境標準化、可管理化，可以很有效降低維護管理與執行成本。
更版文件紀錄手動影響事項
大部分的版本應該避免讓開發人員做除了標準升版流程外的事情，但總會有幾個版本中某些變動需要手動調整，此時就需要在Readme裡獨立一個Section於更版時需要額外手動調整的事項列表，這樣做能讓現場部署人員更容易且清楚知道自己需要做哪些動作。
資料庫版本程式自己管，資料庫利用Upgrade Shell管理好Schema
資料庫的變動是一件嚴肅重要的事情，確保讓程式自己handel自己需要的版本，一種做法是把每個版本的變動寫成shell，並在程式執行時確保這些shell會被執行，如圖示：
絕對避免讓維運人員要自己去操作SQL，會做一些特製Shelll，這樣風險太高了。
能夠跨多版本升級，對外API需要向下相容，讓維運人員只要想著更新到最新版即可
我做的軟體產品有個特性，就是系統都灑在客戶的機房內，隨著建置時間的不同，版本會不一治。而通常情況客戶舊版本用的好好的，是不會想配合變更版本的，所以也不能透過日常維護去變更版本，而且這樣維護成本也會過高。所以可能的升級時間點就是客戶遇到新需求需要更版的時候，而最新版的時間點可能已經過了好幾版，所以要讓維運人員好做事，就是在每次版本更新時都注意要能夠從向下相容，讓維運人員只要負責一次就升級到最新版即可，比如從v1直接升級到v8。
更版文件紀錄已知問題
有些問題是已知但沒有排在該版本去解決，或是release後才發現的問題，這些都要補在Reademe裡面，如果有客戶反應有問題，維運人員去看Reademe就可以第一時間跟客戶說只要升版即可解決這個問題，或支援這個feature，這個已知問題的Section也是需要被獨立出來的。
READEME結構
所以綜合上述所說，每次釋出版本後READEME應該要有以下章節，重要性由高到低
- 版本資訊（如image id）
- 更新後需人員手動修改部分
- 已知問題
- ADD Feature、FIX Bug……
盡可能降低後續維運成本才是真本事
一套產品系統能否成功，長期能否維護是關鍵，而如果在設計上這個產品的維護與改版難度是成指數成長，很快的就必須要放棄這個產品，因為改版的成本已經大於帶來的效益了。所以這篇文章都只是在盡力做一件事，降低長期維運成本。產品系統才能活下來。