Downtime Contigency Plan

Pada Rekam Medis

Elektronik(Dari Sisi IT/SI)
(2010-2023)
Oleh Windiarto Nugroho
Github https://github.com/mas-elkhanza/SIMRS-Khanza
Licensi https://en.wikipedia.org/wiki/Aladdin_Free_Public_License
Hasil build https://drive.google.com/drive/folders/0ByL--Jg6bdF7RG1NSlVTT2ZPODg
Website https://www.yaski.or.id
Apa itu Downtime?
 Downtime adalah suatu keadaan pada web, sistem komputer, server dan jaringan
atau system lainnya yang tidak dapat diakses untuk beberapa waktu
 Planned Downtime : downtime yang sudah terencana/direncanakan sebelumnya.
Seperti contoh maintenance bulanan server dan upgrade hardware server sehingga
diharuskan server dimatikan sementara.
 Semi Planned Downtime : downtime semi terencana adalah downtime yang
dilakukan secara mendadak namun sudah terorganisir. Seperti contoh update web
server versi PHP 7 ke versi PHP 8 karena adanya fitur baru, setelah diupdate ada
beberapa fungsi yang deprecated, hal ini akan menyebabkan server down selama
beberapa menit, karena Ketika update beberapa fitur harus diperbaiki ulang dan
baru diketahui Ketika aplikasi sedang dijalankan.
 Unplanned Downtime : downtime yang tidak direncanakan, biasanya karena
masalah overload CPU/RAM pada server yang penuh sehingga menyebabkan hang
dan baru normal Kembali setelah server di restart, kerusakan mendadak pada
hardware server, mati listrik, koneksi jaringan, internet dan lainnya.
 Penyebab Downtime
 Putus jaringan : Penyebab pertama adalah terputusnya server dari jaringan secara fisik, apabila hal ini
terjadi maka server tidak dapat dijangkau oleh sistem pada jaringan, bisa karena kabel yang sudah
terlalu tua sehingga rapuh, switch yang rusak karena aktifitas alam seperti terkena petir dll.
 Serangan hacker : Penyebab berikutnya adalah terjadi serangan oleh hacker, serangan cyber crime
seperti ini dapat terjadi kapan saja pada server kamu apabila keamanan kurang baik. Nah, ketika
hacker berhasil menerobos dan mengendalikan server maka kemungkinan besar akan downtime.
Karena hacker akan mencegah adanya akses ke server tersebut.
 Traffic terlalu tinggi : Sebuah server memiliki batas traffic-nya masing-masing. Apabila sebuah server
mendapat traffic tinggi namun tidak bisa menerimanya, otomatis server akan down. Kondisi ini akan
teratasi apabila traffic sudah mulai menurun.
 Pemadaman listrik : Penyebab yang seringkali terjadi jika server tersebut berada di Indonesia adalah
pemadaman listrik. Sebuah server biasanya ditempatkan pada sebuah data center yang disuplai tenaga
listrik. Apabila terjadi pemadaman dan tidak memiliki daya cadangan seperti generator dan UPS, maka
otomatis akan terjadi downtime.
 Kerusakan hardware : Selanjutnya downtime bisa terjadi apabila terdapat kerusakan pada hardware,
baik berupa HDD, SSD, maupun hardware lain yang berfungsi untuk menunjang server. Apabila ada
salah satu yang rusak, maka akibatnya server akan downtime.
 Software : Selain hardware, dari sisi software juga dapat menjadi penyebab terjadinya downtime.
Seperti upgrade OS, update library, update paket, update database dll
 Proses restart software : Contohnya adalah Apache pada server web, restart database. Ketika restart
dilakukan, hal itu akan menyebabkan downtime. Namun, tidak akan berjalan lama hanya
membutuhkan waktu beberapa menit saja. Setelah itu akan kembali normal.
 Kesalahan Manusia : salah config database, kesalahan SOP dalam proses update dll.
Cara untuk Meminimalkan Downtime
 Untuk Yang Terkait Sistem Online Bisa Menggunakan Beberapa Layanan. Menggunakan beberapa
layanan sekaligus diperlukan untuk menjaga sistem dengan lebih baik dan aman. Jika layanan
koneksi utama sedang mengalami gangguan bisa dialihkan ke layanan jaringan yang lain, ataubisa
melakukan load balance.
 Pencadangan Rutin dan Pemulihan Terkait Bencana, Pencadangan tidak akan mencegah krisis
terjadi, tetapi ketika terjadi bencana atau kesalahan, data yang telah disimpan dapat membuat
sistem kembali normal dengan lebih mudah, cepat, dan juga murah. Secara umum, simpan
setidaknya tiga salinan data, dengan salah satunya harus disimpan di luar infrastruktur TI normal.
Penting juga untuk membuat cadangan data seperti ini secara teratur untuk memastikan datanya
terkini dan meminimalkan dampak penurunan system
 Beban Pengujian, Pengujian beban pada sistem IT inti harus dilakukan untuk memeriksa apakah
