گیت‌هاب دلیل ۸ ساعت قطع بودنش رو گفت. ساده بخوام توضیح بدم:

دلیل اصلی این بوده که لود بالانسر اینقدر بهش فشار اومده که ترکیده.
لود بالانسر چیه؟ کارش اینه که درخواست‌های ورودی رو بین نسخه‌های مختلف از پروژه پخش کنه تا به یکیش زیاد فشار نیاد. معمولا اینجوریه که از پروژه شما چند تا نسخه اجرا می‌شه و لودبالانسر دیتا رو بین اینها پخش می‌کنه، و هروقت هم ترافیک زیاد شد خودکار تعداد اون نسخه‌ها از پروژه زیاد می‌شه تا هیچ‌کدوم از نسخه ها بهش بیش از حد فشار نیاد.

ولی معمولا پروژه رو به تنهایی اجرا نمی‌کنیم، یک سری سرویس/پروژه هم کنارش اجرا می‌شن تا بهش کمک کنن، به این پروژه‌ها می‌گن sidecar. ریشه مشکل، تنظیمات اشتباه یک sidecar بوده. اینجوری بوده که سایدکار تنظیم شده بود تا فقط به یک تعداد مشخص درخواست هم‌زمان جواب بده، و وقتی از اون تعداد بیشتر می‌شد دیگه درست کار نمی‌کرد. اما اون مکانیزمی که حواسش بود که اگر به این نسخه‌ها (به‌علاوه سایدکارهاشون) فشار اومد خودکار تعدادشون رو زیاد کنه، به تنظیمات سایدکار توجه نمی‌کرد و فقط مثلا وقتی رم بیشتر از یک حدی پر می‌شد یه نسخه دیگه رو ران می‌کرد. یعنی سیستم نمی‌تونست تعداد نسخه های پروژه رو خودکار زیاد کنه. به همین خاطر نسخه های موجود از پروژه زیر فشار ترکیده بودن و جواب نمی‌دادن.

این باعث شد اون لود بالانسر هم زیر فشار بیشتری بره: هم سرویس‌های دیگه وقتی از این لود بالانسر جواب نمی‌گرفتن دوباره درخواست می‌فرستادن (retry)، و هم خود لود بالانسر برای رسیدگی به درخواست‌های لاگین یه مکانیزم تلاش مجدد داخلی خوش‌بینانه داشت که باعث می‌شد خودش هم به خودش فشار اضافه بیاره. جدا از اینا، خود کاربرهای عادی هم وقتی صفحه‌شون ارور می‌خورد هی رفرش/تلاش مجدد می‌کردن، و یه سری ربات هم بودن که داشتن از گیت‌هاب دیتا/فایل برمی‌داشتن و اونام احتمالا وقتی ارور می‌خوردن دوباره تلاش می‌کردن. این‌همه تلاش مجدد از منابع مختلف روی هم جمع شد و کار راه اندازش مجدد سرویس ها رو سخت‌تر کرد.

هم‌زمان یه اتفاق دیگه هم افتاد: کوپایلت (هوش مصنوعی VS Code) سر لاگین کردن هی ارور می‌خورد و خودش هم هی دوباره تلاش می‌کرد. اینقدر این تلاش مجددها زیاد شد که فشار روی سیستم ۱۰ برابر حالت عادی شد و ریکاوری کندتر شد.

چطوری درستش کردن؟ اول سریع ترافیک رو به یه دیتاسنتر دیگه هدایت کردن، بعد اون نسخه از لود بالانسرها که مشکل داشت رو قطع کردن، کلا لاگین کوپایلت رو موقتا مسدود کردن تا درخواست جدید نفرسته، تلاش‌های مجدد رو هم توی خود لود بالانسرها کمتر کردن تا اگر سرویسی قطع شد ترافیک داخلی اونقدر زیاد نشه که خود سیستم خودشو بترکونه. دارن باگ کد VS Code رو رفع می‌کنن تا مکانیزم تلاش مجددش درست بشه، تنظیمات سایدکار رو درست کردن، و تنظیمات اون سیستمی که تعداد نسخه هارو زیاد میکنه رو هم اصلاح کردن تا از این به بعد توی این حالت متوجه وضعیت بشه و تعداد نسخه‌ها رو زیاد کنه.

این اتفاق برام جالب بود و کلی ازش یاد گرفتم. مثلا اینکه از پیاده‌سازی مکانیزم تلاش مجدد ساده رد نشم و خیلی خوش‌بینانه پیاده‌سازیش نکنم.

مکانیزم تلاش مجدد تلگرام رو احتمالا دیدید: وقتی فیلترشکنتون قطع می‌شه، اولش تند‌تند تلاش می‌کنه به تلگرام وصل بشه، ولی وقتی چندتا درخواست فرستاد و متوجه شد نمی‌تونه وصل بشه، فاصله بین تلاش‌های بعدی رو بیشتر می‌کنه. اینجوری اگر مشکل از اینترنت کاربر نبود و مشکل توی سرویس خود تلگرام بود، کلاینت‌ها سرورها رو منفجر نمی‌کنند.

لینک صفحه:

https://www.githubstatus.com/incidents/zkxwbgr0cnmx

@networkti #networkti

یک اتفاق بد افتاده 😅
سرویس نیتر (Nitter) تعطیل شد!
همون سرویسی که اجازه میداد دفید از تویتر/ایکس پست کاربر هارو بیاره و نمایش بده!
دلیلشم اینه که دوروز پیش ایکس واسشون اخطار حقوقی فرستاده و اونها هم سرویس های عمومیشون رو خاموش کردن!

به همین دلیل فعلا توی اکانت های دفید قسمت اکانت های تویتر کار‌ نمیکنه.
البته چنل های تلگرام و پیامرسان مشکلی ندارن.

اگر سرور شخصی دفید داشتید و از قسمت تویترش استفاده میکردید احتمالا بتونید نسخه های عمومی نیتر که بقیه اوردن بالا رو پیدا کنید استفاده کنید. احتمالا میتونید خودتون هم یک نسخشو ران کنید (من تاحالا اینکارو نکردم)

واسه دفید هم میرم تلاش میکنم یک راه دیگه پیدا کنم یا یک سرور شخصی نیتر بالا بیارم

@networkti #networkti