Studi kasusInfrastruktur & operasi
Memindahkan beban kerja produksi kembali ke server sendiri
Beban kerja produksi yang berjalan di penyedia luar dipindahkan ke infrastruktur sendiri, sehingga biaya berkala turun tanpa membuat pengguna merasakan perubahannya.
- Peran
- IT Network & System Administrator
- Periode
- November 2023 — April 2024
- Status
- Selesai
- Dipakai
Konteks dan masalah
Layanan produksi perusahaan berjalan di penyedia komputasi awan, dan biayanya berulang setiap bulan tanpa henti. Sementara itu server sendiri sudah ada dan belum terpakai sepenuhnya. Pertanyaannya bukan apakah beban kerja itu bisa dipindahkan, melainkan bagaimana memindahkannya tanpa membuat pengguna menyadari bahwa ada yang berubah.
Yang menjadi kendala
- Sistem yang dipindahkan dipakai setiap hari. Kesalahan kecil pada saat pemindahan langsung terasa oleh pengguna.
- Basis data berukuran besar harus tetap utuh dan konsisten setelah berpindah tempat.
- Setelah berpindah, seluruh pemeliharaan harian menjadi tanggung jawab internal tanpa bantuan penyedia.
- Prosedur cadangan masih dikerjakan dengan tangan dan bergantung pada ingatan satu orang, dan itu menjadi risiko begitu semuanya berjalan di tempat sendiri.
Batasan yang tidak bisa diubah
- Tidak boleh ada henti layanan yang dirasakan pengguna selama pemindahan.
- Kapasitas server yang sudah ada harus cukup, karena tujuan pekerjaan ini menekan biaya, bukan menambah belanja perangkat.
- Aplikasi lama berbasis desktop dan basis datanya tidak bisa diubah demi kepentingan pemindahan.
- Waktu perubahan terbatas, sehingga setiap langkah harus bisa diuji dan dibalik bila bermasalah.
Peran dan tanggung jawab saya
- Memindahkan 5 sampai 6 beban kerja produksi dari penyedia awan ke mesin virtual di infrastruktur sendiri, satu per satu.
- Mengelola sistem Linux dan Windows Server produksi beserta basis data yang melayani pengguna aplikasi ERP secara bersamaan.
- Menjaga jalur jaringan perusahaan, kestabilan routing, dan koneksi jarak jauh melalui router yang tersedia.
- Menulis pekerjaan terjadwal otomatis untuk pencadangan basis data dan keadaan sistem ke penyimpanan mandiri, sehingga rutinitas cadangan manual tidak lagi diperlukan.
Cara saya mengerjakannya
- 01
Menetapkan urutan pemindahan berdasarkan risiko
Layanan yang paling jarang dipakai dipindahkan lebih dulu sebagai uji cara kerja. Yang paling sibuk dipindahkan terakhir, setelah prosedurnya terbukti pada beban yang lebih ringan.
- 02
Menyiapkan mesin tujuan sebelum memindahkan apa pun
Mesin virtual tujuan dibangun dan diuji lebih dulu, termasuk kapasitas penyimpanan dan jalur jaringannya, agar pemindahan tidak berubah menjadi pekerjaan perbaikan di tengah jalan.
- 03
Memindahkan data dan aplikasi secara terpisah
Basis data dipindahkan dan keutuhannya diperiksa lebih dulu, baru aplikasi diarahkan ke sumber data yang baru. Dengan cara ini satu langkah yang gagal tidak merusak langkah lainnya.
- 04
Mengotomatiskan rutinitas cadangan
Pengambilan dump basis data dan keadaan sistem dijalankan oleh jadwal otomatis, dengan hasilnya disimpan di penyimpanan mandiri agar bisa diakses tanpa bergantung pada satu server.
Keputusan memindahkan beban kerja kembali ke server sendiri sering terdengar seperti langkah mundur. Di sini alasannya sederhana: biaya bulanan yang terus keluar sementara mesin yang dimiliki belum terpakai penuh. Yang membuat pekerjaan ini sulit bukan pemindahannya, melainkan bahwa sistemnya sedang dipakai orang setiap hari.
Mengapa dipindahkan, bukan sekadar diperkecil
Pilihan pertama yang dipertimbangkan adalah mengurangi kapasitas di penyedia awan sampai biayanya turun. Pilihan itu ditolak karena beban kerjanya tidak berkurang, dan kapasitas yang dikurangi akan menjadi masalah tersendiri saat pemakaian naik. Memindahkan seluruhnya lebih jelas batasnya: satu kali kerja, lalu biaya bulanan berhenti.
Urutan pemindahan menentukan risikonya
Tidak ada satu malam besar untuk berpindah. Layanan yang paling jarang dipakai dipindahkan lebih dulu, bukan karena paling mudah, tetapi karena bila cara yang dipakai salah, dampaknya kecil dan bisa diperbaiki tanpa pengguna mengetahui apa pun. Setelah prosedurnya terbukti, beban kerja yang paling sibuk menyusul. Karena itu pula data dan aplikasi dipindahkan sebagai dua langkah terpisah: basis data dipindahkan dan diperiksa lebih dulu, baru aplikasi diarahkan ke sana.
Cadangan yang tidak lagi bergantung pada ingatan
Sebelumnya pencadangan dikerjakan manual, dan itu berarti bergantung pada orang yang ingat melakukannya. Setelah semua sistem berada di tempat sendiri, risiko itu menjadi lebih besar karena tidak ada lagi pihak lain yang menyimpan salinannya. Rutinitasnya digantikan pekerjaan terjadwal otomatis yang mengambil dump basis data dan keadaan sistem ke penyimpanan mandiri.
Ringkasan hasil
Lima sampai enam beban kerja produksi berpindah dari penyedia awan ke mesin virtual sendiri, dan pemindahannya berjalan tanpa henti layanan. Biaya operasional bulanan ke penyedia awan berkurang, meski besarnya penghematan tidak pernah diukur sehingga tidak ada angka yang bisa disebutkan. Pencadangan basis data dan keadaan sistem kini berjalan terjadwal dan otomatis, bukan lagi rutinitas manual.
Hasil
Pemindahan 5 sampai 6 beban kerja produksi dari penyedia awan ke mesin virtual sendiri berjalan tanpa henti layanan.
Tidak ada jendela henti layanan yang diumumkan atau dijalankan selama pemindahan.
terverifikasi
Biaya operasional berkala yang dibayarkan ke penyedia awan berkurang setelah pemindahan.
Besarnya penghematan tidak pernah diukur, sehingga tidak ada angka yang bisa dikutip.
Pencadangan basis data dan keadaan sistem berjalan terjadwal dan otomatis, menggantikan rutinitas manual.
terverifikasi
Setelah seluruh sistem berada di satu tempat, penelusuran masalah menjadi lebih langsung karena kendali atas jaringan dan server ada di tangan sendiri.
Detail teknis
Bagian ini hanya diperlukan bila Anda ingin menilai sisi teknisnya. Isi di atas sudah cukup untuk memahami hasilnya.
Buka detail implementasi3 keputusan
Beban kerja produksi dipindahkan dari AWS ke Proxmox VE di infrastruktur sendiri. Lingkungan produksi mencakup Linux dan Windows Server beserta Microsoft SQL Server berukuran multi-gigabyte yang melayani pengguna ERP dengan konkurensi tinggi. Routing dan koneksi VPN dipegang MikroTik, dan pencadangan dijalankan sebagai pekerjaan Bash terjadwal dengan cron ke penyimpanan Nextcloud yang dihosting sendiri.
- Memindahkan beban kerja satu per satu, bukan sekaligus dalam satu jendela pemeliharaan.
- Pendekatan ini memperpanjang masa pengerjaan dan menuntut setiap langkah diuji terpisah. Yang diperoleh adalah kemungkinan membalik satu langkah tanpa membawa turun seluruh layanan sekaligus.
- Menulis pencadangan sebagai pekerjaan terjadwal ke penyimpanan mandiri, bukan memakai layanan cadangan terkelola.
- Biaya berlangganan tidak muncul dan data tetap berada di kendali sendiri, tetapi pemantauan keberhasilan pencadangan menjadi tanggung jawab internal, dan tidak ada pihak yang bisa dihubungi ketika hasilnya tidak ada.
- Memakai router dan topologi jaringan yang sudah ada selama pemindahan.
- Menghindari dua perubahan besar pada waktu yang sama membuat penyebab gangguan lebih mudah ditentukan. Konsekuensinya utang rancangan pada jaringan tetap ada setelah pemindahan selesai.
Bagian yang paling menentukan bukan alat pemindahannya, melainkan urutan pengerjaannya. Yang akan dilakukan berbeda: mengukur biaya sebelum dan sesudah secara sengaja, karena penghematan tanpa angka tidak bisa dipakai untuk meyakinkan siapa pun di kemudian hari.
Yang saya pelajari
- Memindahkan sistem yang sedang dipakai lebih banyak soal urutan daripada soal alat. Mulai dari yang paling jarang dipakai membuat kesalahan pertama tidak mahal.
- Penghematan yang tidak diukur tetap nyata, tetapi tidak bisa dipakai untuk meyakinkan orang lain. Pengukuran seharusnya disiapkan sebelum pekerjaan dimulai.
- Cadangan yang bergantung pada ingatan satu orang adalah cadangan yang belum selesai, sekalipun datanya tersimpan.