Otomasi IT dan Kalendar Bulan

15 Sep 2011 Otomasi IT dan Kalendar Bulan

Apakah ada pengaruh awal Ramdhan, lebaran Fitri, lebaran Haji, lebaran Imlek dan hari-hari penting lain yang berbasis kalendar bulan (lunar system calendar) dalam operasi IT? Lebarannya memang tak berkaitan dengan operasi IT. Tetapi tanggal merahnya tentu saja sangat berkaitan. Karena aktivitas bisnis tidak akan lepas dari batasan-batasan hari libur. Dan penentu utama hari libur adalah kalendar, baik dari muatan umum yang bersifat internasional dan nasional maupun muatan khusus baik dari unsur tradisi maupun agama atau kepercayaan.

Untuk bisnis tertentu, ragam proses informasi bisa berbeda-beda setiap harinya. Aplikasi penggajian mungkin dijalankan sebulan sekali pada tanggal tertentu. Ada juga proses akhir pekan yang hanya dijalankan pada hari terakhir dalam seminggu. Proses akhir bulan dan akhir tahun tentunya hanya dijalankan pada hari-hari tertentu. Bahkan bisa jadi ada pula keragaman proses informasi di hari-hari biasa. Semua itu menunjukkan adanya keragaman jadwal proses informasi dari hari ke hari.

Jadwal sepertinya sederhana selama yang dijadwalkan adalah sesuatu yang berdaur atau berulang. Setiap Jumat sore, Sabtu dan Minggu dijadwalkan beberapa proses akhir pekan. Setiap tanggal-tanggal akhir di setiap bulan dijadwalkan beberapa proses akhir bulan. Namun giliran muncul hari libur yang bukan Sabtu maupun Minggu, sejenak harus menghela nafas. Apakah proses akhir pekan yang dijadwalkan setiap Jumat sore harus tetap diexekusi jika Jumat kali ini libur? Di alihkan kemanakah proses-proses yang lazimnya dijalankan hari Jumat jika ternyata tidak boleh diexekusi di hari libur?

Misalnya untuk perbankan, pada hari libur bisa saja ATM dan kartu kredit tetap beroperasi. Tetapi kantor cabang tidak mungkin buka. Toko-toko juga mungkin sebagian tutup. Transportasi dan penjualan tiketnya bisa saja terus beroperasi meskipun di hari libur. Tetapi bagian manajemen dan administrasi libur.

Demikian pula sistem informasi pemerintahan (e-Government). Ada sejumlah instansi yang libur di hari libur. Ada pula yang tidak libur meskipun hari libur. Bahkan ada pula yang siap memberi pelayanan publik 24 jam sehari dan 7 hari seminggu. Padahal seluruh instansi baik pusat maupun daerah dalam sebuah pemerintahan sebuah negara tentu saling terkait. Sehingga sistemnya pun harus merupakan sebuah sistem terpadu atau network centric computing. Server pusat dan back-end system melayani semua instansi dari daerah hingga pusat yang jadwal operasinya sangat beragam. Tentu harus mampu mengakomodir segala kekhususan dalam penjadwalan operasi IT.

Contoh-contoh kasus di atas menggambarkan adanya kerumitan penjadwalan operasi dapur IT. Terutama di server pusat dan/atau back-end system dan dan sejumlah server lain yang mengemban tugas proses dan/atau konsolidasi data secara batch.

Apa itu Jadwal Operasi? Apa itu batch?

Barangkali ada sebagian pembaca yang masih bingung, kenapa ada proses akhir hari, akhir pekan, akhir bulan dan akhir tahun. Kenapa sedemikian serius membahas jadwal operasi? Apa itu batch? Padahal server pada umumnya untuk mengoperasikan web server, mail server FTP server dan sebangsanya. Paling sekali start untuk beberapa bulan. Dimatikan hanya manakala ada masalah atau karena ada upgrade. Lantas apanya yang dijadwalkan? Mana ada batch? Paling backup data. Sepertinya tidak ada yang aneh?

