Kegagalan GitHub Disebabkan oleh Lonjakan Lalu Lintas yang Digerakkan oleh AI dan Kesalahan Konfigurasi

Pada 9 Februari tahun ini, pada waktu malam waktu Beijing, jutaan pembangun di seluruh dunia membuka GitHub dan melihat halaman yang sama.

Bukan 404, tetapi lebih mengganggu daripada 404—iaitu bar amaran kuning yang membuat semua jurutera merasa sejuk di belakang, ditambah dengan lampu indikator dalam senarai yang berubah dari hijau menjadi merah di halaman status.

github.com tidak berfungsi.

API tidak berfungsi.

GitHub Actions gagal.

Operasi Git gagal—bahkan Copilot pun tidak terkecuali.

Pada malam itu, talian CI/CD seseorang terhenti pada titik paling kritikal, pelabuhan automatik seseorang tergantung di udara, dan seseorang menunggu PR yang tidak kunjung digabungkan—semuanya berlatar belakang satu fungsi yang menanti pelancaran, menunggu pengguna sebenar.

GitHub kemudian menerbitkan laporan insiden. Punca utama, dalam istilah teknikal, ialah «kumpulan pangkalan data utama yang bertanggungjawab atas autentikasi dan pengurusan pengguna menjadi terlalu beban». Tetapi di sebalik beberapa perkataan ini tersembunyi satu rantai pemicu yang mengejutkan—

Dua hari yang lalu, pasukan kejuruteraan mengubah masa segar semula « cache tetapan pengguna » dari 12 jam kepada 2 jam untuk segera menghantar model baharu kepada pengguna. Hanya perubahan nombor konfigurasi ini.

Akibatnya, proses penulisan semula cache yang seharusnya tersebar selama 12 jam dipadatkan menjadi hanya 2 jam, menciptakan "badai penulisan semula cache" yang padat, menyebabkan antrian tugas asinkron meluap seketika, komponen infrastruktur bersama gagal, dan reaksi berantai menyebar ke perkhidmatan yang bertanggungjawab atas operasi HTTPS Git proxy, akhirnya menyebabkan seluruh platform kehabisan sambungan.

Satu nombor, berubah dari 12 kepada 2.

GitHub, dilanggar oleh konfigurasi yang saya ubah sendiri.

Tetapi jika anda hanya melihat perubahan konfigurasi ini sahaja, anda mungkin telah melepasi bahagian paling penting cerita ini.

Insiden pada 9 Februari bukanlah satu peristiwa yang berasingan.

Sebenarnya, pada tiga bulan pertama tahun 2026, GitHub mengalami sekurang-kurangnya 8 kegagalan besar. Pada bulan Februari sahaja, tercatat 37 kegagalan kecil dan besar. CTO GitHub, Vlad Fedorov, kemudian mengakui dalam blog bahawa selama dua bulan tersebut, GitHub gagal mempertahankan "tiga sembilan" — ketersediaan 99,9% — yang dijanjikan kepada pelanggan korporat.

Dengan memeriksa fail gangguan dua bulan terakhir, anda akan menemui pola yang aneh: setiap kejadian kelihatan disebabkan oleh sebab yang berbeza.

2 Februari: Masalah penyedia komputasi Azure, GitHub Actions terhenti selama hampir 4 jam, Copilot code agent, CodeQL, dan Dependabot semuanya terjejas.

9 Februari: Badai penulisan semula cache, pangkalan data pengesahan terlebih beban.

5 Mac: Kegagalan kluster Redis, 95% aliran kerja GitHub Actions tidak dapat dimulakan dalam 5 minit, dengan latensi purata 30 minit.

18 Mac: Keterlambatan Webhook meningkat hingga 32 kali ganda daripada paras normal.

Setiap kejadian kelihatan seperti「kebetulan», dan setiap sebab langsungnya berbeza-beza. Tetapi penjelasan Fedorov menghubungkan semuanya menjadi satu cerita yang sama. Beliau berkata, terdapat tiga sebab struktural yang sama di belakang kejadian-kejadian ini: “pertumbuhan beban yang pantas, keterkaitan rapat antara perkhidmatan yang menyebabkan kegagalan tempatan merebak, dan ketiadaan perlindungan trafik sistem terhadap klien yang tidak normal.”

