文章标題的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的微軟工程師好運。感謝閱讀。
本文來自雲栖社群合作夥伴“汪子熙”，了解相關資訊可以關注微信公衆号"汪子熙"。
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)