GitHub 85% uptime: így omlasztják össze az AI ügynökök a világ fejlesztői infrastruktúráját

Ha 2026 áprilisában egy magyar fejlesztőcsapat azt vette észre, hogy a Cursor néha „Network error" hibával ír ki egy egyszerű commit műveletet, vagy a Claude Code-os MCP integráció időnként 503-mal jön vissza, az nem a saját szerverükben volt. A világ legnagyobb fejlesztői platformja — a GitHub — egy hónapon keresztül a 99,9%-os SLA-jának mintegy hatoda alatt teljesített. És amikor Vlad Fedorov, a GitHub CTO-ja május elején nyilvánosan elismerte a problémát, kiderült: a kiesések gyökérproblémája nem hardver, nem konfigurációs hiba, hanem maga az AI ügynök-paradigma, amit egyébként a GitHub is aktívan ösztönöz.

Mi történt a GitHubbal 2026 első negyedévében?

2026 február elején indult a sorozat. Először február 2-án akadt el a GitHub látható részén szinte minden interaktív funkció — push, pull, Actions futtatás, search. Egy héttel később, február 9-én megismétlődött. Március 5-én pedig egy harmadik nagy kiesés zárta le a negyedévet. Ezek nem voltak rövid hibák. A felhasználók órákon át nem tudtak normálisan dolgozni — és pontosan akkor, amikor az AI agent-vezérelt fejlesztés (Cursor, Claude Code, Devin, GitHub Copilot Workspace) a magyar és nemzetközi csapatoknál a napi rutin részévé vált.

Az igazi sokk azonban Vlad Fedorov, a GitHub CTO-jának nyilvános posztja volt május elején. Itt ismerte el a vezetőség először explicit módon, hogy az áprilisi uptime nem érte el a 85%-ot — vagyis a hónap közel 15%-ában a platform a megígért szint alatt teljesített.

„The two most recent incidents were not acceptable. Our uptime in April was below 85%, well short of the 99.9% we promise."

„A két legutóbbi incidens nem volt elfogadható. Az uptime áprilisban 85% alatt volt, messze az általunk ígért 99,9%-os szint alatt."

— Vlad Fedorov, GitHub CTO, 2026. május (idézi az InfoQ infrastruktúra-elemzése)

A 99,9%-os és a 85%-os uptime közti különbség nem nüansz. Az alábbi táblázat világosan megmutatja, mit jelent egy SLA-szint a gyakorlatban:

Ha a magyar fejlesztőcégek többsége GitHubon dolgozik (és becslések szerint pontosan ez a helyzet), akkor a 85%-os teljesítmény nem fejlesztői kényelmetlenség, hanem üzleti kockázat. A SocialPro pillér cikkben — Anthropic 900 milliárdos valuáció és AI infrastruktúra 2026 — már részletesen elemeztük, miért szűkült össze 2026-ra a globális AI compute kapacitás. A GitHub-eset ennek a tükörképe a fejlesztői platform oldalán: nem a számítási kapacitás kevés, hanem a koordinációs réteg nem bírja az autonóm hívási mintákat.

1. 2026.02.02 — Első nagy GitHub kiesés. A push, pull és Actions funkciók egyszerre estek ki órákon keresztül. A GitHub Status oldalon „degraded performance" jelzéssel.
2. 2026.02.09 — Egy héttel később, gyakorlatilag azonos minta szerint, ismét leesik a platform. Ez már jelezte, hogy nem véletlen incidensről van szó.
3. 2026.03.05 — Harmadik nagy incidens, ezúttal a search index és a webhook-küldés akadt el órákon át. A GitHub belső retro szerint ez vezetett az áprilisi 85% alatti uptime-hoz.

Miért omlanak össze az infrastruktúrák AI ügynökök alatt?

