記一次SAP開發工程師給微軟Azure報incident的體驗

文章標題的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...

同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/6...

回到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...

我把本身採起的問題定位方式概括命名爲「最小系統法」。本世紀初，國內電腦界流行DIY，你們分別購買本身中意品牌的電腦零配件，本身動手組裝，運行時常常出現沒法開機(俗稱「點不亮」)的狀況。電腦發燒友們習慣經過「最小系統法」去逐一排查，最終找到出故障的配件。

我處理那個IBASE bug由於沒法單步調試，僅能經過ST22 Dump裏的靜態信息進行分析，因此我也使用了「最小系統法」，分析出可能引發故障的子模塊，再寫測試程序運行這些模塊，逐一驗證個人猜測。

關於我提交的這個不能穩定重現的Azure incident，我也會持續關注。最後祝個人同行，處理這個incident的微軟工程師好運。感謝閱讀。

要獲取更多Jerry的原創文章，請關注公衆號"汪子熙":