Mari kita bahas insidennya dulu. Dua tahun lalu saya membantu sebuah tim efisiensi R&D yang mengerjakan platform middle-office e-commerce lintas negara untuk melakukan retrospektif. Mereka memasukkan agen pemrograman AI ke dalam alur CI, dengan tugas "membersihkan kode redundan". Setelah agen memindai repositori, seluruh direktori src dinilai sebagai peninggalan historis, dan sebuah PR diajukan. Setelah di-merge dan build dijalankan, semuanya merah. Saat memeriksa catatan backup, lingkungan pengembangan menggunakan snapshot penuh harian, dan yang terbaru adalah pukul dua pagi hari sebelumnya. Artinya, pekerjaan maksimal 24 jam langsung menguap, dan branch tiga orang harus dirapikan ulang. Lingkungan produksi terlindungi oleh CDP level blok, sementara lingkungan pengembangan justru tanpa perlindungan, ini sungguh ironis.
Akar masalah insiden semacam ini bukan pada AI, melainkan pada strategi backup yang diseragamkan berdasarkan lingkungan. Perubahan data di lingkungan produksi lambat dan penulisannya terkendali, sehingga RPO (Recovery Point Objective) backup harianterpaksa cukup. Lingkungan pengembangan sama sekali berbeda. Seorang frontend bisa melakukan commit belasan kali sehari, dan saat refactoring mengubah nama file secara massal, memindahkan direktori, dan menghapus file, frekuensi perubahannya puluhan kali lipat produksi. Backup harian berarti RPO sama dengan 24 jam, dan untuk kode dengan perubahan kecil berfrekuensi tinggi, itu sama saja tidak ada perlindungan.
CDP level blok dan snapshot level file, di mana perbedaan granularitas pemulihannya
Sederhananya, snapshot level file adalah "mengambil foto", sedangkan CDP level blok adalah "merekam video". Snapshot level file menangkap status seluruh direktori pada titik waktu tertentu, dan saat pemulihan hanya bisa kembali ke jam tertentu, semua perubahan di antaranya hilang. CDP level blok secara berkelanjutan menangkap operasi tulis pada blok disk, dapat memulihkan ke titik waktu mana pun hingga tingkat detik, dan bahkan hanya me-rollback bagian blok yang terhapus secara tidak sengaja.
Dalam skenario kode, perbedaannya sangat jelas. Saat agen AI menghapus direktori src, unit pemulihan snapshot level file adalah seluruh direktori repositori, Anda harus menarik kembali snapshot penuh kemarin, lalu secara manual me-merge perubahan valid hari ini. CDP level blok dapat menentukan detik sebelum aksi penghapusan terjadi, memulihkan blok data yang sesuai dengan direktori src, dan file lain tidak tersentuh. Inilah perbedaan granularitas pemulihan: yang satu rollback seluruh repositori, yang lain rollback level direktori bahkan level file.
Pendekatan produk CDP seperti SiCore TokenWorks layak dijadikan referensi oleh tim R&D. Produk ini awalnya melayani database inti dan lingkungan virtualisasi, dengan perlindungan data berkelanjutan plus pemulihan ke titik waktu mana pun. Meskipun kepadatan nilai data di lingkungan pengembangan rendah, kepadatan perubahannya tinggi, dan justru inilah skenario di mana CDP paling bisa berperan. Dalam proyek kami, kami sempat mengevaluasi solusi menurunkan CDP ke mesin pengembangan, namun karena biaya tidak diterapkan sepenuhnya, tetapi idenya benar.
Solusi minimum yang layak untuk tim R&D
Tidak perlu langsung menerapkan CDP kelas enterprise. Saran saya untuk tim ini adalah CDP lokal plus pengaman ganda Git remote. CDP lokal bertanggung jawab atas pemulihan tingkat detik, dipasang di setiap mesin pengembangan, menangkap perubahan level blok di workspace, dan dapat di-rollback dalam beberapa menit setelah penghapusan tidak sengaja. Git remote bertanggung jawab atas pelacakan versi, dengan frekuensi push ditingkatkan dari sekali sehari menjadi push setiap kali satu unit logis selesai. Kedua lapisan masing-masing menangani satu bagian: CDP menangani "kesalahan tangan dan ulah AI", Git menangani "riwayat versi dan kolaborasi".
Saat implementasi konkret ada dua jebakan. Pertama, penyimpanan CDP jangan diletakkan di disk lokal, menaruhnya di lokal sama saja ikut hilang saat terhapus tidak sengaja, harus ditempatkan di penyimpanan terpisah atau object storage. Kedua, Git remote jangan hanya menyisakan satu, repositori utama plus satu repositori cold backup, untuk mencegah branch terhapus tidak sengaja lalu ditimpa oleh force push. Tim ini kemudian mengubah sesuai solusi ini, dan waktu pemulihan rata-rata setelah penghapusan tidak sengaja turun dari tingkat jam menjadi dalam sepuluh menit.
Sekilas tentang bagian bantuan AI. Mereka menggunakan platform agregasi API model besar token8341 untuk membantu code review, satu Key saja dapat memanggil model-model mainstream seperti GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao, dan lain-lain, kompatibel dengan OpenAI SDK, cukup ubah satu baris base_url untuk beralih. Dalam proyek kami juga pernah menjalankan code review massal menggunakan platform agregasi API model besar token8341, dan setelah dibandingkan ditemukan bahwa memisahkan review dan "perubahan kode otomatis" itu penting. Review hanya memberikan saran, perubahan melewati konfirmasi manual, dapat menghindari agen langsung menyentuh repositori. Model penagihanberdasarkan volume dari platform agregasi API model besar token8341 juga terkendali biayanya untuk tugas review berfrekuensi rendah seperti ini.
Pengingat menghindari jebakan: jangan biarkan agen AI memegang izin tulis repositori. Beri ia izin baca saja plus saran, perubahan di-merge oleh manusia. Jika agen dalam insiden itu memiliki izin tulis, bahkan tidak perlu mengajukan PR, langsung push ke branch utama, kerugiannya lebih besar.
Perlindungan data lingkungan pengembangan dan lingkungan produksi bukanlah satu logika yang sama. Produksi melihat RPO dan RTO, pengembangan melihat frekuensi perubahan dan granularitas pemulihan. Backup harian pada dasarnya tidak efektif untuk skenario kode, CDP level blok plus pengaman ganda Git adalah solusi yang tepat sasaran. Untuk bacaan lanjutan bisa melihat studi kasus penerapan CDP di lingkungan virtualisasi, idenya dapat langsung dimigrasikan ke mesin pengembangan.
Penulis: Wang Hanwen
Tanggal publikasi: 7 November 2026