記一次SAP開(kāi)發(fā)工程師給微軟Azure報(bào)incident的體驗(yàn)

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

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

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

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

在排除了問(wèn)題不是我們消費(fèi)端代碼引起之后，我開(kāi)始給Azure報(bào)incident。

雖然Azure的字面意思是天藍(lán)色，但Jerry打開(kāi)的Azure頁(yè)面全是下圖這種純黑色背景，只是因?yàn)槲覔Q了一個(gè)黑色主題。

新建一個(gè)支持請(qǐng)求(Support Request)，類(lèi)型選擇為T(mén)echnical：

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

然后指定遇到問(wèn)題的Service類(lèi)型，和具體的Resource名稱(chēng)。Subscription，Service，Resource這三個(gè)字段都是聯(lián)動(dòng)的下拉菜單。

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

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

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

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

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

Jerry處理過(guò)的317個(gè)客戶(hù)incidents中也不乏Very High的，當(dāng)時(shí)處理時(shí)承擔(dān)的壓力，至今思之仍覺(jué)得后怕。

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

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

因?yàn)槲覀兿硎艿腟upport Plan級(jí)別是Premier，在這個(gè)級(jí)別之下，理論上15分鐘之內(nèi)就會(huì)收到響應(yīng)。

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

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

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

這個(gè)會(huì)剛結(jié)束，我手機(jī)又接到一個(gè)號(hào)碼顯示為美國(guó)的來(lái)電，一位自稱(chēng)是微軟Critical Situation Manager的女士，詢(xún)問(wèn)我對(duì)剛才和Azure Support工程師開(kāi)會(huì)的體驗(yàn)，以及對(duì)這個(gè)incident優(yōu)先級(jí)的降低是否有異議。

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

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

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

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

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

https://launchpad.support.sap.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我處理那個(gè)IBASE bug因?yàn)闊o(wú)法單步調(diào)試，僅能通過(guò)ST22 Dump里的靜態(tài)信息進(jìn)行分析，所以我也使用了“最小系統(tǒng)法”，分析出可能引起故障的子模塊，再寫(xiě)測(cè)試程序運(yùn)行這些模塊，逐一驗(yàn)證我的猜想。

關(guān)于我提交的這個(gè)不能穩(wěn)定重現(xiàn)的Azure incident，我也會(huì)持續(xù)關(guān)注。最后祝我的同行，處理這個(gè)incident的微軟工程師好運(yùn)。感謝閱讀。