Gangguan GitHub yang Disebabkan oleh Lonjakan Lalu Lintas yang Didorong AI dan Kesalahan Konfigurasi

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

Bukan 404, tapi lebih membuat cemas daripada 404—adalah bilah peringatan kuning yang membuat semua insinyur merasa dingin di punggung, ditambah lampu indikator berbaris di halaman status yang berubah dari hijau menjadi merah.

github.com down.

API down.

GitHub Actions gagal.

Operasi Git gagal—bahkan Copilot pun tidak selamat.

Pada malam itu, ada yang jalur CI/CD mereka terhenti di titik paling kritis, ada yang deployment otomatis terjebak di tengah jalan, dan ada yang menunggu PR yang tak kunjung digabungkan—semuanya menunggu fitur yang siap diluncurkan, menunggu pengguna nyata.

Setelah kejadian, GitHub merilis laporan insiden. Akar penyebabnya, dalam istilah teknis, adalah "kluster database inti yang bertanggung jawab atas otentikasi dan manajemen pengguna mengalami kelebihan beban". Namun, di balik beberapa kata ini tersembunyi rantai pemicu yang mengejutkan—

Dua hari lalu, tim teknik mengubah waktu penyegaran 'cache pengaturan pengguna' dari 12 jam menjadi 2 jam untuk segera mendorong model baru kepada pengguna. Hanya perubahan angka konfigurasi ini.

Hasilnya, penulisan ulang cache yang seharusnya tersebar dalam 12 jam dipadatkan menjadi hanya 2 jam, menciptakan "badai penulisan ulang cache" yang padat, antrian tugas asinkron langsung meledak, komponen infrastruktur bersama runtuh, reaksi berantai menyebar ke layanan yang menangani operasi HTTPS Git proxy, dan akhirnya menyebabkan seluruh platform kehabisan koneksi.

Sebuah angka, berubah dari 12 menjadi 2.

GitHub, dibobol oleh konfigurasi yang saya ubah sendiri.

Tetapi jika Anda hanya melihat perubahan konfigurasi ini, Anda mungkin melewatkan bagian paling penting dari cerita ini.

Insiden pada 9 Februari bukanlah kejadian terpisah.

Faktanya, pada tiga bulan pertama tahun 2026, GitHub mengalami setidaknya delapan insiden besar. Pada bulan Februari saja, tercatat 37 gangguan besar dan kecil. CTO GitHub, Vlad Fedorov, kemudian mengakui di blog bahwa selama dua bulan tersebut, GitHub gagal mempertahankan janji "tiga sembilan" — ketersediaan 99,9% — yang dijanjikan kepada pelanggan perusahaan.

Dengan membuka arsip gangguan dua bulan terakhir, Anda akan menemukan pola aneh: setiap insiden tampaknya memiliki penyebab yang berbeda.

2 Februari: Masalah pada penyedia komputasi Azure, GitHub Actions lumpuh selama hampir 4 jam, Copilot code agent, CodeQL, dan Dependabot semua terdampak.

9 Februari: Badai penulisan ulang cache, database otentikasi kelebihan beban.

5 Maret: Gangguan klaster Redis, 95% alur kerja GitHub Actions gagal dimulai dalam 5 menit, dengan latensi rata-rata 30 menit.

18 Maret: Latensi Webhook meningkat hingga 32 kali lipat dari tingkat normal.

Setiap kejadian tampak seperti "kecelakaan tak terduga," dan setiap penyebab langsungnya berbeda. Namun penjelasan Fedorov menghubungkan semuanya menjadi satu cerita yang sama. Ia mengatakan bahwa ada tiga alasan struktural umum di balik kejadian-kejadian ini: "pertumbuhan beban yang cepat, ketergantungan erat antar layanan yang menyebabkan penyebaran kegagalan lokal, serta kurangnya kemampuan sistem untuk melindungi lalu lintas dari klien yang tidak normal."

