就是現(xiàn)在，根據(jù) DownDetector 故障檢測(cè)器的報(bào)告，幾乎你能想到的主要互聯(lián)網(wǎng)服務(wù)供應(yīng)商都出現(xiàn)了顯著故障與錯(cuò)誤。背后的線索全部指向 Google 云平臺(tái) GCP 上的一場(chǎng)全局性大故障。

GCP 疑似因?yàn)楹诵牡纳矸莺驮L問管理（IAM）服務(wù)（內(nèi)部名為 Chemist）出現(xiàn)全球地域，全局性的服務(wù)不可用。這場(chǎng)故障的原因幾乎與前年 如出一轍。

GCP 的故障影響到 Cloudflare 的關(guān)鍵服務(wù)，進(jìn)一步導(dǎo)致承載了全球互聯(lián)網(wǎng) 20% 的流量的云平臺(tái) Cloudflare 出現(xiàn)故障。CF 故障進(jìn)一步將故障放大到互聯(lián)網(wǎng)的各個(gè)角落。包括 Cursor，Claude，Spotify，Discord，Snapchat，Supabase 等諸多知名應(yīng)用與服務(wù)都收到影響。

事件時(shí)間線

同時(shí)，Cloudflare 也發(fā)布了故障報(bào)告：

故障根本原因分析

根據(jù)Google在故障初期發(fā)布的信息，此次中斷是由身份和訪問管理（Identity and Access Management，IAM）服務(wù)的問題引起 （theregister.com[1] 有相關(guān)報(bào)道）

這次故障的原因，與阿里云在 2023年雙十一 的原因類似，都是由于身份驗(yàn)證、權(quán)限檢查的核心服務(wù)發(fā)生故障，進(jìn)而導(dǎo)致幾乎所有的云產(chǎn)品故障。

事故發(fā)生后不久，Google狀態(tài)頁直接提示“多項(xiàng)GCP產(chǎn)品因IAM服務(wù)問題而受到影響。這一點(diǎn)也在后續(xù)各種跡象中得到印證：許多用戶報(bào)告調(diào)用GCP API時(shí)出現(xiàn)諸如“visibility check failed”（可見性檢查失敗）或“cannot load policy”（無法加載策略）之類的錯(cuò)誤。這些錯(cuò)誤信息表明，請(qǐng)求被阻斷在權(quán)限/策略驗(yàn)證的環(huán)節(jié)，即云請(qǐng)求在到達(dá)目標(biāo)服務(wù)前就因?yàn)闄?quán)限或策略檢查無法通過而失敗。因此，可以推斷根因在于Google Cloud內(nèi)部的全局權(quán)限控制/策略服務(wù)出現(xiàn)異常。

Hacker News等技術(shù)社區(qū)的討論挖掘出更多細(xì)節(jié)。一位疑似Google內(nèi)部人士的評(píng)論提到，Google Cloud內(nèi)部有一個(gè)代號(hào)為“Chemist”的核心服務(wù)，正是負(fù)責(zé)所有API請(qǐng)求的項(xiàng)目狀態(tài)和策略檢查。根據(jù)Google官方文檔描述：Chemist在每個(gè)API請(qǐng)求到來時(shí)，會(huì)檢查項(xiàng)目是否激活、帳戶有無欠費(fèi)或被封禁、服務(wù)啟用狀態(tài)、地域訪問限制、VPC服務(wù)控制策略、超額配額（SuperQuota）以及其他各種策略；在請(qǐng)求完成后還會(huì)記錄遙測(cè)數(shù)據(jù)用于計(jì)費(fèi)和監(jiān)控

觸發(fā)因素分析

觸發(fā)因素分析：截至目前（事故發(fā)生次日），Google尚未公布詳細(xì)的事后分析報(bào)告（RCA），僅表示將在內(nèi)部調(diào)查完成后對(duì)外發(fā)布分析。因此具體的觸發(fā)原因只能根據(jù)現(xiàn)有信息推斷。

