Lewati ke konten utama
Versi: 1.2

Langkah 7 — Monitoring & On-call via Chat

Langkah terakhir menutup loop: production melapor ke Telegram, agent melakukan investigasi pertama, dan kamu hanya turun tangan ketika keputusan manusia dibutuhkan. Di titik ini seluruh siklus — task → kode → review → deploy → operate — hidup di satu tempat: chat-mu.

Pasang tiga sinyal minimum

Operasi solo tidak butuh observability stack raksasa. Tiga sinyal cukup untuk mulai:

  1. Error trackingSentry (free tier cukup) atau padanannya: exception + stack trace + release yang memperkenalkannya.
  2. Uptime check — ping endpoint /health tiap menit (UptimeRobot/Better Stack/cron sederhana).
  3. Log terpusat yang bisa di-query dari CLI — minimal journalctl/docker logs di servermu, atau platform log kalau sudah ada.

Checkpoint: matikan aplikasi staging-mu 2 menit — alert uptime datang; lempar exception uji — muncul di error tracker dengan stack trace.

Arahkan semua alert ke Telegram

Telegram bot API bisa dipanggil dengan satu curl — hampir semua tool monitoring punya webhook, tinggal dijembatani:

# pola dasar yang dipakai semua integrasi
curl -s "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage" \
-d chat_id="$ALLOWED_CHAT_ID" \
-d text="🔴 [prod] Error rate naik: $DETAIL"
  • Sentry → Settings → Integrations → Webhooks (atau Telegram integration siap pakai).
  • UptimeRobot/Better Stack → alert contact tipe webhook/Telegram.
  • CI gagal di main → step if: failure() yang memanggil curl di atas.

Pakai satu chat/channel khusus untuk alert, terpisah dari chat perintah — supaya riwayat insiden bersih dan bisa dibaca ulang.

Checkpoint: ketiga sumber (error, uptime, CI) terbukti sampai di Telegram — uji ketiganya, jangan diasumsikan.

Jadikan agent responder pertama

Saat alert masuk, refleksmu berubah dari "buka laptop" menjadi "forward ke agent". Dengan gateway dari Langkah 3, teruskan alert ke agent dengan instruksi standar:

Investigasi alert ini. Yang boleh: baca log, baca kode, query error tracker,
cek release terakhir (gh). Yang TIDAK boleh: mengubah production.
Laporkan: (1) apa yang terjadi, (2) sejak kapan / release mana,
(3) dugaan penyebab + bukti, (4) rekomendasi: rollback / fix forward / observasi.

Beri agent akses read-only yang dibutuhkan: sentry-cli atau API token read-only, akses log (ssh terbatas atau log platform CLI), dan gh untuk melihat deploy terakhir. Jalur OpenClaw/Hermes bisa mengotomatiskan ini penuh — alert webhook → agent langsung investigasi → laporan muncul di bawah alert-nya, sebelum kamu sempat membuka HP.

Keputusannya tetap milikmu, dan biasanya tinggal satu kata dari Langkah 6: rollback (agent/kamu eksekusi) atau fix forward (jadi task baru → worktree → PR → siklus normal).

Checkpoint: satu insiden (boleh disimulasikan: deploy bug kecil ke staging) tertangani penuh dari HP — alert → laporan investigasi agent → keputusan → resolusi.

Post-mortem ditulis agent, disetujui manusia

Setelah insiden nyata selesai, minta agent menulis post-mortem singkat dari riwayat chat + log:

Tulis post-mortem insiden tadi ke docs/postmortems/YYYY-MM-DD-<slug>.md:
timeline, akar masalah, dampak, apa yang berjalan baik, dan 1–3 action item
konkret. Tanpa menyalahkan. Buka PR.

Action item post-mortem masuk backlog seperti task biasa — dan yang terbaik di antaranya biasanya berupa guardrail baru: aturan AGENTS.md, test regresi, alert baru, atau item baru di gerbang manusia.

Checkpoint: minimal satu post-mortem ter-merge di repo, dan action item-nya benar-benar dikerjakan (bukan sekadar ditulis).

Rutinitas operasional mingguan

Sistem ini butuh satu ritual manusia agar tidak diam-diam membusuk — 30 menit tiap minggu:

  • Baca ringkasan minggu (boleh disiapkan agent): PR merged, insiden, biaya API/model, error rate.
  • Retro kebocoran review (Langkah 5) dan evaluasi gerbang manusia (Langkah 6).
  • Pangkas: worktree yatim, branch mati, aturan AGENTS.md yang tidak lagi relevan.

Otomasi ringkasan mingguan dan pekerjaan terjadwal lainnya dibahas di Automation Lanjutan.

Checkpoint: ritual mingguan sudah terjadi ≥ 2 kali berturut-turut. Kalau ya — selamat: kamu sedang menjalankan team engineering berisi satu manusia. Playbook selesai; dari sini lanjut ke Automation Lanjutan.