گیت‌هاب دوباره از دسترس خارج شد؛ قطعی گسترده‌ای که همه‌چیز را مختل کرد

به گزارش هفت صبح درخواست‌های API، اکشن‌ها (Actions)، وب‌هوک‌ها (Webhooks)، ایشوها (Issues)، پول‌ریکوئست‌ها (Pull Requests) و کوپایلت (Copilot) همگی با افت عملکرد مواجه شدند؛ برخی سرویس‌ها به‌صورت زنجیره‌ای و با گسترش ابعاد مشکل، به لیستِ دچار اختلال اضافه شدند. تنها عملیات‌های Git همچنان فعال بودند؛ تسلایی که برای توسعه‌دهنده‌ای که کل خط تولید (Pipeline) نرم‌افزارش بر سایر سرویس‌ها استوار است، چندان کارساز نیست.

وقتی داربست‌ها فرو می‌ریزند

آخرین قطعی گیت‌هاب تمام لایه‌هایی که توسعه‌دهندگان عملاً برای انتشار نرم‌افزار به آن‌ها نیاز دارند را هدف قرار داد؛ نه فقط سرویس میزبانی کد.

نرخ شکست (Failure rates) گویای عمق فاجعه است. ترافیک رابط کاربری وب و API با نرخ خطای تقریبی ۲۰ درصد مواجه شد. دانلود آرشیوها و محتوای خام مخازن (Repositories) تا ۵۰ درصد شکست خوردند. با گسترش این رخداد، گیت‌هاب سرویس‌های کوپایلت و گیت‌هاب پیجز (GitHub Pages) را نیز به لیست سرویس‌های تحت تأثیر اضافه کرد؛ این یعنی شعاع انفجار از همکاری و اتوماسیون، به برنامه‌نویسیِ هوش‌مصنوعی و انتشار وب‌سایت‌ها نیز کشیده شد. در حالی که دستور git clone هنوز کار می‌کرد، اما بررسی پول‌ریکوئست‌ها، تست‌های CI، استقرار (Deployment) مبتنی بر وب‌هوک و پیشنهادات کوپایلت همگی به‌شدت مختل شدند؛ حتی اگر تمام درخواست‌ها در سطح جهان شکست نخورده باشند.

نگاهی اجمالی به سرویس‌های تحت تأثیر:

• درخواست‌های API و رابط کاربری وب: نرخ خطای حدود ۲۰ درصد
• دانلود آرشیو و محتوای خام مخازن: نرخ شکست حدود ۵۰ درصد
• اکشن‌ها (Actions): توقف تست‌های خودکار و استقرارها
• وب‌هوک‌ها: اختلال در یکپارچه‌سازی‌های خارجی
• کوپایلت و گیت‌هاب پیجز: اضافه شدن به لیست در جریان گسترش اختلال

الگویی که گیت‌هاب نمی‌تواند نادیده بگیرد

تنها در ماه جولای هشت مورد اختلال رخ داد و قطعیِ آگوست که خودِ گیت‌هاب آن را «غیرقابل‌قبول» خواند، نشان می‌دهد که این یک بدشانسیِ گذرا نیست.

تا آخرین گزارش‌ها، گیت‌هاب هنوز دلیل اصلی قطعی دوشنبه را اعلام نکرده است. با این حال، پیش‌زمینه این اتفاق به‌سختی قابل نادیده گرفتن است. گزارشِ وضعیت دسترسیِ ماه جولایِ ۲۰۲۶ِ این شرکت، هشت مورد افت عملکرد مجزا را در آن ماه ثبت کرده بود. در ۸ جولای، رابط کاربری وب، REST API، GraphQL API، اکشن‌ها، پکیج‌ها، کوپایلت و عملیات‌های Git در محیط‌های «Enterprise Cloud» از دسترس خارج شدند. سپس در ۶ آگوست، یک به‌روزرسانیِ معمول در سرویسِ «اکشن‌ها» باعث بروز زنجیره‌ای از مشکلات در خوشه‌ها (Clusters) شد؛ چیزی شبیه به اینکه یک به‌روزرسانی کوچک، تمام فیوزهای یک ساختمان را بپراند. گیت‌هاب آن حادثه را «غیرقابل‌قبول» توصیف کرد و اعلام کرد که در حال تسریعِ اقدامات مربوط به جداسازی (Isolation) و تاب‌آوری (Resiliency) در بخش اکشن‌هاست.

استقرارهای معمول نباید پلتفرم شما را به آتش بکشند، اما این اتفاق افتاد؛ و بازیابی سیستم مستلزم افزایش ظرفیت و محدود کردنِ کارهایِ مبتنی بر وب‌هوک بود تا وضعیت به ثبات برسد.

هزینه‌ی تمرکزگرایی

وقتی یک پلتفرم مالکِ تمامِ بخش‌های CI/CD، بررسی کد، ابزارهای هوش مصنوعی و اتوماسیونِ شماست، روزهای بدِ آن پلتفرم، به روزهای بدِ شما تبدیل می‌شود.

اگر این الگو ادامه یابد، واکنش منطقی، وحشت نیست؛ بلکه ایجاد «افزونگی» (Redundancy) است. استفاده از اتوماسیون‌های توزیع‌شده برای استقرار، داشتنِ نسخه‌های پشتیبان از سورس‌کد و ابزارهای برنامه‌نویسی هوش مصنوعی که همگی به یک نقطه از شکست (Single point of failure) متکی نباشند. تا زمانی که سرمایه‌گذاری‌های زیرساختیِ گیت‌هاب این شکاف‌ها را پر نکند، شما عملاً برنامه‌ی انتشار نرم‌افزار خود را بر پلتفرمی شرط‌بندی کرده‌اید که هشت حادثه‌ی قابل‌اطمینان نبودن را در یک ماه ثبت کرده و هنوز توضیحی برای آنچه دوشنبه شکست، ارائه نکرده است. برای تیم‌هایی که در تمام لایه‌های پشته (Stack) فناوری خود به گیت‌هاب متکی هستند، این روندِ اصلاح باید سریع‌تر پیش برود.