一台服务器在00:32断电，我们在08:18发现。

# 服务器于00:32断电，我们于08:18发现 来源：https://danubedata.ro/blog/storage-power-loss-postmortem-august-2026 > **已解决。** 该事件发生在2026年8月17日00:32至08:47 UTC，现已关闭。**无客户数据丢失、损坏或泄露。** 若您的部署在此时间窗口内失败，它不会自动重试——请再次触发，即可完成部署。以下为事件完整始末及我们所做变更的详细说明。 2026年8月17日（周日）00:32 UTC，我们的一台存储服务器断电。它既未重启，也未崩溃，只是突然停止运行，并保持关机状态直至08:22 UTC工程师手动按下电源按钮。 在八小时十五分钟内，S3兼容对象存储、容器仓库、无服务器部署和静态站点部署均不可用。运行中的应用程序持续提供服务，无数据丢失。 我们的状态页在00:35 UTC检测到故障并自动创建事件——事发仅三分钟后。该检测准确无误，公开透明，并在故障持续期间始终保持更新。 无人查看状态页。直到08:18 UTC，一位工程师因其他原因打开状态页，才注意到众多服务显示红色警报。 这一间隔——系统知晓与人员知晓之间的时间差——才是真正的事故核心。其余皆为细节。 ## 客户所见现象 故障有一个根本原因和四个表象，这解释了为何状态页显示的故障范围比单台机器宕机应有的影响更大。 - **对象存储**返回连接被拒错误，而非响应缓慢。S3完全不可用，而非性能降级。 - **容器仓库**随对象存储一同宕机，因为仓库的blob数据存储在对象存储中。 - **无服务器与静态站点部署**因此失败，因它们通过该仓库推送和拉取镜像。失败的部署保持失败状态——它们不会自动重试，后续需要手动重新触发。 - **现有工作负载不受影响。** 应用程序在整个过程中持续提供当前版本服务。 一个细节影响了部分客户，在此需明确说明：**在无服务器容器上仅更改环境变量仍会联系仓库。** Knative在每个新修订版中都会将镜像标签解析为摘要，因此即使部署重用您已推送的镜像，只要仓库宕机就会失败。若您在此期间假定仅变更环境变量是安全的，这种假设虽合理但不正确。 ## 为何单台机器导致全服务中断 这是关键所在，却非我们预先计划阐述的部分。 客户对象数据采用纠删码存储——每个对象被分割为四个数据块和两个校验块，共六份拷贝，任意四份均可重建对象。理论上可承受两份丢失。 问题在于*这六份拷贝允许存放的位置*。 我们的存储集群将数据块分散在各独立磁盘上，但不要求它们位于不同机器。每台存储服务器承载大量磁盘。因此当一台服务器宕机时，它平均带走每个对象六份拷贝中的一点五份——大量对象实际丢失了两至三份拷贝。 - 丢失六份中的一份：对象仍可访问。 - 丢失两份：低于安全服务所需的最低数量——读取操作停止。 - 丢失三份：低于重建所需的四份——在磁盘恢复前无法读取。 这就是故障导致完全中断而非部分中断的原因，也是机器关机期间无法自愈的原因。数据从未丢失，只是在硬件恢复前无法访问。 显而易见的解决方案是要求六份拷贝必须分布在六台不同机器上。**当日我们无法实现此方案，因为四加二方案需要六个故障域，而我们仅有四台存储机器。** 这从来不是一个配置开关就能解决的问题，而是一项长期被默认配置掩盖的容量规划决策。 额外的存储容量本已规划中，**此次事件后，我们优先实施对象存储的主机级冗余方案。** 我们此处不设定具体日期——宁愿在方案就绪后公布，而非承诺一周后修订计划。 第二个较小的次要问题加剧了影响。除了主体数据，对象存储还维护少量内部簿记记录，这些记录以两份副本存储而非采用纠删码。这些副本同样允许存放在同一台机器上——少数关键记录（包括存储网关启动时读取的记录）的两份副本均位于故障服务器上。正是这微小的记录差异，导致*降级读取*变为*连接被拒*。数百TB客户数据的恢复能力，竟逊于描述其的几KB配置数据。 此部分无需新硬件。将簿记记录迁移至三份跨三台独立机器的副本，可在现有服务器上实现，且这是将完全中断转变为缓慢响应的关键变更。此任务已列入优先队列。 ## 未遂危机 还有第二件未发生的事，我们宁愿告知您而非隐瞒。 当存储服务器消失时，集群开始将缺失副本重建至剩余机器。这本是正常行为。在此情况下，这意味着需将约115 TiB数据重建至三台服务器（它们共有140 TiB可用空间）。 该轨迹将在约97%容量时终结——超过集群完全停止写入的阈值，将通过自动化操作将读取中断转变为完全中断，无需额外硬件故障。按观测的重建速度，此过程约需五天，因此我们有数日缓冲而非数小时。但趋势已显异常，我们并未抑制重建过程。 根本性教训令人不适却简洁：**在71%利用率下，四节点集群无法承受单节点的永久丢失。** 应对此类情况需要显著更多可用空间或更多机器。 ## 断电原因 我们尚不明确，亦不妄加揣测。 所有软件可见原因均已排除。未发生内核崩溃、崩溃日志、任何内存错误或过热事件。所有十块硬盘健康检查均零错误。在宕机前，该机器已连续运行103天，未出现任何内核警告。 这也非重启事件。系统日志在一句话中途结束，直到八小时后手动开机前毫无启动记录。存储层独立确认是突然断电而非关机。 硬件供应商报告数据中心当时无电力事件，且无该机器本身的监控数据。可进行完整硬件检查，但需存储节点约六小时停机时间。目前机器运行正常时，停机成本高于检查收益。该事件已记录在案。**若再次发生，我们将立即预约检查**，本次事件证据将使诊断速度大幅提升。 ## 当日所做变更 恢复后数小时内实施两项变更。 ### 1. 值班人员现在将接到电话通知 在此事件前，平台事故仅通过邮件通知一人。周日凌晨00:35，邮件并非有效警报。 当事件出现在公开状态页时，系统将向值班人员发起语音通话，同时发送短信。三个设计选择尤为关键，因其确保可靠性： - **刻意独立于我们的常规通知系统。** 常规系统应用偏好设置、摘要、频率限制和静默期——这些对客户通知合理，但对寻呼机绝对错误。寻呼机警报不可被抑制。 - **语音消息内置于通话请求中**，而非从自身基础设施的页面获取。被报告的宕机很可能正是本应提供该页面的服务。 - **无法由历史记录触发。** 事后撰写的事件记录（包括本次事后分析背后的补录条目）将被忽略。事后分析不应在凌晨3点触发电话呼叫。 ### 2. 可自动重启宕机机器的监控程序 我们的服务器暴露管理API，可报告实际电源状态并执行电源按钮操作。最终，八小时的中断源于无人清醒去按下按钮。 监控程序现每分钟探测每台服务器，并可无人值守按下该按钮。由于此操作错误的后果极其严重——向*健康*的存储节点发送关机命令，导致其本应预防的中断——几乎所有工作都致力于使其拒绝误操作： - **它不运行于所监控的基础设施上。** 监控程序若运行于被监控系统内，将随其一同宕机。 - **必须达成四重独立信号共识**——网络可达性、集群健康状态、报告电源状态、工作负载健康——方可执行操作。 - **同时两台以上机器故障被视为监控或网络故障，绝非同时硬件故障。** 它不会对关联性中断采取行动。 - **它不会猜测电源状态。** 若硬件无法确认机器确实关机，监控程序将发出警报并停止。 - 在探测失败与实际行动之间，设有确认窗口、冷却期、健康工作负载否决权等多项互锁机制。 决策逻辑为单一纯函数且无副作用，因此所有防护措施均由测试覆盖而非依赖侥幸。 该程序已通过不光彩的方式证明价值：次日清晨，它因一台完全健康的机器发出警报——触发于确认窗口应用前的代码路径。单个丢弃的网络包即足以触发。此问题已修复，我们宁愿如此发现而非通过其他方式。 ## 尚未修复的问题 我们宁愿公布此清单而非粉饰太平。 - **存储布局尚未修复。** 在数据与簿记副本确保存放于不同机器之前，单台机器故障仍将中断对象存储。监控程序缩短中断时间，但无法完全避免。簿记部分无需新硬件，其余部分需尚未添加的规划容量。 - **容量余量过薄**，无法吸收节点永久丢失。与前述扩容计划时间相同。 - **值班人员仅单一号码。** 单一接收者在唯一旨在消除单点故障的系统中成为单点故障。 - **断电根本原因未明**，我们选择待再次发生时再行排查。 ## 从此事汲取的教训 **检测与通知是不同系统，而我们仅构建了其一。** 我们的监控在八小时内准确、快速且公开，而众人皆在熟睡。无人被惊醒的监控只是记录，而非警报。 **冗余有其形态，形态即关键属性。** “六份副本”与“允许共享机器的六份副本”是完全不同的保障等级。我们配置了后者，却误以为拥有了前者。 **最微小的组件造成了最大破坏。** 数百TB客户数据按设计降级。几KB的内部簿记——因体积小而存储时未被同等重视——却将服务从缓慢降至不可用。若您运行类似系统，请优先审计最小的数据池。 **在客户实际所处环境中验证恢复能力。** 事件期间，我们曾一度认为仓库已恢复，因其返回了认证响应。该响应来自从未接触存储的层级。若据此行动，我们会告知三位客户重试仍损坏的服务。唯一有效的测试是读取真实数据的请求。 ## 当前状态 无客户数据丢失、损坏或泄露。备份在整个过程中保持完整。 若您的部署在此时间窗口内失败，它们不会自动重试——请再次触发，即可完成。 我们承诺的内容具体而非空泛：**我们将变更存储布局，使单台机器故障导致服务降级而非中断，并添加该变更所需的容量。** 完成后我们将发布后续公告，而非现在公布时间表。 我们为此次中断致歉，尤其为系统知晓而我们未能知晓的八小时深感抱歉。