17 अगस्त के GitHub आउटेज में डाउनलोड से लेकर Copilot तक प्रभावित

बाद में GitHub ने बताया कि उसने प्रभावित घटक की पहचान कर सुधारात्मक कार्रवाई की। अमेरिकी ईस्टर्न टाइम के अनुसार दोपहर 12:36 बजे जारी अपडेट में कंपनी ने कहा कि प्लेटफॉर्म में रिकवरी के मजबूत संकेत दिख रहे हैं, हालांकि सेवा पूरी तरह स्थिर नहीं हुई थी।

रिकवरी सभी सेवाओं में एक साथ नहीं हुई। स्टेटस अपडेट में कई प्रमुख सेवाओं को ऑपरेशनल दिखाया गया, लेकिन कुछ ऐप्लिकेशन में Copilot की ऑथेंटिकेशन समस्या बनी रही। अन्य घटना-रिपोर्टों के मुताबिक, पूरी घटना लगभग 21:15 UTC पर समाप्त हुई—यानी गंभीर गिरावट की शुरुआती अवधि से काफी लंबी चली।

आउटेज कितना गंभीर था?

GitHub द्वारा बताए गए एरर रेट असर का सबसे स्पष्ट संकेत देते हैं:

• वेब अनुभव और API ट्रैफिक: लगभग 20% एरर।
• आर्काइव डाउनलोड और रॉ रिपॉजिटरी-कंटेंट: लगभग 50% एरर।
• डेवलपर सेवाएं: Pull Requests, Issues, Actions, Webhooks, Git ऑपरेशंस और Pages अलग-अलग समय पर धीमे या अनुपलब्ध रहे।
• AI कोडिंग सहायता: GitHub Copilot प्रभावित रहा और कई मुख्य सेवाओं के लौटने के बाद भी इसमें समस्या बनी रही।
• एंटरप्राइज़ पहचान सेवाएं: SAML और OIDC ऑथेंटिकेशन, SCIM प्रोविजनिंग तथा Team Sync में भी बाधा की रिपोर्ट आई। इससे कुछ संगठनों के लिए यूजर साइन-इन और एक्सेस मैनेजमेंट अविश्वसनीय हो गया।

यहां एक महत्वपूर्ण सावधानी जरूरी है। ये आंकड़े एरर रेट बताते हैं, प्रभावित GitHub यूजर्स का प्रतिशत नहीं। उदाहरण के लिए, 20% API एरर का अर्थ यह नहीं है कि ठीक 20% ग्राहक ऑफलाइन थे। इसी तरह 50% का आंकड़ा प्रभावित डाउनलोड अनुरोधों पर लागू होता है, पूरे रिपॉजिटरी ट्रैफिक पर नहीं।

सोमवार की सुबह ने असर क्यों बढ़ाया?

यह घटना अमेरिका में सोमवार सुबह शुरू हुई—यानी कई इंजीनियरिंग टीमों के कार्यसप्ताह की शुरुआत के समय। दिन की शुरुआत में सोर्स कोड एक्सेस, कोड रिव्यू, कंटीन्यूअस इंटीग्रेशन और डिप्लॉयमेंट ऑटोमेशन अक्सर एक-दूसरे से जुड़े होते हैं। Actions, Pull Requests, APIs और Webhooks सभी प्रभावित होने के कारण टीमों को किसी एक फीचर की नहीं, बल्कि जुड़े हुए कई चरणों में विफलताओं का सामना करना पड़ा।

आउटेज-ट्रैकिंग सेवाओं के आंकड़े समय और क्षेत्र के अनुसार अलग-अलग रहे। एक रिपोर्ट के अनुसार, प्रशांत समयानुसार सुबह 8:12 बजे तक Downdetector पर 10,000 से अधिक रिपोर्ट दर्ज हो चुकी थीं। दूसरी रिकवरी रिपोर्ट में करीब 3,000 रिपोर्ट के शीर्ष स्तर का उल्लेख है। इन आंकड़ों को प्रभावित यूजर्स की सटीक संख्या नहीं माना जाना चाहिए, क्योंकि ऐसे प्लेटफॉर्म यूजर्स की भेजी गई शिकायतें गिनते हैं और उनका आंकड़ा समय, स्थान व रिपोर्टिंग पद्धति के साथ बदलता रहता है।

GitHub ने क्या किया, और क्या अब भी स्पष्ट नहीं है?

कंपनी के सार्वजनिक अपडेट से प्रतिक्रिया के तीन मुख्य चरण सामने आते हैं:

1. इंजीनियरों ने कई सेवाओं में बढ़ी हुई प्रदर्शन समस्याओं की जांच की।
2. GitHub ने समस्या से जुड़े एक घटक की पहचान कर सुधारात्मक कदम उठाए।
3. मुख्य प्लेटफॉर्म सेवाओं में सुधार शुरू होने के बाद भी कंपनी ने शेष समस्याओं, खासकर कुछ ऐप्लिकेशन में Copilot ऑथेंटिकेशन विफलताओं, के लिए उपाय जारी रखे।

