GitHub: Git कार्यों में बाधा
(githubstatus.com)- 18 नवंबर 2025 (UTC) को GitHub पर सभी Git कार्य विफल हो गए, जिससे SSH·HTTP क्लाइंट और raw file access बाधित हो गया
- समस्या का कारण आंतरिक सेवाओं के बीच संचार में उपयोग किए गए TLS certificate की अवधि समाप्त होना पाया गया
- GitHub ने समाप्त हो चुके certificate को बदलकर और प्रभावित सेवाओं को restart करके सामान्य बहाली पूरी की
- इसके बाद certificate expiry monitoring alerts को मजबूत किया गया, और manually managed certificates को हटाने के लिए automation transition work जारी है
- इस outage ने GitHub के Git Operations और Codespaces को प्रभावित किया, और बहाली के बाद सभी सेवाएं सामान्य स्थिति में लौट आईं
Git कार्य बाधा रिपोर्ट
-
18 नवंबर 2025 20:30~21:34 UTC के दौरान GitHub पर सभी Git कार्य विफल हुए
- SSH और HTTP Git client interactions, तथा raw file access सभी प्रभावित हुए
- Git कार्यों पर निर्भर प्रोडक्ट्स ने भी इसी तरह बाधा का सामना किया
-
कारण आंतरिक सेवाओं के बीच संचार में उपयोग किए गए समाप्त TLS certificate के रूप में पहचाना गया
- GitHub ने certificate बदलकर और प्रभावित सेवाओं को restart करके समस्या का समाधान किया
- सेवा restart के बाद पूर्ण बहाली हुई
-
GitHub भविष्य में ऐसी ही समस्या रोकने के लिए certificate expiry alert system को सुदृढ़ कर रहा है
- संबंधित क्षेत्रों के अन्य certificates पर भी monitoring और automation checks किए जा रहे हैं
- बचे हुए manual certificate management को हटाने और automated service-to-service communication system बनाने की प्रक्रिया तेज की जा रही है
बाधा की प्रगति और बहाली चरण
- 20:39 UTC: Git कार्यों और Codespaces में availability degradation रिपोर्ट हुई
- 20:52 UTC: कुछ Git HTTP कार्यों की विफलता की पुष्टि हुई
- 21:11 UTC: सभी Git कार्यों की विफलता की पुष्टि हुई
- 21:25 UTC: Codespaces में availability degradation जारी रही
- 21:27 UTC: कारण की पहचान पूरी, fix का काम जारी
- 21:36 UTC: fix deploy होने के बाद आंशिक बहाली शुरू हुई
- 21:55 UTC: सभी सेवाएं सामान्य, Codespaces की बहाली पूरी
- 21:56 UTC: Git कार्यों के सामान्य संचालन की पुष्टि हुई
- 21:59 UTC: घटना समाप्त और रिपोर्ट प्रकाशित
प्रभावित सेवाएं
- Git Operations
- SSH और HTTP आधारित Git कार्यों का पूरा दायरा
- Codespaces
- अस्थायी availability degradation हुई
अनुवर्ती कार्रवाई
- certificate expiry monitoring और automation को मजबूत करना
- expiry से पहले warning alert system स्थापित करना
- सभी आंतरिक certificates की automatic renewal process की जांच
- security और operations automation का विस्तार
- manual certificate management हटाना
- आधुनिक security practices के अनुरूप automated service-to-service communication बनाना
1 टिप्पणियां
Hacker News टिप्पणियाँ
हाल की बड़ी software system outages बहुत ज़्यादा बार हो रही हैं, यह चिंता की बात लगती है
पिछले साल काम को प्रभावित करने वाली outages सिर्फ़ चार थीं, लेकिन इस quarter में यह पहले से ही चौथी है
लगता है कि network software की resiliency धीरे-धीरे गायब होती जा रही है
हमारी टीम monolithic architecture पर है, लेकिन Redis, S3, external integration services जैसी कई dependencies हैं
इसलिए हमने outage conditions को document किया, testing और deployment automation को मज़बूत किया, और cloud की जगह VPS पर migrate करने जैसी simplification की
नतीजा यह हुआ कि system काफ़ी ज़्यादा stable और predictable हो गया
अगर यह उबाऊ लेकिन ज़रूरी काम नहीं किया होता, तो सिर्फ़ complexity बढ़ती और system और नाज़ुक बन जाता
हाल में जिन outages का सामना किया, वे AWS us-east-1, Azure Front Door, Cloudflare, और GitHub outages थे
ग्राहक resiliency या redundant infrastructure पर पैसा खर्च नहीं करना चाहते
2008 के बाद से मैंने 10 से ज़्यादा projects किए हैं, लेकिन ज़्यादातर का रवैया “बस किस्मत पर छोड़ दो” वाला था
Git एक distributed version control system है, इसलिए GitHub के बिना भी काम किया जा सकता है
GitHub सिर्फ़ एक convenient hub है
GitHub की reliability की कमी गंभीर लगती है
CI/CD पर निर्भर लोगों के लिए यह घातक है
अंदरूनी तौर पर इसे सिर्फ़ “हमारी टीम का CI/CD टूट गया” के स्तर पर देखा जाता है, “दुनिया का आधा हिस्सा रुक गया” इस नज़रिए की कमी है
ऐसी silo culture और “यह हमारी समस्या नहीं है” वाला रवैया reliability गिरने की वजह बनता है
ऊपर से monopoly जैसी स्थिति के कारण ग्राहक भी मजबूरी में इसे झेलते रहते हैं
यह वैसा ही रवैया है जैसा पहले Verio, Verisign में देखा था: “वैसे भी आप कहीं और जा नहीं सकते”
यह जानने की उत्सुकता है कि आजकल cloud/SaaS outages सचमुच ज़्यादा बार हो रही हैं या नहीं
समझ नहीं आता कि सिर्फ़ reporting बढ़ी है या frequency सच में बढ़ी है
क्या इसकी वजह budget cuts, layoffs, AI adoption, या overgrowth हो सकती है?
पहले साल में एक-दो बार होता था, अब लगभग हर महीने, और हाल में तो हर हफ़्ते जैसा लग रहा है
AI से बने छोटे code fragments भी domino-style outage पैदा कर सकते हैं
कुछ लोग मानते हैं कि mass layoffs ने reliability गिरने पर असर डाला है
और आख़िरकार stability के लिए ज़रूरी आख़िरी 10% काम नज़रअंदाज़ हो जाता है
push नहीं हो रहा था, तो पहले लगा कि समस्या मेरी ही है
सोचा आज के लिए छोड़ देता हूँ और कल फिर कोशिश करूँगा
आज वैसे भी काम करने का मन नहीं था, और Cloudflare के बाद GitHub भी ठप हो गया, तो यह बस आराम करने का संकेत लग रहा है
ज़्यादा technological sovereignty और decentralization की ज़रूरत है
पिछले 5 साल में इस्तेमाल की गई services में GitHub सबसे unstable रहा है
सोच रहा हूँ GitLab बेहतर है या नहीं। अब GitHub पर भरोसा लगभग शून्य है
शायद large monorepo environment की वजह से, लेकिन scalability issues साफ़ हैं
फिर भी repository, CI/CD, issues, wiki को एक ही जगह रखना इसका फ़ायदा है
GitHub cloud outages के प्रति कमज़ोर है, जबकि GitLab में automatic upgrade failures बार-बार होते हैं
दोनों के अपने फ़ायदे और नुकसान हैं
कई MB का JS लोड करता है, इसलिए slow networks पर page लगभग खुलता ही नहीं
emergency में GitHub web UI से सीधे file edit की जा सकती है
लेकिन GH Actions का
actions/checkout@v4इस समय git समस्या की वजह से काम नहीं कर रहापिछले 10 साल में बड़ी companies और startups के बीच काम करते हुए एक common pattern देखा है
startup → enterprise customers को serve करना → complex redesign → idealism → profit chasing → product bloat → core engineers का जाना → quality गिरना
यही cycle cloud giants (AWS, Cloudflare, GCP आदि) में भी दोहराई जाती है
अंदरूनी तौर पर भी हर service को छोटी business units में बाँट दिया जाता है और वे profit-centric तरीके से चलती हैं
आख़िरकार basic infrastructure भी profit pressure की वजह से कमज़ोर पड़ने लगती है
“AWS या GCP इतने बड़े हैं कि कभी नहीं गिरेंगे” ऐसा विश्वास ख़तरनाक लगता है
लेकिन शुरुआती startup दौर का technical debt और security issues भी गंभीर थे
आख़िरकार बड़े पैमाने की growth के दौरान system की दरारें दिखना स्वाभाविक है
GitHub status page पर फिर वही लिखा गया: “कुछ users को issues हो सकते हैं”
लेकिन हक़ीक़त यह है कि सिर्फ़ HTTPS ही नहीं बल्कि SSH push भी पूरी तरह fail हो रहा है
PR-style euphemism के बजाय अगर पारदर्शी जानकारी दी जाए तो भरोसा ज़्यादा बढ़ेगा
ऊपर से कई बार status page updates भी देर से आते हैं