تبين أن نهاية الشهر الأول وبداية الشهر الثاني من صيف 2019 كانت صعبة وتميزت بعدة انخفاضات كبيرة في خدمات تكنولوجيا المعلومات العالمية. من بين الحوادث البارزة: حادثان خطيران في البنية التحتية لـ CloudFlare (الأول - بأيدي ملتوية وإهمال تجاه BGP من جانب بعض مزودي خدمة الإنترنت من الولايات المتحدة الأمريكية؛ والثاني - مع نشر ملتوي لـ CF أنفسهم، مما أثر على كل من يستخدم CF ، وهذه العديد من الخدمات البارزة) والتشغيل غير المستقر للبنية التحتية لـ Facebook CDN (أثر على جميع منتجات FB، بما في ذلك Instagram وWhatsApp). كان علينا أيضًا أن ننشغل بالتوزيع، على الرغم من أن انقطاع الخدمة لدينا كان أقل وضوحًا بكثير على الخلفية العالمية. لقد بدأ شخص ما بالفعل في جر المروحيات السوداء والمؤامرات "السيادية"، لذلك نحن نصدر تقريرًا عامًا بعد الوفاة عن حادثتنا.
03.07.2019، 16: 05
بدأ تسجيل مشاكل تتعلق بالموارد، على غرار انقطاع الاتصال بالشبكة الداخلية. بعد عدم التحقق من كل شيء بشكل كامل، بدأوا في إلقاء اللوم على أداء القناة الخارجية تجاه DataLine، حيث أصبح من الواضح أن المشكلة كانت تتعلق بوصول الشبكة الداخلية إلى الإنترنت (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
أعد جلسة BGP البريئة مع DataLine.
03.07.2019، 18: 25
بدأوا في تسجيل مشاكل الموارد، والتي كانت بسبب التغيير في العنوان الخارجي لتجمع NAT وغيابه في قائمة التحكم في الوصول لعدد من الخدمات، والتي تم تصحيحها على الفور. بدأت المحمصة العمل على الفور.
03.07.2019، 20: 30
لقد لاحظنا أخطاء تتعلق بروبوتات Telegram. اتضح أنهم نسوا تسجيل العنوان الخارجي في اثنين من ACL (خوادم بروكسي)، والذي تم تصحيحه على الفور.
النتائج
- وقد فشلت المعدات التي أثارت الشكوك في السابق حول مدى ملاءمتها. وكانت هناك خطط لإزالتها من العمل، لأنها تتداخل مع تطوير الشبكة وتواجه مشاكل في التوافق، لكنها في الوقت نفسه تؤدي وظيفة حاسمة، ولهذا السبب كان أي استبدال صعبًا من الناحية الفنية دون انقطاع الخدمات. الآن يمكنك المضي قدما.
- يمكن تجنب مشكلة DNS عن طريق تقريبها من الشبكة الأساسية الجديدة خارج شبكة NAT مع الاستمرار في الاتصال الكامل بالشبكة الرمادية دون ترجمة (التي كانت الخطة قبل الحادث).
- لا يجب عليك استخدام أسماء النطاقات عند تجميع مجموعات RDBMS، نظرًا لأن سهولة تغيير عنوان IP بشفافية ليست ضرورية بشكل خاص، نظرًا لأن مثل هذه المعالجات لا تزال تتطلب إعادة بناء المجموعة. تم فرض هذا القرار لأسباب تاريخية، وقبل كل شيء، وضوح نقاط النهاية بالاسم في تكوينات RDBMS. بشكل عام، فخ كلاسيكي.
- من حيث المبدأ، تم إجراء تمارين مماثلة ل "سيادة الرونيت"، هناك شيء للتفكير فيه فيما يتعلق بتعزيز قدرات البقاء المستقل.
المصدر: www.habr.com