AI-संचालित ट्रैफिक वृद्धि और कॉन्फ़िगरेशन त्रुटि के कारण GitHub में ठहराव

icon MarsBit
साझा करें
Share IconShare IconShare IconShare IconShare IconShare IconCopy
AI summary iconसारांश

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

9 फरवरी, वर्ष 2024 को, बीजिंग समय सुबह के बाद, दुनिया भर के करोड़ों डेवलपर्स ने GitHub पर एक ही पेज देखा।

404 नहीं, 404 से अधिक चिंताजनक—वह पीली चेतावनी पट्टी, जो सभी इंजीनियरों की पीठ पर ठंडक महसूस कराती है, और स्टेटस पेज पर हरे से लाल हो जाने वाले लाइट्स की पंक्ति।

github.com बंद है।

API बंद हो गया है।

GitHub Actions बंद हो गया है।

Git ऑपरेशन बंद हो गया—कोपिलॉट भी इससे बच नहीं पाया।

उस रात, किसी की CI/CD पाइपलाइन सबसे महत्वपूर्ण बिंदु पर रुक गई, किसी का स्वचालित डिप्लॉयमेंट हवा में फंस गया, और किसी को एक लंबे समय से मर्ज न होने वाले PR का इंतजार करना पड़ रहा था—जिसके पीछे एक लाइव होने का इंतजार कर रहा फीचर था, और वास्तविक उपयोगकर्ता थे।

गिटहब ने घटना की बाद की रिपोर्ट जारी की। तकनीकी भाषा में, मूल कारण यह था कि "प्रमाणीकरण और उपयोगकर्ता प्रबंधन के लिए जिम्मेदार मुख्य डेटाबेस क्लस्टर ओवरलोड हो गया।" लेकिन इन कुछ शब्दों के पीछे एक चौंकाने वाली ट्रिगर श्रृंखला छिपी हुई है—

दो दिन पहले, इंजीनियरिंग टीम ने उपयोगकर्ताओं को जल्द से जल्द एक नया मॉडल प्राप्त कराने के लिए, एक «उपयोगकर्ता सेटिंग्स कैश» के अपडेट समय को 12 घंटे से बदलकर 2 घंटे कर दिया। यह केवल एक कॉन्फ़िगरेशन संख्या का परिवर्तन था।

परिणामस्वरूप, जो 12 घंटे में बिखरा हुआ कैश पुनर्लिखन था, वह 2 घंटे में संकुचित हो गया, जिससे एक घनी बर्फ़बारी कैश पुनर्लिखन घटना बन गई, जिससे असिंक्रोनस कार्य पंक्ति तुरंत ओवरलोड हो गई, साझा बुनियादी ढांचा घटक टूट गए, और श्रृंखलागत प्रतिक्रिया HTTPS Git ऑपरेशन के लिए जिम्मेदार सेवा तक पहुंच गई, जिसके परिणामस्वरूप पूरे प्लेटफॉर्म के कनेक्शन समाप्त हो गए।

एक संख्या, 12 से बदलकर 2 कर दी गई।

GitHub, एक अपने द्वारा बदले गए कॉन्फ़िगरेशन के कारण बाधित हो गया।

लेकिन अगर आप केवल इस एक कॉन्फ़िगरेशन बदलाव को ही देख रहे हैं, तो आप शायद इस कहानी का सबसे महत्वपूर्ण हिस्सा छूट गए हैं।

01 एक दुर्घटना नहीं, बल्कि दस दुर्घटनाएँ हैं

2 फरवरी की घटना एक अलग घटना नहीं है।

वास्तव में, 2026 के पहले तीन महीनों में, GitHub ने कम से कम 8 बड़ी घटनाओं का सामना किया। फरवरी में अकेले 37 बड़ी और छोटी खराबियों की रिपोर्ट की गई। GitHub के CTO Vlad Fedorov ने बाद में अपने ब्लॉग में स्वीकार किया कि इन दो महीनों में GitHub ने अपने उद्योग ग्राहकों को दिए गए 'तीन नौ'—99.9% उपलब्धता—का वादा पूरा नहीं किया।

इन दो महीनों के खराबी रिकॉर्ड को देखें, आप एक अजीब पैटर्न देखेंगे: हर दुर्घटना अलग-अलग कारणों से लगती है।