老馮認(rèn)為此次故障最大可能是因?yàn)?strong>配置或軟件更新錯(cuò)誤導(dǎo)致的：大型云服務(wù)商的全球性事故，常常源于配置變更或代碼更新的失誤。考慮到此次事故在太平洋時(shí)間上午突然發(fā)生，可能恰逢某個(gè)全球發(fā)布窗口或變更操作。

一種合理推測(cè)是：Google對(duì)IAM/策略服務(wù)進(jìn)行了某項(xiàng)更新（例如推送了錯(cuò)誤的配置規(guī)則或部署了有缺陷的軟件版本），結(jié)果導(dǎo)致該服務(wù)崩潰或拒絕請(qǐng)求，例如，阿里云 IAM 大故障的原因就是更新了 IAM 黑白名單配置導(dǎo)致其 依賴的 OSS 無法訪問導(dǎo)致的。

歷史上Google也發(fā)生過類似情況：如2020年12月的全球宕機(jī)事故，就源于內(nèi)部身份認(rèn)證系統(tǒng)因?yàn)?strong>存儲(chǔ)配額配置變更而觸發(fā)bug，最終讓身份服務(wù)癱瘓45分鐘。此次2025年故障的癥狀與之相似——都是核心身份/權(quán)限系統(tǒng)出了問題。很可能一次不當(dāng)?shù)淖兏笴hemist或相關(guān)IAM服務(wù)無法正常允許請(qǐng)求，從而“一票否決”了各項(xiàng)云操作。Google官方在事故中后期的表述也支持這一點(diǎn)：工程師發(fā)現(xiàn)了根本原因并采取措施，表明他們找到問題所在并進(jìn)行了回滾或修復(fù)

另外的可能觸發(fā)因素包括：網(wǎng)絡(luò)路由（BGP）故障，邊界/骨干網(wǎng)絡(luò)中斷，Google云內(nèi)部SDN（如Andromeda）問題。但似乎都沒有更多證據(jù)可以證明這一點(diǎn)。

結(jié)論

本次事故有極大概率是Google自身軟件或配置失誤引發(fā)的一場(chǎng)控制平面災(zāi)難，而非外部攻擊或純粹硬件故障。Google官方和多家媒體均未提及任何安全事件跡象。沒有證據(jù)表明發(fā)生了惡意入侵、DDoS等攻擊。一切線索都指向人為操作失誤：不是配置錯(cuò)誤，就是軟件Bug。

另一個(gè)值得警醒的現(xiàn)象是，Cloudflare 作為一家云廠商，卻對(duì)第三方 GCP 云平臺(tái)有著依賴，在這次故障中被間接拖垮，這確實(shí)是一件非常奇怪的事情。

這場(chǎng)故障揭示出大型公有云平臺(tái)的脆弱性： Google這次的控制服務(wù)故障，其影響都超出了單個(gè)公司的范疇，成為全網(wǎng)用戶共同承受的“多米諾骨牌”式中斷。這警示著整個(gè)科技行業(yè)：大型公有云廠商已經(jīng)成為互聯(lián)網(wǎng)世界的 “單點(diǎn)”，而這可并不是互聯(lián)網(wǎng)發(fā)明的初衷。

許多僅依賴自有服務(wù)器的獨(dú)立網(wǎng)站都在此次事故中完好無損 —— 大多數(shù)公司最好投資一些 IT人員，而不是將系統(tǒng)全部交給某個(gè)專有且極其復(fù)雜的云環(huán)境。否則，你會(huì)越來越依賴于你不認(rèn)識(shí)、無法控制、也無法直接溝通的人與服務(wù)。

References

[1]: https://cloud.google.com/service-infrastructure/docs/service-management/reference/rpc/google.api#control
[2]: https://status.cloud.google.com/
[3]: https://www.cloudflarestatus.com/incidents/25r9t0vz99rp

云計(jì)算泥石流專欄

馬工

馬工

馬工

馬工

馬工

Leo

馬工

馬工

馬工

馬工