اختلال گستردهٔ گیت‌هاب در ۱۷ اوت؛ پنجمین رخداد بزرگ در سه هفته

گیت‌هاب عصر ۱۷ اوت ۲۰۲۶ یک اختلال گستردهٔ چندسرویسی را تجربه کرد که از حدود ۱۳:۴۰ UTC نرخ خطای وب و API را به حدود ۲۰ درصد رساند و تقریباً نیمی از دانلودهای آرشیو و raw مخازن را با شکست مواجه ساخت. این پنجمین رخداد قابل‌توجه این پلتفرم در سه هفتهٔ گذشته است.

#چه اتفاقی افتاد؟

بر اساس صفحهٔ وضعیت گیت‌هاب و گزارش‌های مستقل، اختلال تقریباً تمام سرویس‌های اصلی را در بر گرفت: GitHub Actions، Webhooks، Issues، Pull Requests، Copilot و حتی احراز هویت SAML/OIDC و Team Sync. با توجه به اینکه بسیاری از سازمان‌ها از گیت‌هاب به‌عنوان ارائه‌دهندهٔ هویت (Identity Provider) استفاده می‌کنند، قطعی احراز هویت یعنی خروج کاربران از زنجیره‌ای از ابزارهای دیگر.

این رخداد در ادامهٔ قطعی ۱۰ ساعتهٔ Actions و Pages در ۶ تا ۷ اوت رخ داده و سومین ماجرا از ۲۹ ژوئیه تاکنون است. آمار IncidentHub نشان می‌دهد GitHub Actions در سال ۲۰۲۶ تاکنون ۴۸ قطعی داشته که ۲۶ مورد آن «عمده» طبقه‌بندی شده‌اند.

#جزئیات فنی

• نرخ خطای ~۲۰٪ در وب و API در اوج اختلال
• ~۵۰٪ شکست در دانلود آرشیو مخازن و فایل‌های raw
• شروع حدود ۱۳:۴۰ UTC در ۱۷ اوت ۲۰۲۶
• دامنهٔ اثر: Actions، Webhooks، Issues، PR، Copilot، SAML/OIDC، Team Sync

از منظر مهندسی قابلیت اطمینان، چنین الگویی — خطاهای پراکنده در چند سرویس به‌ظاهر مستقل — معمولاً به یک وابستگی مشترک زیرین اشاره دارد: لایهٔ داده، شبکهٔ داخلی یا سرویس هویت. نکتهٔ مهم برای مصرف‌کنندگان این است که Webhookهایی که در دورهٔ اختلال از دست رفته‌اند، بدون مکانیزم بازپخش (replay) ممکن است برای همیشه گم شوند و صف‌های CI به‌صورت نیمه‌کاره باقی بمانند.

IncidentHub تاکنون ۴۸ قطعی GitHub Actions را در سال ۲۰۲۶ ثبت کرده است — GitHub

#چرا مهم است؟

گیت‌هاب دیگر فقط یک میزبان کد نیست؛ هم‌زمان CI/CD، سامانهٔ بازبینی کد، ارائه‌دهندهٔ هویت و دستیار هوش مصنوعی (Copilot) میلیون‌ها توسعه‌دهنده است. این تجمیع یعنی هر قطعی، چهار خط تولید را هم‌زمان متوقف می‌کند. وقتی Actions از کار می‌افتد، دیپلوی‌ها در سراسر صنعت نگه داشته می‌شوند؛ وقتی SAML اختلال دارد، کارمندان از ابزارهای داخلی هم بیرون می‌مانند.

پنج رخداد در سه هفته از یک پلتفرم به بزرگی گیت‌هاب، یک سیگنال ساختاری است، نه تصادف. تیم‌های SRE باید سه درس عملی از این موج بگیرند: اول، طراحی تخلیهٔ صف (queue-drain) برای Actions تا پس از بازگشت سرویس، انباشت Jobها سامانه را دوباره از پا نیندازد؛ دوم، پیاده‌سازی بازپخش Webhookهای ازدست‌رفته؛ سوم، داشتن مسیر جایگزین — رجیستری پشتیبان و Runnerهای خارج از گیت‌هاب — برای لحظاتی که اتکای کامل به یک ارائه‌دهنده گران تمام می‌شود.

#اعداد و ارقام

• ۵ رخداد قابل‌توجه در سه هفته (از ۲۹ ژوئیه تا ۱۷ اوت)
• ۱۰ ساعت: طول قطعی Actions و Pages در ۶–۷ اوت
• ۴۸ قطعی Actions در ۲۰۲۶ که ۲۶ مورد آن عمده بوده است
• ~۲۰٪ نرخ خطا در وب/API و ~۵۰٪ شکست در دانلود آرشیوها

#الگوی تکرار و بدهی قابلیت اطمینان

نگاهی به صفحهٔ تاریخچهٔ وضعیت گیت‌هاب نشان می‌دهد که موج تابستان ۲۰۲۶ اتفاقی منفرد نیست: ۴۸ رخداد Actions در کمتر از هشت ماه یعنی به‌طور میانگین بیش از یک قطعی در هر پنج روز برای حیاتی‌ترین سرویس CI این پلتفرم. برای سازمان‌هایی که SLA دیپلوی‌شان به گیت‌هاب گره خورده، این عدد باید مستقیماً وارد مدل ریسک شود.

از منظر طراحی سیستم نیز نکته‌ای که کمتر دیده می‌شود، ماهیت at-most-once بسیاری از مصرف‌کننده‌های Webhook است: اگر در لحظهٔ تحویل، سرویس شما یا خود گیت‌هاب در دسترس نباشد، رویداد ممکن است بی‌سروصدا گم شود. پیاده‌سازی reconciliation دوره‌ای — مثلاً مقایسهٔ وضعیت PRها با وضعیت pipelineها — تنها راه مطمئن برای جبران این خلأ است.

#جمع‌بندی

موج اخیر اختلال‌های گیت‌هاب بحث قدیمی «تمرکززدایی» را دوباره زنده کرده است؛ اما واقعیت این است که برای اکثر سازمان‌ها خروج از گیت‌هاب گزینهٔ عملی نیست و راه‌حل واقع‌بینانه، تحمل‌پذیری در برابر خرابی آن است: صف‌های مقاوم، بازپخش رویدادها، مسیرهای جایگزین دیپلوی و مهم‌تر از همه، سند رخدادی که پیش از وقوع نوشته شده باشد. قطعی بعدی حتماً می‌آید؛ سؤال فقط این است که آیا تیم شما برایش سناریو دارد یا نه.

#منابع

• GitHub Status
• تحلیل اختلال ۱۷ اوت در dev.to