قطعی گیت‌هاب در اواسط ماه اوت، هم‌زمان با عبور پلتفرم از مرز 2.9 میلیارد کامیت ماهانه، نشان داد زیرساخت کنونی برای مدیریت این حجم رشد ناگهانی هنوز ناکافی است. گیت‌هاب همچنین ماهانه میزبان 130 میلیون pull request ادغام‌شده و 24 میلیون مخزن جدید است که افزایش فشار روی سرویس‌ها را تشدید می‌کند.

علت قطعی گیت‌هاب

گزارش پس از حادثه نشان می‌دهد قطعی از زمانی آغاز شد که ترافیک به اوج جدیدی رسید و یک مؤلفهٔ کلیدی در مرکز دادهٔ «Central US» نتوانست مقیاس‌پذیری لازم را فراهم کند. فشار ظرفیت زنجیروار منجر به شکست‌های احراز هویت شد و چندین سرویس اصلی را مختل کرد. ولاد فِدُروف، مدیر فناوری گیت‌هاب، علت را مسائل مقیاس‌پذیری عنوان کرده و تأکید شده مشکل ناشی از تغییرات کد نبوده است.

گام‌های گیت‌هاب برای افزایش ظرفیت و در دسترس‌پذیری

گیت‌هاب با ترکیبی از مهاجرت به خدمات ابری و افزودن سخت‌افزار داخلی در تلاش برای افزایش ظرفیت بوده است. طبق گفتهٔ فِدُروف، اکنون حدود 58% بار پلتفرم توسط Azure تأمین می‌شود؛ جهشی از 12% در ماه می. تیم فنی همچنین امسال حدود 3,000,000 هستهٔ پردازشی جدید و 120 پتابایت ذخیرهٔ پرسرعت به مجموعه افزوده‌اند.

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

با وجود این، مراکز دادهٔ داخلی گیت‌هاب به محدودیت‌های برق و فضا رسیده‌اند و شرکت ناگزیر به تسریع مهاجرت به ابر شده است. تیم‌ها منابع خود را به سمت افزایش در دسترس‌پذیری هدایت کرده‌اند و بر تست‌های قوی‌تر، عرضهٔ ایمن‌تر، قابلیت مشاهدهٔ بهتر و هشداردهی مؤثرتر تمرکز می‌کنند.

تغییرات عملیاتی برای جلوگیری از تکرار قطعی گیت‌هاب

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

  • اعمال محدودیت‌ها و بودجه‌بندی برای تلاش‌های مجدد (retry) بین سرویس‌ها
  • تنظیم تایم‌اوت‌ها و اجرای backoff نمایی برای جلوگیری از «طوفان تلاش مجدد» و بار آبشاری
  • ایزوله‌سازی سیستم‌های حیاتی و کاهش وابستگی‌های مشترک میان آن‌ها
  • سرمایه‌گذاری در ابزارهای مانیتورینگ و هشداردهی برای شناسایی زودهنگام فشارهای ظرفیت

رقابت و فرصت‌ها پس از قطعی

این رخداد فضای رقابتی را باز کرده است. بازیگران جدید و استارتاپ‌ها به‌ویژه در حوزهٔ مدیریت بارهای ناشی از عامل‌های برنامه‌نویسی (coding agents) و معماری توزیع‌شده فعال شده‌اند. نمونه‌هایی از این بازیگران، از جمله استارتاپ Entire که توسط مدیرعامل سابق گیت‌هاب بنیان‌گذاری شده، روی سیستم‌های توزیع‌شده برای مدیریت بهتر چنین بارهایی تمرکز دارند؛ محصولاتی مانند Origin و Cursor نیز در این بازار حضور دارند.

نمونه‌ای از کنسول مدیریت مخازن و لاگ‌ها

آنچه پیش روست

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

توصیه‌ها برای توسعه‌دهندگان و تیم‌های عملیات

  • تهیهٔ آینه (mirror) از مخازن حیاتی و پیکربندی fallback برای ابزارهای CI/CD
  • اعمال کش محلی برای بسته‌ها و artifactها در خطوط ساخت به‌منظور کاهش وابستگی به سرویس‌های میزبان در زمان قطعی
  • طراحی retry با backoff نمایی و محدودیت کلی برای جلوگیری از بار آبشاری روی سرویس‌ها
  • استفاده از چند منطقهٔ ابری یا multi-cloud و بررسی گزینه‌های جایگزین میزبانی کد برای سرویس‌های حیاتی
  • افزایش مشاهده‌پذیری (observability) و تست سناریوهای بار بالا به‌صورت منظم

برای مطالعهٔ بیشتر می‌توانید به صفحهٔ گیت‌هاب در ویکی‌پدیا و بلاگ رسمی گیت‌هاب در GitHub Blog مراجعه کنید.