लेकिन उपलब्ध जानकारी उस घटक का नाम, सटीक सुधारात्मक कार्रवाई या इस खास घटना के लिए क्षमता-संबंधी दबाव को मूल कारण साबित नहीं करती। GitHub ने अपनी व्यापक विश्वसनीयता चर्चाओं में AI-सहायित और एजेंटिक डेवलपमेंट वर्कफ्लो से बढ़ते ट्रैफिक तथा इंफ्रास्ट्रक्चर सीमाओं का उल्लेख किया है। फिर भी, पोस्टमॉर्टम आने से पहले इन्हें 17 अगस्त के आउटेज का पुष्ट कारण बताना सही नहीं होगा।

GitHub की 2026 की बड़ी विश्वसनीयता चुनौती

अगस्त की घटना एक कठिन अवधि के बाद आई। GitHub की जुलाई उपलब्धता रिपोर्ट में उस महीने आठ घटनाओं का उल्लेख था। इनमें 8 जुलाई की एक घटना सात घंटे से अधिक चली और Web UI, REST API, GraphQL API, Actions, Packages, Copilot तथा कुछ Enterprise Cloud वातावरण में Git ऑपरेशंस प्रभावित हुए।

GitHub ने अपनी उपलब्धता संबंधी जानकारी में यह भी कहा कि AI-सहायित और एजेंटिक डेवलपमेंट वर्कफ्लो के कारण ट्रैफिक तेजी से बढ़ रहा है। कंपनी के बताए उपायों में अधिक इलास्टिक क्षमता के लिए Azure पर वर्कलोड ले जाना, सेवाओं को अलग-अलग करना और साझा विफलता-बिंदुओं को कम करना शामिल है।

इंफ्रास्ट्रक्चर योजना का पैमाना भी उल्लेखनीय है। रिपोर्टों के अनुसार, GitHub ने पहले अपनी क्षमता को 10 गुना बढ़ाने का लक्ष्य रखा था, लेकिन बाद में उसे अपनी तत्कालीन स्केल से 30 गुना क्षमता के लिए डिजाइन करने की जरूरत समझ आई। अन्य रिपोर्टों में Azure के साथ अतिरिक्त मल्टीक्लाउड क्षमता, जिसमें AWS भी शामिल है, से जुड़े प्रयासों का उल्लेख है। हालांकि, ये योजनाएं अपने-आप में 17 अगस्त की घटना का कारण साबित नहीं करतीं।

इस संदर्भ में यह आउटेज सिर्फ एक खराब सुबह से अधिक महत्वपूर्ण है। GitHub अब केवल Git रिपॉजिटरी रखने की जगह नहीं है; यह सहयोग, ऑटोमेशन, पहचान प्रबंधन और AI कोडिंग का भी आधार बन चुका है। साझा निर्भरताओं में समस्या आने पर एक ही घटना रिपॉजिटरी एक्सेस, रिव्यू, बिल्ड, डिप्लॉयमेंट, Webhooks और कोडिंग सहायता—सभी को प्रभावित कर सकती है।

संगठनों के लिए सबक

यह आउटेज इस बात का प्रमाण नहीं है कि डेवलपर जल्द ही GitHub छोड़ने वाले हैं। उपलब्ध साक्ष्य किसी आसन्न बड़े माइग्रेशन की भविष्यवाणी का आधार भी नहीं देते। लेकिन यह जरूर दिखाता है कि GitHub पर प्रोडक्शन डिलीवरी निर्भर करने वाले संगठनों को अपनी विफलता-सम्बंधी धारणाओं की समीक्षा करनी चाहिए।

व्यावहारिक सुरक्षा उपायों में रिपॉजिटरी बैकअप या मिरर बनाए रखना, CI/CD कॉन्फिगरेशन को पोर्टेबल रखना, आपातकालीन रिलीज प्रक्रिया लिखित रूप में तैयार रखना और SSO, Webhooks या होस्टेड रनर्स अनुपलब्ध होने की स्थिति के लिए टीमों को प्रशिक्षित करना शामिल है। ये कदम प्लेटफॉर्म जोखिम खत्म नहीं करते, लेकिन अगली सेवा बाधा का असर सीमित कर सकते हैं।

17 अगस्त की घटना पर अंतिम निष्कर्ष GitHub के पोस्टमॉर्टम के बाद ही निकलेगा। तब तक सबसे ठोस निष्कर्ष यही है: GitHub को व्यापक और परस्पर जुड़ी सेवा-विफलता का सामना करना पड़ा, जिसका सबसे गंभीर असर रिपॉजिटरी डाउनलोड और डेवलपर वर्कफ्लो पर पड़ा; रिकवरी चरणों में हुई; और कंपनी ने अभी तक मूल तकनीकी कारण सार्वजनिक रूप से स्पष्ट नहीं किया है।