Malam itu, seorang anak muda masuk ke warung dengan mata merah dan wajah lelah. Ia memesan kopi hitam double shot, lalu duduk dengan tatapan kosong.
"Mas, saya baru kerja di IT bank. Malam ini lembur sampai jam 2 pagi buat deploy fitur baru ke production. Besok pagi sudah harus live buat jutaan nasabah. Saya deg-degan banget, Mas. Kalau ada bug, gimana?"
 |
| "Di bank, satu klik deploy bisa memengaruhi jutaan nasabah. Tidak ada tombol undo kalau sudah salah. 🏦" |
Saya menuangkan kopinya sambil tersenyum. "Le, selamat datang di dunia IT perbankan. Di sini, deploy bukan cuma soal kode jalan atau tidak. Ini soal kepercayaan jutaan orang yang menaruh uangnya di sistem yang kamu bangun."
Malam ini, mari saya jelaskan apa artinya "deploy ke production" di bank — dan kenapa prosesnya jauh lebih ketat daripada di startup atau perusahaan teknologi biasa. 🏦💻
🚀 Apa Itu Deploy ke Production?
Deploy ke production adalah proses merilis aplikasi atau fitur dari lingkungan pengujian (testing) ke lingkungan nyata (production) yang digunakan oleh pengguna akhir — dalam hal ini, nasabah bank dan karyawan bank.
Kalau diibaratkan:
- Development (DEV) = dapur tempat chef bereksperimen
- Testing (SIT/UAT) = ruang cicip sebelum makanan disajikan
- Production (PROD) = meja makan tempat pelanggan menikmati hidangan
Di startup, deploy ke production bisa terjadi berkali-kali sehari dengan risiko kecil. Tapi di bank? Deploy adalah ritual sakral yang butuh perencanaan matang, approval berlapis, dan sering dilakukan tengah malam atau akhir pekan saat transaksi minimal.
🏦 Kenapa Deploy di Bank Beda dengan Perusahaan Lain?
1. Risiko yang Sangat Tinggi
Satu bug di sistem core banking bisa menyebabkan:
- Saldo nasabah hilang atau dobel
- Transaksi gagal tapi uang sudah terdebet
- Data pribadi nasabah bocor
- Sistem down saat jam sibuk
Di startup, bug bikin user kesal. Di bank, bug bisa bikin orang tidak bisa bayar kuliah anaknya atau perusahaan tidak bisa transfer gaji karyawan.
2. Regulasi Ketat dari OJK dan Bank Indonesia
Bank diawasi ketat oleh Otoritas Jasa Keuangan (OJK) dan Bank Indonesia (BI). Setiap perubahan sistem harus memenuhi standar keamanan, audit trail, dan compliance. Tidak bisa "deploy dulu, fix nanti".
3. Proses Approval yang Panjang
Sebelum kode bisa masuk production, harus melewati banyak approval:
- Developer → kode selesai
- Team Lead → code review
- QA/Tester → testing SIT (System Integration Testing)
- Business User → UAT (User Acceptance Testing)
- Security Team → penetration testing
- Change Management → approval perubahan
- Risk & Compliance → approval risiko
Bisa butuh minggu sampai bulan dari kode selesai sampai bisa deploy!
4. Jendela Deploy yang Terbatas
Bank tidak bisa deploy kapan saja. Ada maintenance window yang biasanya:
- Malam hari (jam 12 malam - 4 pagi) saat transaksi minimal
- Akhir pekan (Sabtu malam atau Minggu pagi)
- Hari libur nasional kalau perubahan besar
Itulah kenapa anak IT bank sering lembur malam-malam atau kerja weekend. Bukan karena manajemennya buruk, tapi karena tidak ada pilihan lain.
📋 Proses Deploy di Bank: Dari Dev sampai Prod
Ini adalah alur umum deployment di bank (bisa berbeda antar bank):
Fase 1: Development (DEV)
- Developer menulis kode di lingkungan development
- Unit testing dilakukan
- Code review oleh senior developer
- Merge ke branch development
Fase 2: System Integration Testing (SIT)
- Kode di-deploy ke environment SIT
- Tim QA melakukan testing menyeluruh
- Testing integrasi dengan sistem lain (core banking, payment gateway, dll)
- Bug fixing kalau ada masalah
Fase 3: User Acceptance Testing (UAT)
- Kode di-deploy ke environment UAT
- Business user (orang non-IT dari divisi bisnis) melakukan testing
- Memastikan fitur sesuai kebutuhan bisnis
- Sign-off dari business owner
Fase 4: Pre-Production (PST/Staging)
- Environment yang mirip dengan production
- Final testing sebelum go-live
- Performance testing untuk memastikan sistem kuat
- Security scan dan penetration testing
Fase 5: Production Deployment
- Deploy dilakukan di maintenance window
- Tim on-call standby untuk monitor
- Rollback plan siap kalau ada masalah
- Monitoring pasca-deploy selama beberapa hari
⚠️ Tantangan Khusus Deploy di Bank
1. Legacy System yang Rumit
Banyak bank masih pakai sistem lama (mainframe, COBOL) yang sudah puluhan tahun. Integrasi sistem baru dengan legacy system adalah mimpi buruk — satu perubahan kecil bisa berdampak ke mana-mana.
2. Downtime Tidak Boleh Lama
Kalau sistem down lebih dari beberapa menit, bank bisa kena denda dari regulator dan kehilangan kepercayaan nasabah. Setiap detik downtime = kerugian miliaran rupiah.
3. Data Sensitif dan Privasi
Bank mengelola data paling sensitif: nomor rekening, saldo, transaksi, KTP, bahkan sidik jari. Keamanan data adalah prioritas nomor satu. Satu kebocoran data bisa jadi skandal nasional.
4. Rollback Plan Wajib Ada
Sebelum deploy, tim harus siapkan rollback plan — cara mengembalikan sistem ke versi sebelumnya kalau terjadi masalah. Di bank, tidak ada istilah "deploy dulu, fix nanti".
5. Dokumentasi dan Audit Trail
Setiap perubahan harus terdokumentasi lengkap: siapa yang approve, kapan deploy, apa yang berubah, siapa yang testing. Auditor akan cek ini semua.
💭 Renungan Penjaga Warung: Beratnya Tanggung Jawab di Pundak Anak IT Bank
Sebagai penjaga warung yang sering ngobrol dengan berbagai profesi, saya sering merenung tentang beban yang dipikul anak IT bank.
Di startup, motto-nya sering: "Move fast and break things." Bergerak cepat, rusak dulu, perbaiki kemudian. Ini cocok untuk perusahaan yang masih cari product-market fit.
Tapi di bank? Motto-nya harus: "Move carefully and don't break anything." Karena yang dipertaruhkan bukan cuma reputasi perusahaan, tapi hidup jutaan orang yang menaruh kepercayaan pada sistem yang kamu bangun.
Bayangkan: seorang ibu yang mau bayar uang sekolah anaknya, tapi transaksi gagal karena bug di kode yang kamu deploy. Atau seorang pengusaha yang tidak bisa transfer gaji karyawan karena sistem down. Atau seorang pensiunan yang tidak bisa tarik uang karena ATM error.
Di balik setiap baris kode, ada cerita manusia. Di balik setiap deployment, ada tanggung jawab moral.
Maka, Bos, kalau ada kenalan Bos yang kerja di IT bank dan sering lembur malam-malam atau kerja weekend, jangan buru-buru bilang mereka "kurang kerja-life balance". Mereka sedang memikul beban yang tidak semua orang sanggup pikul — menjaga kepercayaan jutaan orang agar tidak hancur karena satu kesalahan kecil.
Dan kalau Bos sendiri adalah anak IT bank yang malam ini sedang deg-degan mau deploy, ingatlah: rasa deg-degan itu bukan tanda kelemahan. Itu tanda bahwa Bos sadar akan tanggung jawab yang Bos emban. Dan kesadaran itulah yang membuat Bos menjadi profesional yang baik.
Tetap semangat, Bos. Satu deployment sukses malam ini bisa jadi alasan jutaan orang tidur nyenyak besok pagi. 🏦🤍
- Catatan Rendah Hati dari Admin: Admin blog ini bukan praktisi IT perbankan. Tulisan ini adalah gambaran umum proses deployment di bank berdasarkan literatur dan pengalaman yang dibagikan secara publik. Proses spesifik bisa berbeda antar bank. Untuk detail teknis, silakan konsultasikan dengan tim IT di bank tempat Bos bekerja. Matur nuwun!*
0 comments:
Posting Komentar
Sopanlah dalam berkomentar kawan