گزارش کالبدشکافی هابر: روی روزنامه افتاد

پایان اولین و آغاز ماه دوم تابستان 2019 دشوار بود و با چندین افت عمده در خدمات فناوری اطلاعات جهانی مشخص شد. از جمله موارد قابل توجه: دو حادثه جدی در زیرساخت CloudFlare (اول - با دست های کج و نگرش سهل انگارانه نسبت به BGP از سوی برخی از ISP های ایالات متحده؛ دوم - با استقرار نادرست خود CF، که همه افراد را تحت تأثیر قرار داد که از CF استفاده می کردند. و اینها بسیاری از خدمات قابل توجه هستند) و عملکرد ناپایدار زیرساخت CDN فیس بوک (بر همه محصولات FB از جمله اینستاگرام و واتساپ تأثیر گذاشته است). ما همچنین باید درگیر توزیع می شدیم، اگرچه قطعی ما در پس زمینه جهانی بسیار کمتر قابل توجه بود. کسی قبلاً شروع به کشیدن هلیکوپترهای سیاه و توطئه های "حاکمیت" کرده است، بنابراین ما در حال انتشار یک کالبدشکافی عمومی از حادثه خود هستیم.

گزارش کالبدشکافی هابر: روی روزنامه افتاد

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
عملکرد محدود Habr بازیابی شده است.

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 و عدم وجود آن در acl تعدادی از خدمات بود که به سرعت اصلاح شد. توستر بلافاصله شروع به کار کرد.

03.07.2019، 20: 30
متوجه خطاهای مربوط به ربات های تلگرام شدیم. معلوم شد که آنها فراموش کرده اند آدرس خارجی را در چند سرور acl (سرور پروکسی) ثبت کنند که به سرعت اصلاح شد.

گزارش کالبدشکافی هابر: روی روزنامه افتاد

یافته ها

  • تجهیزاتی که قبلاً در مورد مناسب بودن آن تردید ایجاد کرده بود، شکست خورد. برنامه‌هایی برای حذف آن از کار وجود داشت، زیرا در توسعه شبکه تداخل داشت و مشکلات سازگاری داشت، اما در عین حال عملکرد مهمی را انجام می‌داد، به همین دلیل است که هرگونه جایگزینی بدون وقفه در خدمات از نظر فنی دشوار بود. حالا می توانید ادامه دهید.
  • مشکل DNS را می توان با نزدیک کردن آنها به شبکه اصلی جدید خارج از شبکه NAT و همچنان اتصال کامل به شبکه خاکستری بدون ترجمه (که برنامه قبل از حادثه بود) اجتناب کرد.
  • هنگام جمع آوری خوشه های RDBMS نباید از نام های دامنه استفاده کنید، زیرا راحتی تغییر شفاف آدرس IP به ویژه ضروری نیست، زیرا چنین دستکاری هایی همچنان به بازسازی خوشه نیاز دارد. این تصمیم به دلایل تاریخی و اول از همه بدیهی بودن نقاط پایانی بر اساس نام در تنظیمات RDBMS دیکته شده است. به طور کلی، یک تله کلاسیک.
  • در اصل، تمرینات قابل مقایسه با "حاکمیت Runet" انجام شده است.

منبع: www.habr.com

اضافه کردن نظر