Belajar n8n - Operational Readiness & Runbooks

#Pendahuluan

Di episode 18 workflow kalian sudah hidup di Git dan dideploy lewat pipeline CI/CD. Tapi kode yang terkelola belum berarti sistem yang siap operasional. "Siap" artinya ketika jam 3 pagi workflow pembayaran berhenti bekerja, ada yang tahu apa yang harus dilakukan, siapa pemiliknya, dan bagaimana memulihkannya — tanpa membuka dokumentasi yang sudah usang.

Di episode ini kita membangun fondasi operasionalnya:

1. Runbook: prosedur terdokumentasi untuk insiden dan recovery.
2. SLA dan ownership: siapa yang bertanggung jawab atas tiap workflow.
3. Backup, restore, dan disaster recovery yang benar-benar bisa dieksekusi.

#Runbook: Dokumen Operasional yang Hidup

Runbook adalah prosedur langkah demi langkah untuk menangani situasi yang berulang — terutama yang jarang tapi berisiko tinggi. Tanpa runbook, tiap insiden memulai dari nol; dengan runbook, insiden jadi checklist yang bisa dijalankan orang baru sekalipun.

Template runbook sederhana untuk satu workflow:

id: runbook-order-sync
judul: Order Sync Gagal
service: workflow-order-sync
sla_target: 30 menit
severity: P2
langkah:
  - Buka dashboard monitoring dan cek status terakhir.
  - Buka execution yang gagal di tab Executions UI.
  - Periksa error message dan node mana yang gagal.
  - Coba retry manual lewat tombol execute.
  - Jika tetap gagal, cek status API vendor dari luar.
  - Eskalasi ke owner bila tidak pulih dalam 30 menit.
rollback:
  - Nonaktifkan workflow aktif dari UI.
  - Alihkan webhook ke endpoint cadangan.

Yang membuat runbook "hidup" bukan isinya yang sempurna, melainkan siklusnya: diuji saat drill, diperbarui setelah insiden, dan di-review setiap kuartal. Runbook yang tidak pernah dibuka kembali adalah dokumen mati yang memberi rasa aman palsu.

#SLA, SLO & Ownership

SLA (Service Level Agreement) adalah janji level layanan, sedangkan SLO (Service Level Objective) adalah target yang bisa diukur. Untuk workflow, ukuran yang umum dipakai: persentase eksekusi sukses, latensi rata-rata, dan seberapa cepat pulih saat gagal.

Tetapkan satu objek milik untuk setiap workflow — bukan dua, bukan "tim semua":

workflow: order-sync
owner: tim-platform
backup_owner: tim-integrasi
slo:
  success_rate: 99.9
  max_latency_menit: 5
  rpo: 24 jam
  rto: 4 jam

Konvensi RACI yang umum: owner bertanggung jawab penuh atas perubahan dan perbaikan, backup_owner menggantikan saat owner cuti, dan pihak lain hanya consulted atau informed. Catat SLO ini di dekat metrik (dasar dari episode 13) agar tidak ada diskrepansi antara janji dan kenyataan.

#Backup: Workflow, Credential & Database

Backup n8n harus mencakup tiga lapisan yang berbeda, karena memulihkan satu saja tidak cukup:

• Definisi workflow — versi terbaru dari repositori Git sudah menjadi backup pertama kalian.
• Kredensial terenkripsi — disimpan di database, didekripsi dengan N8N_ENCRYPTION_KEY.
• Database itu sendiri — berisi execution history, tag, dan metadata lain yang tidak ada di Git.

Skrip backup rutin yang menyimpan ketiganya ke object storage:

n8n export:workflow --all --output=./backup/workflows --pretty --decrypted
n8n export:credential --all --output=./backup/credentials --decrypted
pg_dump --host=localhost --dbname=n8n --username=n8n --file=./backup/n8n.sql
rclone copy ./backup s3:backups/n8n/$(date +%F) --progress

Tiga hal yang sering dilupakan:

• Simpan backup di luar instance — disk yang sama dengan database tidak menolong saat server mati.
• Backup N8N_ENCRYPTION_KEY bersama credential. Tanpa kunci itu, file credential yang terdekripsi pun tidak berguna.
• Jadwalkan dengan cron atau scheduler yang berbeda dari workflow yang di-backup, agar kegagalan n8n tidak ikut mematikan backup-nya.

#Restore & Disaster Recovery

Restore adalah ujian sebenarnya dari backup. Untuk instance baru, alurnya: instal n8n versi yang sama, set N8N_ENCRYPTION_KEY ke kunci yang sama, lalu import semuanya:

n8n import:workflow --separate --input=./backup/workflows
n8n import:credential --all --input=./backup/credentials
psql --host=localhost --dbname=n8n --username=n8n --file=./backup/n8n.sql

Disaster recovery bukan hanya soal perintah restore, tapi juga angka: RPO (Recovery Point Objective) seberapa banyak data yang boleh hilang, dan RTO (Recovery Time Objective) seberapa cepat layanan harus pulih. Contoh di atas memakai RPO 24 jam dan RTO 4 jam — artinya backup harian cukup, dan proses restore terukur dalam jam, bukan hari.

Uji drill setidaknya sekali sekuartal: restore ke environment kosong dan jalankan smoke test. Backup yang tidak pernah diuji sama saja dengan tidak punya backup.

#On-Call: Menghadapi Insiden

Saat insiden benar-benar terjadi, ikuti urutan yang disiplin:

1. Baca runbook dulu — sebelum menyentuh apa pun, konfirmasi bahwa situasi memang cocok dengan skenario.
2. Kumpulkan fakta — screenshot execution yang gagal, catat waktu, versi node, dan error message.
3. Bertindak sesuai prioritas — pulihkan layanan lebih dulu, analisis akar masalah kemudian.
4. Catat timeline — setelah selesai, tulis postmortem singkat dan perbarui runbook dengan temuan baru.

Alerting dari episode 13 dan error workflow dari episode 7 menjadi mata kalian: alert memberi tahu lebih awal, error workflow menyimpan konteks kegagalan, dan runbook memberi tahu apa yang harus dilakukan. Ketiganya adalah satu sistem, bukan tiga hal terpisah.

#Penutup

Operational readiness mengubah n8n dari alat yang "berfungsi" menjadi layanan yang "dijaga":

• Runbook mendokumentasikan prosedur insiden dan recovery agar bisa dijalankan siapa pun.
• SLA dan SLO membuat janji layanan terukur, dengan ownership yang jelas per workflow.
• Backup mencakup definisi workflow, kredensial, dan database — disimpan di luar instance.
• Restore dan disaster recovery diuji lewat drill berkala, bukan hanya tertulis.
• On-call mengikuti alur yang disiplin dan menutup siklus dengan postmortem.

Di episode 20 kita masuk ke bagian yang lebih menyenangkan: advanced use cases dan design patterns — end-to-end automation untuk marketing, sales, operasional, dan IT, event-driven orchestration, approval workflow, hingga integrasi chatbot, AI, dan RPA. Sampai jumpa!