文章標題的incident含義：在企業級軟件領域裏，當客戶使用軟件提供商的軟件，遇到各種問題或故障，可以使用專門的工具，向軟件供應商尋求幫助。我們通常稱這種工具創建的幫助請求(Support Request)爲incident.
今天這篇文章無關具體的技術。Jerry最近使用微軟Azure雲平臺時遇到一個問題，通過Azure提供的Support工具向微軟提交incident的過程中，感嘆自己十多年來一直是修bug的命，這次終於翻身了，由我給另一家軟件公司報bug，體驗了一回當上帝的感覺。
我在SAP這些年，一共處理過317個客戶incidents(當然並不是所有的都是Jerry修復的，包括我分析後轉手到其他部分的也算).
我們Commerce Cloud團隊使用Azure提供的Function create API在Azure上創建Lambda Function，過程中遇到一些問題，詳見Jerry之前的文章：SAP ABAP應用服務器的HTTP響應狀態碼(Status Code).
在排除了問題不是我們消費端代碼引起之後，我開始給Azure報incident.
雖然Azure的字面意思是天藍色，但Jerry打開的Azure頁面全是下圖這種純黑色背景，只是因爲我換了一個黑色主題。
新建一個支持請求(Support Request)，類型選擇爲Technical：
選中之後，Subscription就自動填充爲我當前這個用戶的訂閱ID了。大家可以把Azure Subscription的作用類比成SAP Cloud Platform的Global Account.
然後指定遇到問題的Service類型，和具體的Resource名稱。Subscription，Service，Resource這三個字段都是聯動的下拉菜單。
Service，Problem type和Problem subtype這三個聯動的下拉菜單，共同扮演的角色，類似給SAP產品報incident時需要維護的Application Component. 下圖是SAP Application Component的樹狀關係圖。
Jerry個人覺得Azure這種多層級聯式下拉菜單的做法，爲用戶免去了記憶component ID的負擔；但作爲程序員，我個人還是更喜歡SAP這種通過樹形結構維護component的方式。
回到Azure Portal，維護好了問題類型和描述信息後，Azure根據這些信息自動從其後臺檢索出相關的推薦解決方案。我瀏覽了一下，發現並不能解決我遇到的問題，於是點Next繼續：
這裏可以維護明細信息和上傳附件。我當時將重現問題的步驟，Postman請求的payload，我的分析，包括我搭建的jMeter等信息全部寫到一個PDF文件裏了，總共8頁，添加到附件裏。
然後是選擇故障的緊急程度，Azure有四檔緊急程度可選：Critical，Urgent，Moderate和Minimal. 而對應的SAP裏的術語叫Priority(優先級)，SAP incident的優先級也分四檔：Very High，High，Medium和Low.
Jerry處理過的317個客戶incidents中也不乏Very High的，當時處理時承擔的壓力，至今思之仍覺得後怕。
儘管明白“程序員何苦爲難程序員”的道理，我還是選擇了最高級別的Critical impact，享受一次7×24小時的服務。留下自己的手機以供聯繫。
最後點擊Next就能成功創建Support Request.
因爲我們享受的Support Plan級別是Premier，在這個級別之下，理論上15分鐘之內就會收到響應。
果然，幾分鐘之後Jerry就收到了一個用Teams發起的會議請求：
我心想，微軟真是動作神速啊，這麼快就派出工程師準備和我一起在線調試了嗎？本來我正在吃飯，只得放下碗筷回到電腦面前。
登入Microsoft Teams參加了會議我才知道，這個會的目的首先是，Azure Support工程師確認他們對我附件PDF裏描述信息的理解是否正確，然後討論這個incident的Severity是否應該從Critical降成Urgent. 工程師們詳細詢問了我們組對這個API的使用場景，以及當前Azure上是否存在已經上線的應用。最終我也同意了這個降級請求，畢竟微軟這套衡量incident優先級的標準和SAP類似，都是按照Business Impact來界定的。
這個會剛結束，我手機又接到一個號碼顯示爲美國的來電，一位自稱是微軟Critical Situation Manager的女士，詢問我對剛纔和Azure Support工程師開會的體驗，以及對這個incident優先級的降低是否有異議。
整體來講，我對這次向Azure提交incident的體驗很滿意，無論是響應速度還是同Azure Support工程師及Critical Situation Manager交談下來感受到的專業程度，都給我留下了深刻的印象。
最後還是再來回顧一下SAP從業者們最熟悉的如何給SAP產品報incident的工具吧。
在SAP Cloud for Customer about菜單裏集成了提交incident的功能：
提交界面比較簡潔，維護標題和問題詳細描述，上傳附件。
當然也能使用最統一最通用的SAP One Support Launchpad：
https://launchpad.support.sap.com
同Azure一樣，SAP Support Launchpad也鼓勵用戶，在實際提交incident之前，首先去Knowledge Base裏查詢有無相關線索和解決方案。
不搜不知道，一搜嚇一跳，原來HTTP 400 bad request確實是一個普遍問題，在SAP領域也一共存在1400多個相關note和討論：
如果覺得這些搜索結果沒有幫助，點擊Submit an Incident. SAP incident也分4檔不同的優先級：
關於上圖的必填字段Component，如果是基於ABAP的SAP產品，很容易在開發包的Application Component字段找到這個值：
如果是SAP Cloud Platform的某個模塊遇到了問題，對應的Application Component在SAP Help上能查到：
https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/08d1103928fb42f3a73b3f425e00e13c.html?scp-env=Cloud%20Foundry
回到Jerry給Azure報的那個incident，目前還在處理過程中。對此我也非常能理解，這種不能100%重現的故障是最讓程序員頭疼的。
我想起之前處理過的一個SAP CRM IBASE問題，應用運行時有一定概率會出現運行時Dump，但不是總能重現。
當年Jerry還在SAP成都研究院CRM開發團隊工作，負責SAP CRM IBASE的維護。
當時給我報bug的同事也坦言，這個Dump不能穩定重現。如果試一次是正常工作的話…那就多試幾次，直到出現Dump爲止…
最讓我抓狂的是，如果單步調試，這個故障100%無法重現。換句話說，我多年積累下來的在文章SAP錯誤消息調試之七種武器：讓所有的錯誤消息都能被定位裏介紹的ABAP單步調試經驗，在這個問題的分析上完全派不上用場。
幸運的是我最終通過自己的分析，寫了一個腳手架程序，通過該測試程序能夠100%重現Dump. 既然能穩定重現，剩下的任務就輕鬆了，通過單步調試就能找到問題根源。
這個問題折騰了我整整兩天，解決完問題之後，我也做了覆盤，分析自己爲什麼會花掉這麼多時間。我把我的經驗教訓，以及最終通過分析找到能夠穩定重現問題的突破口，寫成了一篇SAP社區博客：
My Tips about how to handle complex and tricky issues
https://blogs.sap.com/2014/05/01/my-tips-about-how-to-handle-complex-and-tricky-issues/
我把自己採取的問題定位方式歸納命名爲“最小系統法”。本世紀初，國內電腦界流行DIY，大家分別購買自己中意品牌的電腦零配件，自己動手組裝，運行時經常出現無法開機(俗稱“點不亮”)的情況。電腦發燒友們習慣通過“最小系統法”去逐一排查，最終找到出故障的配件。
我處理那個IBASE bug因爲無法單步調試，僅能通過ST22 Dump裏的靜態信息進行分析，所以我也使用了“最小系統法”，分析出可能引起故障的子模塊，再寫測試程序運行這些模塊，逐一驗證我的猜想。
關於我提交的這個不能穩定重現的Azure incident，我也會持續關注。最後祝我的同行，處理這個incident的微軟工程師好運。感謝閱讀。
要獲取更多Jerry的原創文章，請關注公衆號"汪子熙":
