جب GitHub رک جاتا ہے، سافٹ ویئر ڈیلیوری رک جاتی ہے: نو گھنٹے کی رکاوٹ سے کاروباری قیادت کے اسباق

6 اگست 2026 کو 15:22 UTC پر، GitHub نے GitHub Actions کے لیے کارکردگی میں کمی کی اطلاع دینا شروع کی — یہ وہ خودکار سروس ہے جو لاکھوں اداروں کے لیے سافٹ ویئر بناتی، آزماتی اور شپ کرتی ہے۔ چند گھنٹوں کے اندر یہ رکاوٹ GitHub Pages، Actions REST API، Copilot code review، Copilot coding agent، hosted اور self-hosted runners، webhook ڈیلیوری اور GitHub Enterprise Importer migrations تک پھیل گئی۔ GitHub نے 7 اگست کو 00:06 UTC پر، آغاز کے تقریباً نو گھنٹے بعد، کمی کو قابو میں قرار دیا۔ کام کے دن کا بیشتر حصہ، دنیا کی سافٹ ویئر ڈیلیوری کی صلاحیت کا ایک قابلِ توجہ حصہ متاثر رہا۔

یہ اب کیوں اہم ہے

GitHub اب محض کوڈ ریپازٹری نہیں رہا۔ یہ جدید سافٹ ویئر ڈیلیوری کا آپریشنل اعصابی مرکز ہے: جہاں کوڈ رہتا ہے، جہاں continuous integration چلتا ہے، جہاں deployments شروع ہوتے ہیں اور تیزی سے جہاں AI coding agents اپنا کام کرتے ہیں۔ جب Copilot code review اور Copilot coding agent، Actions کے ساتھ ساتھ آف لائن ہوئے، تو جن اداروں نے اپنی ڈیلیوری کے عمل میں AI معاونت بُنی ہوئی تھی، انہوں نے pipelines رکتے ہی وہ صلاحیت بھی کھو دی۔ ہم جتنا زیادہ ڈیولپمنٹ، آٹومیشن اور AI ٹولنگ کو ایک ہی پلیٹ فارم پر مرکوز کرتے ہیں، اتنا ہی ایک واقعہ معیشت بھر کے واقعے کی طرح برتاؤ کرتا ہے۔

کیا ہوا ہے

GitHub کے سرکاری اسٹیٹس پیج کے مطابق، بنیادی ناکامی میں runners کو غلط جاب اسائنمنٹس ملنا شامل تھا، جبکہ self-hosted runners کام اٹھانے میں ناکام رہے اور رجسٹریشن کے دوران غلطیوں اور rate limiting کا سامنا ہوا۔ Workflow runs شروع یا مکمل ہونے میں ناکام رہے، قطار میں لگے کاموں کا وقت ختم ہو گیا، Actions REST API نے غلطیاں لوٹائیں، اور webhook سے چلنے والے workflows میں تاخیر ہوئی۔ بازیابی کے لیے سسٹم بھر میں جمع شدہ قطاریں خالی کرنا، runner جاب اسائنمنٹ کے لیے اصلاحات تعینات کرنا، webhook سے چلنے والے workflow تھروپٹ کو بحال کرنا اور self-hosted runners کو مرحلہ وار دوبارہ فعال کرنا ضروری تھا۔ GitHub نے ابھی تک تفصیلی بنیادی وجہ کا تجزیہ شائع نہیں کیا۔ یہ واقعہ قابلِ اعتمادگی کے واقعات کے ایک مشکل سلسلے کے بعد آیا: The Register اپریل میں 26 واقعات، مئی میں 23، جون میں 23 اور جولائی میں 26 رپورٹ کرتا ہے، اور GitHub کا اپنا اسٹیٹس پیج Actions کے لیے 90 دن کی اپ ٹائم 99.42 فیصد دکھاتا ہے، جو اس سطح سے نمایاں طور پر کم ہے جو ادارے اس وقت مانگتے ہیں جب وہ اپنی پوری ڈیلیوری چین ایک فروخت کنندہ پر رکھتے ہیں۔

ٹیکنالوجی اور آرکیٹیکچر کے مضمرات

