U posljednjih šest mjeseci, neki od najvećih pružatelja infrastrukture na internetu, uključujući AWS, Cloudflare i GitHub, prolaze kroz ozbiljne ispade. GitHub se posebno bori s dostupnošću, u tolikoj mjeri da njihov CTO piše javne isprike, a dugogodišnji maintaineri napuštaju platformu. Već dugo vremena su te kompanije tiho radile svoj posao bez previše buke, a apstrakcija su jednostavno funkcionirale. No infrastruktura koja je to omogućavala, ona koja je trebala biti dosadan, stabilan dio cijele priče, polako se pogoršava.
Umjesto jednog dramatičnog pada, radi se o sporom nakupljanju incidenata koji su pitanje "je li samo meni GitHub pao?" pretvorili u tjednu rutinu. Pet devetki, odnosno 99,999% dostupnosti, što znači pet minuta zastoja godišnje, uvijek je bila ambiciozna meta za platformu GitHubovog opsega. No sada se sve više može primjetit kako taj postotak klizi, od 99,9% pa sve prema 89,9%.
Dva incidenta u jednom tjednu
U prvom incidentu, 23. travnja, GitHubov merge queue počeo je tiho vraćati već postojeći kod na main branch. Jednostavan PR od 29 linija prošao je review, ušao u queue, a na mainu je završio jedan commit koji je obrisao više od tisuću linija nepovezanog, već isporučenog koda. Svaki sljedeći merge samo je gomilao pogreške na toj pokvarenoj historiji.
Nekoliko dana kasnije, u trenutku kad se misli da ne može biti gore, može. Sigurnosna tvrtka Wiz objavila je ozbiljnu ranjivost, CVE-2026-3854, koja neautentificiranom napadaču otvara put do izvršavanja remote koda kroz jedan jedini git push. Točka-zarez na krivom mjestu istraživačima je omogućila izlaz iz sandboxa i pristup dijeljenom nodeu koji servira milijune repozitorija, zajedno s cross-tenant podacima.
Svaki od ova dva incidenta zasebno bio bi katastrofalan tjedan. Zajedno, u roku od sedam dana, na platformi koja već bilježi sve lošije rezultate pouzdanosti, to ozbiljno narušava ugled platforme.
Reakcija zajednice
Reakcija je bila oštra. Počela su se postavljati logična pitanja: u kojoj točki korisnici kreću drugdje, i kamo? GitHubov odgovor temeljio se na postocima, ističući da je merge bug zahvatio "samo otprilike 0,07%" PR-ova. Timovima koji su poslijepodne proveli na force-rebuildu repozitorijske povijesti taj broj nije donio puno utjehe.
Tome se pridružuju i glasovi uglednih developera. Mitchell Hashimoto, autor Ghosttyja, terminalskog emulatora koji brzo raste u popularnosti, prošli tjedan je napisao da svoj projekt miče s platforme jer više nije dovoljno pouzdana. Armin Ronacher, kreator Flaska i osnivač Sentryja, te jedan od najrespektabilnijih glasova vezan uz Python i open-source zajednicu, isti tjedan objavio je tekst naslovljen "Before GitHub", podsjećajući da je open-source ekosustav postojao i prije centralizirane platforme, i postojat će i poslije nje. Kad iskusni developeri bez skrivenih motiva počnu javno preispitivati oslanjanje na alat, onda platforma ima ozbiljan problem.
AI teret koji se ne može zanemariti
Što je zapravo uzrok? GitHubova vlastita analiza prilično je iskrena. Priznaju da su planirali 10x povećanje kapaciteta od kraja 2025., no do veljače 2026. taj cilj morao je porasti na 30x.
Krivac su takozvani "agentic development workflows." AI coding petlje poput Claude Codea i Cursora zatrpavaju sustav. Prosječan developer otvori nekoliko PR-ova dnevno. AI agent može ih izbaciti na desetke na sat, po repozitoriju. Svaki prolazi kroz CI, branch protections, API, search index i webhookove. Grafovi koje su objavili govore sve: pull requestovi dosežu vrhunac od gotovo 90 milijuna mjesečno, commitovi 1,4 milijarde, novi repozitoriji 20 milijuna. Gotovo nijedna platforma nije projektirana za ovakav promet.
Što slijedi
Postoji nekoliko scenarija u kojima se ovo može odviti, no uglavnom se svode na tri:
- GitHub se oporavlja: Izoliraju servise, prepisuju kritične putanje i grade pametnije API-je. Inženjerski problem je zahtjevan, ali dobro poznat. Ovo je vjerojatno najvjerojatniji dugoročni ishod, mada može potrajati 12 do 18 mjeseci.
- Ekosustav se fragmentira: Veliki open-source projekti migriraju na platforme poput Codeberga ili self-hosted rješenja. Zajednica se raspršuje, a pronalazak projekata postaje kompliciraniji nego danas.
- AI opterećenje se stabilizira: Počinjemo sve više viđati postepeno smanjenje API rate limitinga za agente, ili se ti workflowi sele na private forkove koji pushaju samo na zahtjev. Matematika skaliranja 30x svakih šest mjeseci nije održiva bez promjene ulaznih parametara.
Zanimljivo razlog eksplozije AI prometa leži u tome što su provideri kroz gotovo dvije godine skrivali stvarnu cijenu pokretanja AI petlje od developera, subvencionirajući je kako bi ih privukli. Flat-rate Copilot seats, velikodušne "premium request" kvote i agresivno promotivno cijenjenje zajedno su tvorili primamljiv paket. Zašto ne pokrenuti coding agenta i pustiti ga da melje kod?
No ta faza izgleda završava: Copilot je prešao na usage-based naplatu koji troškove daleko preciznije poravnavaju s onim što svaki zahtjev troši na backendu. Kad ta ekonomska stvarnost sjedne u inženjerske organizacije, mnogi "pusti agenta da radi preko noći" workflowi počet će izgledati sasvim drugačije na fakturi, kao i volumen pusheva, PR-ova i CI pokretanja koja generiraju prema GitHubu.
Git kao tehnologija nema gotovo nikakve veze s nedavnim problemima. Osnovna tehnologija funkcionira. Propada centralizirani socijalni i CI/CD sloj izgrađen na vrhu.
Za kraj
Sve ovo može zvučati pesimistično, no nema razloga za paniku i veliku migraciju repozitorija. Ovo je dobar trenutak za pragmatičnu provjeru:
- Tretirajte GitHub Akcije kao svaki drugi dependency: Ako vaš release pipeline padne kad Actions padne, to je single point of failure za vaše poslovanje. Izgradite lokalni fallback put kako biste mogli ručno pushati release iz čistog checkoutua ako zatreba. Testirajte jednom kvartalno.
- Backupirajte sve bitno: Kod, releaseve, exportove issue trackera i wikije. Trošak je minimalan, a optionalnost ogromna. Postavljanje remotea je jedna linija u Gitu.
- Čitajte izvješća o incidentima s razumijevanjem: Timovi u GitHubu nose distribuirane sustave u uvjetima opterećenja koji praktički nisu postojali prije 18 mjeseci.
Radi se o kompromisu. Centraliziranim providerima dajete podatke, workflow i povjerenje. Oni vam zauzvrat daju pouzdanost i performanse. Kad jedna strana podbaci, sasvim je razumno početi razmatrati opcije.
