IBM Bob · 工作坊教學材料

工作坊教材 · IT 維運輔助

用 IBM Bob 輔助 WAS、MQ、Db2 維運與 Ansible 自動化

本單元以「超級便利銀行」在一個真實維運日所發生的事故為主軸：早晨結算高峰時 WAS 因 JVM Heap 耗盡崩潰，導致 MQ 財金 FISC 清算通道大量訊息積壓；事後調查發現 Db2 的 LOCKLIST 參數不足才是深層根因；最終以 Ansible Playbook 自動化完成參數調整後的安全重啟。四個情境環環相扣，帶您練習如何把系統日誌貼入 IBM Bob，讓 Bob 逐步協助診斷並恢復服務。

本單元涵蓋的四個情境

以下四個情境依照事故發生的時序排列，建議依序練習。每個情境都會提供：一段真實的日誌或需求描述作為輸入素材、一個建議的 Prompt，以及對 Bob 預期回應方向與下一步的說明。

① WAS 日誌診斷

08:19 跨行匯款結算批次跑到一半崩潰——解讀 JVM Heap 耗盡的根因，取得調參建議，為後續重啟做準備。

② MQ 通道排查

WAS 崩潰期間 MQ 訊息持續累積——定位 AMQ9208E 斷線原因，了解財金 FISC 清算積壓如何發生並排除。

③ Db2 SQL 輔助

清算恢復後發現 Db2 鎖定才是爆量深層根因——由 Bob 生成診斷 SQL，確認 LOCKLIST 過小導致的鎖定升級。

④ Ansible 自動維護

根因確認後套用調整——用 Ansible Playbook 對所有 WAS 節點執行滾動重啟並驗證服務恢復。

情境一：WAS SystemOut.log 分析

切換到 Ask 模式。11/15 早上 08:19，「超級便利銀行」核心轉帳系統在跨行匯款結算高峰期間發生 JVM Heap 耗盡，server1 強制關閉。以下是完整的 SystemOut.log，請展開後複製，再附上下方的 Prompt：

載入中…
輸入以下 Prompt（Ask 模式）
「請幫我診斷這段 WAS 日誌。發生了什麼問題？根本原因為何？我該如何排查，以及在 WAS 主控台需要調整哪些參數以防止再次發生？」
預期 Bob 的回應方向
Bob 會識別出在跨行匯款結算批次處理 15,842 筆 TWD 時發生 OutOfMemoryError: Java heap space，分析 BatchSerializer 與 TransactionCache 的記憶體洩漏路徑，並建議調整 WAS 管理主控台的 JVM 最大堆疊記憶體、啟用 HeapDumpOnOutOfMemoryError，以及實施分批處理策略來防止下一次結算高峰再度觸發 OOM。

→ 下一步：WAS 崩潰期間，MQ 的財金 FISC 清算通道也同時出現訊息積壓。進入情境二，了解 AMQ9208E 斷線的細節以及如何設定 KeepAlive 防止復發。

情境二：IBM MQ AMQERR01.LOG 分析

切換到 Ask 模式。同樣在 11/15，「超級便利銀行」與財金資訊（FISC）之間的 MQ 清算通道在 WAS 崩潰後出現斷線與訊息積壓。以下是 AMQERR01.LOG 完整日誌，請展開後複製，再附上 Prompt：

載入中…
輸入以下 Prompt（Ask 模式）
「我的 MQ 通道 TO.FISC.CLEARING 今天斷線了兩次，AMQ9208E 伴隨錯誤碼 10054 代表什麼？為什麼佇列積壓了 1,247 筆 TWD 跨行清算訊息？我該如何設定 KeepAlive 以避免再次發生？」
預期 Bob 的回應方向
Bob 會解釋 AMQ9208E 與 TCP 錯誤碼 10054（Connection reset by peer）的含義，分析財金 FISC 防火牆的閒置逾時策略是主要根因，並提供 HBINT（心跳間隔）與 KAINT（KeepAlive 間隔）的設定建議，以及日誌中已套用的 HBINT(30) KAINT(30) 設定的驗證方式。

