Hampir setiap pemilik bisnis yang memakai aplikasi buatan sendiri pernah mengalami ini. Developer yang membangun sistem mengundurkan diri, atau vendor tidak lagi membalas pesan. Aplikasinya masih jalan, pelanggan dan karyawan masih memakainya setiap hari. Tapi tidak ada lagi orang yang paham isinya.

Situasi ini jarang terasa darurat di hari pertama. Masalahnya muncul pelan-pelan: fitur kecil tidak bisa ditambah, error mulai sering muncul, dan tidak ada yang berani menyentuh server karena takut semuanya berhenti.

Tahun ini kami mengambil alih dua sistem dalam kondisi seperti itu. Pertama, platform operasional sebuah lembaga pendidikan yang dipakai ratusan pengguna setiap hari. Kedua, sistem kasir dan kontrol lampu otomatis untuk usaha biliar yang ditinggal developer-nya saat pengerjaan baru sekitar 90 persen. Keduanya kini berjalan normal, dan keduanya tidak perlu dibangun ulang dari nol.

Enam angka dari dua pengambilalihan sistem: 5 celah keamanan ditutup, 3 masalah tindak lanjut, 90 persen progres saat ditinggal, 2 sistem diambil alih, 0 dibangun ulang, ratusan pengguna harian

Kenapa membangun ulang jarang jadi jawaban pertama

Reaksi paling umum saat developer pergi adalah ingin mengganti semuanya. Wajar, karena sistem yang tidak dipahami terasa berisiko. Tapi membangun ulang berarti membayar dua kali untuk fungsi yang sama, menunggu berbulan-bulan, dan memindahkan data lama dengan risiko ada yang hilang.

Dalam banyak kasus, aplikasinya sendiri tidak buruk. Yang hilang hanya dokumentasi, akses, dan orang yang memegangnya. Itu bisa dipulihkan jauh lebih cepat dan lebih murah daripada menulis ulang seluruh sistem.

Urutan langkah yang kami jalankan

Lima langkah mengambil alih aplikasi yang sudah berjalan: amankan akses, audit, tutup risiko terbesar, stabilkan lalu kembangkan, dokumentasi dan rilis rapi

1. Amankan akses lebih dulu. Sebelum menyentuh kode, pastikan bisnis Anda memegang semua kuncinya: akses server atau hosting, database, repositori kode, domain, dan akun layanan pihak ketiga seperti payment gateway. Banyak bisnis baru sadar di tahap ini bahwa sebagian akun masih atas nama developer lama.

2. Audit apa adanya. Petakan apa yang sebenarnya berjalan: teknologi yang dipakai, alur data, dan konfigurasi server. Di tahap ini temuan keamanan hampir selalu muncul.

3. Tutup risiko yang paling berbahaya hari itu juga. Tidak semua temuan harus dikerjakan sekaligus. Celah yang membuka data ke publik ditutup lebih dulu, perbaikan lain dijadwalkan.

4. Stabilkan, baru kembangkan. Setelah sistem aman dan dipahami, barulah fitur tertunda dilanjutkan. Pada sistem biliar tadi, pengembangan dilanjutkan sampai tahap uji coba oleh klien, lalu dipasang di lokasi.

5. Tulis dokumentasi dan pasang proses rilis yang rapi. Tujuannya supaya kejadian yang sama tidak terulang, siapa pun yang memegang sistem ini nanti.

Temuan yang hampir selalu muncul di minggu pertama

Lima celah keamanan yang ditutup di hari pertama audit beserta risiko dan perbaikannya

Dari audit platform lembaga pendidikan tadi, kami menutup lima celah keamanan pada hari yang sama:

  • Mode debug masih aktif di server produksi, sehingga pesan error menampilkan detail internal sistem ke siapa saja.
  • Halaman informasi konfigurasi server bisa dibuka publik.
  • Situs masih bisa diakses lewat HTTP biasa tanpa dialihkan ke HTTPS.
  • Tidak ada security header dasar untuk melindungi pengguna dari serangan umum di browser.
  • Berkas pengaturan mesin pencari membuka jalur yang seharusnya tidak diindeks.

Tiga masalah lain butuh tindak lanjut bertahap: notifikasi email yang ternyata tidak pernah tersambung ke server email sungguhan, koneksi database yang habis saat trafik sedang tinggi, dan unggahan berkas yang sesekali gagal.

Tidak satu pun dari temuan ini terlihat oleh pengguna sehari-hari. Semuanya utang teknis yang menumpuk diam-diam, dan itulah bahayanya. Sistem terlihat baik-baik saja sampai suatu hari tidak.

Kapan membangun ulang memang lebih masuk akal

Ada kondisi ketika menyelamatkan sistem lama justru lebih mahal:

  • Teknologinya sudah tidak didukung lagi dan tidak bisa diperbarui dengan aman.
  • Kode sumbernya tidak ada, yang tersisa hanya aplikasi jadi di server.
  • Kebutuhan bisnis Anda sudah berubah jauh dari tujuan awal sistem itu dibuat.

Audit di awal gunanya menjawab pertanyaan ini dengan data, bukan dengan tebakan. Hasilnya bisa jadi rekomendasi untuk diselamatkan, bisa juga untuk dibangun ulang. Keduanya sah, asal keputusannya berdasarkan kondisi sistem yang sebenarnya.

Tiga kemungkinan hasil audit: selamatkan, audit per modul, atau bangun ulang

Tanda aplikasi Anda perlu segera ditangani

  • Tidak ada orang di tim Anda yang bisa login ke server atau hosting.
  • Error kecil dibiarkan berminggu-minggu karena tidak ada yang tahu cara memperbaikinya.
  • Anda tidak yakin kapan terakhir data di-backup.
  • Permintaan fitur baru selalu dijawab "nanti dulu."
  • Akun hosting, domain, atau payment gateway masih atas nama orang yang sudah tidak bekerja dengan Anda.

Kalau dua atau lebih tanda di atas terjadi di bisnis Anda, sebaiknya sistem itu diaudit sebelum masalah kecil berubah jadi gangguan layanan.

Mulai dari audit

Tim XETUP menangani pengambilalihan dan pemeliharaan aplikasi web, mobile, dan sistem internal yang sudah berjalan, termasuk yang dibangun pihak lain. Kami mulai dari audit, menutup risiko terbesar lebih dulu, lalu memegang sistem Anda dalam skema pemeliharaan bulanan supaya bisnis tidak lagi bergantung pada satu orang.

Ceritakan kondisi aplikasi Anda lewat halaman Kontak, atau lihat layanan Maintenance & Support kami.