線上問題排查經驗

長期從過後端研發工做，不可避免的會遭遇到許多線上服務的問題，結合我本身的一些經驗，整理下排查的過程及思路，供你們參考。

1、定位優先級及緊急程度

根據功能及影響範圍，肯定優先級及緊急程度；決定是否須要向上通報，協調其餘資源介入。

2、作好通報

在問題發生的時候，研發同窗常常一心問題的排查上，心無旁騖。這個認真程度是很是贊同的，在排場時間過長的狀況下，就有可能形成業務相關方及問題發佈者長時間沒有收到反饋。本着「提高用戶體驗」的理念，咱們要將這些同窗當成用戶來看待，要作到有進度、有通報。

通常通報能夠在幾種場景下進行：

1. 首先，接到問題的第一時間表示跟進。
2. 視優先級及緊急程度，告知業務相關方，方便他們瞭解狀況，作出相應調整。
3. 視優先級及緊急程度，告知上級，方便作出更上層的決策及協調更多資源。
4. 有較大進展的時候，進行周知，方便相關人員瞭解進展。
5. 若是問題定位時間較長。重大問題能夠採用定時通告的方式；次要問題能夠進行排期後周知相關人員。
6. 若是有必要進行回滾，回滾先後都通告下相關人員，方便他們瞭解狀況，肯定影響，作出調整。
7. 問題有結論後，進行通告，並給出後續解決方案。
8. 問題最終排期解決後，進行通告。

這些通告的目的是同步信息，方便相關方作出對應措施。

3、問題排查的思路及方法

1、收集問題及環境信息

      信息越豐富，意味着問題的脈絡更清晰，並且若是不在第一現場儘量多的收集這些信息，就有可能由於現場的破壞而致使線索再也採集不到。

      須要收集的信息可能有：
     
           問題的已知首次發生時間

           問題反饋人員所處的環境，例如省、市、ip、ISP、瀏覽器、手機型號、app 版本等

           問題是全員的仍是部分的

           問題發生在哪些服務器上

           同期相關的日誌、數據信息

           同時期的上線、配置變動、運維操做、基礎服務變動等記錄

           同時期基礎服務提供商的變動、故障公告等

 2、彙總信息並從多條排查線去進行分析

      這裏我經常使用的思路有：

           經過變動記錄來諮詢相關人員，大量問題其實都是上線、變動等引發的，因此排查下同時期有過業務相關的變動操做人員，每每就能夠把不少問題排除在這道線上了。

           經過日誌、數據等，把一些已知問題篩選出來。

           經過影響人羣、問題點等信息嘗試找出復現方法。通常來講，能有方法穩定復現的問題，就比較容易排查到了。

           到這一步的問題，基本上都屬於一些疑難雜症了，就沒有一些特別通用的方法了。須要開闊思路，找找規律，將平時沒關注到的技術、業務點再瞭解的更細緻，更深刻一些，或者求助於團隊的幫助一塊兒來解決。

4、總結

這裏的總結包括兩個部分。

 一個是我的的總結。一次問題的定位解決每每伴隨着我的的成長，咱們不要放棄這樣的機會。在追查過程當中瞭解的知識點是比較零碎的，不繫統。過後就須要你們將這些點總體串起來，而且以點帶面，將知識點變動知識面。

 二是團隊的總結，這個總結又分兩個部分

      一是對此次問題的反思，咱們應該在流程、代碼、工具或者哪些方面作出調整，能夠更好的避免同類型問題的出現。

      二是對追查過程的總結，在問題定位的過程當中，咱們缺乏哪些幫助及工具的支持，可否更好的提高排查問題的效率，而後相關人員是否對過程結果存在異議。

最後，也但願用拋磚引玉的方式，帶出你們的思考與總結。