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

來源：簡書

作者：JerryWang_汪子熙

時間：2020-06-18

最近使用微軟Azure云平臺時遇到一個問題，以下是通過Azure提供的Support工具向微軟提交incident的過程。

文章標(biāo)題的incident含義：在企業(yè)級軟件領(lǐng)域里，當(dāng)客戶使用軟件提供商的軟件，遇到各種問題或故障，可以使用專門的工具，向軟件供應(yīng)商尋求幫助。我們通常稱這種工具創(chuàng)建的幫助請求(Support Request)為incident。

今天這篇文章無關(guān)具體的技術(shù)。Jerry最近使用微軟Azure云平臺時遇到一個問題，通過Azure提供的Support工具向微軟提交incident的過程中，感嘆自己十多年來一直是修bug的命，這次終于翻身了，由我給另一家軟件公司報bug，體驗了一回當(dāng)上帝的感覺。

我在SAP這些年，一共處理過317個客戶incidents(當(dāng)然并不是所有的都是Jerry修復(fù)的，包括我分析后轉(zhuǎn)手到其他部分的也算)。

我們Commerce Cloud團(tuán)隊使用Azure提供的Function create API在Azure上創(chuàng)建Lambda Function，過程中遇到一些問題，詳見Jerry之前的文章：SAP ABAP應(yīng)用服務(wù)器的HTTP響應(yīng)狀態(tài)碼(Status Code)。

在排除了問題不是我們消費端代碼引起之后，我開始給Azure報incident。

雖然Azure的字面意思是天藍(lán)色，但Jerry打開的Azure頁面全是下圖這種純黑色背景，只是因為我換了一個黑色主題。

新建一個支持請求(Support Request)，類型選擇為Technical：

選中之后，Subscription就自動填充為我當(dāng)前這個用戶的訂閱ID了。大家可以把Azure Subscription的作用類比成SAP Cloud Platform的Global Account。

然后指定遇到問題的Service類型，和具體的Resource名稱。Subscription，Service，Resource這三個字段都是聯(lián)動的下拉菜單。

Service，Problem type和Problem subtype這三個聯(lián)動的下拉菜單，共同扮演的角色，類似給SAP產(chǎn)品報incident時需要維護(hù)的Application Component。下圖是SAP Application Component的樹狀關(guān)系圖。

Jerry個人覺得Azure這種多層級聯(lián)式下拉菜單的做法，為用戶免去了記憶component ID的負(fù)擔(dān)；但作為程序員，我個人還是更喜歡SAP這種通過樹形結(jié)構(gòu)維護(hù)component的方式。

回到Azure Portal，維護(hù)好了問題類型和描述信息后，Azure根據(jù)這些信息自動從其后臺檢索出相關(guān)的推薦解決方案。我瀏覽了一下，發(fā)現(xiàn)并不能解決我遇到的問題，于是點Next繼續(xù)：

這里可以維護(hù)明細(xì)信息和上傳附件。我當(dāng)時將重現(xiàn)問題的步驟，Postman請求的payload，我的分析，包括我搭建的jMeter等信息全部寫到一個PDF文件里了，總共8頁，添加到附件里。

然后是選擇故障的緊急程度，Azure有四檔緊急程度可選：Critical，Urgent，Moderate和Minimal。而對應(yīng)的SAP里的術(shù)語叫Priority(優(yōu)先級)，SAP incident的優(yōu)先級也分四檔：Very High，High，Medium和Low。

Jerry處理過的317個客戶incidents中也不乏Very High的，當(dāng)時處理時承擔(dān)的壓力，至今思之仍覺得后怕。

盡管明白“程序員何苦為難程序員”的道理，我還是選擇了最高級別的Critical impact，享受一次7×24小時的服務(wù)。留下自己的手機(jī)以供聯(lián)系。

最后點擊Next就能成功創(chuàng)建Support Request。

因為我們享受的Support Plan級別是Premier，在這個級別之下，理論上15分鐘之內(nèi)就會收到響應(yīng)。

果然，幾分鐘之后Jerry就收到了一個用Teams發(fā)起的會議請求：

我心想，微軟真是動作神速啊，這么快就派出工程師準(zhǔn)備和我一起在線調(diào)試了嗎？本來我正在吃飯，只得放下碗筷回到電腦面前。

