做了兩年的產品運維系統開發， 積累了一點經驗和認識， 分享一下。
產品運維， 解決什么問題
1. 產品出現故障時， 如何快速診斷和解決問題， 快速響應客戶反饋與投訴？
2. 產品運行狀況是否透明是否可控， 是否能夠及時預防問題的發生？
3. 產品暴露的問題中， 哪些比較棘手難以診斷， 哪些處理起來非常麻煩耗時， 哪些常常出現， 由產品的什么BUG導致， 是否可以快速修復？ 如何從運維角度發現產品的不足並推進改進？
4. 產品關鍵指標的統計數據， 有什么規律？ 為什么會這樣？ 從中可以發現什么線索， 對產品下一步策略有什么支撐性依據？
產品運維的三個層面
1. 管理與操作層面： 產品資源與屬性的信息展示與查詢； 提供哪些操作恢復產品的正常使用；
2. 監控與預警層面： 產品運行的實時狀況， 透明度/健康度 評估， 預警；
3. 統計與決策側面： 通過對產品關鍵指標的統計， 發現規律， 更好地規划后續策略；
產品運維的具體工作
(1) 產品新特性的運維新需求。 產品新特性上線之后， 必定要對該新特性進行可用性運維， 同時要考慮與現有特性的兼容與聯接。比如雲磁盤上線后，對雲磁盤的管理不再依附於雲服務器， 需要新開一個雲磁盤的管理界面，一個快照管理的管理界面， 原有的磁盤快照管理也需要進行改造， 以適應本地磁盤與雲磁盤的兼容和混用。
(2) 適應項目變更，保證運維系統服務可用性。擁抱變化， 應對變化， 在產品發展過程中， 常常會進行多個項目來進行產品的改進， 這種情況下， 不會有大的關鍵的新特性上線， 但是會產生內部結構變更， 比如數據庫變更、依賴的外部系統服務的變更、線上環境變更等。 運維開發工作必須保持對這些變更的緊密關注， 緊密跟進， 才能保證不出差錯。
(3) 產品全方位監控視圖及資源屬性的關聯管理。 一方面， 通過監控來提升產品運行狀況的透明度， 使之逐漸可控； 另一方面， 需要逐步建立對產品健康度評估的標准， 能夠對產品當前狀態有一個基本的宏觀評定。
(4) 用戶體驗與故障處理、工單效率提升。 運維系統的用戶通常是技服、PE同學， 為他們提供有力的工具來診斷問題、解決問題， 從而更快地響應客戶反饋， 對公司信譽有非常重要的間接影響力。 因此， 運維系統也需要進行仔細設計， 保證知識與操作的准確性、響應的流暢性、 操作流設計的適應性。
知識與操作的准確性， 是指技服\PE同學執行某個操作時，明確知道該操作做了什么事情，而且確實只做了這個事情，不多也不少； 響應的流暢性是指， 系統的響應必須稍快於人的操作速度和心理需求， 在該快速返回的時候不能阻塞， 在該緩的時候不要反應過敏， 導致用戶誤操作； 操作流設計的適應性是指， 操作流的設計必須非常便捷地切合問題的解決， 而不僅僅是提供了所需的功能， 但用戶需要解決問題要多個地方跳轉和切換， 影響效率。
(5) 從臨時需求中挖掘問題和需求點。比如售后工程師不定時會提出一些臨時需求， 這些需求往往需要快速便捷地響應， 而不能等待到發布。從重復性的臨時需求中挖掘問題和需求點， 添加到運維系統的功能集中， 也是運維工作的一個重要方面。 比如， 售后工程師不時會需要獲取批量雲服務器的用戶賬號， 而當前系統中僅提供了查看單台服務器的賬號信息。這可以形成一個需求點。
(6) 消除重復性的困擾。 有些功能設計不恰當會導致重復性的困擾。比如黑洞清洗操作中， 右側顯示的是該雲服務器所在NC上的所有雲服務器的攻擊記錄。 不止一次有同學反映右側攻擊記錄的IP為什么跟左側該雲服務器的不一致， 會產生困惑是不是查錯了。 實際上， 右側這個顯示實在應該放在 NC 視圖中， 放在這里為了方便， 但給不知情者造成了困擾。
(7) 運維工作標准與檢驗的逐步建立。 更准， 更好， 更高效！ 這永遠是運維工作的格言和座右銘。需要逐步建立一套運維標准， 來檢驗當前運維工作的等級。 比如， 接到問題的響應時間（不一定解決，但一定要先響應， 類似異步接口）， 定位原因的響應時間， 解決問題的響應時間； 故障時長； 是否檢測出產品的重要缺陷； 運維工作流程；故障處理記錄與REVIEW 等；
(8) 瑣碎事項的規范化處理。 經常會有一些瑣碎的事情需要處理， 而且還很容易為此耗費時間。 比如， 開發需要訂正數據庫； 新入項目和團隊需要申請各種權限等。 對於前者， 是否可以通過更好的技術來解決， 對於后者， 是否可以指派專人來進行申請， 申請人只需要提交申請哪些權限即可； 此外， 不同級別的開發/測試/技服/PE/業務支持 等角色各需要哪些權限， 是否可以有一些表格和標准可以參考， 而不是零碎地靠個人多次問詢多次去完成。