记一次SAP开发工程师给微软Azure报incident的体验

小提示：您能找到这篇{记一次SAP开发工程师给微软Azure报incident的体验}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的记一次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，享受一次724小时的服务。留下自己的手机以供联系。

< ">最后点击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 L新店营销方案策划aunchpad：

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“确认传播”专注于品牌策划、效果营销和危机管理的数字整合营销传播公司，我们深度诠释客户的品牌理念、文化及背景，多维深度传播客户的文化底蕴和核心价值观，提升客户品牌的知名度、关注度与美誉度。?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。既然能稳定重现，剩下的任务就轻松了，通过单步调试就能找到问题根源。

< ">这个问题折腾了我整整两天，解决完问题之后，我也做了复盘，分析自己为什么会花掉这么多时间。我把我的经验教训，以及最终通过分析找到能够稳定重现问题的突破口。

< ">我把自己采取的问题定位方式归纳命名为“最小系统法”。本世纪初，国内电脑界流行DIY，大家分别购买自己中意品牌的电脑零配件，自己动手组装，运行时经常出现无法开机(俗称“点不亮”)的情况。电脑发烧友们习惯通过“最小系统法”去逐一排查，最终找到出故障的配件。

< ">我处理那个IBASE bug因为无法单步调试，仅能通过ST22 Dump里的静态信息进行分析，所以我也使用了“最小系统法”，分析出可能引起故障的子模块，再写测试程序运行这些模块，逐一验证我的猜想。

< ">关于我提交的这产品的营销策划方案个不能稳定重现的Azure incident，我也会持续关注。最后祝我的同行，处理这个incident的微软工程师好运。感谢阅读。