2 फरवरी: एज़्यर कॉम्प्यूटिंग प्रोवाइडर में समस्या, गिटहब एक्शन्स लगभग 4 घंटे के लिए बंद, कोपिलट कोडिंग एजेंट, कोडक्यूएल, डिपेंडाबॉट सभी प्रभावित।

9 फरवरी: कैश राइट-ब्रोस्ट, प्रमाणीकरण डेटाबेस ओवरलोड।

5 मार्च: Redis क्लस्टर फ़ॉल्ट, GitHub Actions के 95% वर्कफ़्लो 5 मिनट में शुरू नहीं हो पाए, औसत देरी 30 मिनट।

18 मार्च: वेबहुक लेटेंसी सामान्य स्तर के 32 गुना तक बढ़ गई।

हर बार ऐसा लगता है कि यह "अनपेक्षित" घटना है, और हर बार सीधा कारण अलग-अलग होता है। लेकिन फेडोरोव की व्याख्या इन्हें एक ही कहानी में जोड़ देती है। उनका कहना है कि इन दुर्घटनाओं के पीछे तीन सामान्य संरचनात्मक कारण हैं: "तेजी से बढ़ता लोड, सेवाओं के बीच सख्त संबंध जिससे स्थानीय खराबी फैलती है, और प्रणाली में असामान्य क्लाइंट्स के ट्रैफिक के लिए सुरक्षा की कमी।"

इंजीनियर की भाषा में, GitHub की नींव नए लोड के भार के तहत दरारें शुरू कर चुकी है।

और इस "नए लोड" का एक विशिष्ट नाम है।

02 प्रति सप्ताह 275 मिलियन सबमिशन

महत्वपूर्ण डेटा

2025 के पूरे वर्ष के लिए कुल commit: लगभग 1 बिलियन

2026 के एक सप्ताह में commit की संख्या: 275 मिलियन

इस गति से, 2026 के पूरे वर्ष के लिए अनुमानित: 14 अरब (पिछले वर्ष की तुलना में 14 गुना वृद्धि)

GitHub Actions की गणना: 2023 में सप्ताहिक 5 अरब मिनट → 2025 में 10 अरब → 2026 की शुरुआत में किसी सप्ताह में 21 अरब मिनट

अगर आप GitHub के इंफ्रास्ट्रक्चर इंजीनियर हैं, तो 2025 और 2026 के मॉनिटरिंग डैशबोर्ड की तुलना आपको हैरान कर देगी।

2025 के पूरे वर्ष में, GitHub ने लगभग 1 अरब कोड सबमिशन्स को संभाला। यह संख्या अपने आप में बहुत बड़ी है, जो GitHub प्लेटफॉर्म के कई वर्षों के विकास का परिणाम है। लेकिन 2026 में, एक सप्ताह में ही सबमिशन्स की संख्या 275 मिलियन हो गई। इसे वर्षभर के लिए अनुमानित करें—इस गति से आगे बढ़ने पर, 2026 में कुल सबमिशन्स की संख्या लगभग 14 अरब होगी, जो 2025 के पूरे वर्ष की तुलना में सटीक 14 गुना है।

यह एक चिकनी वृद्धि वाला वक्र नहीं है, बल्कि एक तीव्र ढलान है। GitHub के Actions की गणना में परिवर्तन इसे और स्पष्ट करता है: 2023 में सप्ताहिक 5 अरब मिनट खपत हुए, 2025 में यह दोगुना होकर 10 अरब हो गया, और 2026 की शुरुआत में किसी सप्ताह में सीधे 21 अरब मिनट पर पहुँच गया।

क्या बहुत सारे कोड सबमिट कर रहा है?

Not a human developer.

GitHub के डेटा के अनुसार, AI एजेंट इस प्लेटफॉर्म पर सबसे सक्रिय 'उपयोगकर्ता' बन रहे हैं। Claude Code एकल उपकरण के रूप में, अब GitHub के सभी खुले रिपॉजिटरी में 4.5% कमिट्स का योगदान दे रहा है। सप्ताह में 26 लाख कमिट्स, जबकि 2025 की सितंबर के अंत तक यह संख्या केवल 10 लाख थी—तीन महीनों में 25 गुना की वृद्धि।

