GitHub ishlamaydi: 9 yilda 1125 ta hodisa — nima bu dasturchilar uchun ma'nosi?

GitHub — bu faqat kod saqlash joyi emas. Bugungi kunda u CI/CD konveyeri, paketlar registri, Actions ishga tushiruvchisi, Codespaces bulut muhiti va ko'plab boshqa xizmatlarning markazi. Agar GitHub to'xtasa, minglab kompaniyalarning deploy-jaroayi, testlari va hatto ishlab chiqish jarayoni to'xtab qoladi. Shuning uchun platformaning "sog'ligi" har bir dasturchi va DevOps mutaxassisi uchun shaxsiy ishtirok etmasdan ham muhim.

Raqamlar nima ayta oladi?

March 2016 yilidan hozirgacha GitHub status sahifasida rasmiy ravishda 1125 ta hodisa ro'y bergan. Bu o'rtacha har oyda 24 ta hodisa degani. Oxirgi uch oyda bu ko'rsatkich 5% ga kamaygan — 23 tagacha tushgan. Avval nazarda tutilmasa, bu "yaxshi yangilik" deb o'tib ketishi mumkin. Lekin kontekstni qo'shsak: 2026-yil fevralida 37 ta hodisa ro'y bergan — bu rekord. Ya'ni tizim hali ham barqaror emas, faqat o'ziga xos dalanglar bor.

Eng uzoq tinchlik davri — 8 kun. U 2026-yil 31-dekabrda tugagan. Bu degani, yil oxirida hatto dam olish kunlarida ham tizim charchagan. Hafta kunlari bo'yicha taqsimot ham qiziqarli: charcha kunlari 245 ta hodisa (22%) bilan yetakchi, yakshanba kunlari esa 27 ta (2%) bilan oxirgi o'rin. Bu tasodif emas — charcha odatda sprintning o'rtasi, deploy faolligi va on-call aylanishlari bilan uchraydi.

Qanday hodisalar ko'p?

Statistika ko'rsatadiki, hodisalarning 81% i (911 ta) — "Minor" (kichik) darajaga mansub. Bu odatda bitta xizmatning qisman buzilishi, masalan, Gist yuklanmasligi yoki Actions loglari kechikishi. 17% (186 ta) — "Major", ya'ni ko'plab xizmatlar yoki katta foydalanuvchi guruhiga ta'sir. Va faqat 2% (28 ta) — "Critical", yani platforma butunlay yoki katta qismi ishlamaydi.

Lekin "Minor" degani "ehtiyotsiz" emas. Agar sizning CI/CD pipeline'ingiz GitHub Packages yoki Container Registry ga bog'liq bo'lsa, u yerda 10 daqiqa lik buzilish ham deployni bekor qiladi va qayta ishga tushirishni talab qiladi. Har bir hodisa o'zining "ta'sir radiusiga" ega — u qaysi xizmatlar to'plamiga tegishli ekanligiga qarab farqli darajada og'riq beradi.

Eng qachon va qanchalik buzilgan?

Hodisa soni bo'yicha eng yomon kunlar ro'yxati ko'rinib turibdi: 2026-yil 9-fevral (7 ta hodisa), 23-aprel (4 ta), 5-mart (4 ta) va boshqalar. Lekin downtime (ishlamaslik vaqti) bo'yicha reyting boshqacha: 2025-yil 16-aprel — 1 kun 2 soat, 20-noyabr — 1 kun 1 soat, 2026-yil 29-aprel va 30-aprel — har biri 1 kun. Ya'ni, ko'p hodisa bo'lgan kunlar doim eng uzoq to'xtashga olib kermaydi. Bitta katta infrastruktura muammosi (masalan, bazaviy ma'lumlar bazasi yoki DNS) bir necha kichik hodisalardan og'roq.

Nima uchun bu sizga kerak?

Har bir komanda o'z "reliability narrative" (ishonchlilik hikoyasi) yasaydi. Birinchi uchun GitHub Actions buzilishi — bu kritika, chunki u deployni bloklaydi. Ikkinchisi uchun bu faqat loglarni ko'rib turish imkoniyatini yo'qotadi. Uchinchi uchun — Codespaces ishlamasa, uzoq masofadagi jamoalar to'xtab qoladi. Siz qaysi xizmatlardan foydalanyapsiz? Shu bilan bog'liq hodisalarni filtrlash — bu sizning haqiqiy SLA (xizmat ko'rsatish darajasi) tushunchangizni shakllantiradi.

