Belajar OpenClaw - Operational Readiness & Runbooks

#Pendahuluan

Episode 20 menutup dengan observability skala besar — kalian tahu cara melihat dan mengawasi OpenClaw dari banyak sisi. Episode 21 ini menaikkan level: dari alat ke manusia dan proses. Sistem sekencang apa pun tetap digerakkan orang, dan orang butuh petunjuk yang jelas saat panik. Inilah operational readiness.

Roadmap episode 21: menyusun runbooks untuk insiden policy, mendefinisikan ownership dan support boundaries antar tim, membangun audit rutin dan compliance reviews, serta menyiapkan on-call dan incident management yang tidak membakar tim.

#Runbooks untuk Insiden Policy

Runbook adalah instruksi langkah demi langkah yang bisa diikuti saat alert berbunyi — bahkan oleh orang yang baru bergabung atau sedang panik di tengah malam. Runbook yang baik menjawab tiga pertanyaan: apa yang terjadi, siapa yang harus dilibatkan, dan langkah pertama apa yang aman dilakukan.

runbook:
  id: openclaw-policy-denial-spike
  severity: SEV2
  symptoms:
    - "Alert PolicyDenialSpike menyala"
    - "Error 5xx naik pada service tertentu"
  checklist:
    - "Buka dashboard policy dan cek policy yang berubah 24 jam terakhir"
    - "Cek commit terakhir di repo policy lewat log deployment GitOps"
    - "Jika perubahan baru ditemukan, git revert dan sinkronkan"
    - "Pantau denial rate kembali normal selama 15 menit"
    - "Kategorikan insiden dan tulis postmortem"
  contacts:
    - "Platform on-call: @platform-oncall"

Perhatikan urutan checklist di atas: diagnosis dulu, baru tindakan. Panik membuat orang langsung mengubah policy — yang justru memperparah. Runbook memaksa langkah diperiksa satu per satu. Simpan runbook di lokasi yang bisa diakses siapa pun, misalnya di repo atau wiki, dan tulis dengan bahasa yang bisa dimengerti tanpa konteks sebelumnya.

Runbook bukan dokumen mati. Setelah setiap insiden, perbarui dengan hal yang ternyata berguna saat itu: perintah yang menyelamatkan hari, urutan yang tidak bekerja, atau data yang ternyata menyesatkan. Runbook yang usang sama bahayanya dengan tidak punya runbook — orang malah menaruh kepercayaan pada instruksi yang sudah tidak relevan.

#Ownership dan Support Boundaries

Insiden policy bisa datang dari dua arah yang berbeda: control plane yang rusak (urusan platform) atau policy yang salah ditulis (urusan tim aplikasi). Tanpa batas yang jelas, semua insiden akan jatuh ke platform team dan semua orang saling menunggu. Definisi ownership menyelesaikan kebuntuan itu.

• Platform team memiliki control plane, instalasi, upgrade, dan stabilitas OpenClaw secara keseluruhan.
• Tim aplikasi memiliki policy di namespace mereka sendiri, perilaku traffic service mereka, dan eksperimen routing.
• Tim keamanan memiliki standard dan kebijakan lintas tim, misalnya kebijakan default deny global.

Dokumentasi sebagai kontrak. Tulis di mana batasnya: siapa boleh mengubah policy apa, siapa yang memegang akses ke control plane, dan bagaimana insiden dilimpahkan. Kalau dua tim tidak setuju siapa pemilik sebuah policy, itu gejala dokumentasi yang hilang, bukan masalah teknis. Service ownership matrix yang jelas mencegah situasi "tidak ada yang merasa itu urusannya".

Support boundaries di CI/CD. Validasi dari episode 19 ikut menjaga batas ini. Gate yang mengharuskan approval dari pemilik service sebelum policy-nya diubah membuat perubahan tidak bisa lewat diam-diam, dan setiap tim bertanggung jawab atas policy miliknya sendiri.

RACI sebagai pelengkap. Selain siapa pemilik, tulis juga siapa yang bertanggung jawab mengeksekusi, siapa yang dikonsultasi, dan siapa yang hanya diinformasikan. Matriks RACI mencegah insiden berhenti di tengah jalan karena "semua orang setuju itu penting, tapi tidak ada yang merasa bertanggung jawab". Untuk OpenClaw, misalnya: platform team bertanggung jawab memulihkan control plane, tim aplikasi dimintai konsultasi saat policy mereka terdampak, dan manajemen cukup diinformasikan lewat laporan.

#Audit Rutin dan Compliance Reviews