Memang betul. Umumnya dapur IT sangat sederhana. Tugas operator cukup hanya men-start semua aplikasi yang diperlukan dan memantaunya. Namun sebenarnya bagi praktisi IT yang bekerja di IT berskala besar dan serius seperti perbankan, penerbangan dan pemerintahan (yang serius!) tentu sudah sangat terbiasa dengan istilah jadwal operasi, run book dan batch.

Jadwal operasi IT menjadi rumit dan dibahas serius manakala banyak workload yang bersifat batch yang harus dioperasikan setiap hari. Di sistem perbankan rata-rata sekitar 3000an batch workload dioperasikan setiap hari. Di sistem pemerintahan (e-Gov) bisa jauh lebih banyak lagi, karena nasabahnya seluruh rakyat, seluruh instansi pemerintah, seluruh instansi swasta dan sebagian besar lembaga-lembaga organisasi resmi lainnya. Jenis layanannya pun jauh lebih banyak.

Workload adalah obyek operasi, bisa program aplikasi (lazim disebut job atau task) maupun command. Sedangkan batch adalah sifat dari workload yang jalan di background dan tidak menyelenggarakan interaksi dengan manusia selama beroperasi. Jadi sekali di-start, dia jalan memproses data dan berhenti sendiri manakala proses selesai atau mengalami kegagalan. Proses batch inilah yang pada umumnya mendominasi penjadwalan operasi. Namun bukan berarti yang non-batch tidak perlu dijadwalkan. Di perbankan ada non-batch workload (atau online workload) yang tiap pagi di-start dan tiap malam di-shutdown, yaitu transaksi interaktif yang digunakan para teller di cabang-cabang. Workload semacam ini harus dijadwalkan meskipun bukan batch, karena rutinitasnya jelas.

Kenapa ada batch?

Bagi yang sering menjalankan program di background mungkin bisa membantu menjawab apa alasannya menjalankan program secara batch. Mungkinkah karena kinerja batch lebih baik? Ataukah karena pembuatan programnya lebih sederhana?

Secara awam, program yang inputnya sudah bisa dipastikan dari awal, akan jauh lebih sederhana jika dijalankan secara batch. Input dipersiapkan dalam bentuk file jauh lebih cepat diproses ketimbang dipasok lewat interaksi yang memakan waktu. Lebih-lebih jika input memang sudah dalam bentuk file.

