GitHub की availability पर अपडेट

 (github.blog)
2 पॉइंट द्वारा GN⁺ 18 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • हाल की दो outages के बाद GitHub availability को सर्वोच्च प्राथमिकता दे रहा है, और तेज़ी से बढ़े development workloads तथा agentic development workflows के अनुरूप अपने infrastructure और architecture को फिर से व्यवस्थित कर रहा है
  • एक pull request भी Git repository, Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, databases तक व्यापक रूप से जुड़ी होती है, इसलिए छोटी inefficiency भी बढ़कर queue buildup और dependency propagation में बदल सकती है
  • अल्पकाल में GitHub, webhooks के backend migration, user session cache के redesign, authentication·authorization flow के adjustment, और Azure-आधारित compute expansion के ज़रिए bottlenecks और database load घटाने पर ध्यान दे रहा है
  • दीर्घकाल में core service isolation, single point of failure को कम करना, Ruby monolith के कुछ हिस्सों को Go में migrate करना, public cloud migration और multi cloud path सुनिश्चित करने के जरिए resilience और flexibility बढ़ाई जा रही है
  • 23 अप्रैल की merge queue regression और 27 अप्रैल के Elasticsearch overload—दोनों मामलों में data loss नहीं हुआ, और GitHub status page में availability metrics जोड़कर तथा छोटे outages तक को सार्वजनिक कर transparency भी बढ़ा रहा है

availability प्रतिक्रिया की पृष्ठभूमि

  • GitHub ने हाल की दो outages के बाद availability और reliability सुधार कार्यों की वर्तमान स्थिति साझा की है
  • अक्टूबर 2025 से capacity को 10 गुना बढ़ाने की योजना लागू की गई थी, और फ़रवरी 2026 तक यह स्पष्ट हो गया कि मौजूदा scale के 30 गुना को ध्यान में रखकर design करना पड़ेगा
  • software development के तरीकों में बदलाव इसका मुख्य कारण है, और 2025 की दूसरी छमाही के बाद agentic development workflows तेज़ी से बढ़े हैं
  • repository creation, pull request activity, API usage, automation, और large repository workloads—सब तेज़ी से बढ़ रहे हैं

विस्तार के दौरान सामने आया संरचनात्मक दबाव

  • एक pull request Git repository, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, databases—सभी को एक साथ प्रभावित कर सकती है
  • बड़े scale पर छोटी inefficiency भी जमा होकर queue buildup, cache miss के कारण database load transfer, index delay, retry traffic amplification, और धीमी dependency के multi-product impact तक पहुँच सकती है
  • प्राथमिकता क्रम है: availability पहले, फिर capacity, और उसके बाद नए features
  • अनावश्यक work कम करना, cache सुधारना, core services को isolate करना, single point of failure हटाना, और performance-sensitive paths को dedicated systems में migrate करना—ये काम साथ-साथ चल रहे हैं
  • लक्ष्य यह है कि किसी एक subsystem पर दबाव आने पर पूरा सिस्टम न गिरे; इसके लिए hidden coupling कम करना, blast radius सीमित करना, और graceful degradation सुनिश्चित करना प्रमुख कार्य हैं

वर्तमान में चल रहे सुधार

  • अल्पकाल में GitHub उन bottlenecks को दूर करने पर केंद्रित है जो अपेक्षा से पहले सामने आ गए
  • webhooks को MySQL के बाहर दूसरे backend पर migrate किया गया, user session cache को redesign किया गया, और authentication·authorization flow को भी फिर से बदला गया, जिससे database load काफ़ी कम हुआ
  • Azure migration का उपयोग करके ज़्यादा compute resources भी हासिल किए गए
  • इसके बाद git और GitHub Actions जैसी core services की isolation और single point of failure कम करने पर फ़ोकस है
  • dependencies और traffic layers का सूक्ष्म विश्लेषण कर यह पहचाना गया कि क्या अलग करना है, और अलग-अलग हमलों का सामान्य traffic पर असर न्यूनतम करने के लिए risk priority के अनुसार कार्रवाई की जा रही है
  • performance या scale के प्रति संवेदनशील कुछ code को Ruby monolith से Go में migrate करने का काम भी तेज़ किया गया है
  • छोटे self-hosted datacenters से public cloud की ओर migration के बीच, लंबी अवधि के लिए multi cloud path पर भी काम शुरू हो गया है
  • यह दीर्घकालिक कदम भविष्य के लिए आवश्यक resilience, कम latency, और flexibility सुनिश्चित करने के लिए ज़रूरी है