Keamanan yang tidak pernah diperiksa membusuk pelan-pelan: policy yang tidak dipakai, izin yang makin longgar, exception yang lupa dihapus. Audit rutin mengubah pengabaian menjadi rutinitas.

kubectl get servicepolicies -o json | jq -r '.items[] |
  select(.spec.references == null) | .metadata.name'
openclawctl policy report --format markdown > audit-report.md

Audit bukan cuma menegur, tapi menghasilkan artefak. Laporan berisi daftar policy aktif, policy yang tidak pernah dipakai (recall episode 10 dan 11), siapa pemilik masing-masing, kapan terakhir diubah, dan apakah sesuai standard. Simpan laporan sebagai bukti compliance — auditor eksternal maupun review internal sama-sama butuh catatan yang bisa ditunjuk.

Jadwalkan audit berkala: review triwulanan terhadap policy yang longgar, review tahunan terhadap seluruh kebijakan. Setiap temuan punya pemilik dan tanggal jatuh tempo. Untuk cakupan menyeluruh, jalankan openclawctl policy audit --all-clusters — ia men-trigger audit lintas cluster dalam sekali jalan dan bisa dijadikan bagian dari pipeline bulanan.

Framework compliance seperti SOC 2 atau ISO 27001 menuntut bukti: siapa mengubah apa, kapan, dan bagaimana perubahan itu disetujui. Audit report yang rutin dihasilkan sekaligus menjadi artefak untuk auditor — tanpa proses yang berjalan, kalian akan sibuk mengumpulkan bukti di menit-menit terakhir. Kebiasaan audit berkala adalah investasi yang membayar dua kali: keamanan terjaga dan compliance tercatat.

#On-Call dan Incident Management

Runbook dan ownership tidak berguna kalau tidak ada yang menerima halaman saat alert berbunyi. On-call yang sehat memerlukan rotasi yang jelas, prosedur eskalasi, dan kebiasaan komunikasi yang terdokumentasi:

• Severity matrix — SEV1 (kontrol jaringan hilang), SEV2 (dampak sebagian), SEV3 (dampak kecil, bisa ditangani jam kerja). Setiap level punya waktu respons dan jalur eskalasi sendiri.
• Saluran komunikasi — satu channel incident untuk diskusi, satu status page untuk pengumuman, dan jangan biarkan laporan tercecer di chat pribadi.
• Game days — latih insiden buatan secara berkala, persis seperti game day recovery di episode 18. Runbook yang pernah dipraktikkan bekerja jauh lebih baik daripada runbook yang baru dibaca.

Eskalasi juga perlu bentuk tertulis, bukan sekadar "hubungi yang lebih senior". Definisi severity berikut bisa menjadi titik awal:

severity:
  SEV1:
    response: 15 menit
    escalate: "incident commander"
    channel: "#incident-sev1"
  SEV2:
    response: 60 menit
    escalate: "platform lead"
    channel: "#incident-sev2"
  SEV3:
    response: "jam kerja"
    escalate: "owning team"
    channel: "#openclaw-ops"

Jadikan prosedur eskalasi ini bagian dari onboarding on-call, bukan dokumen yang baru dibaca saat SEV1 menyala. On-call adalah peran yang dijalankan dengan persiapan, bukan keberanian.

Incident management yang baik bukan soal tidak pernah gagal, tapi soal gagal dengan proses: dokumentasikan apa yang terjadi, apa yang tidak berjalan, dan satu perbaikan yang akan dilakukan. Setiap insiden yang dikelola dengan baik membuat sistem berikutnya sedikit lebih kuat.

#Penutup

Pada episode 21, kalian melengkapi sisi manusia dan proses dari OpenClaw: runbook yang bisa diikuti siapa pun saat panic, ownership dan support boundaries yang menghapus kebuntuan antar tim, audit rutin yang menghasilkan artefak compliance, dan on-call dengan rotasi serta eskalasi yang jelas.

Inti yang harus dibawa pulang:

• Runbook yang baik adalah diagnosis dulu, tindakan kemudian — dan bisa diikuti tanpa konteks.
• Ownership yang jelas (platform, aplikasi, keamanan) mencegah insiden mengambang tanpa pemilik.
• Audit rutin harus menghasilkan laporan yang bisa ditunjuk sebagai bukti compliance.
• Severity matrix, channel incident, dan game day membuat on-call tidak membakar tim.
• Setiap insiden ditutup dengan postmortem dan satu perbaikan nyata.

Di episode 22 — episode terakhir seri ini — kalian merangkum semuanya: Production Hardening & Best Practices. Kalian akan menyusun security hardening checklist, membangun policy governance dan lifecycle management, serta menyiapkan long-term maintenance dan upgrade. Sampai jumpa!