AI एजेंट द्वारा खोले गए PR की संख्या भी विस्फोटक रूप से बढ़ रही है। सितंबर 2025 में, AI द्वारा उत्पादित PR लगभग 40 लाख प्रति महीना थे, जबकि मार्च 2026 तक यह संख्या 1.7 करोड़ तक पहुँच गई—छह महीनों में चार गुना से अधिक।

एक चित्र आपको इसका अर्थ समझने में मदद कर सकता है।

पहले, GitHub के "उपयोगकर्ता" मुख्य रूप से मानव प्रोग्रामर होते थे। वे दिन में काम करते, रात में सोते, सप्ताहांत को आराम करते, प्रत्येक कमिट के लिए सोचते, संकोच करते, और अपनी टाइपिंग गति की सीमा होती थी। सिस्टम का लोड मानवीय अनुशासन के साथ चलता था, जिसमें शिखर और निम्न थे, और इसे पूर्वानुमानित किया जा सकता था।

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

गिटहब के इंफ्रास्ट्रक्चर इंजीनियर्स के सामने एक अधिक ट्रैफ़िक वाली समान समस्या नहीं, बल्कि एक पूरी तरह से अलग प्रकृति की समस्या है।

03 कोपिलट के पास जलाने के लिए पैसे नहीं बचे

अक्सर होने वाली खराबियाँ समस्या का केवल एक पहलू हैं, GitHub पर एक और अधिक परेशान करने वाली समस्या यह है कि खाता लगाते समय पता चलता है कि आपको नुकसान हुआ है।

कोपिलट की प्रारंभिक मूल्य निर्धारण तर्क, एक तर्कसंगत मान्यता पर आधारित था: उपयोगकर्ता मुख्य रूप से 'सहायक पूर्ति' शैली में उपयोग करते हैं, प्रत्येक इंटरैक्शन अल्पकालिक होता है और गणना मात्रा भविष्यवाणीयोग्य होती है। व्यक्तिगत संस्करण का मासिक 10 डॉलर और व्यावसायिक संस्करण का मासिक 19 डॉलर, सीट के आधार पर शुल्क, इस मॉडल ने पिछले कुछ वर्षों में अच्छी तरह से काम किया।

फिर, एजेंटिक AI आया।

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

GitHub के सामने यह स्थिति है कि कुछ भारी एजेंटिक उपयोगकर्ता, कुछ डॉलर के मासिक शुल्क का उपयोग करके सैकड़ों डॉलर के कैलकुलेशन संसाधनों का उपयोग कर रहे हैं।

इस स्थिति के सामने, GitHub की प्रतिक्रिया सीधी थी—पहले ट्रैफ़िक कंट्रोल करें, फिर कीमत बदलें।

इस साल की शुरुआत से, GitHub ने Copilot के लिए दो समानांतर लिमिटिंग मैकेनिज्म शुरू किए: सेशन अवधि की अधिकतम सीमा और साप्ताहिक उपयोग सीमा, दोनों आयाम टोकन खपत को मॉडल कैलकुलेशन वजन से गुणा करके गणना किए जाते हैं। इसी समय, कुछ व्यक्तिगत Copilot प्लान्स के लिए नए उपयोगकर्ताओं के पंजीकरण को निलंबित कर दिया गया।

1 जून को, GitHub ने एक अधिक मौलिक मूल्य निर्धारण सुधार पूरा किया: Copilot को पूरी तरह से उपयोग के आधार पर बिलिंग पर स्विच किया गया, जिसमें मूल सब्सक्रिप्शन शुल्क के स्थान पर 'AI क्रेडिट' का उपयोग किया जाता है, जहाँ 1 AI क्रेडिट 1 सेंट के बराबर है, और उपयोग token खपत के आधार पर वास्तविक समय में गिना जाता है।

एजेंटिक एआई के सामने, सीट के आधार पर शुल्क लेने का युग समाप्त हो गया है।

यह परिवर्तन केवल GitHub की समस्या नहीं है। यह 2026 में AI टूल उद्योग की एक सामूहिक मूल्य निर्धारण संकट है—जब AI केवल मानव कार्य का 'सहायता' नहीं करके, बल्कि पूर्ण कार्य प्रवाह को मानव के स्थान पर निष्पादित करना शुरू कर देता है, तो सभी 'प्रति व्यक्ति प्रति माह' आधारित सदस्यता तर्क अक्षम हो जाते हैं।

