這是 jerry 2021 年的第 67 篇文章，也是汪子熙公衆号總共第 344 篇原創文章。
jerry 從 2007 年大學畢業加入 sap 成都研究院至今，一直從事企業管理軟體領域的開發工作。
企業管理軟體面向的是企業級使用者，如果軟體出現故障(bug)，在某些極端情況下，可能會讓企業蒙受巨大的經濟損失，故而對軟體開發人員在程式設計規範，軟體測試和軟體傳遞之前的驗證等各方面都提出了更高的要求。同時，由于企業管理軟體自身高度的複雜性，有些故障很難重制或者隻能在運作了客戶特定業務流程的生産系統上才能重制。這些都給企業管理軟體分析和故障處理帶來了巨大的挑戰。
本文從 jerry 處理過的一個實際軟體故障出發，談談自己對企業管理軟體裡一些棘手故障的處理體會。
在 jerry 看來，這些棘手故障，可以分為以下幾類。
企業管理軟體領域内棘手故障的一些表現形式
我在 sap 成都研究院處理過很多頗讓人頭痛的軟體故障，它們具有下列一項或幾項特征。
例如我處理過的 sap business bydesign 裡一個客戶發票(customer invoice)相關的故障。這個故障隻有在每次 release 發票時才能重制。為了 release 發票，我們必須先建立一個銷售訂單(sales order)，基于該訂單建立 customer demand，然後建立撿貨任務(pick task)，生成交貨單(delivery note),最後才能生成一張新的客戶發票。
這些複雜的流程往往也需要系統事先維護好對應的主資料(master data)和事務資料(transaction data)才能順利執行。複雜的業務流程增添了故障重制的難度。
由于企業管理軟體自身的複雜度，終端使用者眼中看到的貌似簡單的一個故障，背後可能橫跨了軟體實作的多個子產品。
以上述形式 1 描述的故障為例，假設軟體幫助文檔上描述的支援功能為：客戶在銷售訂單界面上添加了一個新的自定義字段并維護了對應值，該值能夠從銷售訂單，經撿貨任務，交貨單，最後傳遞到客戶發票上。我們稱這種字段值從多個文檔間的傳遞稱為 data flow.
那麼如果客戶在發票頁面上，看到這個字段的值為空，客戶可能認為是發票子產品出了故障。然而，在 data flow 的每個節點對應的子產品處理，可能都是造成該故障的罪魁禍首。銷售訂單和客戶發票屬于 crm 子產品，而撿貨任務和發貨單則歸屬 scm 的範疇。
在實際開發工作中，這意味着分析該故障往往需要跨團隊間協作，因為 crm 和 scm 子產品往往分屬不同的開發團隊負責。
在企業管理軟體傳遞之前，必定在内部開發，測試和驗證系統(validation system)進行過不同層次的測試。即便如此，由于種種客觀原因，比如當應用運作在客戶生産系統上，基于某些隻有該客戶才會用到的特定業務流程的配置時，故障才會暴露，而這些配置并沒有被企業管理軟體供應商的内部系統測試所涵蓋到。
這類故障因為隻能在客戶生産系統重制，在分析和定位問題時更加困難重重，尤其當重制步驟會在客戶生産系統進行寫操作時，通常隻能聯系客戶相關人員，采用遠端桌面+電話會議的方式，讓客戶相關人員進行操作，然後軟體供應商的支援人員線上調試。
在企業管理軟體領域特别是 erp 領域，背景作業常常被用來執行一些費時的批處理工作，比如訂單批量處理，報表資料分析和聚合彙總等等。背景作業模式不同于挂接了使用者界面的 online 模式，給單步調試也帶來了困難。
當故障出現這種特征時，實際給支援人員傳遞了一個信号：該故障可能與程式特定的執行時序相關。因為程式正常運作，與處于單步調試模式下運作，執行時序顯然不同，比如在調試器單步調試時，可能會破壞多線程程式正常的執行時序。
因為缺少了調試器這一強有力的武器，分析該類故障，需要支援人員具有更強的理論分析能力和問題抽象能力。
由于篇幅限制，本文僅舉一個實際例子，對上述第五類故障的分析處理流程做一個分享。
jerry 曾經負責過 sap crm ibase(installed base) 子產品的維護工作。ibase 是一個抽象模型，用于描述已在客戶位置安裝的資源對象，例如裝置、機器，服務或軟體。ibase 模型以樹形結構，描述了這些對象的層級結構和它們的各個元件，是服務子產品的參考基礎。
有一天，我收到一個故障報告，另一個團隊的同僚，使用我所在團隊負責的 ibase api，在同一會話過程内建立 ibase 元件，修改，随後删除，然後儲存，會遇到運作時錯誤(runtime error).
在故障描述裡提到的運作時錯誤的截圖如上圖所示。
這位同僚發現，這個錯誤隻能在背景作業模式下重制，并且不一定每次都能夠重制。該故障也無法在單步調試模式下重制。
并不總是能夠重制 != 不能重制。
為了分析這個問題，我得先找到能夠穩定重制的辦法。因為該故障對單步調試大法免疫，我隻能另想他法。
逐字逐句閱讀故障報告裡的描述，發生故障之前的操作流程為：
(1) 建立 ibase
(2) 修改 ibase
(3) 删除 ibase
(4) 儲存事務。
出現運作時錯誤。
因為我就是 ibase 子產品的負責人，是以我三下五除二就寫好了一個不到 200 行的程式，在程式裡依次調用 ibase 的建立，修改和删除 api，再儲存事務。
程式源代碼如下：
執行這個報表，遇到了期望中的運作時錯誤。這是一個好兆頭，因為我現在找到了穩定重制問題的辦法。下一步，我需要縮小問題的範圍，找出我這 200 行代碼裡，到底哪一行代碼的執行，引起了運作時錯誤。
jerry 喜歡稱自己開發的這種專門用于分析故障，重制錯誤的程式，為“腳手架程式”或者“故障觸發器”。
因為這 200 行代碼是我自己編寫的，是以我可以任意修改。
首先把所有代碼全部注釋掉，隻留下 ibase 建立 api 的調用。執行程式，一切正常。
再解除 ibase 修改 api 調用代碼的注釋，讓其參與到程式執行中，一切正常。
再反注釋 ibase 删除 api 調用代碼，執行程式，出現了運作時錯誤!
由此說明，這個運作時錯誤和 ibase 删除的場景相關。
回到故障送出報告裡的運作時錯誤截圖：第 103 行抛出了一個類型為 x 的錯誤，因為調用函數 crm_ibase_comp_get_detail, 并沒有讀取到通過輸入參數 i_date 和 i_time 指定的時間戳對應的 ibase 資料，是以程式決定通過抛出錯誤的方式來終止執行。
通過運作時錯誤的上下文調用棧，我找到了 crm_ibase_comp_get_detail api 沒有傳回任何 ibase 資料的原因：下圖第 53 行高亮代碼的 check 語句，檢查目前傳入的時間戳(預設為 ibase 建立時的時間戳)是否小于待讀取 ibase 擡頭的 valto(即 valid to，指 ibase 有效截止日期的時間戳）字段。如果小于，則順序執行 check 下一條即 54 行。如果大于或等于，則退出資料讀取邏輯所在的循環體。
在背景作業運作模式，以及我的腳手架程式執行時，第 53 行時間戳判斷條件沒有滿足，是以退出了循環，導緻 crm_ibase_comp_get_detail 讀取失敗，是以引發了故障。
要想滿足 53 行的判斷條件，隻有兩種可能：
目前時間戳 > ibase valto 字段值
目前時間戳 = ibase valto 字段值
需要強調的是，abap 程式設計語言裡的時間戳字段，精确到秒，比如 20211024102424 代表 2021年10月24日10點24分24秒。
雖然我的腳手架應用在單步調試模式下也無法重制故障，但是直接執行可以重制。是以，執行執行腳手架應用，在運作時故障頁面點選工具欄的 debugger 按鈕，能彈出調試器，檢視應用程式抛出運作時錯誤的各種資訊：
這一回，在調試器裡，所有的謎題都揭曉了：目前時間戳 = ibase valto 字段值，是以導緻 api crm_ibase_comp_get_detail 讀取失敗，抛出運作時錯誤。
在調用 ibase 建立 api 時，會把待建立的 ibase 擡頭的 valfr 字段，賦以系統的目前時間戳。
在調用 ibase 删除 api 時，會把該待删除 ibase 擡頭的 valto 字段，賦以系統的目前時間戳。
為什麼在單步調試模式下，無法重制這個錯誤呢？我們來看一張簡單的時序圖。
橫軸代表時間戳。t3 代表代碼 53 行判斷語句裡的 -valto 字段值, t1 代表代碼 53 行判斷語句裡的 lv_timestamp 字段值。
在單步調試模式下，假設我們從 ibase 建立 api 開始依次單步執行，則由于按鍵手速原因，t3 必定大于 t1.
而在背景作業模式以及腳手架程式正常運作情況下，如果 ibase 建立，修改和删除的 api 執行得足夠快速，能夠在一秒鐘之内完成，則 t3 與 t1 之差小于 1 秒，故 check 語句執行失敗，直接傳回。
換言之，這個故障送出時，crm ibase api 的開發人員，并沒有考慮到 ibase 的建立和删除會在<code>同一秒之内</code>完成的場景。畢竟正常情況下，客戶不可能在 1 秒鐘之内，在 ui 完成 ibase 先建立再删除的操作。這種場景隻可能在客戶使用 ibase api 進行一些二次開發場景下才有可能出現。
當然，最後這個問題，也絕非僅僅是把 53 行 check 語句的 < 符号，改成小于等于操作那麼簡單。我們仔細評估了改動可能帶來的其他副作用，并和送出該故障的團隊開發人員進行了讨論，最後采取了其他的方式來避免這個故障的發生。
回到這個故障分析過程本身，最開始接到故障時，因為單步調試無法重制，是以jerry很是一籌莫展了一陣，後來想到編寫腳手架程式來穩定重制該故障，這一步是問題分析的突破口。
有了腳手架程式之後，先注釋掉所有的 api 調用，再逐漸開放 ibase 建立，修改和删除的代碼，最終把問題範圍縮小到 ibase 删除過程。
通過腳手架應用的直接執行觸發的運作時錯誤，利用調試器檢視程式抛出錯誤時的變量值，将問題鎖定到時間戳的處理邏輯上，進而找出根源。
這一分析步驟有點像上世紀末本世紀初電腦 diy 發燒友們遇到組裝機無法啟動時的排查措施。當組裝機無法啟動時，隻保留電源,主機闆和 cpu，嘗試啟動，如果成功，再逐一添加顯示卡，硬碟等其他裝置。當新添加的裝置導緻系統重新回到無法啟動狀态，說明該裝置有問題。當時發燒友們把這種方式稱為“最小系統法”。
而整個分析過程的重中之重，就是把故障報告中無法穩定重制故障的背景作業裡執行的内容，抽象成一個不到 200 行的腳手架程式。
《程式設計珠玑》第五章曾經分享過一個關于故障調試的有趣故事：ibm 研究中心一位程式員，新安裝了一台工作站，發現一個故障：他隻能采取坐着的姿勢登入系統；一旦站起來，就無法登陸系統了。大家知道這個故障最後怎麼定位的嗎？去讀讀原書吧!
希望本文能給大家在企業管理軟體領域内的故障排除方法帶來一些啟發，感謝閱讀。
相關閱讀
jerry的檢討：程式員不要輕易說出"這個功能技術上無法實作"
記一次 sap 開發工程師給微軟 azure 報 incident 的體驗
更多jerry的原創文章，盡在："汪子熙":