Dalam istilah insinyur, fondasi GitHub mulai retak di bawah tekanan beban baru.

Dan "beban baru" ini memiliki nama spesifik.

Data kunci

Total komitmen sepanjang tahun 2025: sekitar 1 miliar kali

Jumlah commit dalam satu minggu tahun 2026: 275 juta

Pada kecepatan ini, perkiraan total untuk seluruh tahun 2026: 14 miliar (meningkat 14 kali lipat secara tahunan)

Jumlah komputasi GitHub Actions: 5 miliar menit per minggu pada 2023 → 10 miliar pada 2025 → 21 miliar menit dalam satu minggu awal 2026

Jika Anda seorang insinyur infrastruktur GitHub, perbandingan dashboard pemantauan tahun 2025 dan 2026 kemungkinan akan membuat Anda tercengang.

Pada tahun 2025, GitHub menangani sekitar 1 miliar commit kode. Angka ini sendiri sudah sangat besar, merupakan hasil akumulasi bertahun-tahun dari platform GitHub. Namun, pada tahun 2026, jumlah commit dalam satu minggu mencapai 275 juta. Dihitung secara proporsional—jika kecepatan ini berlanjut sepanjang tahun, total commit pada tahun 2026 akan mendekati 14 miliar, atau 14 kali lipat dari total commit tahun 2025.

Ini bukan kurva pertumbuhan halus, melainkan lereng curam. Perubahan jumlah komputasi GitHub Actions lebih jelas menunjukkan hal ini: pada tahun 2023, konsumsi mingguan mencapai 500 juta menit, pada tahun 2025 melipat ganda menjadi 1 miliar, lalu pada minggu tertentu awal tahun 2026, langsung melonjak menjadi 2,1 miliar menit.

Apa yang sedang mengirimkan kode secara liar?

Bukan pengembang manusia.

Data dari GitHub menunjukkan bahwa AI Agent kini menjadi 'pengguna' paling aktif di platform ini. Hanya dengan satu alat, Claude Code, kini menyumbang 4,5% dari semua commit di repositori publik GitHub. Sebanyak 2,6 juta commit per minggu, padahal pada akhir September 2025, angka tersebut baru 100.000—tumbuh 25 kali lipat dalam tiga bulan.

Jumlah PR yang dibuka oleh AI agen juga meledak. Pada September 2025, PR yang dihasilkan oleh AI sekitar 4 juta per bulan, dan pada Maret 2026, angka ini melonjak menjadi 17 juta—lebih dari empat kali lipat dalam enam bulan.

Ada gambar yang dapat membantu Anda memahami artinya.

Sebelumnya, pengguna GitHub terutama adalah programmer manusia. Mereka bekerja di siang hari, tidur di malam hari, beristirahat di akhir pekan, setiap commit dilakukan dengan pemikiran, keraguan, dan kecepatan tangan yang terbatas. Beban sistem mengikuti ritme kehidupan manusia, memiliki puncak dan lembah yang dapat diprediksi.

Saat ini, semakin banyak "pengguna" adalah AI Agent. Mereka tidak tidur, tidak istirahat, tidak ragu-ragu; satu tugas dapat menjalankan beberapa Agent secara paralel, dan jumlah submit setiap Agent per jam dengan mudah melebihi volume kerja seorang insinyur nyata dalam satu minggu. Lebih penting lagi, mereka tidak hanya mengirimkan kode, tetapi juga terus membuat repositori baru—menganggap repositori sebagai "produk keluaran" alur kerja, bukan "ruang kerja" manusia.

Insinyur infrastruktur GitHub menghadapi bukan masalah sejenis dengan lalu lintas yang lebih besar, melainkan masalah yang sama sekali berbeda sifatnya.

Keseringan gangguan hanyalah satu sisi masalah, GitHub juga memiliki masalah lain yang lebih menyusahkan—ketika menghitung, ternyata mengalami kerugian.