बड़े repositories और merge queue पर काम

  • GitHub ने repository count बढ़ने से भी बड़ी scaling challenge के रूप में बड़े monorepo की बढ़ोतरी को चिह्नित किया है
  • पिछले 3 महीनों में git system और pull request experience—दोनों पक्षों पर इस trend से निपटने के लिए निवेश काफ़ी बढ़ाया गया है
  • अधिक efficiency और scalability के लिए नई API design से जुड़ा काम भी चल रहा है, जिसे अलग blog post में साझा किया जाएगा
  • ऐसे repositories के लिए जहाँ प्रतिदिन हज़ारों pull requests आती हैं, merge queue workload optimization में भी निवेश किया जा रहा है

हाल की outage 1: 23 अप्रैल का merge queue issue

  • 23 अप्रैल को pull request की merge queue behavior regression हुई
  • squash merge method इस्तेमाल करने वाली merge queue में, यदि merge group में दो या अधिक pull requests शामिल थीं, तो गलत merge commit बन रहा था
  • प्रभावित मामलों में बाद की merges ऐसी स्थिति बना देती थीं जहाँ पहले merged pull requests और मौजूदा commits के बदलाव अनजाने में revert हो जाते थे
  • प्रभाव की अवधि में 658 repositories और 2,092 pull requests प्रभावित हुईं
  • शुरुआती संख्या conservative अनुमान पर आधारित थी, इसलिए पहले साझा किया गया आँकड़ा इससे थोड़ा अधिक था
  • merge queue के बाहर merged pull requests प्रभावित नहीं हुईं, और merge या rebase method इस्तेमाल करने वाले merge queue groups भी प्रभावित नहीं हुए
  • data loss नहीं हुआ। सभी commits Git में सुरक्षित रूप से मौजूद रहे
  • हालाँकि प्रभावित repositories की default branch की स्थिति गलत हो गई थी, और सभी repositories को अपने-आप सुरक्षित रूप से restore करना संभव नहीं था
  • incident root cause analysis: यहाँ अतिरिक्त विवरण देखे जा सकते हैं
  • इस outage ने कई process failures को उजागर किया, और GitHub अब उन processes को बदल रहा है ताकि इसी तरह की समस्या दोबारा न हो

हाल की outage 2: 27 अप्रैल का search-related issue

  • 27 अप्रैल को कई search-based experiences को संभालने वाले Elasticsearch subsystem में outage हुई
  • प्रभावित दायरे में pull requests, issues, और projects के कुछ search-based UI शामिल थे
  • root cause analysis अभी पूरी की जा रही है और जल्द साझा की जाएगी
  • अब तक की जानकारी के अनुसार cluster overload state में चला गया था, जिसके कारण वह search results लौटाने में विफल रहा
  • overload के कारण के रूप में botnet attack की संभावना भी खुली है, लेकिन root cause analysis अभी पूरी नहीं हुई है
  • data loss नहीं हुआ, और Git operations और APIs प्रभावित नहीं हुए
  • लेकिन search पर निर्भर कुछ UI कोई परिणाम दिखा ही नहीं पाईं, जिससे काफ़ी भ्रम पैदा हुआ
  • यह सिस्टम उन क्षेत्रों में था जहाँ single point of failure हटाने के लिए पूर्ण isolation अभी पूरी नहीं हुई थी, और तब तक अन्य क्षेत्रों के risk की प्राथमिकता अधिक थी
  • अब इसी तरह के dependency analysis और blast radius reduction कार्य लागू किए जा रहे हैं ताकि ऐसी विफलताओं की संभावना और प्रभाव कम किए जा सकें

outage transparency को मज़बूत करना

  • outages के दौरान यह स्पष्ट हुआ कि customers अधिक transparency चाहते हैं
  • GitHub ने हाल ही में GitHub status page अपडेट किया है ताकि उसमें availability metrics शामिल हों
  • अब केवल बड़ी outages ही नहीं, छोटी outages भी status पर डाली जाएँगी, ताकि users को यह अनुमान न लगाना पड़े कि समस्या उनकी ओर है या GitHub की ओर
  • incident classification का तरीका भी लगातार सुधारा जा रहा है ताकि scale और scope को अधिक आसानी से समझा जा सके
  • outages के दौरान customers किस तरह signals साझा करते हैं और issues report करते हैं, इसे बेहतर बनाने पर भी साथ-साथ काम चल रहा है

आगे की प्रतिबद्धता

  • GitHub ने availability सुधार, resilience बढ़ाने, भविष्य के software development scale के अनुरूप विस्तार, और अधिक transparent communication का वादा किया है
  • 23 अप्रैल की outage से प्रभावित repositories की संख्या 28 अप्रैल 2026 के आधार पर अपडेट की गई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 18 시간 전
