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.
Operasi solo tidak butuh observability stack raksasa. Tiga sinyal cukup untuk mulai:
- Error tracking — Sentry (free tier cukup) atau padanannya: exception + stack trace + release yang memperkenalkannya.
- Uptime check — ping endpoint
/healthtiap menit (UptimeRobot/Better Stack/cron sederhana). - Log terpusat yang bisa di-query dari CLI — minimal
journalctl/docker logsdi 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.
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.
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.
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).
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.