3 पॉइंट द्वारा GN⁺ 2025-11-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 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 टिप्पणियां

 
GN⁺ 2025-11-20
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 किए हैं, लेकिन ज़्यादातर का रवैया “बस किस्मत पर छोड़ दो” वाला था
    • सहमत हूँ। cost cutting का नतीजा आख़िरकार यह हो रहा है कि “outage आने पर भी टिके रहने वाले systems बनाना हम भूलते जा रहे हैं”
    • जानबूझकर थोड़ा उकसाने वाले अंदाज़ में कहूँ तो, LLM usage में बढ़ोतरी भी इस स्थिति में योगदान दे रही है
  • Git एक distributed version control system है, इसलिए GitHub के बिना भी काम किया जा सकता है
    GitHub सिर्फ़ एक convenient hub है

    • लेकिन अगर कोई company GitHub Actions पर पूरी तरह निर्भर है, तो वह अभी की तरह पूरी तरह रुक जाती है
    • यह कुछ ऐसा है जैसे “यह escalator अस्थायी रूप से सीढ़ी बन गया है। असुविधा के लिए खेद है”
    • समस्या की असली जड़ यह है कि GitHub down है, git ख़ुद down नहीं है
    • GitHub के बिना आप दूसरों के साथ collaboration hub वाली क्षमता खो देते हैं
    • अभी Hacker News पर होने की वजह यह है कि काम नहीं हो पा रहा
  • GitHub की reliability की कमी गंभीर लगती है
    CI/CD पर निर्भर लोगों के लिए यह घातक है
    अंदरूनी तौर पर इसे सिर्फ़ “हमारी टीम का CI/CD टूट गया” के स्तर पर देखा जाता है, “दुनिया का आधा हिस्सा रुक गया” इस नज़रिए की कमी है
    ऐसी silo culture और “यह हमारी समस्या नहीं है” वाला रवैया reliability गिरने की वजह बनता है
    ऊपर से monopoly जैसी स्थिति के कारण ग्राहक भी मजबूरी में इसे झेलते रहते हैं
    यह वैसा ही रवैया है जैसा पहले Verio, Verisign में देखा था: “वैसे भी आप कहीं और जा नहीं सकते”

  • यह जानने की उत्सुकता है कि आजकल cloud/SaaS outages सचमुच ज़्यादा बार हो रही हैं या नहीं
    समझ नहीं आता कि सिर्फ़ reporting बढ़ी है या frequency सच में बढ़ी है
    क्या इसकी वजह budget cuts, layoffs, AI adoption, या overgrowth हो सकती है?

    • लगता है Microsoft को विश्वास है कि GitHub को Azure पर ले जाने से समस्या हल हो जाएगी
    • लंबे समय से इस्तेमाल करने वाले के नज़रिए से देखें तो outage frequency बढ़ी है, यह साफ़ महसूस होता है
      पहले साल में एक-दो बार होता था, अब लगभग हर महीने, और हाल में तो हर हफ़्ते जैसा लग रहा है
    • Cloudflare outage के समय किसी ने कहा था कि “AI-based coding culture” ऐसी समस्याओं को बढ़ा रही है
      AI से बने छोटे code fragments भी domino-style outage पैदा कर सकते हैं
    • Techrights article की तरह,
      कुछ लोग मानते हैं कि mass layoffs ने reliability गिरने पर असर डाला है
    • AI की वजह से पैदा हुआ FOMO project timelines को और कस देता है,
      और आख़िरकार stability के लिए ज़रूरी आख़िरी 10% काम नज़रअंदाज़ हो जाता है
  • push नहीं हो रहा था, तो पहले लगा कि समस्या मेरी ही है
    सोचा आज के लिए छोड़ देता हूँ और कल फिर कोशिश करूँगा

    • authentication हो रहा था लेकिन push नहीं हो रहा था, यह सचमुच बाल नोच लेने जैसा अनुभव था
    • नई SSH key जोड़ने से भी कोई फ़ायदा नहीं हुआ। पहले अजीब error आते रहे, फिर आख़िर में “upstream unhealthy” message मिला
    • मैं भी लगभग अपना environment शुरू से फिर से set up करने वाला था
  • आज वैसे भी काम करने का मन नहीं था, और Cloudflare के बाद GitHub भी ठप हो गया, तो यह बस आराम करने का संकेत लग रहा है

    • अमेरिका-केंद्रित centralized tech dependence ही समस्या है
      ज़्यादा technological sovereignty और decentralization की ज़रूरत है
  • पिछले 5 साल में इस्तेमाल की गई services में GitHub सबसे unstable रहा है
    सोच रहा हूँ GitLab बेहतर है या नहीं। अब GitHub पर भरोसा लगभग शून्य है

    • हमारी company GitLab को self-host करती है, लेकिन Gitaly servers अक्सर crash हो जाते हैं
      शायद large monorepo environment की वजह से, लेकिन scalability issues साफ़ हैं
    • GitLab में features बहुत हैं, लेकिन integration ढीला-ढाला है और polish कम है
      फिर भी repository, CI/CD, issues, wiki को एक ही जगह रखना इसका फ़ायदा है
    • हम GitHub.com और self-hosted GitLab दोनों इस्तेमाल करते हैं,
      GitHub cloud outages के प्रति कमज़ोर है, जबकि GitLab में automatic upgrade failures बार-बार होते हैं
      दोनों के अपने फ़ायदे और नुकसान हैं
    • GitLab की समस्या यह है कि यह slow और heavy है
      कई MB का JS लोड करता है, इसलिए slow networks पर page लगभग खुलता ही नहीं
    • अगर इसे on-premises रखा जाए, तो चाहें उतनी stability हासिल की जा सकती है
  • emergency में GitHub web UI से सीधे file edit की जा सकती है
    लेकिन GH Actions का actions/checkout@v4 इस समय git समस्या की वजह से काम नहीं कर रहा

    • सच तो यह है कि किसी भी SSH-accessible host पर git push/pull किया जा सकता है
    • हम भी production hotfix कर रहे थे, लेकिन वहीं अटक गए। समझ नहीं आता आजकल internet पर क्या हो रहा है
    • CircleCI में भी GitHub SSH key recognition issue की वजह से git operations fail हो रहे हैं
    • इस बार GitHub AI ने githubstatus.com चेक करने को कहा, और वह अनपेक्षित रूप से मददगार निकला
    • सोच रहा हूँ कि GitHub UI में branch create करना संभव है या नहीं
  • पिछले 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 इतने बड़े हैं कि कभी नहीं गिरेंगे” ऐसा विश्वास ख़तरनाक लगता है

    • सहमत हूँ। enterprise की ज़रूरतें पूरी करते-करते product का complex और sluggish हो जाना लगभग तय है
      लेकिन शुरुआती startup दौर का technical debt और security issues भी गंभीर थे
      आख़िरकार बड़े पैमाने की growth के दौरान system की दरारें दिखना स्वाभाविक है
  • GitHub status page पर फिर वही लिखा गया: “कुछ users को issues हो सकते हैं”
    लेकिन हक़ीक़त यह है कि सिर्फ़ HTTPS ही नहीं बल्कि SSH push भी पूरी तरह fail हो रहा है

    • लगता है status page संभालने वाले लोग “कुछ users” वाली भाषा से बाहर निकल ही नहीं पाते
      PR-style euphemism के बजाय अगर पारदर्शी जानकारी दी जाए तो भरोसा ज़्यादा बढ़ेगा
      ऊपर से कई बार status page updates भी देर से आते हैं
    • मेरे एक दोस्त ने कहा कि थोड़ी देर के लिए push हुआ था, लेकिन ज़्यादातर लोग अभी भी fatal errors में फँसे हैं