Studi kasus penerapan AI
"Karena masih jalan, jangan disentuh." Sistem yang terus disebut demikian, tanpa disadari masih berjalan sebagai pusat perusahaan dalam kondisi seperti 10 tahun lalu — pasti banyak perusahaan yang merasa mengalaminya. Kali ini, ini adalah catatan lapangan memindahkan sistem manajemen proyek rilis 2016, yangmasih dipublikasikan ke internet di atas OS yang berakhir masa dukungannya pada 2020dan tetap dipakai dalam kondisi itu, ke lingkungan terkini. 2 hari kerja.Kami mewarisi 3.623 tiket dan 4,0 GB lampiran tanpa satu pun yang hilang.
"Karena masih jalan, tak bisa disentuh" telah berlangsung 10 tahun.
Objeknya adalah sistem manajemen proyek internal (Redmine). Kemajuan proyek, catatan penanganan gangguan, riwayat komunikasi dengan pelanggan — data 10 tahun terhimpun di sini. Benar-benar dalam kondisitak bisa disentuh karena tak bisa dihentikan.
Namun setelah isinya diperiksa, ternyata ini sama sekali bukan kondisi yang boleh dibiarkan.
| Item | Sebelum migrasi | Setelah migrasi |
|---|---|---|
| OS | CentOS 6.10 (dukungan berakhir 2020) | AlmaLinux 10.1 |
| Aplikasi | Redmine 3.2.1 (2016) | Redmine 6.1.3 |
| Lingkungan eksekusi | Ruby 2.2.4 | Ruby 3.3.10 |
| Basis data | MySQL 5.7 | MariaDB 10.11 |
| Server web | Apache 2.2 + Passenger | nginx 1.26 + puma |
Sudah 6 tahun sejak dukungan OS berakhir.Selama itu, tak satu pun perbaikan atas kerentanan yang dipublikasikan diterapkan. Dan itu terus berjalan dalam kondisi yang dapat diakses dari luar kantor. Bukan "aman karena masih jalan", melainkan"hanya berjalan, tetapi tidak terlindungi"adalah ungkapan yang tepat.
Melainkan bahwa, tanpa rusak sekalipun, hanya perlindungannya yang berhenti.
Berhasil atau tidaknya migrasi sudah ditentukan oleh pengukuran nyata sebelum memulai.
Sebelum masuk ke migrasi, kami memastikan kondisi saat ini dalam bentuk angka. Bagian inilah yang akhirnya sangat menentukan besarnya tenaga kerja.
- Basis data 38MB / berkas lampiran 4,0 GB
- 20–30 permintaan per hari =masih aktif digunakan
- Plugin ekstensi: nol. Desain khusus: tidak ada
Baris terakhir itulah yang menentukan. Yang paling sering menjadi masalah dalam migrasi jenis ini adalahapakah fitur ekstensi yang ditambahkan belakangan akan berjalan di versi baru. Jika tidak berjalan, tinggallah tiga pilihan "mencari penggantinya", "merelakan fungsinya", atau "memperbaikinya sendiri", dan di situ beberapa minggu lenyap. Kali ini hambatan itu memang tidak ada sejak awal.
Berdasarkan pengukuran nyata ini, sebelum memulai kami menetapkan tiga kebijakan.
1. Kami berhenti menaikkan versi setahap demi setahap
Awalnya kami mengestimasi dengan asumsi menaikkannya secara bertahap 3.2 → 4.2 → 5.1 → 6.x. Namun setelah diverifikasi, ternyatakami bisa memperbaruinya dengan melompati 10 tahun sekaligus. Tenaga kerja yang kami perkirakan pun menjadi tak diperlukan sama sekali.
2. Kami tidak mengubah jenis basis data
Ada juga usulan memindahkannya ke produk basis data lain agar operasinya seragam dengan sistem lain. Namun karena format data sumbernya berbeda, perlu menyisipkan proses konversi.Kami tidak membawa risiko konversi ke dalam "data yang sulit disadari bila hilang" berupa 3.623 tiket dan 6.071 riwayat.Kami mengutamakan agar tak satu pun data hilang, di atas penyeragaman operasi.
3. Kami tidak meng-upgrade server yang ada secara langsung
Kami menyiapkan server baru terpisah, dan pengalihan cukup dengan menulis ulang satu baris pengaturan di pintu masuk.Meski gagal, cukup kembalikan satu baris maka pulih seperti semula— agar kondisi seperti itu terjaga sampai akhir.
Yang memakan waktu ternyata bukan Redmine-nya.
Dari sini adalah pekerjaan nyatanya. Bila masalah yang kami injak selama migrasi dijajarkan, kecenderungannya tampak jelas.
Dari kedelapan masalah itu,hanya 3 yang berasal dari inti Redmine. Bahkan salah satunya adalah salah perkiraan yang menyenangkan berupa "ternyata lebih mudah dari dugaan". Yang benar-benar merepotkan hanyalah 2 masalah.
Sisanya adalah selisih generasi OS, mekanisme keamanan, jalur komunikasi, enkripsi, dan integrasi sistem eksternal —semuanya berada di luar aplikasi.
Melainkan "selisih lingkungan sekitar" yang terhimpun selama 10 tahun.
Jangan lepaskan "bisa dikembalikan dengan satu baris" sampai akhir.
Pengalihan hanya mengarahkan tujuan penerusan server pintu masuk ke server baru. Mengembalikannya pun satu baris. Dankami tidak menghentikan lingkungan lama, melainkan membiarkannya tetap berjalan.
Pada hari pengalihan, "lingkungan lama yang berjalan" dan "lingkungan baru yang berjalan" hidup berdampingan, dan kami menjaga kondisi di mana keduanya dapat dilintasi bolak-balik hanya dengan satu baris. Setelah beberapa hari memastikan tidak ada masalah, barulah kami menghentikan sisi lama.
Kami tidak berhenti pada migrasi, melainkan menambal kekurangan 10 tahun sekaligus.
Di lingkungan baru, kami sekaligus menata hal-hal yang tidak ada di lingkungan lama.
- Cadangan harian (7 generasi) — lingkungan lama sama sekali tidak memiliki mekanisme cadangan
- Pencatatan sumber akses — sebelum migrasi, seluruh akses tampak sama sehingga tak dapat dilacak siapa datang dari mana
- Pembatasan percobaan masuk — karena tidak ada fitur standar, kami perkuat di sisi server web
- Pembaruan otomatis integrasi kode sumber — integrasi yang secara de facto beku kini diperbarui setiap 15 menit
Data yang akhirnya kami wariskan adalah sebagai berikut. Kami memastikan jumlahnya benar-benar cocok antara lingkungan lama dan baru.
Integrasi dari sistem eksternal pun berjalan apa adanya tanpa perubahan pengaturan.Dari sudut pandang pengguna, hanya layar masuknya yang menjadi baru— sebuah pendaratan yang ideal sebagai sebuah migrasi.
Kalau "kami juga punya server yang sama".
Alasan migrasi kali ini selesai dalam waktu singkat dapat diringkas menjadi tiga.
- Tidak ada fitur ekstensi yang terpasang— karena itu kami bisa melompati 10 tahun sekaligus
- Kami mengukur secara nyata sebelum memulai— bahan pengambilan keputusan sudah tersedia dalam bentuk angka
- Kami menjaga kondisi yang bisa dikembalikan— sehingga tak perlu berjudi pada hari pengalihan
Sebaliknya,ketiga hal ini bisa dipastikan sebelum memulai."Ada sistem yang tak bisa dihentikan berjalan di atas server tanpa dukungan" — bila Anda merasa mengalaminya, mari mulai berkonsultasi dari memahami kondisi saat ini dalam bentuk angka. Apakah ia bisa dipindahkan, biasanya akan ketahuan bila diselidiki.
Kami mendukung migrasi dan pembaruan sistem bisnis yang terus berjalan di atas OS tanpa dukungan dan kerangka kerja lama.
Investigasi kondisi saat ini (versi, volume data, ada tidaknya fitur ekstensi, cakupan publikasi) kami lakukan gratis. Bersamaan dengan pembaruan sistem lama (AI Re: Platform / disingkat AIR Platform),Silakan hubungi kami sekarang.
Formulir kontak(mohon tambahkan catatan "Meminta konsultasi migrasi sistem lama") / info@flagship-ai.jp
Seri "Catatan Lapangan Legacy to AI"
- Rangkuman: 22 sistem dan 246 ribu baris pada satu PC — catatan terukur pengembangan AI selama 3,5 bulan
- Catatan Lapangan ①: Memperbarui total Java berusia 20 tahun dalam sekitar satu minggu
- Catatan Lapangan ②: Membuat pintu masuk baru ke sistem inti tanpa mengubah satu baris pun kode yang ada
- Catatan Lapangan ③: Menuntaskan kajian arsitektur sebulan dengan prototipe 2 hari + pengukuran nyata
- Catatan Lapangan ④: PC mining lama menjadi "ChatGPT khusus internal" dalam 2 hari
- Catatan Lapangan ⑤: Menyelamatkan sistem berusia 10 tahun dari server tanpa dukungan dalam 2 hari (artikel ini)
*Angka dalam artikel ini adalah nilai terukur per Agustus 2026. Durasi dan lingkup pekerjaan migrasi berbeda-beda tergantung konfigurasi sistem dan ada tidaknya fitur ekstensi.