轉自 OSC開源社群
2023 年 11 月 27 日晚間， 滴滴因系統故障導致 App 服務異常 ，不顯示定位且無法打車。11 月 27 日晚，滴滴出行進行了回復：非常抱歉，由於系統故障。
2023 年 11 月 28 日早間，滴滴出行訊息稱，網約車等服務已恢復，騎車等在陸續修復中。11 月 28 日，在滴滴發出公告的同時，記者在上海、深圳等地使用滴滴呼叫網約車，發現網約車功能並未恢復使用，網路載入異常，仍無法打車。11 月 28 日，滴滴向記者回應稱，網約車服務已恢復，司機乘客權益陸續恢復補發。
11 月 29 日，滴滴再次發文致歉，稱初步確定事故起因是底層系統軟體發生故障 。
來源： https://weibo.com/2838754010/NuMAAaUEl
在滴滴官方釋出這份公告之前，已經有資深 IT 技術人士分析：「從表現上看，打車、共享單車全掛，不同的業務板塊之間應該是有隔離的，說明問題出在更加底層的基礎設施。攻擊者一般只能存取到套用層，基礎設施存取不到。要麽是被攻擊者打穿，要麽是自己系統操作不慎掛了。即便是前者，也算是一種系統缺陷，才會被打穿。」
360 安全專家認為，滴滴閃崩背後的技術原因可能有六種：
第一，系統更新升級過程中出現了編程錯誤、邏輯錯誤或未處理的異常情況：一般情況下，互聯網廠商釋出更新都會在晚上，與滴滴發生故障的時間也能對應，當然業務升級維護是放量更新，但現在滴滴全平台、全業務都故障了，說明肯定是他 「家裏」 的問題。
第二，伺服器故障：比如滴滴的核心機房，可能恒溫恒濕環境出了問題，導致伺服器過熱、CPU 燒了，或者核心機房所在地發生了自然災害如地震、洪水、海嘯等，這種情況下，硬體需要重新更換，裏面的服務軟體也需要重新配置，恢復周期相對較長，但這個可能性比較小。
第三，第三方服務故障：滴滴的後台架構可能使用了第三方服務或者元件。如果第三方出了問題，也可能會影響滴滴的正常執行。但出於安全性考慮，滴滴可能不會將核心業務托管給第三方，不過這個可能性也較小。
第四，DDOS 攻擊：黑客采用 分布式拒絕服務 的方式，搶占了大量的伺服器資源，導致使用者無法存取，但這個不太可能，因為 DDos 不會導致數據出錯，而且滴滴從體量上來說，有足夠的成本和能力去對抗。
第五，其他網路攻擊：某些黑灰產團伙可能會透過拖庫盜取數據，然後在暗網上售賣，在這個過程中不排除會有誤操作，破壞了資料庫。
第六，勒索病毒：網路攻擊黑客對滴滴的底層數據、業務程式碼進行了加密。據披露現象，使用者的賬單和打車數據都算錯了，存在一定可能是滴滴為了避免更大損失主動暫停了業務。近期勒索攻擊事件屢屢發生，月初，某金融機構就是因為遭遇勒索病毒攻擊造成了業務停擺。
不過也有網路安全公司專家認為，如果是來自外部的黑客攻擊，公司一般會在第一時間進行聲明。他猜測更集中於滴滴發生了內部重大業務調整，或有新業務接入原系統，但沒有做好預案，導致關聯業務或關聯系統出現重大故障，這是大公司系統故障最常見的原因。
因此對於滴滴此次大規模的長時間故障，有行業人士認為， 降本增效可能也是原因之一 。
該人士認為， 互聯網公司核心業務頻繁宕機，且長時間宕機，是降本增效的附屬品之一。系統投資少了，維護資源少了，程式設計師更換頻繁了，BUG 就多 。
他舉例稱，一般在業務上行階段都有冗余，為了迎接隨時爆發的訂單，上行階段要維持負載的上限不能過大，比如平時 70%，這樣遇到一個小爆發不用擔心會出問題，足以應對小高峰；但是下行期的邏輯就不同了，負載很高的時候抗一抗就行了，雖然後面遇到小高峰可能會難受，但是隨著時間的推移總體負載會下降。
插播一條：如果你近期準備面試跳槽， 00+ 道，幾乎覆蓋了所有主流 Java 技術面試題。
最後來看一下網傳的訊息，有同行說滴滴這次嚴重故障是升級 k8s 版本導致，當時 SRE 工程師定位了三個小時都沒定位到問題。
從滴滴公開的技術分享來看，滴滴彈性雲在上個月升級了 k8s 版本：從 k8s 1.12 升級到 1.20。（ K8s 1.12釋出於 2018 年， K8s 1.20 釋出於 2020 年。 ）
