Ang GitHub Outage ay dulot ng pagtaas ng trapiko na dinudulot ng AI at pagkakamali sa konfigurasyon

Noong Pebrero 9 ngayong taon, sa gabi sa Beijing Time, milyon-milyon na developer sa buong mundo ay binuksan ang GitHub at nakita ang parehong pahina.

Hindi 404, kundi mas nakakapagod kaysa sa 404—ang dilaw na warning bar na nagpapalabas ng takot sa likod ng lahat ng engineer, kasama ang mga indicator light na nagsisilbi sa status page na nagbabago mula sa green patungo sa red.

Nag-crash ang github.com.

Nag-fail ang API.

Nag-fail ang GitHub Actions.

Nag-fail ang Git operation—kahit si Copilot ay hindi nakaligtas.

Sa gabi na iyon, tumigil ang ilang CI/CD pipeline sa pinakamahalagang punto, natigil ang ilang automated deployment sa gitna, at naghihintay ang ilan sa isang PR na hindi pa maaaring i-merge—lahat ay para sa isang function na naghihintay ng paglulunsad, at naghihintay sa totoong mga user.

Pagkatapos ay naglabas ng ulat sa insidente ang GitHub. Ang pangunahing sanhi, sa teknikal na wika, ay "isang core database cluster na responsable sa authentication at user management na nabigla." Ngunit ang mga salitang ito ay naglalaman ng isang nakakatakot na chain ng pag-trigger—

Dalawang araw na ang nakalipas, ang engineering team ay nagbago ng isang setting na nagpapalit ng oras ng pag-refresh ng “user settings cache” mula sa 12 na oras patungo sa 2 na oras upang maipadala agad ang isang bagong model sa mga user. Ito ay isang pagbabago lamang sa isang numerikong setting.

Ang resulta ay ang pagpapalit ng cache na orihinal na nakaiskedyul sa loob ng 12 oras ay napapalitan sa loob ng 2 oras, nagbuo ng isang malakas na “storm ng pagpapalit ng cache,” na nagpabagsak sa queue ng asynchronous tasks, nagdulot ng pagbagsak sa mga komponente ng shared infrastructure, at ang chain reaction ay umabot sa serbisyo na responsable sa HTTPS Git operations, na nagresulta sa pagkawala ng lahat ng koneksyon sa buong platform.

Isang numero, binago mula sa 12 patungo sa 2.

GitHub, nasira dahil sa isang configuration na aking binago.

Ngunit kung ikaw ay nakikita lamang ang isang pagbabago sa konfigurasyon na ito, malamang na missed mo ang pinakamahalagang bahagi ng kuwento.

Ang insidente noong Pebrero 9 ay hindi isang isoladong pangyayari.

Sa totoo lang, noong unang tatlong buwan ng 2026, nagdanas ang GitHub ng hindi bababa sa walong malalaking insidente. May 37 mga pagkabigo, maliit o malaki, na naitala lamang sa Pebrero. Tinanggap ng CTO ng GitHub, Vlad Fedorov, sa isang blog post na sa loob ng dalawang buwang iyon, hindi kayang pangatuparan ng GitHub ang kanilang pangako sa mga corporate na kliyente ng “three nines”—99.9% na availability.

Sa pagtingin sa mga rekord ng mga pagsabog sa loob ng dalawang buwan, makikita mo ang isang kakaibang pattern: bawat insidente, tila may iba’t ibang dahilan.

Pebrero 2: May problema sa Azure compute provider, nagsara ang GitHub Actions nang halos 4 na oras, at naapektuhan ang lahat ng Copilot code agent, CodeQL, at Dependabot.

Pebrero 9: Storm ng cache rewrite, overloaded ang authentication database.

Marso 5: Pagkabigo ng Redis cluster, 95% ng mga workflow sa GitHub Actions ay hindi nakapagsimula sa loob ng 5 minuto, average na delay ng 30 minuto.

Marso 18: Ang pagkakalat ng webhook ay tumaas sa 32 beses ang normal na antas.

Bawat pagkakataon ay tila isang “katastropa,” at bawat direkta dahilan ay iba-iba. Ngunit ang paliwanag ni Fedorov ay nag-uugnay sa lahat ng ito bilang iisang kuwento. Sinabi niya na may tatlong karaniwang struktural na dahilan sa likod ng mga aksidente: “mabilis na pagdami ng load, malapit na pagkakasalig sa pagitan ng mga serbisyo na nagdudulot ng pagkalat ng lokal na pagkabigo, at kakulangan ng sistema sa kakayahang protektahan ang trapiko mula sa mga anomalous na client.”

