GitHub یک قطعی چندسرویسی هفت‌ساعته را تجربه کرد که Git، Actions و Copilot را تحت تأثیر قرار داد

GitHub روز دوشنبه یکی از طولانی‌ترین و گسترده‌ترین قطعی‌های اخیر خود را تجربه کرد، حادثه‌ای زنجیره‌ای که در ساعت ۱۳:۴۰ UTC آغاز شد و بیش از هفت ساعت بعد همچنان از صفحه وضعیت GitHub به‌روزرسانی تولید می‌کرد. Microsoft، مالک GitHub، این قطعی را تأیید کرد چراکه فهرست سرویس‌های تحت تأثیر جزء‌به‌جزء در طول بعدازظهر رشد کرد.

چگونگی گسترش قطعی

این حادثه به‌عنوان یک مشکل عملکردی شروع شد اما سریعاً گسترش یافت: API Requests در ساعت ۱۳:۴۱ UTC از کار افتاد، Actions در ۱۳:۴۲، Webhooks در ۱۳:۴۴، Issues در ۱۳:۴۶ و Pull Requests تا ۱۳:۵۸ — یعنی در حدود ۲۰ دقیقه، بیشتر عملکردهای اصلی که توسعه‌دهندگان برای کار روزانه به آن‌ها متکی هستند دچار افت شد. در اوج، صفحه وضعیت خود GitHub نرخ خطای حدود ۲۰ درصد در صفحات وب و ترافیک API گزارش داد که به حدود ۵۰ درصد در دانلود آرشیو مخازن و درخواست‌های محتوای خام افزایش یافت.

در ساعت ۱۴:۲۴ UTC، این حادثه دوباره گسترش یافت تا احراز هویت را نیز شامل شود: ورود SAML و OIDC، SCIM و Team Sync همگی تحت تأثیر قرار گرفتند. هفت دقیقه بعد، GitHub Copilot به وضعیت دسترسی تنزل‌یافته رفت. عملیات‌های Git خودشان در اوایل حادثه تحت تأثیر قرار نگرفتند، هرچند صفحه وضعیت GitHub بعداً تأیید کرد که Git Operations نیز حدود ساعت ۱۷:۳۰ UTC دچار افت شد.

دنباله طولانی رفع‌های جزئی

به‌روزرسانی‌های وضعیت GitHub الگویی از بهبود جداگانه اجزا به‌جای بهبود همزمان را نشان می‌دهد. تا ساعت ۱۶:۵۹ UTC، شرکت گزارش داد افت در API Requests، Actions، Git Operations، Issues، Pages، Pull Requests و Webhooks رفع شده است. اما مشکلات جدید همچنان ظاهر می‌شدند: API Requests حدود ساعت ۱۸:۴۸ UTC دوباره دچار افت شد. علت اصلی حادثه اولیه فاش نشده است.

چرا قطعی GitHub با این طول اهمیت دارد

مقیاس GitHub این قطعی را به‌طور غیرمعمولی مخرب در سراسر صنعت نرم‌افزار می‌کند. فراتر از علائم قابل‌مشاهده، افت دانلود محتوای خام و مخزن مستقیماً بر سیستم‌های خودکار تأثیر می‌گذارد که انسانی در حلقه ندارند تا متوجه شوند و صبر کنند: pipelineهای build، ساخت image کانتینر و اسکریپت‌های نصب پکیج که وابستگی‌ها را مستقیماً از منابع میزبانی‌شده GitHub دریافت می‌کنند.