2019 年の夏の第 XNUMX 月の終わりと第 XNUMX 月の初めは困難な状況となり、世界的な IT サービスの大幅な低下がいくつか見られました。注目に値するものとしては、CloudFlare インフラストラクチャにおける XNUMX つの重大なインシデントが挙げられます (XNUMX つ目は、米国の一部の ISP 側の BGP に対する曲がった手と怠慢な態度によるものでした。XNUMX つ目は、CF 自体の曲がった展開で、CF を使用するすべての人に影響を及ぼしました) 、これらは多くの注目すべきサービスです）と Facebook CDN インフラストラクチャの動作が不安定です（Instagram や WhatsApp を含むすべての FB 製品に影響します）。また、世界的な背景から見て障害はそれほど目立たなかったものの、当社もこの分布に該当しなければなりませんでした。すでに何者かが黒いヘリコプターと「主権的」陰謀を巻き込み始めているため、私たちは事件の事後解剖を公開します。
03.07.2019、16：05
内部ネットワーク接続の障害と同様に、リソースに関する問題が記録され始めました。すべてを完全にチェックしていないため、内部ネットワークのインターネットへのアクセス (NAT) に問題があることが明らかになり、DataLine への外部チャネルのパフォーマンスに障害が発生し始め、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
Habr の制限された機能が復元されました。
03.07.2019、17：43
しかし最終的には、境界ルーターの 1 つを介してトラフィックを整理するための比較的安全なソリューションが見つかり、すぐに設置されました。インターネット接続が復旧しました。
次の数分間で、監視システムから監視エージェントの機能の復旧に関する多くの通知が届きましたが、ネーム サーバー (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 (プロキシ サーバー) に外部アドレスを登録するのを忘れていたことが判明し、すぐに修正されました。
所見
- 以前はその適合性について疑問の種があったこの装置は失敗した。これはネットワークの発展を妨げ、互換性の問題があるため、作業から排除する計画がありましたが、同時に重要な機能を実行していたため、サービスを中断せずに置き換えるのは技術的に困難でした。これで次に進むことができます。
- DNS の問題は、NAT ネットワークの外側の新しいバックボーン ネットワークの近くに移動し、変換なしでグレー ネットワークへの完全な接続を維持することで回避できます (これはインシデント前の計画でした)。
- RDBMS クラスターを組み立てるときは、ドメイン名を使用しないでください。IP アドレスを透過的に変更する利便性は特に必要ありません。そのような操作ではクラスターの再構築が必要になるからです。この決定は歴史的な理由と、まず第一に、RDBMS 構成におけるエンドポイントの名前が明らかであることによって決定されました。一般に、古典的な罠です。
- 原則として、「ルネットの主権化」に匹敵する演習が実施されているが、自律生存能力の強化という点では考慮すべき点がある。
出所： habr.com