→ 下一步：清算訊息雖已重連並傳送完畢，但後端 Db2 的鎖定問題才是批次爆量的深層根因。進入情境三，用 SQL 查詢確認 LOCKLIST 不足導致鎖定升級的真正原因。

情境三：Db2 db2diag.log 分析與診斷 SQL 生成

切換到 Agent 模式。11/30 月底對帳期間，「超級便利銀行」帳務系統的 Db2 發生大量死鎖與鎖定升級——這與 11/15 的 WAS OOM 共享同一深層根因：LOCKLIST 與 MAXLOCKS 參數過小。此情境需要 Bob 主動生成並驗證 SQL，因此請切換至 Agent 模式，讓 Bob 能直接呼叫工具執行產出的指令。請展開日誌後複製，再讓 Bob 分析並生成診斷 SQL：

載入中…
輸入以下 Prompt（Agent 模式）
「請幫我分析這段 Db2 日誌中的死鎖根本原因，並幫我寫一條 IBM Db2 語法，查詢目前所有正在處於 Lock Wait 狀態的 Application Handle、鎖定的 Table 名稱以及等待的時間（秒數），並依等待時間降序排列。」
預期 Bob 的回應方向
Bob 會識別 BANK.ACCOUNT_MASTER 表上的死鎖鏈根本原因（應用程式存取順序不一致 + LOCKLIST 過小導致鎖定升級），並生成一段查詢 SYSIBMADM.LOCKWAITS 的 SQL，欄位涵蓋 Application Handle、Table 名稱及等待秒數，同時建議調整 LOCKLIST 與 MAXLOCKS 參數以防止月底高峰再次發生鎖定升級。

→ 下一步：根因已確認——把 Bob 建議的 Db2 參數與 WAS JVM 堆疊設定一起套用，再進入情境四，用 Ansible Playbook 對全部 WAS 節點執行安全的滾動重啟。

情境四：Ansible Playbook 生成

繼續保持 Agent 模式。根據前三個情境的診斷結論，已確認需要調整 WAS JVM 堆疊參數並重啟 server1 以套用設定。把需求告訴 Bob，讓它草擬一份可直接執行的滾動重啟 Playbook：

輸入以下 Prompt（Agent 模式）
「根據剛才的分析，我已更新 Db2 的 LOCKLIST/MAXLOCKS 參數與 WAS 的 JVM 最大堆疊記憶體設定。請幫我寫一份 Ansible Playbook，對 was_servers 群組的所有節點執行滾動重啟：先停止 WebSphere 的 server1，等待 port 9080 關閉後再重新啟動，並在啟動完成後確認 port 9080 已恢復監聽。WAS profile 路徑為 /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin。」
預期 Bob 的回應方向
Bob 會依照描述的步驟，產出一份包含 stop、wait_for_port_close、start、verify 四個 Task 的標準 Ansible Playbook YAML，並加入 serial: 1 實現滾動重啟以確保銀行服務不中斷。您可以直接取用或視需要調整帳號、路徑與 timeout 參數後執行。

常見問答

學員疑問 解答說明
Bob 的錯誤碼解讀可能不準確嗎？ 對於 WAS、MQ 這類長期維護的 IBM 產品，主要錯誤碼多年保持相容，Bob 的解讀通常相當可靠。如果回應有疑問，可以追問 Bob「請說明您判斷的依據」，或提供更多日誌上下文讓它修正。
Bob 可以直接幫我執行 Ansible Playbook 嗎？ 可以。在 Agent 模式下，只要您的本機已安裝 ansible-playbook，Bob 被授予 CLI 執行權限後就能直接呼叫並回報執行結果。試試看輸入「請幫我執行剛才產生的 Playbook」。
為什麼 Db2 診斷 SQL 執行後找不到對應的系統表？ 部分 Db2 效能視圖需要先開啟監控器開關。遇到這個情況，可以把錯誤訊息直接貼入 Bob，它會告訴您需要執行哪個 db2 update dbm cfg 指令來啟用監控。

工作坊單元已全部閱讀完畢！

恭喜您順利學會了 IBM Bob 基礎操作、COBOL 系統傳承解讀，以及 WAS/MQ/Db2 自動化運維排查！請點擊下方返回課程主索引頁，並使用複製的指令開始克隆與實作吧！

返回教材主索引頁 →