目錄
企業管理軟體領域内棘手故障的一些表現形式
1. 需要複雜的流程才能重制
2. 故障橫跨企業管理軟體的多個子產品
3. 故障隻能在客戶生産系統重制
4. 故障隻能在背景作業模式下重制，在 online 模式運作時一切正常
5. 故障隻能在軟體正常運作模式時才能重制，單步調試時，軟體工作一切正常
一個實際故障排查過程的案例分享
1. 試圖找到穩定重制故障的辦法
2. 縮小可能引起故障的代碼排查範圍
3. 利用調試器鎖定問題
故障排查過程總結
筆者從2007年大學畢業加入 SAP 成都研究院至今，一直從事企業管理軟體領域的開發工作。
企業管理軟體面向的是企業級使用者，如果軟體出現故障(bug)，在某些極端情況下，可能會讓企業蒙受巨大的經濟損失，故而對軟體開發人員在程式設計規範，軟體測試和軟體傳遞之前的驗證等各方面都提出了更高的要求。同時，由于企業管理軟體自身高度的複雜性，有些故障很難重制或者隻能在運作了客戶特定業務流程的生産系統上才能重制。這些都給企業管理軟體分析和故障處理帶來了巨大的挑戰。
本文從筆者處理過的一個實際軟體故障出發，談談自己對企業管理軟體裡一些棘手故障的處理體會。
在筆者看來，這些棘手故障，可以分為以下幾類。
筆者在 SAP成都研究院處理過很多曾讓我頭痛的軟體故障，它們具有下列一項或幾項特征。
例如我處理過的一個客戶發票(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 模式，給單步調試也帶來了困難。
當故障出現這種特征時，實際給支援人員傳遞了一個信号：該故障可能與程式特定的執行時序相關。因為程式正常運作，與處于單步調試模式下運作，執行時序顯然不同，比如在調試器單步調試時，可能會破壞多線程程式正常的執行時序。
因為缺少了調試器這一強有力的武器，分析該類故障，需要支援人員具有更強的理論分析能力和問題抽象能力。
由于篇幅限制，本文僅舉一個實際例子，對上述第五類故障的分析處理流程做一個分享。
筆者曾經負責 SAP CRM IBASE(Installed Base) 子產品。IBase 是一個抽象模型，用于描述已在客戶位置安裝的資源對象，例如裝置、機器，服務或軟體。IBase 模型以樹形結構，描述了這些對象的層級結構和它們的各個元件，是服務子產品的參考基礎。
并不總是能夠重制 != 不能重制。
為了分析這個問題，我得先找到能夠穩定重制的辦法。因為該故障對單步調試大法免疫，我隻能另想他法。
逐字逐句死扣故障報告裡的描述，發生故障之前的操作流程為：
(1) 建立 IBASE
(2) 修改 IBASE
(3) 删除 IBASE
(4) 儲存事務。
出現運作時錯誤。
因為我就是 IBASE 子產品的負責人，是以我三下五除二就寫好了一個不到 200 行的程式，在程式裡依次調用 IBASE 的建立，修改和删除 API，再儲存事務。
程式源代碼如下：
REPORT zibase_create_delete.
PARAMETERS: txt TYPE char40 OBLIGATORY DEFAULT 'description test',
eid TYPE char30 OBLIGATORY DEFAULT 'PROGRAM',
oid TYPE comm_product-product_id OBLIGATORY DEFAULT 'CHILDOBJ8',
fam TYPE comm_product-object_family OBLIGATORY DEFAULT '0401',
cat TYPE COMT_CATEGORY_ID OBLIGATORY DEFAULT 'OBJ_0401'.
DATA: lt_param TYPE crmt_name_value_pair_tab,
ls_param TYPE crmt_name_value_pair,
lr_core TYPE REF TO cl_crm_bol_core,
ls_object TYPE comm_product,
lr_root TYPE REF TO if_bol_entity_col,
entity TYPE REF TO cl_crm_bol_entity.
CHECK zcl_object_generator=>create_object( iv_id = oid iv_family = fam iv_catid = cat ) = abap_true.
ls_param-name = cl_crm_ibase_il_constant=>createparam.
ls_param-value = '01'.
APPEND ls_param TO lt_param.
lr_core = cl_crm_bol_core=>get_instance( ).
lr_core->load_component_set('IBASE_ONLY').
CALL METHOD lr_core->root_create
EXPORTING
iv_object_name = cl_crm_ibase_il_constant=>root_object
iv_create_param = lt_param
iv_number = 1
RECEIVING
rv_result = lr_root.
CHECK lr_root IS BOUND.
entity ?= lr_root->get_current( ).
CHECK entity IS BOUND.
IF entity->lock( ) = abap_true.
entity->switch_to_change_mode( ).
ENDIF.
entity->set_property_as_string( iv_attr_name = 'DESCR' iv_value = CONV #( txt ) ).
entity->set_property_as_string( iv_attr_name = 'EXTID' iv_value = CONV #( eid ) ).
"entity->set_property_as_string( iv_attr_name = 'IBTYP' iv_value = '01' ).
lr_core->modify( ).
DATA(lv_ibase_id) = entity->get_property_as_string( 'IBASE' ).
DATA(component) = entity->create_related_entity( 'FirstLevelComponent' ).
CHECK component IS NOT INITIAL.
DATA(obj_comp) = component->create_related_entity( 'IBCompObj').
CHECK obj_comp IS NOT INITIAL.
obj_comp->set_property_as_string( iv_attr_name = 'OBJECT_ID' iv_value = CONV #( oid ) ).
SELECT SINGLE * INTO ls_object FROM comm_product WHERE product_id = oid.
ASSERT sy-subrc = 0.
obj_comp->set_property_as_string( iv_attr_name = 'OBJECT_GUID' iv_value = CONV #( ls_object-product_guid ) ).
obj_comp->set_property_as_string( iv_attr_name = 'OBJECT_FAMILY' iv_value = CONV #( ls_object-product_guid ) ).
DATA(lo_message_container) = entity->get_message_container( ).
CALL METHOD lo_message_container->get_messages
iv_message_type = if_genil_message_container=>mt_all
IMPORTING
et_messages = DATA(lt_msg1).
LOOP AT lt_msg1 ASSIGNING FIELD-SYMBOL().
WRITE:/ -message COLOR COL_NEGATIVE.
ENDLOOP.
CHECK lt_msg1 IS INITIAL.
DATA: ls_header TYPE ibap_head1,
lt_struc_tab TYPE ibap_struc1_tab,
ls_comp TYPE IBAP_DAT1.
"delete component"
ls_header-ibase = lv_ibase_id.
CALL FUNCTION 'CRM_IBASE_GET_DETAIL'
i_ibase_head = ls_header
e_struc_ibase_tab = lt_struc_tab
EXCEPTIONS
not_specified = 1
doesnt_exist = 2
no_authority = 3.
CHECK sy-subrc = 0.
READ TABLE lt_struc_tab ASSIGNING FIELD-SYMBOL() INDEX 1.
ls_comp-instance = -instance.
CALL FUNCTION 'CRM_IBASE_COMP_DELETE'
i_comp = ls_comp
DATA_NOT_CONSISTENT = 1
IBASE_LOCKED = 2
NOT_SUCCESFUL = 3
NO_AUTHORITY = 4.
CASE sy-subrc.
WHEN 1.
WRITE: / 'data not consistent' COLOR COL_NEGATIVE.
WHEN 2.
WRITE: / 'cannot delete locked component' COLOR COL_NEGATIVE.
WHEN 3.
WRITE: / 'deletion not successful' COLOR COL_NEGATIVE.
WHEN 4.
WRITE: / 'no deletion authorization' COLOR COL_NEGATIVE.
ENDCASE.
DATA(lo_transaction) = lr_core->get_transaction( ).
DATA(lv_changed) = lo_transaction->check_save_needed( ).
CHECK lv_changed EQ abap_true.
DATA(lv_success) = lo_transaction->save( ).
DATA(lo_glb_msg_cont) = lr_core->get_global_message_cont( ).
CALL METHOD lo_glb_msg_cont->if_genil_message_container~get_messages
et_messages = DATA(lt_msg).
LOOP AT lt_msg ASSIGNING FIELD-SYMBOL().
WRITE:/ -message.
IF lv_success = abap_true.
lo_transaction->commit( ).
WRITE:/ 'IBASE Created Successfully: ', lv_ibase_id COLOR COL_NEGATIVE.
ELSE.
lo_transaction->rollback( ).
執行這個報表，遇到了期望中的運作時錯誤。這是一個好兆頭，因為我現在找到了穩定重制問題的辦法。下一步，我需要縮小問題的範圍，找出我這 200 行代碼裡，到底哪一行代碼的執行，引起了運作時錯誤。
筆者喜歡稱自己開發的這種專門用于分析故障，重制錯誤的程式，為“腳手架程式”或者“故障觸發器”。
因為這 200 行代碼是我自己編寫的，是以我可以任意修改。首先把所有代碼全部注釋掉，隻留下 IBASE 建立 API 的調用。執行程式，一切正常。
再解除 IBASE 修改 API 調用代碼的注釋，讓其參與到程式執行中，一切正常。
再反注釋 IBASE 删除 API 調用代碼，執行程式，出現了運作時錯誤!
由此說明，這個運作時錯誤和 IBASE 删除的場景相關。
回到故障送出報告裡的運作時錯誤截圖：第 103 行抛出了一個類型為 X 的錯誤，因為調用函數 CRM_IBASE_COMP_GET_DETAIL, 并沒有讀取到通過輸入參數 i_date 和 i_time 指定的時間戳對應的 IBASE 資料，是以程式決定通過抛出錯誤的方式來終止執行。
在背景作業運作模式，以及我的腳手架程式執行時，第 53 行時間戳判斷條件沒有滿足，是以退出了循環，導緻 CRM_IBASE_COMP_GET_DETAIL 讀取失敗，是以引發了故障。
要想滿足 53 行的判斷條件，隻有兩種可能：
目前時間戳 > IBASE valto 字段值
目前時間戳 = IBASE valto 字段值
需要強調的是，ABAP 程式設計語言裡的時間戳字段，精确到秒，比如 20211024102424 代表 2021年10月24日10點24分24秒。
雖然我的腳手架應用在單步調試模式下也無法重制故障，但是直接執行可以重制。是以，執行執行腳手架應用，在運作時故障頁面點選工具欄的 Debugger 按鈕，能彈出調試器，檢視應用程式抛出運作時錯誤的各種資訊：
而在背景作業模式以及腳手架程式正常運作情況下，如果 IBASE 建立，修改和删除的 API 執行得足夠快速，能夠在一秒鐘之内完成，則 t3 與 t1 之差小于 1 秒，故 CHECK 語句執行失敗，直接傳回。
換言之，這個故障送出時，CRM IBASE API 的開發人員，并沒有考慮到 IBASE 的建立和删除會在`同一秒之内`完成的場景。畢竟正常情況下，客戶不可能在 1 秒鐘之内，在 UI 完成 IBASE 先建立再删除的操作。這種場景隻可能在客戶使用 IBASE API 進行一些二次開發場景下才有可能出現。
當然，最後這個問題，也絕非僅僅是把 53 行 CHECK 語句的 < 符号，改成小于等于操作那麼簡單。我們仔細評估了改動可能帶來的其他副作用，并和送出該故障的團隊開發人員進行了讨論，最後采取了其他的方式來避免這個故障的發生。
回到這個故障分析過程本身，最開始接到故障時，因為單步調試無法重制，是以筆者很是一籌莫展了一陣，後來想到編寫腳手架程式來穩定重制該故障，這一步是問題分析的突破口。
有了腳手架程式之後，先注釋掉所有的 API 調用，再逐漸開放 IBASE 建立，修改和删除的代碼，最終把問題範圍縮小到 IBASE 删除過程。
通過腳手架應用的直接執行觸發的運作時錯誤，利用調試器檢視程式抛出錯誤時的變量值，将問題鎖定到時間戳的處理邏輯上，進而找出根源。
這一分析步驟有點像上世紀末本世紀初電腦 DIY 發燒友們遇到組裝機無法啟動時的排查措施。當組裝機無法啟動時，隻保留電源,主機闆和 CPU，嘗試啟動，如果成功，再逐一添加顯示卡，硬碟等其他裝置。當新添加的裝置導緻系統重新回到無法啟動狀态，說明該裝置有問題。當時發燒友們把這種方式稱為“最小系統法”。
而整個分析過程的重中之重，就是把故障報告中無法穩定重制故障的背景作業裡執行的内容，抽象成一個不到 200 行的腳手架程式。
《程式設計珠玑》第五章曾經分享過一個關于故障調試的有趣故事：IBM 研究中心一位程式員，新安裝了一台工作站，發現一個故障：他隻能采取坐着的姿勢登入系統；一旦站起來，就無法登陸系統了。大家知道這個故障最後怎麼定位的嗎？去讀讀原書吧!