執行個體生命週期
執行個體任何時候都恰好處於八種狀態中的一種。它處於哪一種狀態決定了你在意的三件事：你能不能連上它、它是不是正在對你計費，以及有哪些操作可用。
狀態機
正常路徑是 creating → running → stopping → stopped → starting → running。拆除一律是 destroying → destroyed，而且可以從 destroyed 以外的任何狀態開始 —— 包括執行個體還在建立、啟動或停止的時候。虛線箭頭表示主機沒有照要求完成操作時，平台把執行個體放回原本的狀態；下文會說明。
要求目前狀態不允許的動作 — 啟動一個已經在執行的執行個體、停止一個還在建立中的執行個體 — 會被拒絕，執行個體維持原狀。
每一種狀態
| 狀態 | 過渡中 | 計費 | 代表的意義 |
|---|---|---|---|
creating | 是 | 無 | 切片已保留，你的工作負載正在第一次啟動。 |
starting | 是 | 無 | 已停止的執行個體正在同一台機器上、以同一顆硬碟重新啟動。 |
running | 否 | GPU，按秒 | 工作負載已就緒。SSH、JupyterLab 與你發布的連接埠都連得上。 |
stopping | 是 | 無 | 容器正在關閉。你的硬碟會保留。 |
stopped | 否 | 硬碟，每 GB 每小時 | 沒有任何東西在執行。硬碟保留；GPU 插槽仍為你保留，除非餘額用完時平台把 GPU 釋放了。 |
destroying | 是 | 無 | 容器與硬碟正在拆除。 |
destroyed | 否 | 無 | 終點。硬碟已消失，報價回到市集上。 |
error | 否 | 無 | 工作負載無法啟動、執行中失敗、停止期間容器不見了，或自己執行結束了。詳見下文。 |
過渡狀態是平台正在積極處理中的那四種；主控台會用閃動的徽章顯示它們，並在進行期間更頻繁地重新整理。它們會自行完成 — 沒有動作需要重試，不過你也可以不等，直接銷毀執行個體。
非過渡狀態是穩定的。執行個體會停在 running、stopped、destroyed 或 error，直到你、計費系統或主機自己的回報讓它移動。
每個轉換的成因
| 轉換 | 觸發條件 |
|---|---|
→ creating | 你進行部署：以一則報價、一個範本與一個硬碟大小呼叫 POST /v1/instances。 |
creating/starting → running | 工作負載回報自己已就緒。GPU 計量從這裡開始，而不是在部署時。 |
creating → error | 工作負載無法啟動。 |
running → stopping | 你停止它，或你的餘額到達 ¥0。餘額用完時的這次停止會在機器支援時釋放 GPU。 |
stopping → stopped | 關閉完成。硬碟計量從這裡開始。 |
stopping → running | 主機在 30 分鐘內沒有確認停止。容器其實還在執行，所以 GPU 計量重新開始，停止會繼續重試。它的 error_code 為 stop_timed_out。 |
stopped → starting | 你啟動它。需要餘額足夠組織名下的一切（包括這個執行個體）跑一小時。 |
starting → stopped | 主機拒絕了恢復、連不上，或在 30 分鐘內沒有確認（start_timed_out）；GPU 被釋放過的執行個體，還可能是原來那幾張 GPU 正被別人使用，或者在那台機器上已停止服務（gpus_unavailable）。執行個體回到已停止，硬碟還在，你可以再次啟動它。 |
running → error | 工作負載失敗、主機弄丟了它，或某個任務自己執行完畢（workload_completed）。GPU 已被釋放。 |
stopped（以及正在停止或啟動的執行個體）→ error | 執行個體停止期間，它的容器在機器上不見了（workload_gone）。已經沒有東西可以啟動，也不再收儲存費用。 |
error → running 或 stopped | 平台發現工作負載其實是健康的 —— 在執行，或連同硬碟一起被保留著 —— 於是把執行個體放回那個狀態。 |
destroyed 以外的任何狀態 → destroying | 你銷毀它。餘額維持為負夠久時，自動銷毀也會對已停止與出錯的執行個體這麼做。 |
destroying → destroyed | 拆除完成。硬碟已刪除，報價已釋出。 |
其中兩個觸發條件不是你發動的。組織餘額到達 ¥0 時，執行中的執行個體會自動停止；在機器支援的地方，這些執行個體和已停止執行個體佔著的 GPU 會被釋放，硬碟保留。如果餘額此後在 ¥0 或以下持續 24 小時，並且到達 −¥35 或更低，已停止與出錯的執行個體會被銷毀。執行中的執行個體永遠不會被直接銷毀 —— 它們會先被停止。兩條規則都在自動停止與自動銷毀中說明。
部署與啟動都需要餘額足夠整個組織跑一小時：所有執行中、啟動中或正在建立的執行個體的 GPU 加上硬碟，所有已停止執行個體的硬碟，再加上你正在部署或啟動的這個執行個體的 GPU 加上硬碟。餘額只是大於零並不夠，不足時請求會以 402 INSUFFICIENT_BALANCE 被拒絕。停止與銷毀從來不需要 — 不論餘額是多少，你隨時都能把東西關掉。
計費跟著狀態走
費用依執行個體實際所處狀態的費率結算，而且每次狀態變更都會在變更生效前先結清先前欠的部分。GPU 計量只在 running 時運作。硬碟計量只在 stopped 時運作。四種過渡狀態、error 與 destroyed 都不計費。
這就是為什麼一次花兩分鐘才啟動完成的部署不會為那兩分鐘計費，也是為什麼已停止的執行個體仍會每分鐘在你的帳本裡產生一筆費用。
「error」代表什麼
error 表示工作負載沒有在執行，平台也沒有替你保留它：映像檔拉取失敗、容器拒絕啟動、主機在啟動過程中停止回報、工作負載在執行中失敗或遺失、執行個體停止期間容器不見了，或某個任務自己執行完畢。是哪一種，執行個體頁面會在發生了什麼問題下說明，API 會在執行個體的 error_code 與 error_message 裡說明。請參閱執行個體為何失敗。
由此可以推出四件事：
- 不會對你計費。 在
error狀態下計量是關閉的，執行個體停在那裡也不會累計任何費用。 - 不會自動重試。 沒有自動重新啟動。除了銷毀，唯一的出路是恢復：如果平台之後發現工作負載其實在執行，或連同硬碟一起被保留著，它會把執行個體放回
running或stopped。 - 它可能被自動清理。 從未執行過就出錯的執行個體，或已知工作負載已經結束的執行個體（包括
workload_completed與workload_gone），會在進入error大約一小時後被自動銷毀，硬碟也一起刪除。執行過、而且工作負載可能還被保留著的執行個體則不會 —— 它會等平台查清楚發生了什麼，或等你處理。 - 銷毀是你唯一能做的動作。 你不能啟動、停止或修復一個出錯的執行個體。銷毀它、修好原因，然後重新部署。
啟動失敗的常見原因出在範本而不是硬體：不存在的映像檔名稱或標籤，或是私有登錄庫的憑證有誤。映像檔不是以 Superheat 基礎映像檔為基底的 ssh 或 jupyter 範本也啟動不了，因為這兩種模式依賴基礎映像檔的進入點。
自己執行結束的任務 —— args 模式範本的指令結束了 —— 會進入 error，error_code 為 workload_completed。它的 GPU 會立即釋放，也不計費；取走你需要的東西之後就銷毀它。
從未進入 running 的執行個體沒有日誌可讀，所以請從範本而不是從執行個體來除錯。疑難排解會逐一說明各種具體的失敗情形。
它不花錢。一旦平台看到它的工作負載已經結束 —— 失敗、遺失或執行完畢 —— 它的 GPU 會立即回到市集。工作負載還沒到達主機就失敗的部署，會一直佔著切片，直到執行個體被銷毀：由你銷毀，或大約一小時後被自動銷毀。不論哪一種，在被銷毀之前它都會算進組織 25 個執行個體的上限。
你在哪裡看得到狀態
執行個體頁面會列出除了已銷毀之外的所有項目。透過 API，GET /v1/instances?include_destroyed=true 可以把它們找回來。
每個執行個體頁面會以徽章顯示目前狀態、只顯示目前狀態允許的操作 — 已停止的執行個體顯示「啟動」，執行中的顯示「停止」，destroyed 以外的每個狀態都顯示「銷毀」 — 並在工作負載就緒後，在連線分頁顯示連線資訊。API 會在執行個體的 allowed_actions 裡回傳同一份清單。