04 30 गुना, 10 गुना नहीं

बुनियादी ढांचे की समस्या पर वापसी। GitHub इस "14 गुना वृद्धि" का सामना करने के लिए क्या योजना बना रहा है?

यहां एक विस्तार है, जो समस्या की गंभीरता को दर्शाता है:

2025 के दिसंबर के अंत में, एजेंटिक वर्कफ्लो अचानक तेजी से बढ़ने लगा। GitHub के इंजीनियर्स ने महसूस किया कि 10 गुना पर्याप्त नहीं है। 2026 के फरवरी तक, उस गंभीर बंद होने के बाद, GitHub ने घोषणा की कि उन्हें आज के स्केल के 30 गुना के अनुसार आर्किटेक्चर को पुनः डिज़ाइन करने की आवश्यकता है।

यह स्केलिंग नहीं, बल्कि पुनः डिज़ाइन है।

इन दोनों शब्दों में बड़ा अंतर है। स्केलिंग का मतलब है कि मौजूदा मशीनों की संख्या बढ़ाना और मौजूदा डेटाबेस को मेमोरी देना—दिशा वही रहती है, केवल पैमाना बढ़ जाता है। पुनः डिज़ाइन का मतलब है कि मौजूदा आर्किटेक्चर की धारणाएँ 30 गुना पैमाने पर व्यवस्थित रूप से विफल हो जाएँगी, और सेवा विभाजन, डेटा प्रवाह और त्रुटि अलगाव के तरीकों को नीचे से पुनः सोचना होगा।

GitHub द्वारा उजागर किए गए विशिष्ट दिशा-निर्देशों में क्रमिक विफलताओं को रोकने के लिए महत्वपूर्ण सेवाओं को अलग करना, बैकप्रेशर मैकेनिज़म और ट्रैफ़िक डिग्रेडेशन क्षमता शामिल करना, हॉट स्पॉट सेवाओं के लिए स्वतंत्र होस्ट तैनात करना, सिंगल पॉइंट ऑफ़ फेलियर को दूर करना, और अधिक व्यापक परिवर्तन प्रबंधन—जैसे 'कैश TTL को 12 घंटे से बदलकर 2 घंटे करना' जैसे ऑपरेशन को बिना पर्याप्त लोड टेस्टिंग के सीधे लाइव करना।

ध्यान दें कि GitHub अकेला नहीं है।

Stripe ने AI एजेंट द्वारा खातों के बड़े पैमाने पर बनाए जाने की समस्या का सामना किया है, और AWS एजेंट-विशिष्ट पहचान प्रणाली, लॉगिंग प्रणाली और उत्पादन नियंत्रण तंत्र विकसित कर रहा है। ये कदम भविष्य की तैयारी नहीं हैं, बल्कि मॉनिटरिंग डैशबोर्ड पर ऐसे संकेत दिखाई दे चुके हैं जिन्हें उन्हें हल करना पड़ा है।

GitHub केवल पहला टूटा हुआ है—क्योंकि यह AI टूलचेन के सबसे केंद्र में है।

05 कोड रिपॉजिटरी, जो AI के निकास नली बन रहे हैं

इस पूरी बातचीत की प्रकृति पर विचार करें।

GitHub क्या है? सबसे सीधा जवाब यह है कि यह प्रोग्रामर्स अपना कोड स्टोर करने की जगह है। लेकिन इससे गहराई से, यह मानवीय सॉफ्टवेयर सहयोग का बुनियादी ढांचा है—कमिट्स सहयोग की यात्रा हैं, PRs चर्चा के कंटेनर हैं, Issues इरादों का संग्रह हैं, और Actions कार्यवाही के पाइपलाइन हैं। पूरी प्रणाली, मानवीय कार्य गति, विचार प्रक्रिया और सहयोग मॉडल के लिए डिज़ाइन की गई है।

AI एजेंट ने यह सब बदल दिया।

जब एक AI एजेंट एक दिन में सैकड़ों बार कोड सबमिट कर सकता है, और प्रत्येक "सबमिट" के पीछे मानवीय सोच और तौलना नहीं होती, बल्कि केवल एक कार्य चक्र का प्रगति चरण होता है—क्या कोड रिपॉजिटरी अभी भी "सहयोग का कंटेनर" है?

