GitHub Actions और Pages में degraded availability का सामना हो रहा है

मूल लेख ↗ Hacker News चर्चा ↗

GitHub Actions और Pages के बार-बार होने वाले, घंटों तक चलने वाले आउटेज कई developers और companies को GitHub की reliability पर सवाल उठाने के लिए मजबूर कर रहे हैं, खासकर क्योंकि ये services CI/CD और deployments के critical path में हैं। टिप्पणीकार Azure migration, AI-चालित तेज़ बढ़ते load, और Microsoft में organizational व cultural मुद्दों जैसी वजहों की अटकलें लगाते हैं, जबकि उनका कहना है कि official uptime आंकड़े और SLAs उनके अनुभव से मेल नहीं खाते। नतीजतन, एक उल्लेखनीय संख्या GitHub के control plane पर निर्भरता कम करने के लिए self-hosted GitLab, Forgejo, Woodpecker, या custom CI setups जैसे alternatives की ओर देख रही है या माइग्रेट कर रही है।

विश्वसनीयता और अपटाइम संबंधी चिंताएँ

  • कई टिप्पणीकार कहते हैं कि GitHub Actions और Pages के आउटेज अब बार-बार होने लगे हैं, और मज़ाक में कहा जा रहा है कि अब व्यावहारिक रूप से “one nine” या “zero nines” अपटाइम है।
  • उद्धृत थर्ड-पार्टी अपटाइम ट्रैकर्स हालिया अवधियों में ~94–98% उपलब्धता दिखाते हैं, जबकि GitHub के अपने SLA आंकड़े इससे कहीं अधिक हैं, जिससे आधिकारिक मीट्रिक्स को भ्रामक बताने के आरोप लगते हैं।
  • इस घटना की अवधि (कुछ लोगों के लिए लगभग पूरा कार्यदिवस) और हाल के महीनों में कई घटनाएँ इस धारणा को बढ़ाती हैं कि विश्वसनीयता बेहतर नहीं, बल्कि बदतर हो रही है।

उपयोगकर्ता पर प्रभाव और निराशा

  • काम रुक जाता है: CI नहीं चलती, PRs मर्ज नहीं हो पाते, hotfixes और ग्राहक रिलीज़ में देरी होती है, production incidents को संभालना कठिन हो जाता है।
  • एरर संदेशों को भ्रामक या अस्पष्ट बताया गया है, जैसे ऐसे फेल्योर जो साफ़ तौर पर “no runners available” नहीं बताते।
  • कुछ enterprises को लगता है कि भुगतान करने के बावजूद उन्हें कोई अतिरिक्त स्थिरता नहीं मिलती, और support/SLA credit mechanisms कमज़ोर या डिज़ाइन से ही “scummy” हैं।

संभावित कारण

  • दो प्रमुख सिद्धांत:
    • भारी load growth, खासकर AI agents और Copilot usage से, जिसके कारण 10–14× अधिक commits और >4× अधिक Actions minutes हो गए हैं, जिससे architecture पर दबाव बढ़ रहा है।
    • GitHub के पुराने infrastructure/AWS से Azure की चल रही migration, जिसमें Azure को flaky और राजनीतिक रूप से अनिवार्य बताया गया है।
  • कई लोगों का मानना है कि load और migration, साथ ही aggressive feature rollout (खासकर AI/Copilot), मिलकर समस्या को और बिगाड़ रहे हैं।
  • कुछ लोग तर्क देते हैं कि ये समस्याएँ खराब नेतृत्व, जल्दबाज़ी वाली timelines, और “performative” engineering culture को दर्शाती हैं।

Actions Architecture और Self‑Hosted Runners

  • उपयोगकर्ता हैरान हैं कि self‑hosted runners भी फेल हो जाते हैं, क्योंकि central scheduler और webhooks डाउन होते हैं।
  • कई लोग डिज़ाइन की आलोचना करते हैं: centralized control plane single point of failure के रूप में, YAML-heavy workflows, और खराब degradation strategies (स्पष्ट load shedding नहीं, या paying customers के लिए priority नहीं)।

विकल्प और Self‑Hosting

  • CI को GitHub से हटाने में गहरी दिलचस्पी है: self‑hosted Jenkins, GitLab, Forgejo, Gitea, Woodpecker, Buildkite, Argo, और विभिन्न niche CI systems का ज़िक्र है।
  • कुछ लोग self‑hosted GitLab/Forgejo + runners (अक्सर एक single server पर) के साथ अच्छे अनुभव बताते हैं, और बेहतर reliability व control का दावा करते हैं।
  • अन्य लोग नोट करते हैं कि vendor lock‑in और switching costs के कारण, outages के बावजूद GitHub फिर भी “wins” करता है, खासकर PR/review UX और network effects की वजह से।

व्यापक टिप्पणियाँ

  • चर्चाएँ GitHub की समस्याओं को व्यापक चिंताओं से जोड़ती हैं: AI “slop,” RAM/datacenter pressure, Microsoft की product quality, और critical dev infrastructure को एक proprietary platform पर केंद्रीकृत करने के जोखिम।