Aplikasi yang berskala besar umumnya melibatkan banyak file transisi di setiap tahapan proses. Hal ini merupakan upaya untuk memberi kemudahan recovery manakala terjadi kegagalan operasi di tengah perjalanan, agar tidak mengulang semua proses. File transisi banyak jenisnya sesuai jenis transaksinya dan setiap jenis memungkinkan banyak cacahnya. Yang sejenis tentu diproses oleh program yang sama meskipun memungkinkan diexekusi dengan job yang beragam. Dengan operasi batch, masing-masing file transisi bisa diproses dengan alur tahapan (job stream sendiri-sendiri secara simultan dengan tingkat multiprogramming yang bisa dikendalikan sesuai dengan banyaknya initiator yang diaktifkan. Metoda ini tidak bisa dilakukan dalam operasi non-batch.

Bisa dibayangkan, untuk tahapan proses yang cukup panjang dengan skala data yang besar, jika diproses langsung dalam sesi interaktif, tentu akan sangat mengganggu kinerja sistem. Tiap jenis transaksi memproses database yang sama secara simultan dengan model multitasking yang tidak bisa dikendalikan cacah subtask (child)-nya. Jika ada error, data yang harus di-recover sangat besar dan tidak ketahuan di tahap mana recovery harus dimulai karena tidak ada transisi.

Terlebih lagi untuk jenis-jenis aplikasi yang dipengaruhi kalendar. Tanpa dipecah menjadi potongan-potongan batch, maka kalendar harus menjadi bagian dari aplikasi tersebut. Misalnya, aplikasi tersebut terdiri dari transaksi A dan B. Transaksi A logik normalnya A1-A2-A3-A4-A5. Tapi untuk hari libur cukup A1-A2-A5 dan di akhir bulan A1-A2-A3-A4-A6. Transaksi B hanya dijalankan di hari kerja pertama setelah libur. Jika hari tersebut Senin, maka alurnya B1-B2. Jika bukan Senin, alurnya B1-B3. Jika aplikasi ini dibuat sebagai program non-batch, maka A dan B harus diwujudkan sebagai subtask agar bisa jalan bareng simultan pada hari kerja pertama setelah libur. Untuk menjalankan masing-masing subtask dan memilih alurnya sesuai kalendar, maka aplikasi tersebut harus mengelola kalendarnya sendiri. Ini akan sangat menyulitkan. Terlebih jika ternyata aplikasi lainnya juga perlu kalendar pula. Bisa jadi ada beberapa duplikasi kalendar dengan format beragam dalam sebuah sistem. Solusi yang paling optimal adalah memecahkan transaksi A dan B menjadi kelompok program terpisah, dan masing-masing terdiri dari program A1, A2, A3, A4, A5, A6 dan B1, B2, B3. Lantas disusun job A berisi susunan step A1-A2-A3-A4-A5 untuk dijadwalkan pada hari-hari normal, job AX berisi susunan step A1-A2-A5 untuk hari libur, job AY berisi susunan step A1-A2-A3-A4-A6 untuk akhir bulan. Juga job B berisi susunan step B1-B2 untuk hari Senin dan job BZ berisi susunan step B1-B3 hari kerja pertama setelah libur yang bukan Senin. Dengan demikian, aplikasi tersebut terbebas dari kalendar karena penjadwalan sepenuhnya dikelola oleh tim operasi.

Selain alasan-alasan di atas, operasi batch juga menjadi solusi terbaik manakala sebuah proses memerlukan input yang berupa koleksi output dari berbagai transaksi, terlebih dari berbagai aplikasi yang berbeda, terlebih lagi dari berbagai server yang berbeda. Setidaknya dari tahap koleksinya hingga terwujud data gabungan yang siap pakai jelas akan jauh lebih efisien melalui operasi batch. Terlebih jika hingga final tidak memerlukan interaksi manual, maka semua tahap cukup dengan operasi batch yang jauh lebih sederhana dan efisien.

Operasi Otomatik

Seperti telah dijelaskan di atas, di lingkungan IT kelas menengah ke atas, operasi bisa mencakup ribuan program batch setiap hari. Belum lagi ditambah pemantauan layar console untuk merespon message tertentu yang kadang juga puluhan bahkan ratusan. Tidak boleh ada kesalahan, baik kesalahan tulis maupun keliru urutannya. Sehingga semua itu merupakan pekerjaan yang padat dan kritis.

Untuk memperkecil kesalahan manusia, hadir produk-produk additif untuk menggantikan pekerjaan operator menjadi mekanisme otomatik. Fungsi-fungsi otomasi secara garis besar dipilah menjadi 2 kelompok, yaitu otomasi penjadwalan (automatic workloads scheduling) dan otomasi penanganan kejadian (automatic events management atau EMS). Dari sisi teknologi, keduanya sangat mirip, karena prinsip kerjanya sama-sama event-driven actions. Bedanya, aksi pada penjadwalan otomatik memiliki daur waktu (time cycle) minimum sekali sehari, dimana aksi tidak akan diulang dalam satu daur. Sedangkan EMS tidak memiliki daur, sehingga aksi akan dijalankan kapan saja kejadian yang ditunggu muncul. Produknya pun pada umumnya dibedakan. Nusantara Software Industry (NSI) juga memproduksi kedua produk komersil tersebut dari hasil karya intelektual bangsa kita sendiri.

Jadwal identik dengan rutinitas, dan rutinitas tidak selalu berpatokan waktu. Rutinitas bisa berpatokan pada kejadian (event) tertentu, dan bisa dikatakan rutin meskipun kemunculannya tidak beraturan dari skala waktu. Semua operasi IT yang rutin pasti bisa diotomasikan. Meskipun tidak banyak, namun ada beberapa software vendor yang menyediakan produk khusus untuk mengotomasikan penjadwalan, antara lain zJOS/Puspa©, produk penjadwal otomatik bikinan Nusantara. Untuk menyimak konsep otomasi penjadwalan secara komprehensif, silakan klik disini.

EMS juga sebuah rutinitas mirip penjadwalan, hanya saja tak mengenal daur. Produk komersil untuk EMS juga tersedia di pasar software, meskipun tidak banyak. Salah satunya adalah zJOS/Sekar© bikinan Nusantara.

Kendala Otomasi

Dalam pengoperasian manual, jadwal dikendalikan oleh pikiran manusia. Trigger bisa waktu maupun event. Tetapi terlebihdulu ditangkap oleh manusia dan aksinya dilakukan oleh manusia pula. Sehingga perubahan jadwal kapan saja tidak ada masalah. Meskipun kadang tidak boleh terlalu mendadak, karena perlu persiapan. Sehingga kalendar operasi pun bisa dirubah kapan saja selama diberikan waktu yang cukup untuk melakukan persiapan.

Lain halnya dengan operasi otomatik, tidak ada sentuhan manual lagi. Jadwal operasi dibakukan sekali dalam setahun. Sekali dibakukan, tidak boleh ada perubahan kecuali dalam keadaan terpaksa. Setiap ada perubahan, harus terlebihdulu masuk ke tahap pengujian kebenaran, kelayakan dan kualitas, mengingat kesalahan dalam penjadwalan otomatik bisa berdampak fatal dalam bisnis. Semua tahapan pengujian tersebut tidak mungkin selesai dalam sehari. Oleh karena itu, hal-hal yang memungkinkan membangkitkan perubahan penjadwalan operasi merupakan kendala utama dalam dunia otomasi.

Hal-hal yang memungkinkan perubahan penjadwalan antara lain koreksi kalendar. Kalendar yang sering dikoreksi adalah kalendar bulan (lunar system calendar), seperti kalendar Jawa, Hijriah, China dll. Selama koreksi tidak berdampak perubahan jadwal libur, mungkin tidak ada pengaruh ke otomasi IT. Karena pada umumnya mekanisme bisnis tidak dipengaruhi penanggalan kalendar bulan selain hadirnya hari libur.

Apakah Lebaran termasuk Kendala Otomasi?

Selama koreksi penanggalannya dilakukan langsung di hari H atau sehari sebelumnya, lebaran dan hari penting lain yang berbasis kalendar bulan termasuk kendala otomasi. Bagaimana tidak? Sampai dengan sehari sebelum hari H belum bisa diputuskan apakah besok benar-benar hari H atau masih nambah sehari lagi. Jika ada sejumlah workload tertentu yang harus dioperasikan di hari H dan/atau setelah hari H, tentu harus ada campur tangan manual.

Solusi Lebaran dalam Otomasi IT

Idealnya ada semacam alat pemantau bulan yang bisa menghasilkan informasi digital. Informasi ini boleh berupa numerik yang menunjukkan sudut kemiringan dan jam penampakan bulan secara terus menerus, maupun sekedar sinyal tertentu yang hanya dibangkitkan manakala sudut kemiringan dan jam penampakan bulan sesuai dengan setting. Yang penting informasi ini bisa dimasukkan dalam komputer untuk digunakan sebagai trigger dalam otomasi. Ini merupakan PR bagi para pakar teknologi sensor untuk mewujudkannya. Agar informasinya akurat, sensor harus tersebar secara sistematik di berbagai wilayah di Tanah Air. Oleh karena itu, penyelenggaraannya mestinya menjadi tanggung jawab pemerintah dan menjadi bagian dari e-Gov. Situs-situs IT lain yang memerlukan dapat mengaksesnya melalui mekanisme tertentu, bisa internet, jaringan khusus maupun SMS dll.

Sementara sebelum solusi ideal di atas terwujud, mau tidak mau otomasi hanya berdasarkan apa yang tertera dalam kalendar resmi di awal tahun. Perubahan susulan hasil pengamatan yang dilakukan pada hari H-1 diabaikan. Bagi yang tidak ingin mengabaikan, satu-satunya pilihan adalah operasi manual.