Az AI ügynökök fejlesztői munkájában van egy alapvető különbség az emberi fejlesztőkhöz képest, amit könnyű elnézni: az ügynök nem heurisztikák alapján dönt arról, mikor küldjön egy API-hívást. Egy emberi fejlesztő nyom egy „push"-t, vár, megnézi a CI eredményt, gondolkodik, kommentel egy PR-t. Egy AI ügynök ezzel szemben — különösen a multi-step, multi-tool agent framework-ök, mint a Cursor agentic mode, a Claude Code vagy a Devin — másodpercenként akár tucatnyi API-hívást indíthat: clone, commit, branch, PR open, review request, status check, retry, retry, retry.

A kulcs az utolsó három szóban van. A „retry" nem ártatlan művelet. Ha egy ügynök nem kap egyértelmű választ — például mert a háttérben éppen lassú a válasz —, akkor sok agent framework alapértelmezetten újrapróbálja. Az iparági szakzsargon ezt thundering herd jelenségnek hívja: amikor több ezer AI ügynök-instancia egy időben próbálja újra ugyanazt a kérést rate-limit hiba után. A klasszikus mitigation — exponential backoff és circuit breaker pattern — viszont a hagyományos egyetlen-kliens-egy-felhasználó modellre lett tervezve, nem pedig arra, hogy egy autonóm agent másodpercenként 200 retry-t indít.

A retry-ok alatt elindulhatnak további delegált hívások (egy code review subagent, egy test runner subagent), amelyek mind újabb GitHub API-hívásokat generálnak. Ez nem hibás kód: ez egy autonóm cikk struktúrája, ami terhelési viselkedését tekintve teljesen idegen attól, amire a GitHub-féle infrastruktúrát eredetileg méretezték. Az AI ügynök működése magyar KKV-knál című cikkünkben részletesen tárgyaltuk az alapvető működési elveket; itt most a következő szintre lépünk: mi történik, ha a platform alatta nem volt felkészítve erre.

„Agents make autonomous API calls at such enormous scale that the underlying infrastructure collapses under the weight. These aren't simple bugs — they're runaway recursive loops."

„Az ügynökök autonóm API-hívásokat tesznek olyan óriási skálán, hogy az alapinfrastruktúra összeomlik a súly alatt. Ez nem egyszerű hibák, hanem elszabaduló rekurzív hurkok."

— Mérnöki elemzés a GitHub-kiesésekről, InfoQ, 2026. április

Tight coupling: a 12 komponens csapdája egy pull requestben

A GitHub belső retroanalízise szerint a kiesések gyökere nem egyetlen szolgáltatásban volt. Egy átlagos pull request műveletkor a platform szinte egyidejűleg vesz igénybe legalább 12 különböző komponenst — és ezek a komponensek szorosan, szinkron módon függnek egymástól (tight coupling). Ez az AI ügynök infrastruktúra alapellentmondása: az ügynökök nagy léptékű, párhuzamos hívásokat generálnak, miközben a mögöttes platform szinkron, szoros csatolásban dolgoz fel mindent.

Egy egyszerű „PR open" parancs a háttérben elindítja a Git storage írást, a mergeability számítást (van-e konfliktus?), a branch protection ellenőrzést (megfelel-e a védett szabályoknak?), a GitHub Actions trigger-eket, a search index frissítést, a notifications küldést a reviewereknek, a permissions ellenőrzést (van-e jogod merge-elni?), a webhook-okat (külső integrációk értesítése), az API válasz formálást, a háttérmunkák betöltését (linter, code scan), a cache invalidálást és a sok adatbázisírást a GitHub különböző shard-jain.

Egy emberi fejlesztő óránként pár ilyen ciklust generál. Egy autonóm AI ügynök másodpercenként tucatnyit. Ha bármelyik a 12 komponens közül lassul, a többi szinkron várakozni kezd — és ha a hívó (az AI agent) közben újabb retry-okat küld, hamarosan exponenciálisan nő a sorbanállás. Ez a klasszikus cascade failure, amire a klasszikus cloud minták (Circuit Breaker, exponential backoff, bulkhead isolation) megoldást adnának — ha implementálva lennének mindenhol, a GitHub teljes API-felületén, nem csak az újabb mikroszolgáltatásokon.