sistem dapat memproses permintaan dan bekerja dengan baik selama penggunaan umum. Pengujian
beban juga memungkinkan persiapan untuk berbagai skenario krisis, seperti kegagalan sebagian
sumber daya. Selama pengujian beban, lacak hambatan apa saja yang terjadi untuk mengetahui
batas atas kinerja dalam sistem. Hambatan tersebut harus dioptimalkan melalui banyak teknik
seperti pengoptimalan algoritma, caching, atau bahkan perubahan dalam arsitektur atau konfigurasi.
Cara untuk Meminimalkan Downtime
 Memantau dan Memperbarui Hardware, Seperti perangkat elektronik lainnya, perangkat keras komputer
tidak akan berfungsi dengan baik selamanya jika tidak dirawat dengan baik. Seiring berlalunya waktu,
perangkat tersebut bisa menjadi usang dan tidak cukup modern untuk menangani solusi perangkat lunak
baru dengan baik. Inilah mengapa peningkatan sistem sangat penting. Pantau terus perangkat yang
digunakan, termasuk memastikan kebersihan, menerima output daya yang stabil dan tepat, dan
menjaganya agar tidak terlalu panas. Selain itu, sama pentingnya untuk memahami kapan server lama
harus diganti dengan mesin baru. Investasi semacam ini terkadang tampak tidak penting. Akan tetapi,
menggunakan server yang terlalu lama dapat menimbulkan konsekuensi yang parah. Bila perlu, Anda bisa
menggunakan cluster server. Cluster server adalah sekelompok server tertaut yang bekerja sama untuk
meningkatkan kinerja sistem, penyeimbangan muatan, dan ketersediaan layanan. Jika server gagal, server
lain dalam cluster dapat mengambil alih fungsi dan beban kerja dari server yang gagal tersebut.
 Menjaga Keamanan Siber, Keamanan siber adalah sesuatu yang sering kali diabaikan oleh banyak
perusahaan. Padahal, keamanan siber sangat penting dan tidak boleh diabaikan. Di satu sisi, ini adalah
masalah yang dapat diatasi dengan memperbaiki berbagai kesalahan sistem, termasuk banyak hal yang
telah disebutkan di atas. Namun, ada satu hal tambahan yang dapat Anda lakukan, yaitu audit keamanan
oleh perusahaan pihak ketiga. Ini cara yang bagus untuk meningkatkan kesadaran keamanan siber dan
mengungkap potensi masalah yang mungkin tidak sadari. Jika ada masalah keamanan yang terjadi, hal itu
dapat mengakibatkan kebocoran data atau bahkan merusak data dan sistem.
Meminimalkan Downtime Saat Proses Update
Database/Versi Aplikasi
 Saat update database jangan melakukan proses sinkron struktur secara
langsung ke server
 Database dibackup di luar server utama
 Hasil backup dibuatkan payload update dengan alat bantu seperti
navicat/yang lain. Kemudian dilihat jika ada proses yang bermasalah dari
payload yang ada. Payload yang bermasalah biasanya dikarenakan perbedaan
nama pada foreign key karena dibuat otomatis oleh database atau ada tabel
atau kolom yang sudah dimodifikasi dan semua itu bisa dilewati
 Hasil payload akan digunakan/diuji secara local sampai tidak ditemukan error
 Hasil payload yang sudah bersih dari error baru akan digunakan untuk
mengupdate server di jam yang tidak sibuk dan biasanya membutuhkan waktu
1 sampai 15 menit tergantung spek server dan konfigurasi database
Meminimalkan Downtime Saat Proses
Update Client
 Gunakan layanan cloud seperti one
drive/google drive/drop box. Semua
aplikasi yang di tanam di client
disinkronkan ke dalam driver tersebut,
sehingga saat dilakukan proses update di
salah satu client, maka semua client akan
terupdate.
 Gunakan aplikasi sinkon local seperti
nextcloud agar semua client bisa
tersinkron aplikasinya dengan aplikasi di
server nextcloud sehingga memotong
waktu update client
 Gunakan aplikasi monitoring client seperti
Net OP, Net Suport School, Veyeon untuk
mereplace ke komputer client dan juga
untuk memantau downtime di computer
client
Cadangan Daya Untuk Jaringan/LAN
 Menggunakan UPS tersentral untuk mengcover satu rumah sakit
 Atau menggunakan UPS untuk setiap switchhub/perangkat jaringan yang ada
Cadangan Daya Untuk Server
Backup Database Untuk Antisipasi Kerusakan Pada
Server, Kegagalan OS, Bencana Alam
 Dibutuhkan Minimal 3 Server. 1 Server Utama, 1 Server Backup Lokal, 1 Server Backup Secara
Cloud/memanfaatkan penyimpanan layanan cloud
 Replikasi Master To Master, model replikasi data yang sifatnya adalah dua arah dan kembar