Logika penetapan harga awal Copilot didasarkan pada asumsi yang masuk akal: pengguna terutama menggunakan fitur ini untuk「melengkapi bantuan」, setiap interaksi bersifat singkat dan jumlah komputasi dapat diprediksi. Versi pribadi seharga 10 dolar AS per bulan, versi bisnis seharga 19 dolar AS per bulan, dibebankan berdasarkan jumlah kursi, model ini berjalan baik selama beberapa tahun terakhir.

Kemudian, Agentic AI datang.

Alur Agentic dan pelengkapan tradisional adalah dua spesies yang berbeda. Pelengkapan kode standar memiliki permintaan yang linier dan dapat diprediksi, dengan siklus komputasi singkat. Sementara sesi pengkodean Agentic dapat berjalan selama beberapa jam, sekaligus memicu beberapa thread paralel, melakukan inferensi multi-langkah, koreksi mandiri, dan refaktorisasi lintas repositori—jumlah token yang dikonsumsi satu sesi dengan mudah melebihi biaya langganan sebulan penuh pengguna biasa.

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

Menghadapi situasi ini, reaksi GitHub sangat langsung—pertama, kendalikan aliran, lalu ubah harga.

Pada awal tahun ini, GitHub meluncurkan dua mekanisme pembatasan paralel untuk Copilot: batas durasi sesi dan batas penggunaan mingguan, keduanya dihitung berdasarkan jumlah token yang dikonsumsi dikalikan dengan bobot komputasi model. Sementara itu, pendaftaran pengguna baru untuk beberapa paket Copilot pribadi ditangguhkan.

Pada 1 Juni, GitHub menyelesaikan reformasi harga yang lebih mendasar: Copilot sepenuhnya beralih ke model penagihan berdasarkan penggunaan, menggantikan biaya paket dengan "AI Credits", di mana 1 AI Credit setara dengan 1 sen AS, dan penggunaan dihitung secara real-time berdasarkan konsumsi token.

Era biaya berdasarkan kursi berakhir di hadapan Agentic AI.

Perubahan ini bukan hanya masalah GitHub. Ini adalah krisis penetapan harga kolektif yang sedang dialami seluruh industri alat AI pada tahun 2026—ketika AI mulai menggantikan manusia dalam menjalankan alur kerja lengkap, bukan hanya "membantu" pekerjaan manusia, semua logika langganan berbasis "per orang per bulan" akan gagal.

Kembali ke masalah infrastruktur. Apa sebenarnya rencana GitHub untuk menghadapi "pertumbuhan 14 kali lipat" ini?

Ada satu detail yang menunjukkan seberapa serius masalah ini:

Akhir Desember 2025, alur kerja Agentic tiba-tiba mulai mempercepat. Insinyur GitHub menyadari bahwa 10 kali lipat tidak cukup. Pada Februari 2026, setelah gangguan serius tersebut, GitHub mengumumkan bahwa arsitektur perlu dirancang ulang dengan skala 30 kali lipat dari saat ini.

Bukan扩容，是重新设计。

Perbedaan antara dua istilah ini sangat besar. Skalabilitas berarti menambah jumlah mesin yang ada atau menambah memori database yang ada—arahnya tetap, hanya skalanya yang membesar. Desain ulang berarti asumsi arsitektur saat ini akan gagal secara sistematis pada skala 30 kali lipat, sehingga harus dipikirkan kembali dari dasar mengenai pemisahan layanan, aliran data, dan isolasi kegagalan.

Arah spesifik yang diungkapkan oleh GitHub meliputi: mendekoupl layanan kunci untuk mencegah kegagalan kaskade, memperkenalkan mekanisme backpressure dan kemampuan penurunan lalu lintas, menerapkan server terpisah untuk layanan populer, menghilangkan titik kegagalan tunggal, serta manajemen perubahan yang lebih komprehensif—menghindari operasi seperti "mengubah TTL cache dari 12 jam menjadi 2 jam" yang langsung diluncurkan tanpa pengujian beban yang memadai.