GitHub o'z status sahifasini ochiq qoldirgan, lekin u ham hamma narsani ko'rsatmaydi. Ba'zi hodisalar "degraded performance" (pasaytirilgan samaradorlik) sifatida belgilanadi va u bu statistikaga kirmaydi. Shuningdek, Microsoft Azure ning o'ziga xos buzilishlari (masalan, 2025-yil maydagi Azure DNS muammosi) GitHub ga ta'sir qilganda, bu alohida hodisa sifatida emas, balki tashqi sabab sifatida ko'rinadi. Bu ma'nosi: sizning monitoringingiz GitHub status sahifasidan kengroq bo'lishi kerak.

Raqobatchilar va muqobil yondashuvlar

GitLab, Bitbucket, Sourcehut va boshqalar ham o'z buzilishlari tariixiga ega. Lekin GitHub markaziy joyga ega — u de facto standart. Bu "vendor lock-in" (yagona ta'minotchiga bog'liq qolish) xavfini kuchaytiradi. Ba'zi kompaniyalar muhim repositoriyalarni aynan GitHub dan tashqariga (masalan, o'z serverlarida GitLab yoki Gitea) nusxalab turishni tanlaydi. Bu qo'shimcha xarajat va boshqaruv og'irini beradi, lekin yagona nuqta buzilishidan himoya qiladi.

Boshqa yondashuv — multi-region CI/CD. GitHub Actions hozir bir necha regionlarda ishishi mumkin, lekin ba'zi xizmatlar (masalan, Packages) hali ham markazlashtirilgan. Agar sizning biznesingiz daqiqa darajasida to'xtashga chidama bo'lsa, deploy artifactlarini S3 yoki GCS ga yuborib, keyin GitHub dan mustaqil ravishda deploy qilish — bu arxitektura qiyinlashtiradi, lekin rezilyentlikni oshiradi.

Ochiq savollar va cheklovlar

• Root cause analysis (RCA) chuqurligi: GitHub hodisa xulosalari odatda umumiy. "Database connectivity issues" — bu nima? Indekslar, ulanish puli, deadlock? Dasturchilar uchun chuqur RCA — bu kelajakda o'z tizimlarini qanday himoya qilishini o'rganish imkoniyati.
• SLA va kompensatsiya: GitHub Enterprise mijozlari uchun SLA bor (99.9% uptime). Lekin "Minor" hodisalar SLA ga hisoblana olmasa ham, ular ish jarayonini buzadi. Qayerda chek o'tadi?
• Vaqti bilan o'zgarish trendi: 2016-2019 oralig'ida hodisalar kamroq edi. 2020-yildan keyin (pandemiya, Actions, Codespaces, Copilot) xizmatlar ko'paydi va murakkablik oshdi. Bu o'sish tabiiymi, yoki arxitektura skalyablanmayapti?

Xulosa: monitoring — bu faqat grafik emas

GitHub ishlamasliklari statistikasi — bu raqamlar to'plami emas, bu sizning infrastruktura strategiyangiz uchun signal. Agar siz hali ham "GitHub ishlamasa, men ham ishlamayman" deb o'ylaysangiz, bu xavf. Agar esa sizning deploy pipeline'ingiz GitHub dan mustaqil ravishda artifactlarni olsa, testlarsa va staging/production ga yuborsa — siz bu 1125 ta hodisadan 90% ni sezmasdan o'tkazib yuborasiz.

Eng muhim savol: sizning komanda qaysi hodisalarni "Critical" deb hisoblaydi? Bu javobni topish — bu monitoring dashboarndan ko'ra qimmatroq va foydali investitsiya.

Asl manba: isgithubcooked.com