identik, biasanya dilakukan untuk membagi beban kerja saat client sudah terlalu banyak sehingga
beberapa computer client diarahkan ke server pertama, dan beberapa computer lain diarahkan ke
server kedua sedangkan kedua server akan saling berkomunikasi untuk mereplikasi datanya. Jika
salah satu server bermasalah, masih bisa menggunakan server yang lain dengan mengganti koneksi
ke server yang lain.
 Replikasi Master To Slave, model replikasi yang sifatnya adalah satu arah, server utama secara
otomatis melakukan replikasi ke server cadangan dalam waktu yang sangat singkat, dan kurang
dari satu detik. Jika server utama bermasalah, server utama bisa langsug dimatikan/diisolasi,
server cadangan bisa langsung digunakan dengan mengganti Ipnya menjadi IP server utama
 Backup & Restore Otomatis Secara Berkala. Untuk linux/unix bisa menggunakan crontab, untuk
windows bisa menggunakan time schedule. Proses backup otomatis biasanya dilakukan di luar jam
sibuk. Server cadangan, sesuai waktu yang ditentukan akan melakukan backup database dari server
utama, kemudian akan merestorenya di lokal database, biasanya ada selesih data dengan server
utama. Saat server utama bermasalah, server cadangan bisa dimanfaatkan dan saat server utama
sudah bisa digunakan Kembali bisa dilakukan sinkron data dengan navicat/yang lain.
Downtime Karena OS/Hardware & Upaya
Menguranginya
 Saat kedua server baik utama dan cadangan tidak bisa
digunakan, masih ada database yang sifatnya cloud dan
bisa diambil Kembali untuk di restore dan bisa digunakan
kembali
 Gunakan OS yang mudah diinstall Seperti Linux mint,
waktu install kurang lebih 5 menit
 Gunakan Aplikasi server dan database yang satu paket dan
tinggal install seperti xampp. Waktu install, konfigurasi,
tuneup kurang lebih 5 menit
 Saat OS dan aplikasi database sudah siap, database dari
backup cloud bisa direstore dan membutuhkan waktu
minimal 10 menit tergantung dari spek computer server.
Alternatif Kedua Saat Alternatif Pertama Gagal
 Sediakan Beberapa Perangkat Yang Sifatnya Portabel/Laptop sebagai
cadangan saat kondisi darurat, jika semua computer baik client maupun
server tidak berfungsi. Jika client masih berfungi, untuk pemrosesan data
bisa dibuatkan secara local di masing-masing komputer
 Beberapa perangkat ini sudah terinstall aplikasi dan database secara local
 Di masing-masin perangkat sudah terdapat data master, minimal data
master dan dokter serta petugas yang melayani.
 Saat terjadi downtime, perangkat cadangan yang sifatnya darurat tersebut
bisa digunakan agar tetap memiliki data elektronik, dan data disimpan
secara lokal di masing2 perangkat tersebut
 Untuk data-data tersebut bisa disinkronkan ke server utama menggunakan
alat bantu seperti navicat saat server utama atau server cadangan sudah
normal Kembali.
Downtime Karena Integrasi Dengan Pihak Ke 3
(BPJS, Kemenkes, Asuransi Lain) Yang Bermasalah
 Pastikan/buatkan prosedur saat pasien datang(pasien bpjs/asuransi)
selalu membawa bukti bayar terakhir
 Bagian IT mengkonfirmasi kepada PIC BPJS/Asuransi akan terjadi
gangguan downtime berapa lama
 Jika downtime diperkirakan lama, pasien akan dilayani terlebih dahulu
dengan menunjukkan bukti bayar terakhirnya asalkan layak/tidak
bermasalah
 Pelayanan dilakukan seperti biasa dan semua data dimasukkan, dan
akan dibuatkan SEP/dikirim ke BPJS saat gangguan berakhir
 Usahakan untuk pembuatan SEP/Surat kontrol/yang lain melalui
aplikasi bridging yang ada di dalam SIMRS. SIMRS menyimpan data
bridging secara lokal, sehingga saat terjadi gangguan, data surat
kontrol terakhir masih bisa dicek di SIMRS untuk pelayanan pasien
Downtime Penggantian Server SIMRS
(Terjadwal)
 Koordinasi dengan Bidang terkait seperti Yanmed, Keperawatan, Penunjang
dll.
 Koordinasi dengan TPPRI, IGD, PONEK, Ruang Perawatan, Lab dll.
 Waktu penggantian server SIMRS mulai dinihari.
 Kegiatan input billing pasien ke SIMRS ditunda sampai proses penggantian
server selesai jika diperkirakan waktu downtime cepat.
 Dokter mengisi berkas rekam medis secara elektronik melalui aplikasi
database yang sudah terinstall secara local/menggunakan kertas
sementara.
 Perawat menulis tindakan kedalam aplikasi secara local/menulis ke dalam
kertas sementara.
 Semua data akan dilakukan proses sinkron ke server jika menggunakan
aplikasi local, akan diinput ke dalam aplikasi jika menggunakan manual