Perencanaan Down Time System

Tadi pagi saya berangkat menggunakan Jupiter MX yang sudah 3 tahun menyertai saya 🙂 , melintasi ruas jalan kota Bekasi dari daerah Patal (bukan Patal Senayan tapi Patal proyek Bekasi) menuju Kranji, Pulo Gebang hingga akhirnya masuk ke jalur Cakung Cilincing Jakarta Utara. Perjalanan dari rumah hingga Patal proyek Bekasi relatif lancar namun terhenti dan macet total saat menuju Kranji. Ada apa gerangan ? Ternyata ada proyek pengecoran jalan.

Sumpah serapah dan caci maki dari pengemudi sepeda motor maupun mobil baik yang searah maupun dari arah berlawanan merusak suasana pagi yang indah dan tenteram. Semua orang tahu bahwa perbaikan dan pengecoran jalan itu penting, tapi jika tidak ada pemberitahuan dan tahu-tahu terjebak macet, tetap saja orang jadi kesal dan jengkel. Alangkah baiknya jika beberapa waktu sebelum pelaksanaan, ada spanduk pengumuman besar yang dipasang dimulut jalan, sebagai pemberitahuan rencana pengecoran jalan.

Hal ini memang tidak 100% membuat orang tidak terjebak karena mungkin saja ada yang baru melintasi jalan namun jika diumumkan sejak beberapa waktu sebelumnya, sebagian besar pengguna jalan yang secara reguler dan periodik  menggunakan jalan tersebut akan tahu dan bisa memilih jalan alternatif. Bisa juga pihak yang melakukan perbaikan jalan membuat strategi pengecoran, misalnya membuat jalur alternatif via jalan lain (misalnya seberang jalan) selama proses pengecoran dilakukan.

Hal yang mirip sebenarnya berlaku pada manajemen sistem di perkantoran. Bukan sekali dua ada keluhan dari pengguna sistem karena tiba-tiba sistem down yang disebabkan adanya proses upgrade atau migrasi atau improvement sistem. Meski sifatnya hanya perbaikan minor dan secara teori 99% akan berhasil tanpa gangguan dan estimasinya hanya memakan waktu beberapa menit, alangkah baiknya jika perencanaan tetap dilakukan sebagai tindakan preventif andaikata prosesnya meleset dari perkiraan.

Perencanaan akan bermanfaat mengurangi masalah yang timbul akibat down time sistem. Kita bisa menyiapkan pengumuman mengenai rencana down time, estimasi lama waktu yang dibutuhkan, akibat yang bisa ditimbulkan, rencana kedua jika skenario awal tidak berjalan sebagaimana mestinya, mekanisme backup yang dilakukan dan lain-lain. Adanya perencanaan seperti ini akan membuat proses down time berjalan lebih mulus dan bisa mengeliminasi kemungkinan adanya penyimpangan. Dalam beberapa kasus, kita bahkan bisa melakukan proses migrasi atau improvement tanpa harus membuat sistem down.

Contoh kasus adalah proses migrasi mail server lama ke mail server baru tanpa harus membuat mail sistem down. Yang dibutuhkan adalah 2 server (Kalau menggunakan 1 server alias server-server itu juga, down time tidak bisa dihindari. Bisa diakali dengan menggunakan virtual server tapi lebih complicated jika dilakukan langsung dimail server lama)

Berikut adalah urutan proses yang bisa ditempuh untuk melakukan migrasi sistem tanpa membuat sistem yang lama down :

1. Install mail server baru dengan nama host, domain dan konfigurasi sama seperti mail server lama. Yang berbeda hanya IP address
2. Import data user name dan password dari mail server lama ke mail server baru
3. Sinkronisasi data mail server lama ke mail server baru. Sinkronisasi dapat dilakukan langsung pada mail server lama atau bisa juga membuat duplikat sistem mail server lama di komputer lain
4. Testing mail server baru hingga 100% siap digunakan
5. Ubah priority MX records lama menjadi lebih besar, misalnya dari 0 jadi 10 atau dari 10 jadi 20.
6. Tambahkan MX records baru dengan priority lebih tinggi dan arahkan ke mail server baru. Jika ini dilakukan, semua email yang masuk akan diterima oleh mail server baru
7. Lakukan sinkronisasi email kembali untuk menyalin sisa email dari mail server lama ke mail server baru
8. Shut down mail server lama
9. Hapus MX records yang mengarah ke mail server lama

Jika proses diatas dilakukan, kemungkinan adanya email hilang atau mail server down selama migrasi dapat dieliminasi. Kalaupun sampai ada proses down, waktunya dapat ditekan seminimal mungkin.

Ada tambahan pendapat atau saran dari yang lebih berpengalaman ?