水木社区手机版
首页
|版面-C程序设计语言(CProgramming)|
新版wap站已上线
返回
1/1
|
转到
主题:一个空指针导致google服务器大面积宕机 (转载)
楼主
|
VChart
|
2025-06-18 22:13:46
|
只看此ID
【 以下文字转载自 NewExpress 讨论区 】
发信人: bfield (哈根屌丝), 信区: NewExpress
标 题: 一个空指针导致google服务器大面积宕机
发信站: 水木社区 (Wed Jun 18 21:54:54 2025), 站内
前几天,工程师花了3小时才解决问题。
--
FROM 112.1.168.*
1楼
|
z16166
|
2025-06-20 11:26:43
|
只看此ID
跟是不是空指针关系不大
blog dot bytebytego dot com /p/how-the-google-cloud-outage-crashed
关键的工程失败
谷歌云服务中断并非单一错误造成的,而是一系列工程疏忽造成的,这些疏忽相互叠加。每个故障点,虽然单独来看很小,但却在将漏洞演变成全球性中断的过程中发挥了重要作用。
以下是导致整个问题的关键失误:
第一个也是最关键的失误是缺少功能开关。新的配额检查逻辑在所有区域都处于活动状态,无法在发布过程中逐步启用或禁用。功能开关是大型系统中的标准安全措施,允许在受控阶段激活新的代码路径。由于缺少功能开关,这个漏洞从一开始就存在于所有环境中。
其次,代码未能包含基本的空值检查。当引入包含空字段的策略时,系统未能妥善处理缺失值。相反,它遇到了空指针异常,导致处理该数据的每个区域中的服务控制二进制文件崩溃。
第三,谷歌的元数据复制系统完全按照设计运行。错误的策略数据几乎瞬间传播到所有区域,导致所有区域崩溃。全局复制流程没有内置延迟或验证检查点,无法在数据进入生产环境之前捕获格式错误的数据。
第四,“us-central1”区域的恢复工作暴露了另一个问题。当服务控制实例尝试重启时,它们会同时影响后端基础设施,从而产生“羊群效应”,导致区域 Spanner 数据库不堪重负。由于系统缺乏适当的随机指数退避算法,恢复过程非但没有缓解压力,反而产生了新的压力。
最后,监控和状态基础设施与核心系统一同出现故障。谷歌自己的云服务健康仪表盘在此次故障期间瘫痪,许多客户无法访问通常用于指导其响应的日志、警报或可观察性工具。这在危机高峰期造成了严重的可见性缺口。
--
FROM 222.129.207.*
1/1
|
转到
选择讨论区
首页
|
分区
|
热推
BYR-Team
©
2010.
KBS Dev-Team
©
2011
登录完整版