Sa mga salita ng isang inhinyero, ang pundasyon ng GitHub ay nagsisimula nang magkaroon ng mga butas dahil sa bigat ng bagong load.

At ang "bagong load" na ito ay may tiyak na pangalan.

Pangunahing datos

Kabuuang bilang ng commit para sa buong taon na 2025: humigit-kumulang 1 bilyon

Isang linggong bilang ng commit noong 2026: 275 milyon

Sa kasalukuyang bilis, inaasahang kabuuan para sa taong 2026: 14 bilyon (14 beses ang pagtaas kumpara sa nakaraang taon)

Damdamin ng GitHub Actions: 500 milyon minuto sa linggo noong 2023 → 1 bilyon noong 2025 → 2.1 bilyon minuto sa isang linggo noong unang bahagi ng 2026

Kung ikaw ay isang infrastructure engineer sa GitHub, ang pagkukumpara ng mga dashboard ng pagmamonitor para sa 2025 at 2026 ay magiging nakakatamlay.

Sa buong taon ng 2025, inilapat ng GitHub ang halos 1 bilyon na code commits. Ang bilang na ito ay malaki na mismo, resulta ng maraming taon ng pagpapalago ng platform ng GitHub. Ngunit noong 2026, umabot na sa 275 milyon ang bilang ng commits sa isang linggo. Ikonvert ito—kung patuloy ang ganitong bilis sa buong taon, ang kabuuang bilang ng commits sa 2026 ay magiging malapit sa 14 bilyon, o 14 beses ang dami ng kabuuang commits noong 2025.

Hindi ito isang malambot na kurba ng paglago, kundi isang malaking pahalang. Mas nagpapakita ang pagbabago sa dami ng pagkalkula ng GitHub Actions: 500 milyon minuto ang ginamit bawat linggo noong 2023, dumoble sa 1 bilyon noong 2025, at biglaang tumalon sa 2.1 bilyon minuto sa isang linggo noong simula ng 2026.

Ano ang nagpapadala ng code nang patuloy?

Hindi human developer.

Ipapakita ng GitHub na ang AI Agent ay nagsisiging maging pinakamalikhaing "tagagamit" sa platform na ito. Isang tool lamang ang Claude Code, ngunit kasalukuyang nagtataglay ng 4.5% ng lahat ng mga pagsubmit sa mga public repository ng GitHub. 2.6 milyong pagsubmit bawat linggo, samantalang noong huling bahagi ng Setyembre 2025, ang bilang ay lamang 100,000—nagdagdag ng 25 beses sa loob ng tatlong buwan.

Ang bilang ng PR na inilabas ng AI agent ay patuloy na tumataas. Noong Setyembre 2025, ang AI-generated PR ay umabot sa halos 4 milyon kada buwan, at noong Marso 2026, tumalon ito sa 17 milyon—higit sa apat na beses sa loob ng anim na buwan.

May isang larawan na makakatulong sa iyo na maunawaan kung ano ang ibig sabihin nito.

Noong nakaraan, ang mga "user" ng GitHub ay pangunahin mga tao na programmer. Gumagawa sila sa araw, natutulog sa gabi, at may pahinga sa mga weekend; bawat commit ay may pag-iisip, pag-aatubili, at may limitasyon sa kanilang bilis. Ang load ng sistema ay sumusunod sa takdang oras ng tao, may mga peak at valley, at maipapalagay.

Ngayon, ang patuloy na pagdami ng mga "user" ay mga AI Agent. Hindi sila natutulog, hindi sila nagpapahinga, at hindi sila nag-aatubili; isang task ay maaaring magkaroon ng maraming parallel na Agent nang sabay-sabay, at ang bilang ng mga sumbong bawat oras ng bawat Agent ay madaling lalampas sa isang taong inhinyero sa isang linggo. Mas mahalaga pa, hindi lamang sila nagpapasa ng code, kundi pati na rin patuloy na lumilikha ng mga bagong repository—ginagamit ang repository bilang "output product" ng workflow, hindi bilang "workspace" ng tao.

Ang mga inhinyero ng imprastruktura ng GitHub ay hindi na nakaharap sa isang mas malaking bersyon ng parehong problema, kundi sa isang problema na iba ang kalikasan.

Ang madalas na pagkakaroon ng mga pagkabigo ay only one side ng problema, ngunit may isa pang mas nakakapagod na problema sa GitHub—nabigla ka nang malaman na nagwala ka.

