发生了什么
2019 年 5 月 17 日,Salesforce 运行了一个与其 Pardot 营销产品相关的数据库脚本,该脚本“导致授予用户的数据访问权限超出预期范围”:现任和前任 Pardot 用户都可以读取和编辑其组织内的所有内容,无视权限设置。为控制暴露范围,Salesforce 封锁了所有包含受影响客户的实例——共计 105 个实例——使与 Pardot 毫无关系的租户也一并宕机。
完整的中断持续了 15 小时 8 分钟,于 5 月 18 日太平洋夏令时 01:04 结束——而同一分钟又开始了新的中断。为使实例可以安全重新开放,Salesforce 清除了受影响用户的权限,仅恢复管理员账户,并告知客户手动重新分配用户权限。整个周末,它编写了一个从备份恢复权限的脚本,但到周日时报告成功率为 89%,因此大约每十个组织中仍有一个的用户权限被清除——而且在某些运行中,该脚本重新授予了它本应移除的广泛访问权限。
修复工作持续到下一周:到 5 月 20 日周一,已有数千张工单处于开放状态,沙盒实例仍然宕机,工程高级副总裁 Anmol Bhasin 在客户电话会议上道歉,称第一次修复“并未成功”,所有可用的工程资源都已投入该问题。这次修复变成了比最初故障更长的一次二次中断。
代价是什么
105 个实例下线;约 15 小时的完全中断,随后是数天的只读清理;周末的恢复脚本对大约十分之一的组织失败
为什么会发生
该变更远远超出了预期范围:一项针对部分 Pardot 组织的权限修复影响了整个平台,而在用户看到本不该看到的数据之前,没有任何防护机制发现范围的扩大。
唯一安全的控制措施是将整个实例下线,因此一个产品团队的错误变成了同一基础设施上无关客户的共同中断。
回滚从未被设计过:恢复脚本是在压力下于周末编写的,在约 11% 的组织上失败,有时还重新授予了它本应移除的访问权限。
恢复工作把负担推给了客户——管理员手动重建用户权限——将一天的事件拉长为一周的清理和支持负担。
教训
未限定范围的数据库脚本是公司级风险。为每项变更限定范围,分阶段推出,并先构建回滚方案——否则疗法会比疾病本身锁住更多客户。
后续
访问权限从 5 月 18 日起逐步恢复;大多数组织到 5 月 20 日周一已恢复工作,沙盒和滞后的组织则又花了数天,因为 Salesforce 逐个实例运行其恢复脚本。Salesforce 表示,对大多数客户而言,除权限检查外无需采取其他行动,但该事件已成为多租户 SaaS 中变更范围界定和爆炸半径控制的经典案例——也是平台团队像对待代码部署一样谨慎对待生产环境数据库脚本的一个原因。
从这里,追溯依据
参考来源
- Salesforce? Salesfarce: Cloud giant in multi-hour meltdown after database blunder grants users access to all data The Register · theregister.com ·
- Salesforce says a major issue with its cloud service results in outage for some customers CNBC · cnbc.com ·
- Salesforces Pardot went down for 15 hours, exposing data in the cloud MarTech · martech.org ·
- Salesforce outage continues: 105 instances down, fix not yet functional The Register · theregister.com ·