Dalam istilah jurutera, asas GitHub telah mulai menunjukkan retak di bawah tekanan beban baru.

Dan "beban baru" ini mempunyai nama tertentu.

Data penting

Jumlah komitmen sepanjang tahun 2025: sekitar 1 miliar kali

Jumlah commit seminggu pada tahun 2026: 275 juta

Pada kadar ini, anggaran penuh tahun 2026: 14 bilion (meningkat 14 kali ganda tahun ke tahun)

Kuantiti pengiraan GitHub Actions: 500 juta minit seminggu pada 2023 → 1 miliar pada 2025 → 2.1 miliar minit dalam suatu minggu awal 2026

Jika anda seorang jurutera infrastruktur GitHub, perbandingan dashboard pemantauan antara tahun 2025 dan 2026 mungkin akan membuat anda tercengang.

Pada tahun 2025, GitHub mengolah sekitar 1 bilion penghantaran kod. Nombor ini sendiri sudah besar, hasil akumulasi bertahun-tahun platform GitHub. Tetapi pada tahun 2026, jumlah penghantaran seminggu mencapai 275 juta. Dikira semula—jika laju ini diteruskan sepanjang tahun, jumlah keseluruhan penghantaran pada tahun 2026 akan mendekati 14 bilion, 14 kali ganda jumlah keseluruhan tahun 2025.

Ini bukan lengkung pertumbuhan yang licin, melainkan kemiringan curam. Perubahan dalam jumlah pengiraan GitHub Actions lebih jelas: pada tahun 2023, ia menghabiskan 500 juta minit seminggu, pada tahun 2025 ia berlipat ganda menjadi 1 miliar, kemudian pada suatu minggu awal 2026, ia melonjak terus ke 2.1 miliar minit.

Apa yang sedang menghantar kod dengan gila-gila?

Bukan pembangun manusia.

Data dari GitHub menunjukkan bahawa AI Agent kini menjadi "pengguna" paling aktif di platform ini. Alat tunggal Claude Code sahaja kini menyumbang 4.5% daripada semua penghantaran ke repositori awam di GitHub. 2.6 juta penghantaran seminggu, manakala pada akhir September 2025, nombor ini hanya 100,000 — meningkat 25 kali ganda dalam tiga bulan.

Jumlah PR yang dibuka oleh Agen AI juga meledak. Pada September 2025, PR yang dihasilkan oleh AI berjumlah sekitar 4 juta sebulan, dan pada Mac 2026, nombor ini melonjak kepada 17 juta—lebih empat kali ganda dalam tempoh enam bulan.

Ada satu gambar yang boleh membantu anda memahami maksudnya.

Sebelum ini, pengguna GitHub terutama adalah jurucakap manusia. Mereka bekerja pada waktu siang, tidur pada waktu malam, berehat pada hujung minggu, setiap penghantaran memerlukan pemikiran, keraguan, dan kelajuan tangan yang terhad. Beban sistem mengikuti jadual manusia, dengan puncak dan lembah yang boleh diramal.

Sekarang, semakin banyak "pengguna" adalah Agen AI. Mereka tidak tidur, tidak rehat, tidak ragu-ragu; satu tugas boleh menjalankan banyak Agen secara serentak, dan jumlah penghantaran setiap Agen setiap jam dengan mudah melebihi jumlah kerja seorang jurutera sebenar dalam seminggu. Lebih penting lagi, bukan sahaja mereka menghantar kod, tetapi juga terus mencipta repositori baharu—menganggap repositori sebagai "produk keluaran" aliran kerja, bukan "ruang kerja" manusia.

Jurutera infrastruktur GitHub menghadapi bukan masalah sejenis yang lebih tinggi trafiknya, tetapi masalah yang berbeza sepenuhnya.

Kegagalan berulang hanyalah satu sisi masalah; GitHub juga mempunyai masalah lain yang lebih memusingkan—apabila membuat perhitungan, ternyata mengalami kerugian.