آرکیٹیکچر کا سبق coupling کے بارے میں ہے۔ بہت سے اداروں نے خاموشی سے ایک فروخت کنندہ کو سورس کوڈ، بلڈ، ٹیسٹ، ڈپلائمنٹ، ڈاکیومینٹیشن ہوسٹنگ اور AI معاونت کا control plane بننے دیا ہے۔ ان میں سے ہر ایک انفرادی طور پر معقول ہے۔ مل کر یہ ایک ایسا انحصار گراف بناتے ہیں جس میں ایک ناکام scheduler نیچے کی طرف سب کچھ روک دیتا ہے۔ خاص طور پر، self-hosted runners، جنہیں بہت سی ٹیمیں خاص طور پر GitHub کے بنیادی ڈھانچے پر انحصار کم کرنے کے لیے چلاتی ہیں، وہ بھی متاثر ہوئے، کیونکہ وہ جاب اسائنمنٹ اور رجسٹریشن کے لیے اب بھی GitHub کے control plane پر منحصر رہتے ہیں۔ اپنا compute ہونا اپنی دستیابی ہونا نہیں ہے۔ معماروں کو یہ نقشہ بنانا چاہیے کہ کون سی صلاحیتیں ایک ساتھ ناکام ہوتی ہیں، معذور آپریشن کے طریقے متعین کرنا چاہیے، اور یہ یقینی بنانا چاہیے کہ ایسے ہنگامی ڈپلائمنٹ راستے موجود ہوں جو بنیادی پلیٹ فارم سے نہ گزریں۔

کاروباری اور مسابقتی مضمرات

نو گھنٹے کی pipeline رکاوٹ کوئی انجینئرنگ تکلیف نہیں۔ یہ ملتوی ریلیزز، تاخیر شدہ اصلاحات، غیر فعال ٹیمیں اور، گاہکوں کے سامنے تبدیلیاں مسلسل شپ کرنے والی فرموں کے لیے، براہِ راست کاروباری اثر ہے۔ مسابقتی زاویہ بھی اتنا ہی حقیقی ہے: آزمائے گئے متبادل راستوں والے ادارے دوسروں کے انتظار کے دوران بھی شپ کرتے رہے۔ ڈیلیوری چین کی قابلِ اعتمادگی خود بخود ایک امتیازی عنصر بنتی جا رہی ہے، اور بااثر آوازیں پہلے سے ہی پلیٹ فارم انحصار پر سوالات اٹھا رہی ہیں۔ The Register ڈویلپر Mitchell Hashimoto کا حوالہ دیتا ہے کہ GitHub اب ڈویلپرز کے سنجیدہ کام کو ہوسٹ کرنے کی جگہ نہیں رہا۔ اس سے اتفاق ہو یا نہ ہو، بااثر انجینئروں میں یہ جذبہ بذاتِ خود ایک ایسا اشارہ ہے جسے بورڈز کو درج کرنا چاہیے۔

خطرات اور گورننس کے پہلو

زیادہ تر انٹرپرائز رسک رجسٹر GitHub کو اہم بنیادی ڈھانچے کے بجائے ایک ڈیولپمنٹ ٹول سمجھتے ہیں۔ یہ واقعہ دوبارہ درجہ بندی کے لیے دلیل فراہم کرتا ہے۔ گورننس کے سوالات فطری طور پر سامنے آتے ہیں۔ کیا ادارہ جانتا ہے کہ ڈیلیوری پلیٹ فارم آف لائن ہونے پر اس کا اصل بازیابی وقت کیا ہے؟ کیا AI coding agents اور خودکار جائزہ مراحل کو تبدیلی کے انتظام میں ناکامی کے واحد نکتے بننے کی اجازت ہے؟ کیا ضابطوں کی ذمہ داریاں، خاص طور پر operational resilience کے دائرے کے تحت مالیاتی خدمات میں، سافٹ ویئر ڈیلیوری چین تک پھیلتی ہیں؟ اور کیا سورس، بلڈ، ڈپلائمنٹ اور AI ٹولنگ کے لیے ایک سپلائر کے ساتھ مرکوزیت فروخت کنندہ کی حکمتِ عملی میں خطرے کے طور پر شامل کی گئی ہے، یا یہ ڈیفالٹ طور پر جمع ہو گئی ہے؟

