關于項目，有一個定義是：項目是創造獨特產品、服務或其他成果的一次性工作任務。

項目并非實現產品經理的需求就完事了。 當項目投產后，在用戶使用的過程中，會遇到千姿百態的問題。相當長的一段時間里，開發人員可能會疲于應付處理這樣的問題。 運維一個應用系統不容易呀，那么，為什么會投入這么多時間呢？可能包括用戶對業務邏輯的不夠清楚，包括程序實現的bug，包括邏輯的復雜，包括線上運行過程中突發的事故。 而這些，往往并不在產品經理的需求范疇里， 所以，在系統實現方面，還應考慮應用系統的運維功能，包括：

監控

系統在運行過程中，難免會因為服務器問題或網絡問題導致掛了， 所以，存活性監控是必不可少的。

業務監控：比如短信平臺出現過被惡意攻擊的情況，客戶通過代理偽造了很多的手機號和IP最終觸發了我們的短信通知。 像這種情況，應該做一個監控，如果某段時間里短信下發量突然暴增，就要告警并給予關注了。

我曾有一篇監控的文章《Promise計算模塊驗證和監控》。

當然，性能監控是更高階的要求了，比如系統吞吐量（TPS）、TP99指標；服務器的disk io、cpu、memory、net io監控不在話題內，略過。

運營支持工具

以差旅訂單通知系統為例，客戶反映，說你系統出現問題了，你開始向客戶索要相關信息，然后排查程序，寫一大堆的sql，這樣一來，個把小時過去了，你終于把客戶的問題解決了。

再以審批系統為例，客服找你，說某個訂單，客人手機出問題了無法通過短信審批，你幫忙改下訂單的審批狀態吧。你開始寫sql，改審批單狀態，改訂單狀態，然后，向領導申請，找運維人員在生產環境執行sql。然后，告知客服改好了，客服再告知客人。這樣一來，估計快也得半小時。

初看起來，處理系統問題，不就是這么回事嘛。 ?作為一名項目管理者，我喜歡從成本和績效的角度考慮，這種處理問題的方式，首先浪費了開發人員的時間，而且這種重復性的工作并不能產生多少業績，所以一些程序員喜歡抱怨自己的工作無聊也不足為怪。其次呢，如果程序員手頭又在參與新的項目，這會令他們無法專注于眼下的工作，事兒多容易亂。那么，我們就要想法對這樣的工作say goodbye！ 運營支持工具就派上用場了，以上面的幫助客服修改訂單審批狀態為例，開發一個這樣的工具，當客戶再有這樣的需求時，一個文本框一個按鈕就搞定了（條件可以的話，把這個工具交給客服操作，我們程序員就解放了）。

從全局的角度看，這樣也節省了客服的工作效率。她們會感謝你的。

運營手冊

系統在使用過程中會出現各種你想不到的問題，

即使前期的需求做的多么完美（實際情況下，多數的產品設計出來的需求，在投產后，很多的問題是產品事先沒有考慮到的）。

技術方面，用戶異常輸入致使字段類型長度不夠、static的誤用、內存的泄露、nullpointerexception。。。等等，無法避免。

不斷的迭代，回歸測試不足是常態，導致新功能滿足了原有功能遭殃了。

好腦袋不如爛筆頭。我們需要一個系統運營手冊，以日歷的形式記錄日常出現的問題，常見的原因，解決方案，或者需業務上哪些人給予協助。 遇到過的技術問題和技術解決方案。同樣，記錄備忘性的內容，比如依賴的上下游系統的接口、聯系人。

要說明的是，對于團隊項目，這些文檔要放到svn等版本管理工具里，大家共享共同更新。

溫故而知新。運營手冊不是整理完了就放那兒不管了，要定期review，對常見的運維內容，提煉出共性，作為新的需求來有針對性的進一步升級系統，如此以來，問題將會逐漸變少，并能hold住。

BTW，如果系統易主，這對于接管的團隊來說，是非常寶貴的資源。

異常錯誤檢測和補償

一個定時跑批服務，可能會因為服務器異常，導致某次該跑但未跑。

一個批處理程序，可能因為某條記錄的“非法”數據，導致漏掉了該條記錄的處理。

涉及到完整的業務流程處理的，可能會因為事務得不到很好的控制，而導致數據不一致。 同樣，對于分布式系統，數據不一致更常見。

以上情況，在系統運行過程中，我們一定會遇到。 我們要對系統的這些異常數據進行檢測，檢測是手段，檢測不是目的，目的是要將數據調整過來，不一致的調成一致，缺失的數據想辦法補充或直接廢除。

通過以上方面的努力，我想，運維一個應用系統將會變得更容易！同時，我們得以解放出來，去專注于更多的工作。 拙文寫的比較糙，還有更多更好的實踐方案還需再積累，也期待和大家一起交流。