技術實驗

Decisions API 能判斷部署失敗後該不該重試嗎？用 10 筆日誌驗證

在本機重現 10 種失敗情況，再用相同設定各重試一次。

·閱讀約 6 分鐘

部署失敗，最後一行日誌顯示 timed out。再按一次重試就能解決嗎？我們在本機重現了兩個首次嘗試日誌完全相同的案例，結果只有一個重試成功。

為了測試能否在部署失敗畫面提供下一步建議，我們把首次嘗試的紀錄交給 OpenAI Decisions API。面對日誌相同的兩個案例，API 都選擇「資訊不足」。另一個案例的日誌顯示，同一個端點在逾時後立刻回傳 HTTP 200，API 則選擇「重試」。

案例 A 和 B 共有的首次嘗試日誌
GET /artifact: TimeoutError: timed out
error: deployment step failed (TimeoutError: timed out)
案例 A 的重試結果收到 HTTP 200，這個步驟成功。
案例 B 的重試結果再次逾時，這個步驟失敗。
圖 1。兩個案例的首次嘗試紀錄完全相同，用相同設定重試的結果卻不同。

下方是逾時後收到確認回應的案例所留下的首次嘗試日誌。和上方的日誌相比，多出的第二行顯示同一個端點回傳了 HTTP 200。

GET /artifact: TimeoutError: timed out
follow-up probe of the same artifact endpoint: HTTP 200
error: deployment step failed (TimeoutError: timed out)

重現失敗，只用首次嘗試的紀錄選擇建議

我們在本機執行一個小程式，模擬部署的建置、啟動和啟動後的就緒檢查。先設定本機模擬 HTTP 伺服器對每次請求的回應，再設計出使用相同設定重試時會成功或失敗的案例。程式記錄的是這些模擬執行過程中的 HTTP 回應和 Python 例外。實驗未使用正式環境的部署日誌或實際服務。

10 個案例的第一次嘗試都會失敗，接著用相同設定各重試一次。HTTP 請求的逾時為 200 毫秒，記錄完首次嘗試後等待 50 毫秒再重試。需要確認是否恢復的案例，會在第一次失敗後向同一個 URL 發出一次確認請求。

提供給 API 的資訊首次嘗試的日誌、失敗階段，以及確認請求的結果（若有）。
選擇建議依提供的紀錄，從三個選項中選一個。
用重試結果評估以相同設定重試一次，再用結果評估這次判斷。
圖 2。實驗先記錄重試結果供評估，傳給 API 的則是首次嘗試的紀錄。

我們事先訂好建議的判斷標準，並寫進 API 的選項說明。有紀錄顯示只是暫時失敗，例如端點已恢復回應，就選「重試」。有具體的設定問題就選「檢查設定」。如果紀錄無法區分這兩種情況，就選「資訊不足」。

我們把失敗階段和首次嘗試的日誌傳給 Decisions API，使用 gpt-6-luna 的 choice 從三個選項中選一個。重試的日誌和結果留作評估。每個案例呼叫一次，共 10 次。 OpenAI Decisions API 的固定選項用法

10 次呼叫的 API 費用估計約 0.00026 美元。使用量紀錄顯示，共有 2,603 個未快取的輸入 token。截至 2026 年 11 月 5 日，Decisions API 的 gpt-6-luna 基本費率為每百萬個未快取的輸入 token 0.10 美元。代入後是 2,603 ÷ 1,000,000 × 0.10 = 0.0002603 美元。輸出不收費。實驗在本機執行，因此沒有 PaaS 部署費用。 OpenAI Decisions API 費率

有兩個案例，光看最後一行無法區分

我們拿只讀最後一行的規則來比較。看到逾時、連線中斷、HTTP 503 或 HTTP 429 時建議「重試」，看到 HTTP 404 或設定錯誤時建議「檢查設定」。下表列出兩種做法和預設建議一致的次數。

預期建議Decisions API只讀最後一行的規則
重試4/4件4/4件
檢查設定4/4件4/4件
資訊不足2/2件0/2件
合計10/10件8/10件
表 1。兩種做法選出的建議，與預先設定的建議一致的次數。

四個「重試」案例中，依賴服務起初回傳 HTTP 503 或 HTTP 429、連線中斷，或未在時限內回應。隨後的確認請求都收到 HTTP 200，用相同設定重試也都成功。四個「檢查設定」案例分別是找不到依賴檔案、缺少必要的環境變數、就緒檢查的 URL 設錯，以及設定檔格式錯誤。這四個案例重試後依然失敗。

剩下兩個案例刻意設計成單憑首次嘗試的紀錄無法區分。只讀最後一行的規則兩次都建議重試，其中一次重試失敗。API 則兩次都選「資訊不足」。這兩筆評估的是提出建議當下有沒有足夠依據，重試結果則另外記錄。