登入Microsoft Teams參加了會議我才知道，這個會的目的首先是，Azure Support工程師確認(rèn)他們對我附件PDF里描述信息的理解是否正確，然后討論這個incident的Severity是否應(yīng)該從Critical降成Urgent.工程師們詳細(xì)詢問了我們組對這個API的使用場景，以及當(dāng)前Azure上是否存在已經(jīng)上線的應(yīng)用。最終我也同意了這個降級請求，畢竟微軟這套衡量incident優(yōu)先級的標(biāo)準(zhǔn)和SAP類似，都是按照Business Impact來界定的。

這個會剛結(jié)束，我手機(jī)又接到一個號碼顯示為美國的來電，一位自稱是微軟Critical Situation Manager的女士，詢問我對剛才和Azure Support工程師開會的體驗，以及對這個incident優(yōu)先級的降低是否有異議。

整體來講，我對這次向Azure提交incident的體驗很滿意，無論是響應(yīng)速度還是同Azure Support工程師及Critical Situation Manager交談下來感受到的專業(yè)程度，都給我留下了深刻的印象。

最后還是再來回顧一下SAP從業(yè)者們最熟悉的如何給SAP產(chǎn)品報incident的工具吧。

在SAP Cloud for Customer about菜單里集成了提交incident的功能：

提交界面比較簡潔，維護(hù)標(biāo)題和問題詳細(xì)描述，上傳附件。

當(dāng)然也能使用最統(tǒng)一最通用的SAP One Support Launchpad：

https://launchpad.support.sap.com

同Azure一樣，SAP Support Launchpad也鼓勵用戶，在實際提交incident之前，首先去Knowledge Base里查詢有無相關(guān)線索和解決方案。

不搜不知道，一搜嚇一跳，原來HTTP 400 bad request確實是一個普遍問題，在SAP領(lǐng)域也一共存在1400多個相關(guān)note和討論：

如果覺得這些搜索結(jié)果沒有幫助，點擊Submit an Incident.SAP incident也分4檔不同的優(yōu)先級：

關(guān)于上圖的必填字段Component，如果是基于ABAP的SAP產(chǎn)品，很容易在開發(fā)包的Application Component字段找到這個值：

如果是SAP Cloud Platform的某個模塊遇到了問題，對應(yīng)的Application Component在SAP Help上能查到：

https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/08d1103928fb42f3a73b3f425e00e13c.html?scp-env=Cloud%20Foundry

回到Jerry給Azure報的那個incident，目前還在處理過程中。對此我也非常能理解，這種不能100%重現(xiàn)的故障是最讓程序員頭疼的。

我想起之前處理過的一個SAP CRM IBASE問題，應(yīng)用運行時有一定概率會出現(xiàn)運行時Dump，但不是總能重現(xiàn)。

當(dāng)年Jerry還在SAP成都研究院CRM開發(fā)團(tuán)隊工作，負(fù)責(zé)SAP CRM IBASE的維護(hù)。

當(dāng)時給我報bug的同事也坦言，這個Dump不能穩(wěn)定重現(xiàn)。如果試一次是正常工作的話......那就多試幾次，直到出現(xiàn)Dump為止......

最讓我抓狂的是，如果單步調(diào)試，這個故障100%無法重現(xiàn)。換句話說，我多年積累下來的在文章SAP錯誤消息調(diào)試之七種武器：讓所有的錯誤消息都能被定位里介紹的ABAP單步調(diào)試經(jīng)驗，在這個問題的分析上完全派不上用場。

幸運的是我最終通過自己的分析，寫了一個腳手架程序，通過該測試程序能夠100%重現(xiàn)Dump。既然能穩(wěn)定重現(xiàn)，剩下的任務(wù)就輕松了，通過單步調(diào)試就能找到問題根源。

這個問題折騰了我整整兩天，解決完問題之后，我也做了復(fù)盤，分析自己為什么會花掉這么多時間。我把我的經(jīng)驗教訓(xùn)，以及最終通過分析找到能夠穩(wěn)定重現(xiàn)問題的突破口。

我把自己采取的問題定位方式歸納命名為“最小系統(tǒng)法”。本世紀(jì)初，國內(nèi)電腦界流行DIY，大家分別購買自己中意品牌的電腦零配件，自己動手組裝，運行時經(jīng)常出現(xiàn)無法開機(jī)(俗稱“點不亮”)的情況。電腦發(fā)燒友們習(xí)慣通過“最小系統(tǒng)法”去逐一排查，最終找到出故障的配件。