Workday宕机源于自家灾备测试，员工无法打卡和查看工资

许多大型雇主用来处理薪资、上下班打卡和休假的软件 Workday，在自身应急备份测试出错后，服务对客户中断。公司检查灾难恢复系统时发现，备份服务意外连接到了客户日常使用的生产数据库，导致记录状态不一致。Workday随后将受影响的系统下线进行修复。

对员工来说，这次故障意味着登录页面显示“Workday目前无法使用”。受影响公司的员工无法上下班打卡、查看薪资信息、申请休假或完成福利登记；向其他公司系统传输数据的定时任务也可能失败。原本用于确保服务在灾难期间持续运行的安全网，反而让服务停摆。

此次故障之所以影响不止人力资源部门，是因为波及范围可能很广。Workday表示，超过11,500家机构在使用其软件；公开客户名单包括沃尔玛、塔吉特、Netflix、Chipotle、西南航空、美国能源部和NASA喷气推进实验室。公司没有透露具体有多少客户受到影响，只称波及“部分客户”，因此，网上流传的“这些雇主全都停摆”之类说法超出了已知事实。据 UC Today 报道，故障追踪网站记录到来自美国和印度的故障报告。

Workday在客户状态页面发布、并由华盛顿大学 IT 团队引用的解释，措辞相当直白。通知称：“在验证灾难恢复租户的每周维护窗口时，我们发现灾难恢复站点中的租户服务意外连接到了生产数据库。”通知还说，数据因此处于“状态不一致”的情形，可能导致用户打开账户时出错，也可能使任务无法完成。随后，公司将其称为 WD1 的客户组中的所有生产环境都转入维护模式，并承诺每30分钟发布一次更新。

这番解释仍没有回答最关键的问题。灾难恢复副本的存在，正是为了防止一处出现问题时波及另一处；而这次测试却触及了真实的生产系统。Workday没有说明这条连接路径为何存在，也没有说明是否有记录丢失，还是仅仅出现了不匹配。公司的沟通方式也招致不满。Reddit 的 sysadmin 和 Workday 论坛上的管理员称，问题在首条客户通知发出数小时前就已开始，但 Workday 尚未证实这一时间线。论坛上分享的一封客户邮件也承认，恢复时间无法预估，并建议有关键期限的公司切换到业务连续性计划。

对员工而言，实际影响取决于故障发生的时机。无法打卡的小时工需要人工补录工时，赶着在福利登记截止前完成手续的人则会发现入口已关闭。部分雇主不得不调整期限：埃默森学院表示，因这次故障延长了开放登记期。此次事件也发生在职场软件经历糟糕一周的尾声；此前，Microsoft 365故障导致 Outlook 和 Exchange 邮件服务连续第二天仍不稳定。

目前已知的时间线如下：埃默森学院称，Workday于11月13日星期五下午5点15分左右将系统下线；LiveNOW from FOX报道称，Downdetector在下午5点刚过便记录到近3,000条故障报告。Workday发言人表示，公司“正紧急调查并解决问题”，并向受影响客户致歉。到星期六上午，Workday告知客户，预计大多数客户的环境将在11月14日星期六美东时间上午11点前完成重新编制索引并重新开放，部分客户可能需要更长时间；公司将通过支持工单联系这些客户。埃默森学院延长后的登记期限现为11月16日星期一美东时间中午。

服务恢复，并不能解答雇主如今向供应商提出的更棘手问题。他们想知道的是：一项旨在证明 Workday 能够抵御灾难的测试，为何会连接到本应受到保护的数据。

标签: IT故障, Workday, 云服务, 人力资源软件, 灾难恢复, 薪资