जब AI टूल्स रिपॉजिटरी को स्वचालित रूप से बनाते हैं, स्वचालित रूप से PR खोलते हैं, स्वचालित रूप से CI चलाते हैं और स्वचालित रूप से मर्ज करते हैं—तो क्या डेवलपर्स अभी भी इस प्रक्रिया के मुख्य हिस्से हैं, या क्या वे केवल “समीक्षक” या यहां तक कि “दर्शक” बन चुके हैं?

GitHub के CTO ने इस संकट का वर्णन करते हुए "लोड में तेजी से वृद्धि" शब्द का उपयोग किया। लेकिन यह शब्द संभवतः समस्या की प्रकृति को कम दर्शा रहा है—यह केवल मात्रा में वृद्धि नहीं है, बल्कि उपयोग के तरीके में गुणात्मक परिवर्तन है। पुराने मॉडल में, GitHub "डेवलपर्स का टूल" था; नए मॉडल में, GitHub "AI का निकास" बन रहा है, एक स्वचालित प्रवाह का आउटपुट पाइपलाइन।

इसका GitHub के लिए क्या अर्थ है, अभी तक कोई जवाब नहीं है। 30 गुना स्केलिंग ट्रैफ़िक समस्या को हल कर सकती है, लेकिन व्यावसायिक मॉडल की पुनः परिभाषा और 'मेरे वास्तविक उपयोगकर्ता कौन हैं' इस पहचान समस्या को हल नहीं कर सकती।

हाल ही में एक काफी मायने रखने वाली घटना देखी गई: GitHub के डाउनटाइम के बाद, उन्होंने कई इंजीनियरिंग ब्लॉग पोस्ट शुरू किए, जिनमें प्रत्येक दुर्घटना के मूल कारण का बहुत विस्तृत वर्णन किया गया, जो लगभग अप्रत्याशित स्तर की पारदर्शिता है। कुछ लोग मानते हैं कि GitHub जानबूझकर विश्वास बना रहा है, जबकि कुछ का मानना है कि यह विकासकर्ता समुदाय की धैर्य के लिए पारदर्शिता का आदान-प्रदान है—क्योंकि आगे की पुनर्निर्माण अवधि में और अधिक अस्थिरता होगी।

एक प्लेटफॉर्म, जो अपनी सफलता से छिद्रित हो गया है, उसे खुद को तोड़कर पुनः बनाने की आवश्यकता है—और इस प्रक्रिया के दौरान, यह भी परीक्षा है कि क्या वह टिक सकता है।

9 फरवरी की रात, उस इंजीनियर ने, जो PR के मर्ज का इंतजार कर रहा था, शायद अंततः हरा बत्ती पाई। लेकिन उसे संभवतः यह नहीं पता था कि उसके इंतजार का कारण बनी डाउनटाइम, GitHub की एक अनिच्छित घटना नहीं, बल्कि पूरे सॉफ्टवेयर विकास उद्योग के एक नए युग की शुरुआत की आवाज़ थी।

यह लेख वेचेन ग्रुप "जीक पार्क" (ID: geekpark) से आया है, लेखक: युहांगयुआन

डिस्क्लेमर: इस पेज पर दी गई जानकारी थर्ड पार्टीज़ से प्राप्त की गई हो सकती है और यह जरूरी नहीं कि KuCoin के विचारों या राय को दर्शाती हो। यह सामग्री केवल सामान्य सूचनात्मक उद्देश्यों के लिए प्रदान की गई है, किसी भी प्रकार के प्रस्तुतीकरण या वारंटी के बिना, न ही इसे वित्तीय या निवेश सलाह के रूप में माना जाएगा। KuCoin किसी भी त्रुटि या चूक के लिए या इस जानकारी के इस्तेमाल से होने वाले किसी भी नतीजे के लिए उत्तरदायी नहीं होगा। डिजिटल संपत्तियों में निवेश जोखिम भरा हो सकता है। कृपया अपनी वित्तीय परिस्थितियों के आधार पर किसी प्रोडक्ट के जोखिमों और अपनी जोखिम सहनशीलता का सावधानीपूर्वक मूल्यांकन करें। अधिक जानकारी के लिए, कृपया हमारे उपयोग के नियम और जोखिम प्रकटीकरण देखें।