Az architektúra-szintű probléma nevezhető pontosan: a GitHub komponens-modellje az emberi fejlesztők hívási mintájához készült, ahol a párhuzamosság természetes felső korlátja az volt, hogy egy fejlesztő egyszerre csak egy dolgot csinál. Az AI agent megszüntette ezt a felső korlátot, anélkül hogy a platform ezt explicit módon tudta volna kezelni.

Mit hibáznak a hagyományos cloud primitívek AI agent terhelés alatt?

A GitHub-eset nem elszigetelt. Ugyanazok a problémák mutatkoznak az AWS Bedrock, az Azure OpenAI, a Google Vertex AI és a GitHub Actions szintjén is, amikor egy ügynök hosszú, multi-step feladatot kap. A hagyományos cloud primitívek — konténerek, serverless függvények, session-alapú autentikáció, kvótabeállítások egy fejlesztőre — három alapvető feltevésre épülnek:

• Rövid life-cycle: egy függvény vagy szolgáltatás-hívás másodpercekig fut, nem napokig.
• Előre tervezett munkafolyamat: a hívás-szekvenciát egy ember (vagy egy CI/CD konfig) tervezte meg.
• Kiszámítható terhelés: egy felhasználó nagyjából annyit kér le, amennyit egy klikkelési ütemmel meg tud csinálni.

Egy autonóm AI ügynök mindhárom feltevést megsérti. Egy Devin-szerű agent perceken-órákon át fut. A hívás-szekvenciát maga a modell tervezi meg, a tanulóadatban látott minták alapján — nem egy mérnök által definiált worflow. És a terhelés sem kiszámítható: egy „javítsd ki ezt a bug-ot" prompt mögött 50 vagy 5000 API-hívás is lehet, attól függően, hogy az ügynök milyen utat választ a feladat megoldására.

Itt jön be az iparág által felismert új réteg-modell, amit egyre több venture capital-jelentés „agent infrastructure"-nek nevez — ez nem azonos a hagyományos cloud-stack-kel. A SocialPro Agent Stack 4-réteg modellje (memory–execution–tooling–governance) ezt a négy réteget foglalja össze.

Az Agent Stack 4-réteg modell — új cloud paradigma

A 2026-os iparági konszenzus az, hogy az AI agent-ek megbízható futtatásához egy új, négyrétegű infrastruktúra-stack kell — a hagyományos cloud primitívek fölé épített, agent-specifikus réteg.

1. Memory (memória): perzisztens, strukturált kontextus, ami túléli a session-t. Egy agent emlékszik arra, mit csinált fél órája — különben minden retry-nál újra kezdődik a feladat.
2. Execution (végrehajtás): sandbox-olt compute milliszekundumos start-up idővel. A klasszikus konténerek 200-500 ms-on indulnak; az agentic feladatokhoz ennél is gyorsabban válaszoló végrehajtási réteg kell.
3. Tooling (eszközök): szabványosított SaaS-integráció. Itt van az MCP (Model Context Protocol) szerepe: egy egységes hívási felület, ami nem 12 különböző szinkron API-hívássá esik szét egyetlen művelet kapcsán.
4. Governance (kormányzás): folyamatos, valószínűségi autentikáció és auditálható nyom. Nem session-alapú, hanem műveletenkénti megbízhatósági pontszám alapján engedélyezi vagy tiltja az ügynök hívásait.

A GitHub-eset pontosan a Tooling és a Governance rétegek hiányát mutatja. A Git API egy emberi tooling — minden műveletet külön híváson végez. Egy agent-ready API ezeket egyetlen tranzakcióba foglalná. A Governance hiánya pedig azt jelenti, hogy a GitHub jelenleg nem tud különbséget tenni egy ártatlan retry-loop és egy szándékos rate-limit megkerülés között — minden hívás egyformán bejut.