Perlu dicatat bahwa GitHub tidak sendirian.

Stripe telah menghadapi masalah pembuatan akun massal oleh AI Agent, dan AWS sedang membangun sistem identitas, sistem log, dan mekanisme kontrol produksi khusus untuk Agent. Tindakan-tindakan ini bukanlah langkah pencegahan, melainkan respons terhadap sinyal yang sudah muncul di dashboard pemantauan yang harus mereka selesaikan.

GitHub hanyalah yang pertama ditembus—karena berada di inti terpenting dari rantai alat AI.

Berhenti sejenak dan pikirkan sifat keseluruhan dari hal ini.

Apa itu GitHub? Jawaban paling intuitif adalah, ini adalah tempat para programmer menyimpan kode. Namun, lebih dalam lagi, ini adalah infrastruktur kolaborasi perangkat lunak manusia—commit log adalah jejak kolaborasi, PR adalah wadah diskusi, Issues adalah penyimpanan niat, dan Action adalah saluran eksekusi. Seluruh sistem ini dirancang untuk menyesuaikan ritme kerja, cara berpikir, dan pola kolaborasi manusia.

AI Agent mengubah semuanya.

Ketika sebuah AI Agent dapat mengirimkan ratusan kode dalam sehari, dan setiap kali "pengiriman" dilakukan tanpa pemikiran dan pertimbangan manusia, hanya merupakan langkah progres dalam siklus tugas—apakah repositori kode masih menjadi "wadah kolaborasi"?

Ketika alat AI secara otomatis menghasilkan repositori, membuka PR secara otomatis, menjalankan CI secara otomatis, dan menggabungkan secara otomatis—apakah pengembang masih menjadi subjek utama dalam proses ini, atau apakah mereka telah berubah menjadi hanya “pemeriksa” bahkan “penonton”?

CTO GitHub dalam menggambarkan krisis ini menggunakan istilah "pertumbuhan beban yang cepat". Namun, istilah ini kemungkinan meremehkan esensi masalahnya—ini bukan hanya pertumbuhan kuantitatif, tetapi perubahan kualitatif dalam cara penggunaan. Dalam model lama, GitHub adalah "alat pengembang"; dalam model baru, GitHub sedang berubah menjadi "saluran pembuangan AI", sebuah saluran output untuk alur kerja otomatis.

Ini masih belum jelas apa artinya bagi GitHub. Skalabilitas 30 kali tidak dapat menyelesaikan masalah lalu lintas, juga tidak dapat menyelesaikan definisi ulang model bisnis atau masalah identitas “siapa pengguna sejati saya?”.

Baru-baru ini, muncul fenomena yang cukup bermakna: GitHub setelah mengalami gangguan, mempublikasikan sejumlah besar blog teknis yang menjelaskan secara rinci akar penyebab setiap insiden, hingga mencapai tingkat transparansi yang hampir mengejutkan. Ada yang berpendapat ini adalah upaya GitHub secara aktif membangun kepercayaan, sementara yang lain berpendapat ini adalah pertukaran transparansi demi kesabaran komunitas pengembang—karena periode rekonstruksi mendatang masih akan menimbulkan lebih banyak ketidakstabilan.

Sebuah platform yang runtuh karena kesuksesannya sendiri perlu dibongkar dan dibangun ulang—dan proses itu sendiri juga menjadi ujian apakah ia mampu bertahan.

Pada malam 9 Februari, insinyur yang menunggu penggabungan PR kemungkinan besar akhirnya mendapatkan lampu hijau. Namun, ia mungkin tidak menyadari bahwa gangguan yang membuatnya menunggu bukanlah kejadian tak terduga di GitHub, melainkan suara tanda dimulainya era baru bagi seluruh industri pengembangan perangkat lunak.

Artikel ini berasal dari akun WeChat "GeekPark" (ID: geekpark), penulis: AstronautMonkey