2019 年夏季第一個月末和第二個月開始的日子很艱難，全球 IT 服務出現了幾次大幅下降。 其中值得注意的是：CloudFlare 基礎設施中發生的兩起嚴重事件（第一起- 來自美國的一些ISP 的不法行為和對BGP 的疏忽態度；第二起- CF 本身的不正當部署，影響了每個使用CF 的人，以及許多值得注意的服務）以及 Facebook CDN 基礎設施運作不穩定（影響了所有 FB 產品，包括 Instagram 和 WhatsApp）。 我們還必須陷入分發的困境，儘管我們的中斷在全球背景下不太明顯。 有人已經開始拖入黑色直升機和「主權」陰謀，因此我們將發布事件的公開事後分析。
03.07.2019，16：05
資源問題開始被記錄，類似內部網路連線故障。 在沒有完全檢查所有內容後，他們開始對通往 DataLine 的外部通道的效能提出錯誤，因為很明顯問題出在內部網路對 Internet (NAT) 的存取上，以至於將 BGP 會話置於 DataLine 上。
03.07.2019，16：35
很明顯，提供網路位址轉換和從站點本地網路存取網際網路 (NAT) 的裝置發生了故障。 嘗試重新啟動設備並沒有導致任何結果，在收到技術支援的回應之前就開始尋找組織連接的替代選項，因為根據經驗，這很可能沒有幫助。
該設備還終止了客戶端 VPN 員工的傳入連接，這在一定程度上加劇了問題，並且遠端復原工作變得更加難以執行。
03.07.2019，16：40
我們試圖恢復先前運作良好的現有備份 NAT 方案。 但很明顯，多次網路整修使該計劃幾乎完全失效，因為它的修復充其量可能不起作用，或者在最壞的情況下，會破壞已經起作用的東西。
我們開始研究一些想法，將流量傳輸到一組為骨幹網路服務的新路由器，但由於核心網路中路由分佈的特殊性，這些想法似乎行不通。
03.07.2019，17：05
同時，在名稱伺服器上的名稱解析機制中發現了一個問題，這導致應用程式中解析端點時出現錯誤，並且他們開始用關鍵服務的記錄快速填充主機檔案。
03.07.2019，17：27
哈布爾的有限功能已恢復。
03.07.2019，17：43
但最終，找到了相對安全的解決方案，透過其中一個邊界路由器來組織流量，並很快安裝了該解決方案。 網路連線已恢復。
在接下來的幾分鐘裡，監控系統發出了大量關於監控代理功能恢復的通知，但由於名稱伺服器（dns）上的名稱解析機制被破壞，一些服務無法運作。
03.07.2019，17：52
NS 重新啟動並清除快取。 解析已恢復。
03.07.2019，17：55
除 MK、Freelansim 和 Toaster 外，所有服務均開始工作。
03.07.2019，18：02
MK 和 Freelansim 開始工作。
03.07.2019，18：07
使用 DataLine 恢復無辜的 BGP 會話。
03.07.2019，18：25
他們開始記錄資源問題，這是由於NAT池的外部位址發生變化，以及一些服務的acl中缺少該問題造成的，很快就得到了糾正。 烤麵包機立即開始工作。
03.07.2019，20：30
我們注意到與 Telegram 機器人相關的錯誤。 事實證明，他們忘記在幾個 acl（代理伺服器）中註冊外部位址，這一問題很快就得到了糾正。
發現
- 該設備先前曾引發對其適用性的質疑，但最終失敗了。 有計劃將其從工作中消除，因為它幹擾了網路的發展並存在相容性問題，但同時它執行了關鍵功能，這就是為什麼在不中斷服務的情況下進行任何替換在技術上都很困難。 現在你可以繼續前進了。
- 透過將它們移近 NAT 網路之外的新骨幹網絡，並且仍然與灰色網路保持完全連接而無需轉換（這是事件發生之前的計劃），可以避免 DNS 問題。
- 在組裝 RDBMS 叢集時不應該使用域名，因為透明地更改 IP 位址的便利性並不是特別必要，因為此類操作仍然需要重建叢集。 這項決定是由歷史原因決定的，首先是 RDBMS 配置中端點名稱的明顯性。 總的來說，是一個經典的陷阱。
- 原則上已經進行了類似「符文主權化」的演習；在加強自主生存能力方面有一些值得思考的地方。
來源： www.habr.com