Semua IT RS punya mimpi buruk yang sama: server mati di hari yang paling gak boleh mati. Dan di antara semua hari itu, Hari H akreditasi adalah juaranya. Lo udah briefing tim, udah cek server seminggu sebelumnya, udah tenang-tenang aja. Terus tiba-tiba, jam 7 pagi hari H, aplikasi gak kebuka. Artikel ini gue tulis buat sharing cerita nyata (dengan beberapa detail diubah biar gak ada yang kena marah), lengkap dengan pelajaran yang bisa lo ambil sebelum giliran RS lo.

Setup: RS Tipe C, Survei Besok

Ceritanya di RS tipe C dengan satu server fisik yang nampung semuanya: SIMRS, database, file server, bahkan printer sharing. Lo pasti udah bisa nebak ending-nya. Tim IT-nya cuma dua orang: gue (yang pegang server) dan satu teknisi yang lebih sering disuruh benerin printer.

Seminggu sebelum survei, kami udah "inspeksi" — cek disk, cek backup, bersihin debu, pastiin UPS nyala. Semua keliatan sehat. Sampe salah satu surveyor nanti bakal nanya, "Bagaimana disaster recovery plan rumah sakit ini?" dan kami udah siap jawab pake bahasa indah: "Kami punya SOP, backup harian, dan uji restore berkala." Padahal jujur aja, backup terakhir yang pernah dites restore itu... bulan lalu, dan itu pun cuma coba-coba.

Hari H: Semua Mulai Normal, Lalu Hancur

Jam 06.30 pagi. Semua jalan. Pendaftaran buka, antrian mulai. Gue senyum-senyum aja, mikir "yaudah, aman lah."

Jam 07.15. Tiba-tiba ada laporan: "SIMRS lemot." Gue buka, iya sih, agak lemot. Tapi masih bisa dipake. Gue pikir cuma beban pagi.

Jam 07.40. "SIMRS gak bisa dibuka." Sekarang panic level 1. Gue SSH ke server, cek proses. CPU 100%, RAM full, dan yang bikin gue merinding: disk full. Log error numpuk sampe memenuhi partisi root. Aplikasi gak bisa nulis apa-apa. Dan yang paling parah — surveyor udah ada di ruang tunggu, ditemenin direktur.

Panic & Keputusan Cepat

Gue sempet freezing lima detik. Dalam kepala gue cuma muter: "Restart? Restart server berisiko, database bisa korup kalau gak clean shutdown. Tapi gak restart, sistem mati total dan surveyor bakal liat panik."

Keputusan gue: jangan restart dulu. Langkah pertama, cek mana yang bikin disk penuh:

