运维承诺

事件处理遵循同一套流程：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 硬盘会在达到耐久度上限前更换，而不是等到出现故障之后。

如果您的集群使用由原厂托管的存储设备，规格书承诺提供：原厂支持的设计、7×24 小时升级处理、每个层级承诺的吞吐量与延迟、可见的使用量与配额，以及经过测试的恢复能力。

• 原厂支持的设计。存储设备来自 VAST Data、WEKA 或 DDN，按其原厂支持的设计构建。
• 7×24 小时升级处理。存储问题可在任何时间升级处理。
• 每个层级的吞吐量与延迟。每个存储层级都有承诺的吞吐量与延迟，您可以依据已知数值规划作业与检查点。
• 使用量与配额。使用量与配额清楚可见，容量不会在无人察觉的情况下耗尽。
• 经过测试的恢复。恢复流程经过实际测试，而不只是写成文档。

两种存储方案，即存储设备与供您自有软件使用的存储节点，在我们的存储与网络页面中都有介绍。

我们以带外方式收集硬件遥测数据，运维遥测数据至少保存 30 天，事件与状态历史记录至少保存 12 个月。

带外遥测数据通过 Redfish 从服务器的 BMC 获取，因此即使操作系统停止上报，它仍会持续上报。网络与机房遥测数据在可获取时一并收集。保存至少 12 个月的事件与状态历史记录，意味着即使某个故障相隔数月才再次出现，仍可追溯到之前的发生记录。

在上述任何承诺适用之前，每个集群都会先通过我们老化测试与验收页面所列的测试。如果您也希望由我们运维您服务器上的平台层，请参阅托管 Kubernetes。