本文是對解決問題的一些方法內容的改寫與補充！
首要的問題
對於發生線上上的問題， 最緊要的事項一定是“以最快最有效的方式解決問題，降低對線上業務的影響”，然後才是深挖問題，探求根本原因，防微杜漸，未雨綢繆。
而對於非線上問題，客觀上會有“相對多一點的處理時間、多一些的分析和處理方法”。
1 接觸與瞭解
從總體著眼，從細節入手！
確認基本相關資訊是必須執行的首要環節，也是後續處理問題的基礎。
如果無法清楚地辨別或陳述問題的基本資訊，那麼，此時要面對的將不僅僅是問題本身！
不明確和不充分的資訊資源，將極大地制約問題處理的效率和效果。
問題的基本資訊概括起來，主要包括兩個方面：在怎樣的背景環境下？發生了怎樣的問題？
進一步的細分，可能涉及如下內容：
1.1 問題現象的描述
- 問題的直觀現象
- 問題的初始級別
- 問題發生的時間、地點、報告人
- 問題發生的階段和場景：新安裝階段、實驗階段、生產場景、維護場景。。。
- 問題發生前的操作
1.2 問題的邊界與歸屬
從現象和場景，來判斷是自身的問題？還是外部問題？
實質上，這是在確認自身在問題處理中的角色定位：該發揮怎樣的作用和達到怎樣的效果，由誰來處理、跟進、協助。
如果是自身的問題，那麼當前的問題級別和影響是什麼？
對應級別和影響的問題，應由對應級別和影響的人去解決，因為這涉及到相應的應急方案措施、資源調動和投入。
如果是外部的問題，那麼誰是相關人？需要提供哪些必要的資訊？需要進行哪些必要的分析？
1.3 當前狀態和進展
確認是自身的問題後，就需要進一步瞭解問題的詳細資訊。
- 裝置版本資訊
- 裝置使用資訊：單方使用還是多方共用。。。
- 裝置相關配置、流程、服務、網路狀態
- 收集裝置當前日誌，並開啟Debug級別日誌
- 報錯資訊來源與內容
- 獲取裝置遠端登入資訊
- 客戶及現場工程師的聯絡方式
- 已採取的步驟、操作、方案。。。問題狀態和現象發生了怎樣的改變；
- 當前投入的資源：參與問題處理的人員及角色定位；
1.4 問題定性
根據收集到問題資訊，清楚地辨別問題性質，是探尋問題本質的第一步，也決定著後續處理的方向。
產品問題？ --- 需求問題？ --- 情緒發洩？
原生問題？ --- 由其他問題引發的衍生問題？
個別？ --- 共性？
偶發？ --- 頻繁？
。。。。。。1.5 下一步的資訊
- 在當前處理狀態下，問題的發展趨勢；
- 下一步的人力或物質資源的需求；
- 下一步的步驟、操作、方案。。。；
2- 定位與分析
從總體著眼，從細節入手！
2.1 一般性流程
precondition status --> configuration & data flow --> log&infos flow --> troubleshooting flow- 每一個環節的前提條件是否成立？
- 每一個環節的配置和資料流是否正確？
- 依據每一個環節的日誌或資訊，能夠獲取怎樣的判斷依據？
問題定位和分析的過程，實質上是具體業務流程的“對映”，順序和步驟大致相同，遵循著業務資料的流向。
每一個業務環節和階段的日誌和配置資訊，都是判斷的依據。
因此，熟悉業務環節和階段是問題定位與分析的基礎要求。
2.2 常用的定位與分析方法
a. 場景區分
針對不同階段和場景，側重點不同。
例如：
- 如果問題發生在全新安裝或全新整合階段，那麼問題發生的原因更可能與誤操作、誤配置、流程錯誤相關。
- 如果問題發生在產品使用階段，那麼要首先確認問題發生之前的狀態、操作資訊、業務使用背景、備份配置等。
b. 最小環境與分解排除
- 最小環境法：正向流程分析（業務起點至終點），從最基本因素開始排查，逐步新增其他因素進行判斷。
- 分解排除法：反向流程分析（業務終點至起點），根據業務原理流程，逐步查詢有效資訊，排除干擾項，縮小範圍。
c. 對比與替換
- 對比：跟正確的做比較，不同的便是可疑的。縱向，同一事物不同時間段的對比；橫向，同一時間段不同事物的對比。
- 替換：分階段分割槽域，逐步調換物件，分別驗證。換資料、換配置、換模組、換裝置、換環境。。。換人。
d. 重現與模擬
- 重現：在真實環境觀察或模擬問題的發生，得到更多的資訊，驗證想法和操作等。
- 模擬：如果沒有真實環境，可以建立虛擬環境（模擬器simulator）來驗證基本流程、配置、資料等。
e. 相似案例
相似的問題現象大都有著相似的原因。
從前期的相似案例中，可以獲取可參考的處理方法，推動當前問題的解決。
f. 試錯
條件允許的情況下，有依據地多次嘗試，可能會發現新的可用資訊或處理方式；
g. 資訊搜尋
資訊不僅來自公司組織內部，也廣泛的存在外部空間。
h. 獲得幫助
每個人都是某一方面的菜鳥，某一細節的白痴。
我們的目標是解決問題，在必要情況下，應該及時從他人請求幫助，這沒什麼可恥的。
可恥的是：有方法有途徑來解決問題，但卻不去嘗試。
3 - 處理與跟進
從總體著眼，從細節入手！
3.1 一些注意事項
- 關注根本問題：問題處理的過程中，很有可能又引入或出現新的問題，此時面對多個問題，應持續關注根本問題，合理排序，逐個解決，如無必要，不建議同時處理多個問題；
- 資訊記錄：儘可能保留相關資訊（log 、 screenshot、等等），作為後續處理和問題回溯的資料，例如：在相關登陸程式中啟用log保留功能；
- 獲取許可權：重大影響及關鍵操作一定要獲得雙授權（customer and local）
- 狀態同步：及時更新狀態並知會相關人。更新資訊應包括：當前狀態、Next action、可能的預計結果、時間點、你的困境和需求等；
- 自我審視：低頭解決問題， 抬頭看問題狀態（自己的角色與作用、進展、性質、customer和high level的反饋。。。）
- 。。。。。。
3.2 無奈的“三板斧”
- 重啟: 根據問題的實際情況，進行業務切換或重啟（程式、服務、模組、系統、節點、叢集、硬體平臺等）；
- 重置：回退到上一版本的配置、回退到預設配置等;
- 重灌: 軟硬體系統已經徹底崩潰或損毀，重灌是無奈的選擇，業務短時間無法恢復；
實際上，以上操作都是“災備方案”的步驟和內容。一個合理的災備方案，必須備份了資料和配置資訊。
在“重啟、重置、重灌”過程中，通過匯入備份資料和配置，有利於業務的快速恢復。
3.3 全域性關注（whole picture）
你只是問題處理流程上的一個環節或者節點，從整個流程上去審視本身的作用，做好該做的事，會更好促進問題解決！
- 從整個事件流程去觀察一個階段和環節；
- 從一個時間範圍去觀察共發事件的相互影響；
- 從一個週期去觀察時間範圍。
4 - 溝通與協作
4.1 換位思考
假定此時你是客戶，從客戶的角度來理解利害點和需求。
受限於資訊不對等，理解會存在偏差，不存在“感同身受”，只是儘可能地“設身處地”去了解。
別把自己的感知強加給他人！
你的理解可能只是你的主觀感受，不是客觀的實際狀態。
4.2 情緒控制
人與人的區別，比人與動物的區別都要大。
個體的巨大差別（知識背景、技能狀態、秉性喜好、利害衝突等等），必然會出現難以理解的情況。
對於過程中出現難以理解的事物，只能說。。。儘量避免情緒上的對立。
普通人一旦有了對立情緒這個內因，必然會導致態度上的消極，事物上的拖延，於己於人於事無益！
一個可行的方法：根據當時的實際情況，來確定意願層級 ： 盡心、盡力、盡責。
- 盡心 --- 願意投入工作時間之外的精力和資源。
- 盡力 --- 工作時間之內，力所能及地做些額外的事情。
- 盡責 --- 基於事情本身，完成職責之內的事情。
如果心中有“猛虎”，就把這理解為只是一份工作中的一個task而已，如果task的安排具有合理性（時間、技能、目標、資源。。。），那就遵從這個合理性的安排。
就事論事，簡單直接的基於事情本身來開展，基於本職盡責。這是共同協作完成事情的基本要求，同時這也是溝通與協作基礎。
4.3 客戶認知
無論是外部客戶還是內部客戶，一般情況下，可預先假定他們是“高貴、繁忙，迫切而又茫然”的。
- 高貴 --- 以客戶滿意度為最高要求，及時同步問題狀態，保持適當update頻率。否則，客戶有了情緒，分分鐘就能“Management Escalation”到high level發起challenge。
- 繁忙 --- 客戶的時間是寶貴的，總是沒時間的，極有可能沒法及時回覆和協作。保持謙遜，連環E-mail，連環Call；引入“high level”，繼續搞。或者，從第三封郵件開始，明確申明這是第幾次請求回覆，並設定預設選項和時間點，促成客觀選擇。
- 迫切 --- 無論問題怎樣，客戶總是希望以最快速度解決。慎重承諾deadline。
- 茫然 --- 通常不具備相關知識背景，或者只瞭解基礎的一部分。因此，最初接觸到的問題資訊和表述，很可能不準確、不完整，未必反映問題的本質。必要時，資訊需要親自重新獲取、確認和對比。需要客戶配合某些操作時，提供詳細的步驟。
如果“恰好”遇到一個“耐心好，時間充裕，懂產品”或者"肯鑽研"的客戶，那麼“However,everything has two sides......”，你懂的。
5 - 問題閉環
問題得到徹底解決的標誌，不是問題現象的消失，而是同樣的問題不再出現。
也就是說，要想使問題真正閉環，需要探求問題的本質，明確產生問題和觸發的根本原因，制定有效的預防措施，並進一步改善處理流程。
這個過程，通常稱為RCA/EDA（Root Cause analysis / Escape Defect Analysis)，簡而言之，這是一個“問題覆盤”和“制定預防措施”的過程。
如果僅僅止步於問題現象的消失，甚至滿足於問題處理完成，忽略了對問題的覆盤和根本原因的探求，那麼這個“根本原因”將會一直潛伏和等待，直到下一個“時機”製造出“更大的驚喜”。
深挖問題，探求根因，防微杜漸，未雨綢繆，這才是業務執行的長久之計。
假設如下幾種場景：
程式碼問題
- 是否考慮加強“Code review”環節？
- 通過多人專家review、舉行review會議、採用自動程式碼檢視工具和框架等方法是否可以有效避免程式碼的異常？
配置問題
- “配置改動”的授權、稽核和操作環節是否足夠安全，
- 能否通過“Double Authorization”、“Double Check”、操作前備份配置檔案和資料等方法來充分保障？
硬體問題
- 為什麼在日常巡檢中沒有發現？
- 原因是什麼（評估指標不合理、檢視訊率過低、人為疏忽等等）？
- 可以採取哪種對應的改進措施（更新評估指標、提高檢視訊率、使用自動指令碼或工具等等）？
- 備件儲備和更換流程是否健全？
測試性問題
- 為什麼本應該在測試階段就應該暴露的問題，結果卻沒有發現？
- 是測試流程有缺失、測試用例和方法不合理、測試環境有缺陷？
6 - 另一種方式
如果你認為下面的問題處理方式是對的：
- 疑似我的問題，請拿出充分的證據，否則就不是我的問題。。。拒不處理！
- 第三方的問題，不做必要分析，直接透傳。
- 存在技術性問題向“非技術性問題”轉換的可能性，於是“其實這不是問題，這是需求，這是體驗差的抱怨。”。
- 過多引入不必要人員和事項，人多事情雜，流程長又慢，問題仍在處理中。
- 多次、長時間的索取不必要的資訊，企圖以時間來淡化微小問題的影響，迫使客戶逐漸失去關注度。
- 問題個別罕見，沒有足夠的資訊支援分析和定位，請在問題重現時，及時提供更多資訊。
- 久拖不決，不了了之。
面對問題時，如果個體基礎能力不足，卻企圖以抖機靈式的技巧來規避，最終都會將自身推入一個更深的大坑，“昨天總會在明天等你！”。