Globális kontextus: Anthropic-SpaceX, GPT-5.5 rate limitek, DeepSeek V4

A GitHub-eset nem önmagában áll. 2026 május első hete számos olyan bejelentést hozott, amelyek mindegyike ugyanarra a problémára adott válasz: az agentic terhelés meghaladta a hagyományos infrastruktúra kapacitását.

Május 6-án a SpaceX bejelentette, hogy 300+ MW új compute-kapacitást és 220 000+ NVIDIA GPU-t ad bérbe az Anthropicnek a Colossus 1 adatközpontból. Ennek részletes elemzését a SpaceX × Anthropic megállapodásról szóló cikkünkben kibontottuk — itt a lényeg az, hogy az Anthropic hivatalos közleménye is azt írja, ez a kapacitás-bővítés szükséges volt a Claude API rate limit-ek emeléséhez. Vagyis a hagyományos hyperscaler-kapacitás (AWS, GCP, Azure) sem volt elég.

Egy nappal korábban, május 5-én az OpenAI bejelentette a GPT-5.5 Instant modellt, amely a ChatGPT új alapértelmezett modellje lett. Az OpenAI GPT-5.5 Instant elemzésünkben részletesen tárgyaltuk a benchmark-eredményeket — itt most az számít, hogy a GPT-5.5 bevezetésével az OpenAI lényegesen szigorúbb agent rate limit politikát is bevezetett. A 72%-kal kevesebb output token önmagában is hatás-csökkentő volt, de a tier-rendszer szerinti kvótabeállítások szintén szigorúbbak lettek a hosszú-futású agent-feladatokra.

Eközben a kínai oldalon a DeepSeek V4 modell 1,6 billió paraméterrel és 1 millió token-es kontextus-ablakkal jelent meg, hivatalosan jóval olcsóbb inference-szel a saját, hardver-szinten optimalizált stack-en. A nyíltforrású alternatíva részben enyhítheti a rate limit-problémát: aki nem akar a OpenAI vagy Anthropic rate limit-jétől függeni, saját kontrollált környezetben futtathatja a modellt — feltéve, hogy van hozzá GPU-ja.

Mindhárom hír egy irányba mutat: az AI agent gazdaság fizikai és koordinációs határaihoz ért. Nem a modellek a szűk keresztmetszet 2026-ban, hanem a futtatási és koordinációs réteg.

Mit jelent ez a magyar fejlesztőcsapatoknak és KKV-knak?

Magyar környezetben a kérdés egyszerű, de a válasz nem az: ha a fejlesztőcsapatod GitHubot használ — és statisztikailag majdnem biztos, hogy igen —, akkor 2026-ban már nem tudsz arra építeni, hogy a platform mindig elérhető. Ez nem GitHub-bashing, hanem reálkép: a SLA hivatalosan 99,9%-os, a tényleges áprilisi teljesítmény 85% alatti volt.

Az EU AI Act 2026 február óta hatályos. Az általános célú MI rendszerek (GPAI) szabályozása konkrét operational resilience-követelményeket támaszt — az MI rendszerek megbízhatósága és a kockázatkezelés már nem kívánatos plusz, hanem jogi kötelezettség. Az EU AI Act magyarországi alkalmazása című cikkünkben részleteztük a követelmények belépését. A GitHub-féle eset egy konkrét próba arra, hogyan néz ki egy mai magyar KKV reálisan, ha az „AI infrastruktúra rendelkezésre állása" nemcsak szlogen, hanem audit-ellenőrzés tárgya.

Néhány konkrét kockázati pont, amit minden magyar fejlesztőcsapatnak érdemes most átgondolnia:

• CI/CD függőség: ha a GitHub Actions kiesik, leáll-e a deploy pipeline-od? Van-e fallback?
• Agent-szintű rate limiting: a Cursor / Claude Code / Copilot-os fejlesztők együttes API-terhelése nem haladja-e meg a saját kvótádat?
• Vendor lock-in: ha holnap a GitHub-ról át kellene állnod GitLab-ra vagy önállóan üzemeltetett Gitea-ra, mennyi idő alatt menne végbe?
• Observability: tudod-e mérni, hogy a build-időid romlása mikor a GitHubon múlik és mikor a saját kódbázisodon?
• Kontraktusos felelősség: az ügyfeleidnek tett SLA-d hogyan viszonyul a beszállítóid (GitHub, OpenAI, Anthropic) SLA-jához?

Az automatizációs infrastruktúra megválasztása sem közömbös. Az n8n, Make és Zapier összehasonlító cikkünkben bemutattuk a három piacvezető platform különbségeit — ahogy az AI agent-ek terhelése nő, ezeknek a workflow-eszközöknek is meg kell birkózniuk az új típusú forgalommal.

5 lépéses gyakorlati mitigation playbook 2026-ra

Ha mindez túl absztrakt, itt egy konkrét, sorrendbe rakott akcióterv. Nem kell mindent egyszerre csinálni, de érdemes a fontossági sorrend szerint haladni.

1. Decoupling (komponens-leválasztás). Kezdj el üzenet-alapú, aszinkron eseménykezelést bevezetni a saját rendszereidben. Ha egy AI agent egy webhook-ot trigger-el, az ne közvetlenül egy szinkron API-hívást indítson, hanem egy queue-ba (RabbitMQ, AWS SQS, Redis Streams) tegye az üzenetet. Így ha lassul a háttér, csak a queue mélysége nő, nem omlik össze a teljes rendszer.
2. Load shedding agent-szinten. Vezess be kvótát minden AI agent kliensre — ne API-kulcsra, hanem konkrét agent-instancera vetítve. Egy Cursor-os fejlesztő agent-je sokkal több hívást generál, mint egy ember; a saját rate limit-ed legyen agent-tudatos. Egy egyszerű, gyakorlati limit: maximum 30 GitHub API-hívás/perc/agent. Az exponential backoff és a circuit breaker pattern alkalmazása itt kötelező.
3. Observability bevezetése. Telepíts Datadog, Grafana vagy OpenTelemetry-alapú monitort, ami nem csak a saját szolgáltatásaidat figyeli, hanem a beszállítóid állapotát is. Ha a GitHub API válaszidő 200 ms-ról 2000 ms-ra nő, ezt a saját dashboard-odon kell látnod, nem a Twitter/X feededben.
4. Backup platform stratégia. Tarts egy minimális mirror repository-t GitLab-on, Bitbucket-en vagy önállóan üzemeltetett Gitea-on a kritikus repo-knak. Nem feltétlenül napi tükrözéssel — de legyen egy működő fallback, amire 24 óra alatt át tudsz állni egy elhúzódó GitHub-incidens esetén.
5. Agent governance. A 2026-os új generációs eszközök (mint a Planview Agent Resource Management) kifejezetten erre a problémára adnak választ: emberi és AI agent erőforrásokat egy helyen kezelnek, audit-trail-lel. Nem kell drága enterprise eszközt vásárolnod elsőre — egy belső táblázat is megteszi, amelyben rögzíted, melyik agent milyen feladatot futtat, mennyi API-hívást generál, és mikor kell leállítani.

Az 5 lépés közül a legolcsóbb és leggyorsabban bevezethető a load shedding és az observability. A decoupling architekturális munka, és általában új release-ben érdemes szállítani. A backup platform és a governance pedig a hosszú távú stratégiai döntés része. Az AI ügynök infrastruktúra megbízhatósága 2026-ban már nem opció, hanem alapelvárás.

GYIK — AI ügynök infrastruktúra kockázatok

Mi az AI ügynök infrastruktúra, és miért vált kockázattá 2026-ban?

