接到線上問題應該如何去做
處理線上問題第一原則：先保障線上服務可用性，第一時間降低故障影響範圍。
機動人員處理問題流程：
- 第一時間在問題群內同步自己開始跟進問題
- 評估問題影響範圍，確認問題的嚴重性，考慮是否回滾和走降級流程，將結果反饋到研發owner
目前監控平臺：實時資料監控平臺prajna，實時錯誤日誌平臺CAT和 打點日誌平臺GALAXY。
prajna上實時可查資料，理想情況下有對各個指標有相關域值，可檢視當日異常資料情況
CAT上可以觀測到當天的異常報錯資料，對比前一天和上週同一天同事間段的資料，是否錯誤異常。
GALAXY上可以收集到當日之前的打點資料，可以拉取前一天和上週同一天同事間段的資料來模擬當日的資料。 - 分析定位問題，在問題群中及時更新處理進度
分析定位問題：
需要同步的處理情況如下：
1. 已查明可能導致故障的原因
2. 故障處理進度，包括嘗試的解決方案及效果
3. 故障跟進人變更（排除本模組問題，轉移給其他模組RD調查）
4. 故障升級（故障超時未解決，故障升級）
如何用資料協助定位問題
1. 檢視prajna上或cat上專案皮膚上的各報錯日誌數量和內容是否異常
2. 如果拿到問題使用者token，在日誌系統（prajna，cat，後端日誌）中拉取該使用者的行 為記錄，復原問題出現的流程和場景
研發owner處理問題流程：
- 根據機動人員反饋的影響範圍，決定是否回滾或者降級，並且通知到產品和QA
- 指定人員解決分析定位問題，將人員安排同步到問題群
- 執行問題升級流程
1. 指定的解決問題人員10分鐘內不能定位問題，則安排全員一起排查問題
2. 全員10分鐘內不能定位，研發owner將目前的情況彙報到上層 - 問題定位並且解決後，準備線上恢復工作。
a. 如果採用的是回滾方案，將bugfix分支經由QA測試迴歸，確定好重新提審的日期，執行正常的釋出流程
b. 如果是採取降級流程，線上恢復後通知到QA做迴歸測試，開發人員在監控系統上對異常資料繼續觀測半個小時，如果資料穩定則確認為問題解決。
5. 線上問題解決後，安排相關人員完成casestudy和事後覆盤工作。
小程式常見問題排查方法
登陸提示“服務出錯了”，一般會出現在導航頁，支付確認頁，購物車頁。檢視登陸請求的http狀態碼如果是403則是被風控，正常則為賬戶中心返回異常
支付提示“該筆交易異常，請稍後重試”。使用者被微信風控
快取問題 不應該出現的資料，在關閉頁面後，5分鐘內新開頁面卻帶有該資料，很有可能是微信快取的問題。
支付提示服務錯誤 很有可能健康檢查的問題，建議拉取後端檢視相關日誌
彈框“微信登入失敗” 訪問賬戶中心超時
故障處理過程中的溝通方法
故障處理需要和第三方溝通時一定要注意資訊傳遞的及時和完整大象溝通，除了反饋問題現象，同時要把已經掌握問題的分析資料反饋到第三方，使第三方儘快的熟知問題。
（圖中的案例，沒有把我們的分析問題的資料直接反饋到第三方，也不是第一時間取得的溝通）
如果第三方沒有回覆，直接電話取得溝通，更快地解決線上的問題對業務和第三方都是必須要做的，不要有所顧慮。
如果聯絡到的第三方負責人不能給出應有的回饋，及時聯絡該團隊leader儘快找到熟悉該業務的人員配合做處理。