گیت‌هاب پس از قطعی تقریباً ۸ ساعته که عملکرد اکشن‌ها، APIها و کوپایلوت را مختل کرد، خدمات خود را بازیابی کرد

وقتی یک وب‌سایت مصرف‌کننده آفلاین می‌شود، تأثیر آن معمولاً محدود به کاربران ناامیدی است که صفحه را رفرش می‌کنند. اما وقتی گیت‌هاب دچار اختلال می‌شود، واقعیت بسیار سیستمی‌تر است. این فقط یک مخزن کد نیست؛ بلکه خط مونتاژ خودکار برای اینترنت مدرن است.[1]

در ۱۷ آگوست ۲۰۲۶، این خط مونتاژ برای تقریباً هشت ساعت متوقف شد. این اختلال در ساعت ۱۳:۴۰ به وقت جهانی (UTC) آغاز شد و در ابتدا به صورت کاهش عملکرد در رابط وب پلتفرم و رابط‌های برنامه‌نویسی کاربردی (API) ظاهر شد.[1][2]

در عرض یک ساعت، دامنه شکست مشخص شد. این قطعی به GitHub Actions، موتور یکپارچه‌سازی مداوم (CI) که به طور خودکار کد را آزمایش و مستقر می‌کند، سرایت کرد و عملاً به‌روزرسانی‌های نرم‌افزاری را در سراسر جهان متوقف ساخت.[2][4]

نرخ خطا به طور چشمگیری افزایش یافت. صفحه وضعیت خود گیت‌هاب نرخ شکست ۲۰ درصدی را برای ترافیک عمومی وب و API گزارش کرد، در حالی که نرخ شکست برای دانلودهای آرشیو و مخازن خام به ۵۰ درصد رسید.[2][3][5]

این اختلال در زیرساخت‌های اولیه متوقف نشد. GitHub Copilot، دستیار کدنویسی هوش مصنوعی که مایکروسافت به شدت آن را تبلیغ کرده و در جریان کار توسعه‌دهندگان ادغام کرده است، نیز دچار کاهش دسترسی شد.[1][5]

این امر یک واقعیت حیاتی در مورد توسعه با کمک هوش مصنوعی را برجسته می‌کند: علی‌رغم زبان بازاریابی که این ابزارها را به عنوان عوامل مستقل معرفی می‌کند، آنها همچنان عمیقاً به زیرساخت ابری متمرکز و لایه‌های احراز هویت وابسته هستند. وقتی ابر دچار مشکل می‌شود، «برنامه‌نویس جفت هوش مصنوعی» به سادگی از کار می‌افتد.[3]

خود احراز هویت در طول این حادثه به یک گلوگاه اصلی تبدیل شد. مشتریان سازمانی که به SAML، OIDC و Team Sync متکی بودند، متوجه شدند که از محیط‌های توسعه خود قفل شده‌اند و قادر به تأیید هویت خود در برابر سرورهای گیت‌هاب نیستند.[1][4]

فرآیند بازیابی به طور قابل توجهی غیرخطی بود و نگاهی واقعی به نحوه ترمیم سیستم‌های توزیع‌شده پیچیده ارائه داد. در حالی که مهندسان گیت‌هاب یک جزء مشکل‌ساز را شناسایی کردند و شروع به اعمال کاهش‌ها در ساعت ۱۶:۳۶ به وقت جهانی کردند، خدمات بین بازیابی و تنزل مجدد در نوسان بود.[1][3]

عملیات گیت و درخواست‌های API برای مدت کوتاهی تثبیت شدند و سپس دوباره دچار تنزل شدند، که نشان‌دهنده وابستگی‌های متقابل پیچیده در معماری گیت‌هاب است. رفع اشکال اعمال شده در یک میکروسرویس اغلب گلوگاه‌های آبشاری را در دیگری آشکار می‌کرد.[1]

برای تثبیت پلتفرم، گیت‌هاب مجبور شد تلاش‌های مجدد توکن احراز هویت را به طور جزئی غیرفعال کند. این کاهش اجباری، سیستم را از غرق شدن در تلاش‌های ورود خودکار باز داشت، اگرچه باعث شد برخی از کاربران کوپایلوت حتی پس از بازگشت خدمات اصلی، با شکست‌های پراکنده مواجه شوند.[1]

این حادثه سرانجام در ساعت ۲۱:۱۵ به وقت جهانی، تقریباً هشت ساعت پس از هشدارهای اولیه، به عنوان حل شده علامت‌گذاری شد. در حالی که گیت‌هاب از کاربران به خاطر صبرشان تشکر کرد، این زمان طولانی توقف، بلافاصله بحث‌هایی را در مورد وابستگی به پلتفرم برانگیخت.[1][6]

این قطعی یک رویداد جداگانه نیست، بلکه بخشی از یک درد فزاینده گسترده‌تر برای این پلتفرم است. این حادثه به دنبال مجموعه‌ای از مشکلات قابلیت اطمینان، از جمله ۲۶ حادثه ثبت شده تنها در جولای ۲۰۲۶ و یک قطعی مهم Actions در اوایل آگوست رخ می‌دهد.[7][8]

تنش اساسی، بین مقیاس و پایداری است. در حالی که گیت‌هاب به طور تهاجمی ویژگی‌های جدید هوش مصنوعی را ارائه می‌دهد و حجم ترافیک بی‌سابقه‌ای را مدیریت می‌کند، زیرساخت‌های بنیادی نشانه‌هایی از فشار را بروز می‌دهند.[6][8]

برای تیم‌های توسعه، توقف هشت ساعته یادآوری آشکاری از خطرات مرتبط با قفل شدن توسط فروشنده است. هنگامی که یک ارائه‌دهنده واحد، مخزن، خط لوله آزمایش و مکانیسم استقرار را کنترل می‌کند، یک خطای مسیریابی محلی به توقف کار جهانی تبدیل می‌شود.[7]

در آینده، رهبران مهندسی به طور فزاینده‌ای در حال ارزیابی ابزارهای آماده برای آفلاین و خطوط لوله CI/CD اضافی هستند. در حالی که گیت‌هاب مرکز بی‌چون و چرای دنیای توسعه متن‌باز و سازمانی باقی می‌ماند، این حادثه ثابت می‌کند که حتی قوی‌ترین ابرها نیز به برنامه‌های پشتیبان نیاز دارند.[6][7]

این حادثه همچنین هزینه‌های پنهان مدل «همه چیز به عنوان یک سرویس» را برجسته می‌کند. توسعه‌دهندگانی که تصور می‌کردند محیط‌های محلی‌شان ایزوله هستند، متوجه شدند که بررسی‌های احراز هویت وابسته به ابر، حتی در دستگاه‌های خودشان، مانع از کامیت کردن کد توسط آنها شده است.[7]

در نهایت، قطعی ۱۷ آگوست به عنوان یک کلاس درس در مورد تاب‌آوری سیستم عمل می‌کند. این حادثه هم شکنندگی پلتفرم‌های بیش از حد متمرکز و هم تلاش مهندسی عظیمی را که برای بازگرداندن یک سیستم توزیع‌شده جهانی به صورت آنلاین و بدون از دست دادن داده لازم است، نشان می‌دهد.[1][8]