Ang orihinal na pricing logic ng Copilot ay batay sa isang makatwirang aksiyoma: ang mga user ay pangunahing gumagamit nito para sa "auxiliary completion," kung saan bawat interaksyon ay maikli at ang computation ay makapagbabadya. Ang personal na bersyon ay $10 bawat buwan, habang ang business na bersyon ay $19 bawat buwan, na batay sa bilang ng upuan, at ang modelo na ito ay nagsisilbi nang maayos sa nakalipas na ilang taon.

Saka dumating ang Agentic AI.

Ang agentic workflow at tradisyonal na completion ay dalawang iba’t ibang uri. Ang karaniwang code completion, ang request ay linyar at makikita, at maikli ang computation cycle. Samantala, ang isang agentic coding session ay maaaring magtrabaho ng ilang oras, habang nagpapatakbo ng maraming parallel threads, gumagawa ng multi-step reasoning, self-correction, at cross-repo refactoring—isang session ay maaaring mag-consume ng token na mas higit pa sa buong buwanang subscription ng isang karaniwang user.

Ang sitwasyon na kinakaharap ng GitHub ay ang ilang maliit na bilang ng mga matalas na Agentic user na gumagamit ng ilang dolyar lamang sa buwan para mag-consume ng mga mapagkukunan sa kompyuter na katumbas ng ilang daan-daqang dolyar.

Sa harap ng sitwasyong ito, ang reaksyon ng GitHub ay direkta—una ay kontrolin ang flow, pagkatapos ay baguhin ang presyo.

Simula sa simula ng taong ito, sinimulan ng GitHub ang dalawang paralel na mekanismo ng pag-limita para sa Copilot: limitasyon sa haba ng session at limitasyon sa paggamit sa loob ng linggo, na parehong batay sa pagkonsyumo ng token na minultiply sa timbang ng modelo. Samantala, ipinagpapatigil ang pag-rehistro ng mga bagong user para sa ilang personal na pakete ng Copilot.

Noong Hunyo 1, natapos ng GitHub ang mas pangunahing pagbabago sa presyo: Ang Copilot ay ganap na lumipat sa pagbabayad batay sa paggamit, na nagpalit ng mga plano sa pamamagitan ng "AI Credits", kung saan ang 1 AI Credit ay katumbas ng 1 sent, at ang paggamit ay kalkulahin sa real-time batay sa pagkawala ng token.

Ang panahon ng pagbabayad ayon sa upuan ay dumating sa katapusan sa harap ng Agentic AI.

Hindi lamang ito isang problema ng GitHub. Ito ay isang kolektibong krisis sa pagtatakda ng presyo na dinaranas ng buong industriya ng AI tool noong 2026—kapag nagsisimula na ang AI na palitan ang tao sa paggawa ng buong workflow, hindi na lamang ang pagpapalakas sa trabaho ng tao, lahat ng logika sa subscription na batay sa “bawat tao bawat buwan” ay magiging walang kwenta.

Balik sa isyu ng infrastraktura. Ano ba talaga ang plano ng GitHub para harapin ang «14-fold na pagdami» na ito?

May isang detalye na nagpapakita ng gravidad ng sitwasyon:

Sa huling bahagi ng Disyembre 2025, biglang nagsimulang mabilis ang Agentic workflow. Naramdaman ng mga inhinyero sa GitHub na ang 10 beses ay hindi sapat. Sa Pebrero 2026, matapos ang malubhang paghinto, inihayag ng GitHub na kailangan nilang muli nang disenyo ang kanilang arkitektura sa 30 beses ang kasalukuyang sukat.

Hindi ito pagpapalawak, kundi pag-redesign.

Malaki ang pagkakaiba sa dalawang salitang ito. Ang pagpapalawak ay ang pagdaragdag ng mga machine at pagdaragdag ng memorya sa database—hindi nagbabago ang direksyon, tanging lumalaki ang sukat. Ang pagbabago ng disenyo naman ay nangangahulugan na ang mga aksiyon sa kasalukuyang arkitektura ay magiging sistemikong hindi makapagpapagana sa 30 beses na sukat, at kailangang muli nating isipin mula sa pundasyon ang paghahati ng serbisyo, paggalaw ng data, at paghihiwalay ng pagkabigo.

Ang mga partikular na direksyon na inilahad ng GitHub ay kasama ang pagde-kouple ng mga kritikal na serbisyo upang maiwasan ang cascade failure, ang pagpapakilala ng mga mekanismo ng backpressure at kapasidad para sa traffic degradation, ang pag-deploy ng mga hiwalay na host para sa mga hotspot service, ang pag-alis ng single point of failure, at ang mas komprehensibong pagpapabago ng pamamahala—upang maiwasan ang pagpapalabas nang direkta ng mga pagbabago tulad ng "pagbabago sa TTL ng cache mula sa 12 oras patungo sa 2 oras" nang walang sapat na stress testing.