Logik penentuan harga awal Copilot dibina berdasarkan andaian yang munasabah: pengguna terutamanya menggunakan secara「bantuan penyempurnaan», setiap interaksi adalah singkat dan pengiraan boleh diramalkan. Versi peribadi pada harga $10 sebulan, versi perniagaan pada harga $19 sebulan, dikenakan mengikut tempat duduk, model ini berfungsi dengan baik dalam beberapa tahun terakhir.

Kemudian, Agentic AI datang.

Aliran Agentic dan pengisian tradisional adalah dua spesies yang berbeza. Pengisian kod standard mempunyai permintaan yang linear dan boleh diramalkan, dengan kitaran pengiraan yang singkat. Sebaliknya, sesi pengkodean Agentic mungkin berjalan selama beberapa jam, sambil memulakan beberapa thread selari, melakukan penalaran berperingkat, memperbaiki kesilapan sendiri, dan merekabentuk semula antar repositori—jumlah token yang digunakan dalam satu sesi dengan mudah melebihi kos langganan seorang pengguna biasa sebulan penuh.

GitHub menghadapi situasi di mana sejumlah kecil pengguna Agentic yang sangat aktif menggunakan sumber daya komputasi bernilai ratusan dolar dengan bayaran bulanan hanya beberapa dolar.

Menghadapi situasi ini, tindakan GitHub sangat langsung—mengawal arus terlebih dahulu, kemudian mengubah harga.

Pada awal tahun ini, GitHub melancarkan dua mekanisme pengurangan laju selari untuk Copilot: had masa sesi dan had penggunaan mingguan, kedua-duanya dihitung berdasarkan jumlah token yang digunakan darab dengan bobot pengiraan model. Sementara itu, pendaftaran pengguna baharu untuk beberapa pakej Copilot peribadi telah dihentikan.

Pada 1 Jun, GitHub menyelesaikan reformasi harga yang lebih mendasar: Copilot beralih sepenuhnya kepada model penagihan berdasarkan penggunaan, menggantikan yuran pakej lama dengan "AI Credits", di mana 1 AI Credit setara dengan 1 sen AS, dan penggunaan dikira secara real-time berdasarkan penggunaan token.

Zaman caj berdasarkan tempat duduk telah sampai ke penghujungnya di hadapan Agentic AI.

Perubahan ini bukan hanya masalah GitHub. Ini adalah krisis penetapan harga kolektif yang sedang dialami oleh seluruh industri alat AI pada tahun 2026—ketika AI mulai menggantikan manusia dalam melaksanakan alur kerja lengkap, bukan sekadar "membantu" pekerjaan manusia, semua logik langganan berdasarkan "per orang per bulan" akan menjadi tidak berkesan.

Kembali kepada isu infrastruktur. Apakah GitHub sebenarnya merancang untuk menangani "pertumbuhan 14 kali" ini?

Terdapat satu butir perincian yang menunjukkan keparahan masalah ini:

Pada akhir Disember 2025, aliran Agentic tiba-tiba bermula mempercepat. Jurutera GitHub sedar bahawa 10 kali tidak mencukupi. Pada Februari 2026, selepas gangguan serius itu, GitHub mengumumkan bahawa arsitektur perlu direka semula pada skala 30 kali ganda daripada skala semasa.

Bukan pengembangan, tetapi reka semula.

Perbezaan antara dua istilah ini sangat besar. Pemuaian bererti menambahkan lebih banyak mesin dan menambahkan lebih banyak memori ke pangkalan data yang sedia ada—arahnya tidak berubah, hanya skala yang bertambah. Reka semula bermaksud bahawa andaian arsitektur semasa akan gagal secara sistemik pada skala 30 kali ganda, dan anda perlu memikirkan semula dari dasar cara pembahagian perkhidmatan, aliran data, dan pengasingan kegagalan.

Arahan pengungkapan GitHub termasuk melepaskan perkhidmatan penting untuk mencegah kegagalan berantai, memperkenalkan mekanisme backpressure dan kemampuan penurunan trafik, menghantar hos tersendiri untuk perkhidmatan panas, menghilangkan titik kegagalan tunggal, serta pengurusan perubahan yang lebih teliti—mengelakkan tindakan seperti "mengubah TTL cache dari 12 jam menjadi 2 jam" yang dilancarkan secara langsung tanpa pengujian beban yang mencukupi.

