Kecelakaan Yandex Cloud: Bot Pindah ke Penyedia Lain dalam 24 Jam. Apa Artinya untuk Pengambilan Data

Dari 8 hingga 11 Oktober 2026, Yandex kehilangan tiga pusat data: Sasovo dan Vladimir berhenti sepenuhnya, Kaluga beroperasi dengan degradasi. Yandex Cloud beralih ke mode darurat dan langsung menyarankan klien untuk mengaktifkan rencana pemulihan darurat mereka sendiri. Yang paling menarik terjadi kemudian. Cloudflare menganalisis apa yang terjadi dengan bot-bot yang berada di cloud ini, dan melihat: mereka tidak menghilang, tetapi dalam waktu satu hari pindah ke penyedia lain. Dan tetap dikenali dengan sidik jari TLS yang sama, JA4. Bagi semua yang terlibat dalam pengambilan data dan otomatisasi, ini adalah eksperimen langka yang mencakup dua pertanyaan: apa yang harus dilakukan ketika infrastruktur gagal, dan mengapa perubahan IP dan hosting tidak mengubah "identitas" bot.

Apa yang Terjadi dengan Yandex

Menurut BleepingComputer, Yandex melaporkan kerusakan pada tiga pusat data akibat serangan drone. Yandex sendiri tidak menyebutkan pelakunya; media mengutip BBC yang mengaitkan serangan tersebut dengan Ukraina. Kronologinya adalah sebagai berikut:

• 8 Oktober — Sasovo (Wilayah Ryazan): kebakaran, lokasi berhenti sepenuhnya;
• 9 Oktober — Kaluga: beroperasi dengan degradasi, tidak sepenuhnya berhenti;
• 11 Oktober — Vladimir: berhenti sepenuhnya.

Di halaman status Yandex Cloud, sebagian layanan (konsol, API, IAM, basis data, S3, Kubernetes) tetap tersedia dengan masalah kinerja, Compute dan AI Studio beroperasi sebagian. Perusahaan menyatakan bahwa mereka tidak dapat memberikan perkiraan waktu pemulihan yang dapat diandalkan, menganggap konfigurasi sumber daya yang tersisa tidak stabil, dan merekomendasikan klien untuk menggunakan rencana pemulihan darurat alternatif. Tidak ada perkiraan pemulihan dan kejelasan mengenai kemungkinan kehilangan data pada saat publikasi BleepingComputer (12 Oktober).

Apa yang Dilihat Cloudflare: Lalu Lintas Turun, Bot Tidak

Pada 14 Oktober, Cloudflare menerbitkan analisis kecelakaan dari sisi jaringannya. Angka-angka kunci:

• 11 Oktober lalu lintas dari jaringan Yandex Search (AS13238) turun 99% dari norma, dari Yandex.Cloud (AS200350) — turun 90%;
• 99,5% permintaan dari AS13238 sebelum kecelakaan adalah otomatis, dan 93,6% permintaan bot adalah crawler Yandex yang terverifikasi. Jaringan ini memberikan sekitar 7% dari semua permintaan bot dari IP Rusia;
• di Yandex.Cloud sekitar 95% permintaan yang dinilai adalah bot, dan tidak ada yang terverifikasi. Ini sekitar 2% dari lalu lintas bot Rusia;
• lalu lintas bot dari Yandex.Cloud turun sekitar 40%, pemindaian plugin WordPress dari jaringan ini turun 90%.

Dan kemudian yang terpenting. Hampir semua permintaan bot dari Yandex.Cloud ditujukan ke satu akun klien Cloudflare di sektor perjudian. Segera setelah kegagalan pada 8 Oktober, permintaan dari Yandex.Cloud ke akun tersebut turun menjadi nol — dan segera muncul permintaan identik dari jaringan penyedia hosting Rusia lainnya, Radist dan Selectel. Dengan sidik jari TLS JA4 yang sama, jalur dan header yang sama, serta string User-Agent yang tidak standar. Hasil selama seminggu: lalu lintas bot Rusia ke akun perjudian tidak turun, tetapi meningkat — dari 167,7 hingga 170,1 juta permintaan (+1,4%).