df -h
# /dev/sda1  30G  30G  0  100%  /
du -sh /var/log/* | sort -rh | head

Ketauan: log aplikasi tumbang gede banget — 12GB di folder log, gara-gara ada loop error di modul antrian yang nge-log terus-terusan tanpa henti. Gue langsung:

  1. Stop servicenya (modul antrian), bukan seluruh server.
  2. Truncate log: > /var/log/simrs/antrian.log — kosongin file log tanpa hapus file-nya.
  3. Restart cuma modul itu, bukan reboot server.

Dalam 10 menit, SIMRS balik normal. Pendaftaran jalan lagi. Surveyor gak pernah tau ada apa-apa. Gue cuma bisa duduk di belakang, keringet dingin, sambil mikir: "Andai tadi gue nekat restart, bisa-bisa gue harus restore backup yang belum pernah dites."

Yang Sebenernya Jadi Pelajaran

Setelah survey selesai (dan hasilnya bagus, alhamdulillah), gue nulis evaluasi jujur buat diri sendiri. Ini yang gue catat, dan insyaallah berguna buat lo:

1. Logging itu bisa jadi bom waktu

Loop error yang nge-log terus itu pembunuh senyap. Sekarang gue selalu pasang log rotation dan alert disk usage. Kalau log udah 80% partisi, alarm bunyi. Bukan nunggu full.

2. Jangan pernah "cukup" sama backup yang gak dites

Backup yang gak pernah dites restore itu cuma ilusi keamanan. Surveyor nanya "bagaimana DRP-nya", kami jawab indah, padahal kalau beneran butuh restore, gue sendiri gak yakin backup-nya valid. Mulai sekarang: test restore tiap bulan, minimal satu file penting, atau full kalau bisa.

3. Server tunggal itu risiko tunggal

Semua nempel di satu server = semua mati kalau server mati. Idealnya pisah database dan aplikasi, atau minimal ada virtualisasi + failover. Tapi kalau budget belum ngizinin, yang bisa lo lakuin: monitoring yang bener dan runbook yang jelas, biar pas panic gak mikir sambil gemeteran.

4. Runbook itu penyelamat saat panik

Waktu itu gue beruntung bisa mikir jernih. Tapi gak semua orang seberuntung itu. Bikin runbook sederhana: "kalau SIMRS lemot → cek df, cek log, jangan restart dulu." Cetak, tempel di server room. Saat panik, otak gak kerja normal, tapi kertas bisa dipegang.

Detik-Detik Setelah SIMRS Balik Normal

Setelah SIMRS balik, gue gak langsung lega. Ada rasa bersalah yang aneh. Di satu sisi, surveyor gak pernah tau apa-apa, dan survei jalan mulus. Di sisi lain, gue tau betul itu cuma keberuntungan — kalau log-nya bukan cuma 12GB tapi bikin partisi makin penuh sampe proses lain ikut mati, atau kalau modul antrian gak bisa di-stop dengan aman, ceritanya bisa beda total.

Jam 10 pagi, pas surveyor lagi diskusi sama direksi, gue menyelinap ke server room. Gue buka log lagi, bener-bener liat apa yang terjadi. Ternyata ada bug di versi modul antrian: kalau ada pasien yang di-panggil ulang lebih dari tiga kali dalam satu menit, modul-nya loop nulis error "duplicate call" terus. Bug sepele yang gak pernah ketauan karena gak ada yang monitor log-nya. Gue langsung bikin tiket ke vendor, dan ternyata mereka udah punya patch-nya — tinggal di-update. Update yang mestinya udah kami lakuin bulan lalu, kalau aja ada yang baca changelog.

Checklist Pencegahan ala Gue (Biar Lo Gak Ngalamin)

Biar cerita gue gak cuma jadi hiburan, ini checklist yang gue terapin setelah kejadian itu. Lo bisa contek mentah-mentah:

  • Monitoring disk & CPU wajib — pakai apapun: Zabbix, Grafana, atau script cron sederhana yang kirim notif ke Telegram kalau disk > 80%. Murah, gampang, dan nyelametin.
  • Log rotation aktif — jangan biarin log nimbun tanpa batas. Konfigurasi logrotate harian/mingguan, dan pastikan file log lama ke-compress atau ke-hapus.
  • Alert kalau servis error berulang — kalau aplikasi lo punya log error, bikin deteksi sederhana: jumlah baris "ERROR" dalam 5 menit > N, kirim alert. Loop error gak akan sempet jadi 12GB.
  • Test restore bulanan — tandain di kalender, jangan cuma niat. Bikin prosedur singkat: restore ke direktori test, cek tabel penting ada, selesai. 30 menit sebulan.
  • Runbook cetak di server room — langkah darurat versi kertas: mulai dari "cek df -h", "cek du", "stop servis yang boros", "truncate log", sampai "kapan boleh restart". Tempel di tembok.
  • Update aplikasi rutin — baca changelog vendor tiap rilis. Bug yang bikin loop error di kasus gue udah ke-patch, tapi kami gak pernah update.

Yang Bisa Lo Jawab ke Surveyor (Tanpa Bohong)

Salah satu pertanyaan favorit surveyor akreditasi: "Apa bukti rumah sakit ini punya sistem yang andal?" Mereka gak cuma dengerin jawaban, mereka juga liat reaksi lo. Setelah kejadian itu, gue jadi bisa jawab dengan tenang dan jujur:

  • "Kami punya monitoring disk yang alert otomatis ke tim IT." — ini nyata, udah kepasang.
  • "Backup harian, dan kami test restore tiap bulan." — sekarang nyata, bukan cuma klaim.
  • "Ada runbook darurat di server room." — nyata, dicetak dan di-frame.
  • "Dokumentasi insiden: kami catat tiap kejadian dan tindak lanjutnya." — ini yang bikin surveyor paling impressed, karena mayoritas RS gak punya.

Surveyor itu orang yang pengalaman. Mereka bisa bedain RS yang cuma hafal teori sama RS yang beneran punya sistem. Dokumentasi insiden yang rapi itu bahasa yang mereka pahami: "kapan, apa yang terjadi, apa dampaknya, apa tindak lanjutnya." Itu bukti, bukan janji.

Kenapa Cerita Ini Layak Dishare

Gue share cerita ini bukan buat pamer "gue bisa handle panic." Justru kebalikannya: gue mau lo liat bahwa yang bikin selamat itu bukan kepintaran, tapi keberuntungan + langkah sederhana yang keinget pas panic. Kalau gue bisa dapet satu pembaca yang besok pagi cek df -h dan pasang monitoring disk, cerita gue udah berharga.

IT RS itu kerjaannya sering dianggap remeh sampe terjadi sesuatu. Pas semuanya jalan, orang lupa kita ada. Pas mati, semua nyari kita. Maka satu-satunya cara biar kita gak jadi pahlawan dadakan yang panik adalah: siapin sistemnya dari sekarang, sebelum hari H. Entah hari H akreditasi, hari H klaim BPJS, atau hari H migrasi — persiapan itu gak pernah sia-sia.

Pelajaran Terakhir: Jujur Sama Diri Sendiri

Yang paling gue sesali bukan disk full-nya. Itu cuma gejala. Yang gue sesali adalah kami tahu backup gak pernah dites, tahu monitoring gak ada, tapi milih nyante karena "belum pernah kenapa-kenapa." Hari H itu alarm pertama yang beruntung gak jadi bencana.

Jadi kalau lo baca ini dan ngerasa "itu gue banget" — bagus, berarti waktunya berbenah sebelum giliran lo. Bukan nunggu survey, bukan nunggu server mati. Mulai dari hal kecil: pasang monitoring disk, bikin runbook, tes backup. Surveyor itu cuma lewat satu hari, tapi RS lo harus jalan terus.

Kalau lo punya cerita server mati versi lo, share di komunitas — soalnya tiap cerita itu ngajarin satu cara buat gak ketimpa nasib yang sama.

Salam server sehat,
MinTIRS