Perlu diperhatikan bahawa GitHub tidak sendirian.

Stripe telah menghadapi masalah pembuatan akaun secara beramai-ramai oleh AI Agent, dan AWS sedang membina sistem identiti, sistem log, dan mekanisme kawalan pengeluaran khas untuk Agent. Tindakan-tindakan ini bukanlah tindakan pencegahan, tetapi merupakan respons terhadap isyarat yang telah muncul di dashboard pemantauan yang perlu mereka selesaikan.

GitHub hanyalah yang pertama ditembus—kerana ia berada di pusat teras rantai alat AI.

Berhenti sebentar dan fikirkan sifat keseluruhan perkara ini.

Apa itu GitHub? Jawapan paling langsung ialah, ia adalah tempat pengaturcara menyimpan kod mereka. Tetapi secara lebih mendalam, ia adalah infrastruktur kolaborasi perisian manusia—rekod commit adalah jejak kolaborasi, PR adalah wadah perbincangan, Isu adalah penyimpanan niat, dan Action adalah saluran pelaksanaan. Seluruh sistem ini direka untuk menyesuaikan dengan ritme kerja, cara berfikir, dan corak kolaborasi manusia.

Agen AI telah mengubah semua ini.

Apabila satu AI Agent boleh menghantar ratusan kali kod sehari, dan setiap kali «penghantaran» tidak disertai pemikiran dan pertimbangan manusia, hanya langkah kemajuan kitar tugas—koleksi kod masihkah «wadah kerjasama»?

Apabila alat AI secara automatik menghasilkan repositori, membuka PR secara automatik, menjalankan CI secara automatik, dan menggabungkan secara automatik—adakah pembangun masih menjadi subjek utama dalam proses ini, atau mereka telah berubah menjadi hanya “pemeriksa” atau bahkan “penonton”?

CTO GitHub, semasa menggambarkan krisis ini, menggunakan frasa "beban yang tumbuh dengan pantas". Namun, frasa ini kemungkinan meremehkan hakikat masalah ini—ia bukan sahaja pertumbuhan kuantiti, tetapi perubahan kualitatif dalam cara penggunaan. Dalam model lama, GitHub adalah "alat pembangun"; dalam model baru, GitHub sedang berubah menjadi "saluran pembuangan AI", satu saluran output untuk aliran kerja automatik.

Ini masih belum jelas apa maksudnya bagi GitHub. Peningkatan kapasitas 30 kali tidak dapat menyelesaikan masalah trafik, juga tidak dapat menyelesaikan definisi semula model perniagaan atau isu identiti “siapakah pengguna sebenar saya?”.

Baru-baru ini, terdapat fenomena yang cukup bermakna: GitHub setelah mengalami gangguan, menerbitkan banyak blog teknikal yang menjelaskan secara terperinci punca asal setiap insiden, hampir mencapai tahap kejelasan yang mengejutkan. Ada yang berpendapat ini adalah usaha GitHub untuk secara aktif membina kepercayaan, sementara yang lain percaya ini adalah pertukaran kejelasan demi kesabaran komuniti pembangun—kerana fasa reka semula yang akan datang masih akan mengalami ketidakstabilan yang lebih banyak.

Sebuah platform yang runtuh akibat kejayaannya sendiri perlu dibongkar dan dibina semula—dan proses ini sendiri juga merupakan ujian sama ada ia mampu bertahan.

Pada malam 9 Februari, jurutera yang menunggu PR disatukan mungkin akhirnya mendapat lampu hijau. Tetapi dia mungkin tidak sedar bahawa gangguan yang menyebabkan penantian itu bukanlah kejadian tak terduga GitHub, tetapi suara pertanda masuknya industri pembangunan perisian ke era baharu.

Artikel ini berasal daripada akaun微信公众号 "GeekPark" (ID: geekpark), penulis: Yu Hang Yuan