這裡比較的是讀取完整首次嘗試日誌與失敗階段的 API，以及只讀最後一行的規則。若要比較兩者讀取相同資訊時的表現，或了解 API 在實際部署中的判斷準確度，仍需要另外驗證。

10 個案例的完整日誌

下方日誌來自本機模擬實驗。路徑和設定名稱都是實驗用的，日誌沒有包含實際服務的主機名稱、憑證或使用者資料。

每個案例列出失敗階段、Decisions API 選擇的建議，以及首次嘗試和重試的日誌。如果有發出確認請求，回應也會記在首次嘗試的日誌裡。

1. 依賴服務暫時回傳 HTTP 503

失敗階段為建置。Decisions API 選擇「重試」。

首次嘗試日誌

GET /artifact: HTTP 503
follow-up probe of the same artifact endpoint: HTTP 200
error: deployment step failed (HTTP 503)

重試日誌（成功）

GET /artifact: HTTP 200
deployment step passed

2. 找不到依賴檔案

失敗階段為建置。Decisions API 選擇「檢查設定」。

首次嘗試日誌

GET /artifact/not-in-lock: HTTP 404
the locked dependency artifact path returned not found
error: deployment step failed (HTTP 404)

重試日誌（失敗）

GET /artifact/not-in-lock: HTTP 404
the locked dependency artifact path returned not found
error: deployment step failed (HTTP 404)

3. 逾時後重試成功（案例 A）

失敗階段為建置。Decisions API 選擇「資訊不足」。

首次嘗試日誌

GET /artifact: TimeoutError: timed out
error: deployment step failed (TimeoutError: timed out)

重試日誌（成功）

GET /artifact: HTTP 200
deployment step passed

4. 缺少必要的環境變數

失敗階段為啟動。Decisions API 選擇「檢查設定」。

首次嘗試日誌

required runtime setting is missing: 'PORT'
error: startup validation failed

重試日誌（失敗）

required runtime setting is missing: 'PORT'
error: startup validation failed

5. 與依賴服務的連線中斷

失敗階段為建置。Decisions API 選擇「重試」。

首次嘗試日誌

GET /artifact: RemoteDisconnected
follow-up probe of the same artifact endpoint: HTTP 200
error: deployment step failed (RemoteDisconnected)

重試日誌（成功）

GET /artifact: HTTP 200
deployment step passed

6. 就緒檢查的路徑設錯

失敗階段為就緒檢查。Decisions API 選擇「檢查設定」。

首次嘗試日誌

GET /ready: HTTP 404
configured readiness path is /ready. App route /health: HTTP 200
error: deployment step failed (HTTP 404)

重試日誌（失敗）

GET /ready: HTTP 404
configured readiness path is /ready. App route /health: HTTP 200
error: deployment step failed (HTTP 404)

7. 依賴服務暫時回傳 HTTP 429

失敗階段為建置。Decisions API 選擇「重試」。

首次嘗試日誌

GET /artifact: HTTP 429
follow-up probe of the same artifact endpoint: HTTP 200
error: deployment step failed (HTTP 429)

重試日誌（成功）

GET /artifact: HTTP 200
deployment step passed

8. 無法剖析設定檔

失敗階段為建置。Decisions API 選擇「檢查設定」。

首次嘗試日誌

could not parse build-settings.json: Expecting value: line 1 column 16 (char 15)
error: build configuration is invalid

重試日誌（失敗）

could not parse build-settings.json: Expecting value: line 1 column 16 (char 15)
error: build configuration is invalid

9. 重試仍然逾時（案例 B）

失敗階段為建置。Decisions API 選擇「資訊不足」。

首次嘗試日誌

GET /artifact: TimeoutError: timed out
error: deployment step failed (TimeoutError: timed out)

重試日誌（失敗）

GET /artifact: TimeoutError: timed out
error: deployment step failed (TimeoutError: timed out)

10. 逾時後用確認請求證實已恢復

失敗階段為建置。Decisions API 選擇「重試」。

首次嘗試日誌

GET /artifact: TimeoutError: timed out
follow-up probe of the same artifact endpoint: HTTP 200
error: deployment step failed (TimeoutError: timed out)

重試日誌（成功）

GET /artifact: HTTP 200
deployment step passed

重試前，先確認失敗階段和端點

如果建置時抓不到依賴檔案，可以先確認同一個檔案的 URL 現在是否有回應。如果失敗的是就緒檢查，可以核對應用程式提供的路徑與設定的檢查路徑。若只看到逾時，就找能指出失敗階段或端點的其他日誌。

若要在部署失敗畫面導入這種判斷，可以在建議旁顯示從日誌確認的事實。比如「剛才無法取得依賴檔案，但隨後的確認請求已收到回應」，讓使用者能看懂為什麼建議重試。這次實驗的 API 回傳選項，畫面上的事實則可以從日誌整理。

KamuiDash 是可從 GitHub 部署 Web 應用程式的 PaaS。 KamuiDash