Belajar Pentaho - Operational Readiness & Runbooks

#Pendahuluan

Episode 19 membahas apa yang terjadi setelah platform berjalan di produksi. Operational readiness bukan sekadar "menjalankan job" — melainkan kemampuan tim merespons kegagalan dengan tenang dan cepat. Alat utamanya: runbook — dokumen langkah-demi-langkah untuk situasi yang sudah atau bisa terjadi.

Kalian akan belajar menyusun runbook untuk deployment, kegagalan, dan recovery; strategi backup yang benar; prosedur incident response; serta jadwal perawatan rutin. Di akhir episode, platform kalian bukan lagi proyek, melainkan layanan yang dikelola.

#Runbook: Dokumen yang Menyelamatkan Insiden

Runbook adalah langkah-langkah tertulis untuk menjalankan prosedur di situasi tertentu. Kenapa penting? Saat insiden, otak manusia bekerja buruk di bawah tekanan — dokumen yang jelas menyelamatkan tim dari keputusan panik.

Runbook yang baik berisi:

• Tujuan: kapan prosedur ini dipakai.
• Prasyarat: akses apa yang dibutuhkan.
• Langkah berurutan: tindakan spesifik, bukan instruksi kabur.
• Kriteria berhasil: bagaimana tahu masalah sudah selesai.
• Pemilik: siapa yang bertanggung jawab menjalankan dan memperbarui.

Runbook yang paling penting untuk platform data Pentaho:

• Deployment job baru ke server.
• Restart Pentaho Server.
• Recovery dari job failure.
• Investigasi data yang tidak konsisten.
• Restore dari backup.

Mulailah menulis runbook untuk tiga situasi paling sering terjadi: deployment, restart server, dan recovery job. Tambahkan yang lain seiring platform bertumbuh.

#Backup Repository dan Konfigurasi

Data yang tidak bisa di-restore sebenarnya tidak ada. Backup harus mencakup:

• Repository Pentaho: database yang menyimpan semua objek — transformation, job, report. Backup database inilah yang paling penting.
• File konfigurasi: kettle.properties, konfigurasi keamanan, dan file kustom di folder server.
• Data hasil ETL: tabel warehouse yang dihasilkan pipeline — dilindungi oleh backup database secara umum.

Backup yang baik harus teruji — percuma backup kalau tidak pernah dicoba restore. Buat jadwal backup rutin dan, sesekali, uji restore di lingkungan terpisah.

Contoh skrip backup sederhana untuk folder konfigurasi PDI di mesin lab:

tar czf /backup/pentaho-config-$(date +%Y%m%d).tar.gz \
  ~/lab/pdi-ce/system \
  ~/lab/pdi-ce/.kettle

Perhatikan bahwa perintah di atas memakai $(date +%Y%m%d) untuk menamai file dengan tanggal — tanpa kurung kurawal, sehingga aman dijalankan di shell manapun. Sesuaikan folder dengan lokasi instalasi kalian.

#Incident Response untuk Job Failure

Saat job gagal, tim harus bergerak mengikuti prosedur, bukan improvisasi. Alur incident response yang sehat:

1. Deteksi: monitoring (episode 13) memberi tahu ada job gagal.
2. Klasifikasi: seberapa parah? Satu job harian gagal vs warehouse korup adalah tingkat yang berbeda.
3. Diagnosis awal: baca log, cari error pertama, tentukan penyebab sementara atau permanen.
4. Mitigasi: jalankan ulang (jika idempoten), atau hold sambil investigasi.
5. Pemulihan: proses data yang tertinggal, verifikasi konsistensi.
6. Tindak lanjut: dokumentasikan akar masalah dan perbaiki pipeline agar tidak terulang.

Poin paling sering diabaikan: jangan retry buta. Jalankan ulang hanya jika memahami penyebabnya. Kalau format file berubah, retry hanya mengulang kegagalan yang sama — dan mungkin menggandakan sebagian data.

#Investigasi Inkonsistensi Data

Data yang salah sering lebih berbahaya daripada job yang gagal — kegagalan terlihat, inkonsistensi tidak. Prosedur investigasi:

• Bandingkan hitungan: jumlah baris sumber vs target, per tanggal, untuk menemukan di mana mulai melenceng.
• Sampling: ambil baris yang mencurigakan dan telusuri dari sumber sampai target.
• Cek watermark: pastikan incremental load (episode 15) tidak melewati atau menggandakan data.
• Audit log: pastikan setiap transformasi mencatat jumlah baris proses untuk pembandingan lintas run.

Kunci pencegahan terbaik: rancang transformasi untuk mencatat metrik (jumlah baris dibaca, ditulis, dibuang) setiap kali berjalan. Dengan data ini, inkonsistensi terdeteksi lebih awal sebelum merembet ke laporan.

#Perawatan Rutin dan Pembersihan

Platform yang sehat butuh perawatan terjadwal:

• Pembersihan file sementara: folder tmp dan log lama yang membengkak.
• Arsip file sumber: pindahkan file input yang sudah diproses ke folder arsip (pola dari episode 5).
• Data retention: bersihkan atau arsipkan data staging yang sudah melampaui masa pakai.
• Review jadwal: periksa job yang berjalan makin lama atau jarang dipakai.
• Update berkala: perbarui Pentaho dan JDK, rencanakan di luar jam sibuk.

Jadwalkan perawatan bulanan, catat hasilnya, dan jadikan bagian dari ritme tim. Perawatan yang teratur jauh lebih murah daripada pemulihan darurat.

#Penutup

Di episode 19 ini kalian menyiapkan platform menghadapi hari sulit: menyusun runbook untuk deployment, kegagalan, dan recovery; menerapkan backup 3-2-1 untuk repository dan konfigurasi; menjalankan incident response yang terstruktur; serta merawat platform secara rutin.

Inti yang harus dibawa pulang:

• Runbook mengubah respons panik menjadi prosedur; mulailah dari tiga skenario paling sering.
• Backup tanpa uji restore adalah ilusi keamanan.
• Job failure dan data inconsistency diperlakukan berbeda, keduanya butuh prosedur tertulis.
• Perawatan rutin dan pencatatan metrik mencegah insiden sebelum terjadi.

Di episode 20, kita menghubungkan semua keterampilan ke dunia nyata: use cases & business scenarios — membangun ETL data warehouse, integrasi master data, otomasi pelaporan, arsitektur pipeline analitik, dan pola integrasi data end-to-end.