Mahalagang tandaan na hindi nag-iisa ang GitHub.

Nakakaranas na ang Stripe ng problema sa pagbuo ng mga account sa pamamagitan ng AI Agent, at nagbuo ang AWS ng espesyal na sistema ng pagkakakilanlan, sistema ng log, at mekanismo ng kontrol sa produksyon para sa mga Agent. Ang mga aksyong ito ay hindi panghahanda, kundi tugon sa mga signal na nakikita na sa mga dashboard ng pagmamasid.

Ang GitHub ay ang unang nasira—dahil nasa pinakadulo ng AI tool chain ito.

Tumigil muna at isipin ang kalikasan ng buong sitwasyon.

Ano ang GitHub? Ang pinakatuwid na sagot ay, ito ay lugar kung saan ang mga programmer ay nag-iimbak ng kanilang code. Ngunit sa mas malalim na antas, ito ay ang imprastruktura ng kolaborasyon ng tao sa software—ang commit history ay ang track ng kolaborasyon, ang PR ay ang container ng diskusyon, ang Issues ay ang pag-iingat ng intensyon, at ang Actions ay ang pipe ng pagpapatupad. Ang buong sistema ay disenyo para sa ritmo ng trabaho, paraan ng pag-iisip, at modelo ng kolaborasyon ng tao.

Binago ng AI Agent ang lahat.

Kapag isang AI Agent ay maaaring magsumite ng higit sa isang daan na beses sa isang araw, at ang bawat “sumite” ay walang tao na pag-iisip at pagpapasya, kundi isang hakbang sa pag-unlad ng isang loop ng gawain—paano pa ba ito isang “container ng pakikipagtulungan” ang code repository?

Kapag ang mga tool ng AI ang awtomatikong nagbuo ng repository, nagbukas ng PR, nagpapatakbo ng CI, at nagmamerge nang awtomatiko—ang mga developer pa rin ba ang pangunahing bahagi ng proseso, o naging mga “tagapagsuri” o kahit “mga manonood” na lamang sila?

Ang GitHub CTO ay gumamit ng salitang "mabilis na pagtaas ng load" habang inilalarawan ang krisis na ito. Ngunit maaaring maliit ang salitang ito sa paglalarawan ng tunay na kalikasan ng problema—hindi lamang ito pagtaas sa dami, kundi pagbabago sa kalikasan ng paggamit. Sa lumang modelo, ang GitHub ay "kagamitan ng mga developer"; sa bagong modelo, ang GitHub ay nagsisimula nang maging "exhaust pipe ng AI," isang pipe na naglalabas ng automated workflow.

Ang ibig sabihin nito sa GitHub ay wala pa ring sagot. Ang 30x scaling ay maaaring lutasin ang problema sa trapiko, ngunit hindi ito lutasin ang pagreredefinisyon ng business model, o ang tanong tungkol sa “Sino ang aking tunay na user?”

Isang napakalalim na pangyayari ang nangyari sa nakaraan: Pagkatapos ng pagkabigo, naglabas ang GitHub ng maraming teknikal na blog post na detalyadong inilalarawan ang bawat pangunahing sanhi ng bawat insidente, halos nasa antas ng hindi inaasahang transparensya. May mga tao na naniniwala na ito ay isang aktibong pagtatayo ng tiwala, habang may iba naman na naniniwala na ito ay pagbabayad ng transparensya para sa pagtitiis ng komunidad ng mga developer—dahil sa susunod na pagsasalin, lalabas pa ang higit pang kawalan ng katatagan.

Isang platform na, pagkatapos mapaslang ng sariling tagumpay, kailangang ibunyag at muling itayo—at ang proseso mismo ay isang pagsubok kung kaya nitong harapin.

Sa gabi ng Pebrero 9, ang inhinyero na naghihintay sa pagpapalabas ng PR ay nagsimula nang makatanggap ng green light. Ngunit baka hindi niya naunawaan na ang pagkabigo na nagdulot sa kanya ng paghihintay ay hindi isang pangyayaring pang-akala sa GitHub, kundi isang malaking tunog na nagpapakita ng pagpasok ng buong industriya ng software development sa isang bagong panahon.

Nakuha mula sa WeChat public account na “GeekPark” (ID: geekpark), may-akda: AstronautMonkey