維運承諾

事件處理遵循同一套順序：15 分鐘內確認受理並指派事件指揮官、工程師投入處理、至少每 60 分鐘更新一次，並在每起影響客戶的事件發生後 7 個日曆天內提供書面事後檢討報告。

1. 確認受理

   我們會在 15 分鐘內確認受理事件並指派事件指揮官。事件指揮官是統籌應變的唯一負責人。

2. 投入處理

   網路維運團隊在任何時段都會於 15 分鐘內投入處理，機房工程或現場代操作人員則在 45 分鐘內投入。

3. 更新

   事件處理期間，您至少每 60 分鐘會收到一次更新。

4. 事後檢討報告

   每起影響客戶的事件發生後 7 個日曆天內，您會收到書面事後檢討報告。

事後檢討報告是對事件的書面說明：發生了什麼、為何發生，以及正在採取哪些措施避免再次發生。

具風險的計畫性作業至少提前 7 個日曆天公告，變更須經過書面變更管理流程，資產清冊則記錄您的叢集，細至每條線纜。

維護事先通知

事先通知適用於高風險的非緊急維護，讓您在作業開始前有時間移轉工作或建立檢查點。緊急作業不適用此通知期。在機房方面，我們要求所使用的資料中心針對高風險維護提前 14 天通知。

變更管理與存取

書面變更管理是指，您叢集的變更都遵循文件化的流程，並留下書面紀錄。頻外存取（在作業系統之下、透過 BMC 存取伺服器的管理路徑）均經稽核。

資產清冊

我們維護一份資產清冊，記錄每個機櫃、節點、GPU、網路卡、硬碟、交換器、連接埠、光收發模組與線纜，並為您提供機器可讀的匯出檔。狀態變更在 5 分鐘內即可看到。偏移偵測會將叢集與約定基準進行比對，因此任何未經規劃的變更都會顯現出來。

我們正以開源元件開發自有平台軟體，用於資產清冊管理、監控與燒機測試自動化。客戶入口網站與公開 API 也屬於這項工作的一部分，目前尚未推出。

我們負責找出並修復硬體、機房、散熱與叢集網路的故障，並立即隔離出現致命故障的 GPU。

隔離會讓受影響的硬體停止服務，直到故障修復為止，因此不會有任何工作被分派到該硬體上。XID 13 與 XID 31 可能源自應用程式而非 GPU，因此我們會在其反覆出現並超過約定次數時才採取行動。當 NCCL 工作停滯時，我們會檢查同一時間點的叢集網路事件，以找出造成停滯的連結或交換器故障。靜默資料損毀是最難察覺的故障之一，因為沒有任何機制會回報它，這也是疑似節點會保持隔離的原因。NVMe 硬碟會在達到耐用度上限前更換，而不是等到故障之後。

如果您的叢集使用由原廠代管的儲存設備，規格書承諾提供：原廠支援的設計、24/7 升級處理、每個層級的承諾輸送量與延遲、可見的使用量與配額，以及經過測試的復原能力。

• 原廠支援的設計。來自 VAST Data、WEKA 或 DDN 的儲存設備，依其原廠支援的設計建置。
• 24/7 升級處理。儲存問題可在任何時段升級處理。
• 每個層級的輸送量與延遲。每個儲存層級都有承諾的輸送量與延遲，讓您可以依據已知數值規劃工作與檢查點。
• 使用量與配額。使用量與配額清楚可見，容量不會在無人察覺的情況下耗盡。
• 經過測試的復原。復原程序經過實際測試，而不只是寫成文件。

兩種儲存選項，即儲存設備與供您自有軟體使用的儲存節點，在我們的儲存與網路頁面中都有說明。

我們以頻外方式收集硬體遙測資料，維運遙測資料至少保存 30 天，事件與狀態歷史紀錄至少保存 12 個月。

頻外遙測資料透過 Redfish 從伺服器的 BMC 取得，因此即使作業系統停止回報，它仍會持續回報。網路與機房遙測資料在可取得時一併收集。保存至少 12 個月的事件與狀態歷史紀錄，代表即使故障相隔數月才再次發生，仍可追溯到先前的發生紀錄。

在上述任何承諾適用之前，每個叢集都會先通過我們燒機與驗收頁面所列的測試。如果您也希望由我們維運您伺服器上的平台層，請參閱代管 Kubernetes。