Kesimpulan Cloudflare dinyatakan dengan tegas: infrastruktur fisik statis, sementara otomatisasi berbahaya dibangun untuk berpindah. Penurunan volume lalu lintas HTTP menunjukkan kecelakaan, tetapi tidak berarti bahwa bot-bot berhenti.

Versi Nyaring dan Data: Mengapa "Bot-bot Diam" Ternyata Berlebihan

Secara bersamaan, Pusat Penanggulangan Disinformasi Ukraina (CPD) menyatakan bahwa setelah serangan di Sasovo, jumlah laporan akun mencurigakan di Facebook dan Telegram dalam sehari turun 83,6% — dari 4.032 menjadi 660. Namun, seperti yang dianalisis oleh TechRadar, pada 10 Oktober aktivitas kembali ke 4.585 laporan, dan pada 11 Oktober melebihi tingkat sebelum serangan. Cloudflare tidak menemukan pergeseran yang signifikan: lalu lintas bot dari IP Rusia ke endpoint "post, reply, like" dari satu jejaring sosial hanya turun 5,7%. Graphika juga tidak melihat kehilangan akun aktif di komunitas yang dipantau. Peneliti Rene DiResta di Lawfare menyebut cerita ini menarik, tetapi lebih mirip fiksi daripada fakta.

Pelajaran terpisah untuk para analis: pada 8 Oktober, bank, ritel, operator, dan media di seluruh Rusia mengalami gangguan, sehingga setiap penurunan "aktivitas" pada hari itu tidak dapat tanpa syarat dikaitkan dengan bot. Lalu lintas agregat dengan mudah menyesatkan.

Pelajaran Pertama: IP dan Hosting — Bukan Identitas Bot

Cloudflare mengenali hubungan "Yandex.Cloud → Radist/Selectel" bukan berdasarkan alamat — alamat dan ASN berubah sepenuhnya. Dikenali berdasarkan perilaku dan sidik jari klien:

• JA4 — hash TLS ClientHello: kumpulan cipher, ekstensi, versi protokol. Ini menggambarkan program, bukan jaringan. Skrip Python yang sama di server baru memberikan JA4 yang sama;
• jalur dan header yang jarang — urutan dan kumpulan header HTTP yang tidak ditemukan di browser biasa;
• User-Agent sendiri — string unik yang berfungsi sebagai label.

Kesimpulan praktis untuk pengambilan data yang legal: perubahan pusat data atau kumpulan IP tidak membuat Anda "baru" bagi anti-bot, jika seluruh tumpukan klien tetap sama. Dan sebaliknya: jika crawler Anda dengan jujur memperkenalkan diri, berperilaku hati-hati, dan tidak menyerang endpoint yang sensitif, sidik jari yang stabil — bukan masalah. Masalah muncul ketika tumpukan terlihat seperti sesuatu yang tidak ada pada pengguna nyata: Chrome yang dinyatakan dengan sidik jari TLS dari pustaka requests, UA eksotis, header yang tidak standar. Secara rinci tentang bagaimana lapisan deteksi ini bekerja, kami telah menulis dalam analisis JA4 dan TLS-fingerprinting saat pengambilan data.

Perhatikan juga satu detail: bot-bot berpindah dari satu pusat data ke pusat data lainnya. Bagi Cloudflare, ini semua masih dalam kategori ASN hosting yang banyak situsnya sudah memiliki ketidakpercayaan yang tinggi. Jaringan berbeda — profil risiko tetap sama.

Pelajaran Kedua: Infrastruktur Harus Dapat Dipindahkan dalam Hitungan Jam

Para penjahat berpindah dalam waktu satu hari karena otomatisasi mereka pada awalnya dapat dipindahkan. Tim yang jujur, yang mengumpulkan harga, memantau hasil, atau melakukan analisis, juga memerlukan portabilitas tersebut. Rekomendasi Yandex Cloud "gunakan rencana pemulihan darurat alternatif" hanya baik jika rencana tersebut sudah ada. Daftar periksa minimum:

1. Kode dan konfigurasi — di luar cloud. Repositori, gambar kontainer, variabel lingkungan harus disimpan sedemikian rupa sehingga parser dapat diterapkan di penyedia lain dengan satu perintah.
2. Penyedia kedua sebelumnya. Akun, pembayaran, dan server uji di penyedia alternatif di yurisdiksi dan wilayah yang berbeda. Mendaftar dan melewati verifikasi pada hari kecelakaan — sudah terlambat.
3. Layer keluar terpisah dari komputasi. Jika permintaan ke situs target melalui penyedia proxy, bukan langsung dari IP server, pemindahan komputasi tidak mengubah geo, jenis IP, atau riwayat sesi. Server dapat dipindahkan, tetapi untuk situs Anda tetap sebagai klien yang sama.
4. Data dan antrean — dengan replikasi. Hasil pengambilan data dan status tugas disalin ke penyimpanan lain, jika tidak, setelah kecelakaan, Anda harus memulai pengambilan data dari awal.
5. Penyedia cadangan — benar-benar berbeda. Hosting cadangan atau penyedia proxy tidak boleh menjadi infrastruktur yang sama di bawah merek yang berbeda. Bagaimana memeriksa ini pada proxy, kami membahas dalam materi tentang mengapa penyedia proxy cadangan dapat menjadi kumpulan yang sama.
6. Latihan darurat. Sekali dalam satu kuartal, jalankan parser di lokasi cadangan dan jalankan tugas nyata. Rencana yang belum pernah dijalankan biasanya tidak berfungsi dalam praktik.

Jenis Proxy Apa yang Menyelesaikan Masalah dalam Situasi Ini

Proxy tidak menyelamatkan dari sidik jari yang buruk — ini terlihat dari contoh analisis Cloudflare. Namun, mereka memisahkan "wajah" permintaan Anda dari tempat di mana kode secara fisik berjalan:

• Proxy residensial — untuk situs di mana ASN hosting dipotong sebelumnya atau mendapatkan CAPTCHA. Saat berpindah server, keluar tetap pada IP domestik negara yang dibutuhkan.
• Proxy pusat data — untuk API dan situs yang loyal, di mana kecepatan dan harga penting. Mereka juga harus disimpan di penyedia yang tidak tergantung pada cloud Anda, agar kecelakaan hosting tidak membawa serta IP keluar.

Namun, proxy hanyalah satu lapisan. Jika tumpukan TLS, header, dan perilaku klien Anda menonjol, mereka akan dikenali di IP mana pun, seperti yang terjadi pada bot-bot yang berpindah ke Radist dan Selectel.

Apa Artinya Ini bagi Pemilik Situs

Cloudflare juga menarik kesimpulan sebaliknya: ASN dan volume lalu lintas — bukan tanda bot yang dapat diandalkan. Pemblokiran jaringan "buruk" bekerja hingga pemindahan pertama. Lebih dapat diandalkan untuk melihat perilaku: sidik jari JA4 yang umum di berbagai jaringan, frekuensi permintaan yang tidak normal, dan aturan WAF pada endpoint sensitif terlepas dari dari mana permintaan datang. Ada juga sisi lain dari koin: 40,5% klien Cloudflare menjawab crawler Yandex dengan kode 403, dan lalu lintas dari jaringan Yandex ke situs berita selama kecelakaan turun 44% — yang berarti bahwa indeksasi yang sah paling terkena dampak.

Kesimpulan

Kecelakaan Yandex menjadi ujian nyata dari dua kebenaran sederhana. Pertama: infrastruktur dapat menghilang dalam sehari, dan yang menang adalah mereka yang dapat memindahkannya dalam hitungan jam — dengan kode di luar cloud, penyedia kedua, dan lapisan keluar yang tidak terikat pada server. Kedua: bagi anti-bot, Anda adalah tumpukan klien Anda, bukan IP Anda. Pusat data baru dengan JA4 yang sama dan User-Agent yang sama — adalah bot yang sama di alamat baru. Bangun pengambilan data Anda sehingga dapat bertahan dari perubahan lokasi dan tetap terlihat sama rapi di IP mana pun.