運維工作是專案工作的延續，是公司專案管理系統中的最後一環。接手運維工作也有一段時間了，遇見過各種各樣的客戶，處理過各種各樣的問題。在解決問題的過程中，發現每類專案都會有相似的問題出現，比如安全漏洞問題、後續系統接入的協助問題、產品出現bug等等，每一類問題都有它對應的解決方式和注意事項。
本文將對運維工作中常見的問題進行分類，並總結常用的解決辦法和注意事項，同時為制定運維管理制度提供思路以及解決辦法。
與一般工作相比，運維工作的特別在於突發性、時間不規律性和緊迫性。
運維工作通常是出現問題後由客戶反饋而來的，問題都是突然發生的且沒有預兆，那麼出現問題的時間就更是不確定不規律了，即便是執行了一段時間的系統，也可能突然觸發一些未知的bug，由於這些bug會影響到生產環境，也就體現了運維工作的緊迫性。
由於是生產環境，每次公升級替換都需要在客戶使用頻率低的時候進行調整，通常是週末或者半夜，因此熬夜加班也是運維工作必然要面臨的挑戰。
專案運維的目的要從兩個層面來理解，一方面專案運維是專案實施的必要環節，開始於專案上線確認之後，截止於公司與甲方的合作終止，主要是為了延續專案價值，保障收款，積累產品經驗等等；另一方面是保持與客戶的溝通協作，為後續專案的持續開展提供基礎，同時工作中的一些成果可以考慮作為人天抵扣到後續專案中。
對待客戶要注意能夠解決的事情要盡快解決，當下不能解決的事情要做好工作排期，對客戶生產環境影響大的問題，要第一時間反饋給公司領導尋求資源，同時做好客戶的安撫工作。
由於運維人員對於程式的把握未必是那麼到位的，很多時候需要記錄問題並尋求資源。運維工作需要的詳細記錄包括提報時間、問題型別、解決耗時及互動人等等，一些影響比較大的問題，要做情況說明，記錄當時的事情經過，改動事項等等，這些都會為後續的運維以及產品改進提供思路。
在運維過程中，客戶主要問題分為兩類，諮詢類的問題主要是客戶在產品的基礎使用以及特定業務場景的靈活使用上遇到的問題；產品bug報修類的問題根據產生bug的原因可分為操作問題、環境問題和產品問題等等。
此類問題在專案交付之初比較常見，以產品的基礎使用為主，也有一些是新業務場景不知道如何適配。在這個階段，客戶通常只有對場景的描述或者是思路，需要我們據此給出具體的解決方案。
這個階段對於公司的價值體現在擴充套件產品的業務適應性，記錄下產品適用的主要業務場景以及各類業務場景的解決方案，在宣講時可以作為問題提問宣講人。
由於公司承接的大多是整合類專案，因此很多時候是以運維作為中轉的核心，因此當有新系統接入或者是第三方系統改造時，需要運維協助提供資料或技術支援。
在這個階段對於公司的價值主要是掌握、驗證第三方對接的技術，提公升水平。
這類問題伴隨專案運維的整個週期，產品bug類問題與產品改造類問題非常相似，很多時候產品改造本質上就是對bug進行處理，這裡要注意的是，對於專案問題只做專案級調整，產品級調整要根據公司的戰略來執行。
在這個階段對於公司的價值主要是測試產品bug，修復產品，提公升效能。
產品改造類要區分於產品bug類的是，產品改造類主要是客戶針對實際場景，對於產品提出了新的需求。產品改造類問題的解決通常是在與客戶需求確認過程中，提出替代性的解決方案，通過簡單的開發來實現的。
在這個階段對於公司的價值主要是擴充套件產品功能，提取整合需求，為後續產品公升級迭代提供方向。
雖然運維問題多種多樣，但是每一類都有比較通用的處理方法和注意事項。整體的問題處理要把握乙個原則，影響客戶當前使用的一定要優先改。客戶諮詢的問題，給出的答覆要需求擴大化；客戶提出需要後續協助，能給方案的就先不要自己動手；產品改進類的問題，收集意見及時反饋，盡量不要做調整。
諮詢類問題預設為高優先順序，因為是即問即答的形式，解決的基本點是指導客戶工作，而不是參與具體工作。
同時需要注意的是，專案運維階段不是專案實施階段，對客戶的想法要適當予以婉拒。如果全盤接收，諮詢類問題就很容易變為改造類問題，在運維階段實施產品改造，如果沒有後續專案落地，通常是難以收取費用的，因此要特別注意。
協助類問題預設為中優先順序，解決的基本點是客戶要有明確的工作意向和思路，我方只是參與部分工作，即我方不是工作的主導部門。
專案協助類常見的問題有專案上線後第三方系統接入、部分專案資料的索取、第三方系統出現問題協助定位等。處理這類問題時要注意，有了結果要第一時間通知客戶，以便客戶可以繼續推動後續工作的開展。
產品bug類問題預設為中優先順序，其中影響客戶登入的問題，預設優先順序是高。解決的基本點是先恢復後修復，一定要保證客戶能夠正常使用，哪怕是通過遮蔽功能的方式，也要先保證客戶的使用，後續再進行調整。
對於產品bug類問題的即時修復手段主要有遮蔽頁面功能、調整資料庫資料（修改人員狀態）、集群改單機等等，後續要有跟進和落實，針對bug要制定解決方案，審核通過後再進行修改，修改內容及方案要統一在svn留存。
產品改造類問題預設為低優先順序，原則上已驗收專案不做產品改造，如果有重大安全隱患或者客戶比較重要，可以考慮進行產品改造。
產品改造一般是要有商務參與的，但是這部分工作不需要運維人員來考慮，唯一需要考慮的是，改造是專案級改造還是產品統一公升級，相關的實施辦法與bug修改要一致。
上述問題解決的過程中，一定要保持適當頻度的匯報，匯報的物件主要是運維負責人和公司領導。具體包括日常匯報和重點匯報，日常匯報是定期對運維工作的匯報，重點匯報是對高優先順序內容的匯報，以及涉及商務問題的請示。
日常匯報分為日匯報和周匯報，日匯報有專人負責，每天統計運維情況，整理成excel進行匯報，周匯報是對一周內運維情況的總結，針對運維中的重大事宜，要在會議穿透時進行匯報，包括當前的解決進度、解決方法、解決過程是否有突發情況等。
此外，計畫定期對專案運維進行一次核定，初步計畫是每季度一次，包括對專案運維等級的評定、專案運維情況統計、產品問題反饋等等，具體的匯報格式尚未確定。
緊急匯報是針對兩種情況，一是影響客戶使用的，沒有替代方法且自己難以解決；二是對客戶影響較大的，比如單點登入異常、系統無法登入等等。
緊急匯報主要是申請資源，請求協助解決問題，因此一定要快速、簡潔、準確地反饋問題。在解決問題後，要向協助人員反饋問題已解決。對於解決問題的過程要有記錄，記入重點匯報的工作中。
重點匯報是對高優先順序內容的匯報，必須及時通知到運維負責人及公司領導。例如客戶門戶登入異常、業務整合同步中斷、客戶有新的需求需要商務溝通等等。對於修復過程超過0.5天的重點問題，要給出書面記錄，記錄修復過程以及解決方案，上傳至svn作為備忘。
專案運維工作是專案實施不可或缺的步驟，想要做好運維工作就一定要做到有章可循，這就需要大量的工作積累。由於出現的問題大多在生產環境，要求運維人員快速、準確地定位問題，這就導致運維工作交接困難，新的運維人員往往需要一段時間才能適應。不斷地總結、分類、梳理運維問題，可以使運維工作在交接的過程中非常順利，也可以保證專案後續跟進時，實施人員對專案有充分的理解。
IBMMQ運維常見問題
目錄 1.錯誤日誌 2.日誌檔案 3.常用排障方法 4.常見問題 websphere mq 使用許多錯誤日誌來捕捉websphere mq自身的操作 任何佇列管理器的啟動和正在使用的通道的錯誤資訊。錯誤日誌的位置取決於佇列管理器名，以及錯誤是否與客戶機相關。在 websphere mq window...
RocketMQ系列 四 運維常見問題
1 rocketmq生產端和消費端版本不一致導致不能正常消費的問題 問題描述 同乙個生產端發出訊息，a消費端可消費，b消費端卻無法消費，rocketmq console 現 not found the consumer group consume stats,because return offse...
linux 常見問題及解決
平時開發中需要連線到虛擬機器linux centos 進行，期間有些常見問題，在此記錄備忘 1 ssh連線突然變慢，在centos中ping一些常見 也特別慢 分析 估計dns解析有問題，檢視vm中的 etc resolv.conf 與本機dns差異，發現第乙個備用dns不同。ping 第乙個nam...