Az AI ügynök infrastruktúra azoknak a platformoknak, API-knak és cloud-szolgáltatásoknak az összessége, amelyeken keresztül az autonóm AI agent-ek (Cursor, Claude Code, Devin) műveleteket hajtanak végre. 2026-ban azért vált kritikus kockázattá, mert az ügynökök hívási mintája — gyors, párhuzamos, rekurzív — meghaladja azt, amire a platformok eredetileg méretezve lettek. A GitHub áprilisi 85%-os uptime-zuhanása konkrét bizonyíték erre.

Van-e konkrét bizonyíték arra, hogy az AI ügynökök okozták a GitHub kieséseket?

A GitHub belső retroanalízise és Vlad Fedorov CTO május elejei nyilvános posztja explicit említi az autonóm agentic API-hívások szerepét. Az InfoQ által idézett mérnöki elemzés is ezt erősíti meg. A GitHub nem nevez meg konkrét agent platformot (Cursor, Claude Code, Devin), de a leírt minta — autonóm, rekurzív, nagy léptékű API-hívások — egyértelműen agentikus természetű.

Magyar KKV-ként kell-e már most reagálnom?

Igen, ha bármilyen AI agent eszközt (Cursor, Claude Code, Copilot agentic mode, n8n agent node) használsz a fejlesztésben vagy production rendszerben. Az 5 lépéses playbook első két pontja (load shedding, observability) néhány nap alatt bevezethető és kifejezetten megéri.

Át kellene állnunk GitHubról GitLabra?

Nem szükséges teljes migráció. A reális stratégia: GitHub marad fő platformnak, de tarts egy backup mirror-t egy másik szolgáltatón. Ez nem költséges és jelentősen csökkenti a kockázatot.

Mennyibe kerül egy ilyen mitigation playbook bevezetése?

Az első három lépés (decoupling, load shedding, observability) nagyrészt belső munkaóra-kérdés — egy közepes magyar dev csapatnak 2-4 hét munka. A Datadog/Grafana eszközök havi 50-200 USD/host nagyságrendben mozognak. Egy backup GitLab self-hosted instance hardveroldalon havi 30-100 USD-ből megoldható. Az agent governance eszközök ára változó, de táblázatos megoldással induláskor zéró.

Mi a kapcsolat az EU AI Act-tel?

Az EU AI Act operational resilience-követelményeket támaszt a GPAI (általános célú MI) rendszerekre. Ha egy magyar KKV AI agent-eket használ production-ben, az infrastruktúra megbízhatósága audit-tárgy lesz — különösen pénzügyi, egészségügyi vagy közszolgálati területeken. A 5 lépéses playbook gyakorlatilag a megfelelőség alapcsomagja is.

Az 1000× inference demand növekedés (IDC) reális?

Az IDC 2026-os jelentésének előrejelzése a globális összesített inference-igényre vonatkozik 2027-ig. Ez piaci szintű előrejelzés, nem egyetlen cég vagy ország szintjén értelmezendő. Magyar KKV-knak gyakorlati üzenete: a saját AI-használatuk növekedési pályája meredek lesz, és ezt tervezni kell.

A GitHub-eset egy figyelmeztető lövés. Az AI agent gazdaság elérte azt a pontot, ahol már nem a modell-minőség a szűk keresztmetszet, hanem az infrastruktúra megbízhatósága. Magyar fejlesztőcsapatoknak ez nem fenyegetés, hanem lehetőség: aki most kezdi el az 5 lépéses playbook bevezetését, két év múlva nem védekezni fog, hanem versenyelőnyből építkezni. A 2026-os év nem arról szól majd, ki tudja jobban használni az AI ügynököket — hanem arról, kinek áll meg az infrastruktúrája az AI ügynökök terhelése alatt.

Ha szeretnéd átvilágítani a saját DevOps stack-edet AI agent kockázat szempontjából, vagy kíváncsi vagy a részletes implementációs útmutatóra a 5 lépéshez, vedd fel a kapcsolatot a SocialPro csapatával — magyar KKV környezetre szabott auditot készítünk a GitHub-szintű és agent-szintű kockázatok feltárására.