CEO کو کیا کرنا چاہیے

پہلے، اپنی ٹیکنالوجی قیادت سے ایک سوال پوچھیں: اگر GitHub، یا اس کے مساوی، پورا دن آف لائن رہے تو صارفین سے ہمارے وعدوں کا کیا ہوگا۔ یقین دہانی کے بجائے واضح، ثبوت کے ساتھ جواب مانگیں۔ دوسرے، ڈویلپر پلیٹ فارم انحصار کو سپلائر مرکوزیت کا خطرہ سمجھیں اور اسے اتنی ہی بورڈ نمائش دیں جتنی cloud مرکوزیت کو۔ تیسرے، لچک کے کام کے لیے واضح طور پر فنڈ کریں۔ متبادل راستے، mirrored ریپازٹریز اور مشق شدہ معذور طریقے بیمہ پریمیم کی طرح ہیں، اور وہ ہمیشہ اس رکاوٹ سے سستے ہوتے ہیں جو ان کی عدم موجودگی ثابت کرتی ہے۔

CTO کو کیا کرنا چاہیے

اپنے ڈیلیوری پلیٹ فارم کے blast radius کا ایمانداری سے نقشہ بنائیں، جس میں اب جائزہ اور کوڈنگ workflows میں شامل AI ٹولز بھی شامل ہیں۔ اپنی اہم ترین خدمات کے لیے ایک آزاد ہنگامی ڈپلائمنٹ راستہ برقرار رکھیں اور سہ ماہی مشق کریں۔ سورس کوڈ کو باقاعدگی سے ثانوی مقام پر mirror کریں۔ Self-hosted صلاحیت کو اس طرح ڈیزائن کریں کہ فروخت کنندہ کے control plane کی عدم دستیابی پر وہ خاموشی سے کمزور ہو، یہ فرض کیے بغیر کہ self-hosting کا مطلب آزادی ہے۔ آخر میں، آپ کے ذہن میں بیٹھے مارکیٹنگ اعداد و شمار کے بجائے فروخت کنندہ کے اصل شائع شدہ اپ ٹائم کے مقابلے میں اندرونی دستیابی کی توقعات مقرر کریں، اور اسی کے مطابق error budgets بنائیں۔

اسٹریٹجک نتیجہ

یہ رکاوٹ چند دنوں میں سرخیوں سے غائب ہو جائے گی۔ جس انحصار کو اس نے بے نقاب کیا، وہ غائب نہیں ہوگا۔ سمت کم نہیں، زیادہ مرکوزیت کی ہے: AI agents ڈیلیوری کے عمل کا بڑا حصہ لیں گے، اور وہ انہی پلیٹ فارمز پر چلیں گے جو اس ہفتے ناکام ہوئے۔ قائدین کو اس واقعے کو مفت stress test سمجھنا چاہیے۔ مطالعہ کریں کہ اس نے آپ کے ادارے کے بارے میں کیا ظاہر کیا، خلا کو باقاعدگی سے بند کریں، اور پلیٹ فارم کی لچک کو ہنگامی ردعمل کے بجائے ٹیکنالوجی حکمتِ عملی کا مستقل حصہ بنائیں۔

اس ہفتے جب آپ کا ڈیلیوری پلیٹ فارم خاموش ہوا، کیا آپ کا ادارہ شپ کرتا رہا، یا اس نے ناکامی کا ایسا واحد نکتہ دریافت کیا جس کا کبھی جائزہ نہیں لیا گیا تھا۔ میں یہ سننا چاہوں گا کہ آپ کی ٹیموں نے اسے کیسے سنبھالا۔

ریاضیانہ سوچیں۔ ذہانت سے انجینئر کریں۔ اسٹریٹجک طور پر قیادت کریں۔ ذمہ داری سے بنائیں۔ عالمی سطح پر پھیلیں۔ مصنوعی ذہانت کے ذریعے حقیقی کاروباری قدر پیدا کریں۔

#GitHub #DevOps #EnterpriseArchitecture #TechnologyStrategy #BusinessContinuity #PlatformEngineering #ArtificialIntelligence #RiskManagement #CTO #CEO

Originally published on LinkedIn by Keshavan Thiagaraja. Read the original on LinkedIn.