Hacker News की राय

  • GitHub ने इस साल अब तक दर्जनों बार outage दिए हैं, और availability व reliability पिछले साल की तुलना में साफ़ तौर पर खराब हुई है
    हालात इतने गंभीर लगते हैं कि dashboard और heatmap घूमने लगें, और HN या Reddit जैसी जगहों पर GitHub instability एक meme बन जाए, उस स्तर तक बात पहुँच चुकी है
    फिर भी प्राथमिकता को "availability, capacity, new features" बताना ज़मीनी हक़ीक़त की बहुत ढीली समझ दिखाता है
    अभी प्राथमिकता 1, 2, 3 सब availability ही होनी चाहिए, और कम से कम 6 महीने तक बाकी किसी बात की जगह सिर्फ़ यही ठीक करना चाहिए

  • 6 महीने पहले कहा गया था कि Azure migration सबसे बड़ी प्राथमिकता है इसलिए feature development टाला जाएगा, और अब कहा जा रहा है कि availability सबसे बड़ी प्राथमिकता है, तो बातों में तालमेल नहीं दिखता
    तब कहा गया था कि AI और Copilot की demand के कारण Virginia data center की capacity limit "existential" है, लेकिन अब भी उसी समस्या से जूझते दिखना और भी अजीब लगता है
    कहा गया कि feature development टली हुई है, फिर भी हर हफ्ते नए features और UI बदलाव आते रहे, और हाल में issue single view भी बदल दिया गया
    Microsoft जैसी resources वाली company का बार-बार उसी जगह अटकना यक़ीन करना मुश्किल बनाता है, और popular developer services खरीदकर सबको एक ही platform पर ले जाने की strategy भी अस्थिर लगती है

    • यह कुछ ज़्यादा ही दुर्भावनापूर्ण व्याख्या जैसा भी लगता है
      बड़े engineering orgs में priorities एक-दूसरे को पूरी तरह exclude नहीं करतीं, और जो teams core priority में सीधे योगदान नहीं देतीं वे दूसरे feature work जारी रख सकती हैं
    • वह single issues view बदलाव performance pressure कम करने के लिए panic hack जैसा था
      https://news.ycombinator.com/item?id=47912521
    • यह भी पूरी तरह संभव है कि Azure migration ने availability की समस्या और बढ़ा दी हो
      dedicated hardware अक्सर cloud से ज़्यादा predictable होता है, और "Azure पर जाने के बजाय कुछ और racks खरीद लेते हैं" जैसी बात GitHub management के स्तर पर तय करने लायक न रही हो
    • पिछले 5 सालों में feature changes बिल्कुल न भी हुए होते तो शायद किसी को गुस्सा नहीं आता, फिर भी लगातार चीज़ें बदली जा रही हैं
      GitHub कोई ऐसी site नहीं है जिसे हर 5 मिनट में redesign करना पड़े, और कभी-कभी ऐसा लगता है जैसे managers अपने होने का औचित्य साबित करने के लिए नए features के लिए नए features धकेल रहे हों
      नतीजा यह है कि जितना ज़्यादा वे चीज़ें तोड़ते हैं, उतना ही users को आकर्षित करने में उल्टा असर पड़ता है
      search भी काफ़ी कमजोर कर दी गई है, और Google Search या YouTube की तरह समझ नहीं आता कि पहले से ठीक चल रही search को सब क्यों बिगाड़ते रहते हैं
      ऊपर से Microsoft के पास लगभग छोड़ा हुआ-सा Azure DevOps भी है और GitHub भी, और दोनों में खासकर ticketing systems पसंद नहीं आते
      Jira projects में हर जगह अलग config देखकर पहले ही थक चुके थे, अब हालत यह है कि लोग कहने लगे हैं, "काश Jira ही होता"

  • वह पोस्ट गंभीरता से पढ़ना मुश्किल लगती है
    सिर्फ़ बड़े numbers वाली बिना label की graphs, लोगों के actual अनुभव से न मिलती priorities, और पिछले 12 महीनों के भयानक uptime को ठीक से स्वीकार न करने वाला रवैया—ये सब बहुत खटकता है

    • graph बिल्कुल सबसे बुरा नहीं है
      नीचे बाएँ axis label नहीं है, लेकिन 2023→2024→2025→2026 के बीच growth rate बहुत तेज़ है, यह मुख्य बात फिर भी समझ आती है
      2026 की शुरुआत या अंत तक यह पिछले 3 सालों को जोड़ने से भी बड़ी growth बताता हुआ पढ़ा जा सकता है, और axis numbers न पता हों तब भी मोटा trend समझ आता है
      linear graph मानना पड़ता है, लेकिन context में यह बहुत खिंचा हुआ assumption नहीं लगता
      अगर कोई company plan से कहीं ज़्यादा growth झेल रही हो तो capacity issue आना तय है, और अब सिर्फ़ hardware बढ़ाने से आगे जाकर backend efficiency पर काम चाहिए
      लिखे गए goals भी ज़्यादातर उसी दिशा में लगते हैं
    • numbers यहाँ भी हैं
      https://x.com/kdaigle/status/2040164759836778878
      समझ नहीं आता लोग current growth के exponential होने पर शक कर रहे हैं, या फिर सालाना 10x growth को मामूली मान रहे हैं
    • हो सकता है acquisition के बाद पूरे 6 साल से यही हाल रहा हो
      https://damrnelson.github.io/github-historical-uptime/
    • कुल मिलाकर यह लगभग 300 शब्दों का "हम सुन रहे हैं" संदेश लगता है
    • इस तरह की सजावटी graphs बहुत से clients इसी तरह इस्तेमाल करते हैं

  • "multi cloud path शुरू किया है" जैसी पंक्ति पढ़कर लगता है कि Microsoft ने लगभग मान लिया है कि Azure अकेले उनकी चाही reliability नहीं दे पा रहा

    • यह काफ़ी गंभीर signal लगता है, और Azure इस्तेमाल करने वालों को यह बात काफ़ी विश्वसनीय भी लगेगी
    • यह शायद downtime में पैसा खोने वाले enterprise customers को ध्यान में रखकर किया गया जवाब भी हो सकता है
      retention बचाने में मदद मिल सकती है
    • इतने बड़े और जटिल system के लिए single vendor dependency से बचना वैसे भी समझदारी है
    • याद पड़ता है कि पहले यहाँ Dave Cutler की Azure vision के priorities, pressure और management के कारण बिगड़ जाने पर एक पोस्ट देखी थी
      मूल सोच यह थी कि operations में इंसानी दखल बहुत कम हो, लेकिन अब स्थिति यह बताई गई थी कि लोग racks या VMs पर serial लगाकर सीधे हाथ से छेड़छाड़ करते हैं, और वही रोज़मर्रा की प्रक्रिया बन गई है
      अभी वह link नहीं मिल रहा
    • Show HN में पोस्ट करने का समय उम्मीद से ज़्यादा मायने रखता है
      Pacific time के हिसाब से Mon–Thu सुबह 9–11 बजे सबसे सक्रिय readers मिलते हैं, जबकि weekend पर competition कम लेकिन engagement भी कम होती है

  • GitHub CTO Codepath.org के board में भी हैं, और अगर वहाँ का description "पहली AI-native पीढ़ी के engineers, CTOs और founders बनाते हैं" जैसा है, तो दिक्कत कहाँ हो सकती है इसका अंदाज़ा लग जाता है

  • अनुभव के स्तर पर GitHub stability काफ़ी खराब रही है, और हाल में web पर दिखने वाले data पर भी भरोसा करना मुश्किल हो गया है
    कल से मैं और मेरे कुछ सहकर्मी कई repositories में PR lists अधूरी दिखने की समस्या देख रहे हैं
    उदाहरण के लिए https://github.com/gap-system/gap/pulls में tab पर "Pull requests 78" दिखता है, लेकिन list view में सिर्फ़ "35 open" दिखता है
    78 सही संख्या है, यह gh pr list से भी confirm होता है, फिर भी https://www.githubstatus.com अब भी "all systems operational" दिखा रहा है

    • मेरे projects में से काफ़ी में हाल के 6 दिनों में बंद हुए PRs एक भी नहीं दिख रहे
      CLI से list आती है, लेकिन search से गुजरने वाले web path में सब गायब हो जाते हैं
      support team ने issue मान लिया है, लेकिन उसके बाद चुप्पी है, और status page पर 27 तारीख़ का शायद जुड़ा हुआ एक issue छोड़कर कुछ नहीं है
      कुछ repositories में बीच में यह ठीक हुआ-सा लगा, लेकिन कई orgs और repos में अभी भी लगातार reproduce हो रहा है
      https://github.com/orgs/community/discussions/193388
    • मैंने भी यही व्यवहार देखा है, और status page पर अब भी इसका ज़िक्र नहीं है
      गायब PRs मुझे branch pages खंगालकर ढूँढने पड़े
    • काफ़ी संभावना है कि scale के कारण approximate queries इस्तेमाल करने वाला कोई hack लगाया गया हो, जो 100% accurate results नहीं देता
      यह पूरी तरह bug कम और infrastructure load घटाने के लिए product के नज़रिए से लिया गया बहुत खराब फैसला ज़्यादा हो सकता है

  • पिछले कुछ सालों के नए repo/issues/commits data को public करना फिर भी दिलचस्प था
    बाहर से लोग जैसा अंदाज़ा लगा रहे थे, उसी तरह यह पुष्टि करता है कि agents GitHub पर अचानक और बड़ा अतिरिक्त load डाल रहे हैं
    पहले से विशाल user base को service देते हुए भी startup जैसी exponential growth झेलनी पड़ रही है, इसलिए निशाने पर आना तय है, और organization के लिए तेज़ी से move करना भी आसान नहीं होगा
    दूसरी तरफ़ talent, infrastructure और capital startup से कहीं ज़्यादा हैं

    • समझ नहीं आया किस data की बात हो रही है
      बस एक बिना label वाला graph और current peak numbers हैं

  • वे graphs आखिर हैं क्या, समझ नहीं आता; लगभग किसी artist की impressionistic painting जैसी लगती हैं
    commit graph देखकर समझ नहीं आता कि बड़े steps के बाद ढलान धीरे-धीरे नीचे क्यों आती है, वे steps तय जगहों पर क्यों नहीं आते, और कभी बड़ा jump होने पर slope छोटा क्यों होता है
    बाकी graphs फिर बिल्कुल अलग shapes में चलती हैं, जिससे बात और भी अजीब लगती है

    • क्योंकि वे आम PowerPoint graphs हैं
      उनका मक़सद actual data या उसके meaning को दिखाना नहीं, बस इतना जताना है कि "कुछ ऊपर जा रहा है"

  • मुझे लगता है federated forges ही आख़िरकार भविष्य हैं
    repositories अपनी-अपनी sovereign infra पर host हों, और ऊपर global IDs व federated metadata issues/PRs जैसी परत हो, यही ढाँचा सही लगता है
    ऐसे global indexes खड़े करना भी आसान होता है, इसलिए availability को बड़ी चिंता बनने से रोका जा सकता है, और हम भी उसी दिशा में काम कर रहे हैं

    • idea प्यारा है, लेकिन ज़्यादातर लोग self-host नहीं करना चाहेंगे
      अंत में अगर third-party hosting ही इस्तेमाल होगी, तो फिर 1–3 बड़े providers दोबारा उभर आएँगे
      और availability issues से बचने के लिए self-hosting भी कर लें, तब भी अगर dependencies GitHub जैसी बड़ी service पर टिकी हैं, तो उसके outage से बचाव नहीं होगा
      इसलिए व्यावहारिक हल वही है जो अभी भी है: जो कुछ इस्तेमाल करते हैं उसका proxy या mirror बनाएँ
    • सच कहें तो यह अभी भी किया जा सकता है
      GitHub, Codeberg, और self-hosted जगहों पर वही repo रखें और बस main branch consistency संभालें
      उसके बाद कहीं से भी update किया जा सकता है, बस README में links ठीक से डालनी होंगी
    • अच्छा होगा अगर coding agents गहरे VCS integration में GitHub को default न मानें
      अगर decent API या webhook देने वाले किसी दूसरे forge को जोड़कर वही convenience मिल सके, तो मैं सब कुछ self-host करना पसंद करूँगा
      agent side पर भी interface खोलना पड़ेगा, लेकिन plugin architecture हो तो GitHub dependency हटाई जा सकती है और बाकी MCP या skills से संभाला जा सकता है
    • यह बढ़िया idea है, और मैं हमारी site के LLM-generated content को भी इससे बदलना चाहूँगा
      बड़े runners मैं self-host कर सकता हूँ, इसलिए हाल में Codeberg पर shift हुआ हूँ, और छोटे cron jobs के लिए Codeberg के दिए runners इस्तेमाल करता हूँ
      वहाँ इस तरह के use case के लिए lazy runner भी है
    • यह concept पहली बार सुन रहा हूँ, sign up करके एक बार आज़माने का सोच रहा हूँ

  • अभी जो हो रहा है, वह कुछ ऐसा लगता है
    token subsidy अब काफ़ी training data खींच चुकी है और agentic junkies business भी अब flywheel घुमाने जितना बड़ा हो गया है, इसलिए उसे बंद किया जाएगा, और loss-leading products समेटे जाएँगे
    https://news.ycombinator.com/item?id=47923357