Hermes AIOps: Alert Harus Membawa Signal, Impact, dan Action

Banyak automation gagal bukan karena tidak punya AI.

Dia gagal karena terlalu cerewet.

Setiap error dikirim ke Telegram. Setiap warning dianggap penting. Setiap log merah berubah jadi notifikasi. Lama-lama manusia bukan merasa dibantu, tapi merasa dikejar-kejar sistem sendiri.

Menurutku, di sinilah Hermes menarik untuk dilihat sebagai operator AIOps, bukan sekadar bot yang bisa menjalankan command.

Hermes yang bagus tidak hanya bertanya ke model, memanggil tool, lalu mengirim pesan. Hermes harus membantu operasi menjadi lebih tenang: membaca sinyal, memahami dampak, menyarankan tindakan, lalu diam kalau memang tidak perlu bicara.

Format kecil yang paling masuk akal adalah ini:

Signal → Impact → Suggested action

Kalau sebuah alert tidak bisa menjawab tiga hal itu, kemungkinan besar alert tersebut belum matang.

Masalahnya bukan kurang alert

Kebanyakan sistem kecil sampai menengah tidak kekurangan alert.

Yang sering kurang adalah konteks.

Contoh alert yang technically benar tapi operasionalnya miskin:

Hermes gateway down.

Informasinya ada. Tapi manusia tetap harus mengecek banyak hal:

• gateway yang mana?
• sejak kapan mati?
• Telegram masih menerima pesan atau tidak?
• cron masih jalan atau ikut terganggu?
• ini crash sekali atau restart loop?
• service boleh direstart otomatis atau harus manual?
• log terakhir menunjukkan auth error, network issue, atau disk penuh?

Kalau semua pertanyaan itu masih harus dijawab manual, maka alert tersebut hanya memindahkan beban dari server ke kepala manusia.

Itu bukan AIOps.

Itu cuma noise dengan timestamp.

Hermes harus jadi triage layer

Hermes punya posisi yang menarik karena dia bisa duduk di antara monitoring tool dan manusia.

Monitoring tool melihat sinyal mentah:

• service mati,
• endpoint lambat,
• cron gagal,
• disk hampir penuh,
• model provider error,
• Telegram delivery gagal,
• backup terlalu lama tidak sukses.

Hermes bisa mengambil sinyal itu, lalu melakukan triage:

1. membaca log terakhir,
2. mengecek status service,
3. melihat impact ke channel atau workflow,
4. membedakan false alarm dan incident nyata,
5. menyarankan tindakan,
6. melakukan recovery kecil kalau sudah diberi izin,
7. memverifikasi hasilnya,
8. melaporkan secara ringkas.

Ini bukan berarti Hermes harus menggantikan monitoring stack seperti Uptime Kuma, Grafana, Sentry, cron watchdog, atau systemd timer.

Justru sebaliknya.

Hermes sebaiknya menjadi operator layer di atas tools itu.

Tool melihat angka. Hermes menjelaskan artinya.

Tool bilang merah. Hermes menjawab: merah ini bahaya, ganggu siapa, dan langkah berikutnya apa.

Format alert yang lebih dewasa

Alert yang berguna tidak harus panjang. Tapi dia harus membawa konteks.

Misalnya bukan begini:

Telegram delivery failed.

Lebih baik begini:

Signal:
Telegram delivery untuk Hermes gagal 6x sejak 08:42 WITA.

Impact:
User tetap bisa memicu job internal, tapi hasil tidak terkirim ke Telegram.
Reminder dan cron report berisiko gagal delivery.

Suggested action:
1. Cek gateway status.
2. Restart gateway jika process mati.
3. Jika tetap gagal, cek provider auth dan recent Telegram error log.

Perbedaannya besar.

Alert pertama membuat manusia bertanya.

Alert kedua membuat manusia bisa bertindak.

Dan kalau Hermes punya permission untuk tindakan aman, dia bisa lanjut:

Action taken:
Gateway restart executed.

Verification:
Telegram send test succeeded.

Status:
Recovered.

Ini baru automation yang terasa hidup.

Bukan karena dia dramatis. Justru karena dia mengurangi drama.

Fakta operasional vs inference

Ada batas penting yang harus dijaga oleh AIOps agent.

Hermes harus memisahkan mana fakta yang benar-benar dibaca dari sistem, dan mana dugaan yang disusun dari pola.

Contoh fakta operasional:

• service hermes-gateway inactive,
• disk /var 91%,
• cron daily-report terakhir sukses 26 jam lalu,
• log terakhir berisi 401 Unauthorized,
• endpoint /health timeout selama 3 menit,
• Telegram test message gagal dengan provider error.

Contoh inference:

• kemungkinan auth token expired,
• kemungkinan disk penuh membuat write gagal,
• kemungkinan provider sedang rate limit,
• kemungkinan issue hanya di delivery layer, bukan worker utama.

Dua hal ini tidak boleh dicampur.

Kalau Hermes menyebut dugaan sebagai fakta, manusia bisa mengambil keputusan yang salah. Kalau Hermes terlalu takut memberi inference, manusia tetap harus mikir dari nol.

Format yang sehat:

Facts:
- Gateway process active.
- Telegram delivery failed 6x.
- Provider response: 429 rate limit.

Inference:
Masalah kemungkinan ada di provider rate limit, bukan gateway crash.

Suggested action:
Pause non-urgent Telegram delivery 10 menit, retry dengan backoff, dan hanya alert manusia kalau masih gagal setelah retry window.

Itu lebih jujur.

Dan dalam operasi, kejujuran lebih penting daripada terdengar pintar.

Jangan semua error dikirim ke manusia

Ini bagian yang sering dilupakan.

AIOps yang baik bukan berarti semua hal menjadi real-time alert.

Kadang sistem cukup diam.

Kalau error kecil bisa retry otomatis dan berhasil, cukup catat di log. Kalau warning muncul sekali lalu hilang, tidak perlu membangunkan manusia. Kalau job non-kritis terlambat 2 menit tapi selesai sendiri, itu bukan incident.

Hermes harus punya aturan seperti:

• silent untuk issue kecil yang auto-recovered,
• log only untuk warning yang tidak berdampak,
• notify untuk masalah yang berdampak ke user atau workflow,
• ask approval untuk tindakan berisiko,
• escalate kalau recovery gagal atau impact membesar.

Ini membedakan operator system dari mesin notifikasi.

Mesin notifikasi ingin bicara terus.

Operator system tahu kapan harus diam.

Recovery otomatis harus kecil dan aman

Hermes bisa melakukan self-healing, tapi jangan kebablasan.

Recovery otomatis harus dimulai dari tindakan kecil yang reversible:

• restart service non-kritis,
• retry job dengan backoff,
• clear temporary lock file yang aman,
• rotate log yang sudah jelas membengkak,
• switch model provider fallback,
• kirim test message setelah gateway restart,
• disable sementara job yang spam error.

Tindakan yang lebih berisiko harus tetap minta approval:

• delete data,
• migrate database,
• edit config produksi,
• rotate credential,
• upgrade package besar,
• restart database utama,
• deploy ulang tanpa test.

Hermes yang bagus bukan agent yang berani melakukan semuanya.

Hermes yang bagus tahu batas.

Dan batas itu harus tertulis jelas di playbook, bukan diserahkan ke mood model AI hari itu.

Contoh playbook kecil untuk Hermes

Misalnya kita punya alert: gateway Telegram Hermes tidak merespons.

Playbook yang lebih masuk akal:

1. Detect
   - Check gateway process.
   - Check port / health endpoint.
   - Check last Telegram delivery error.

2. Diagnose
   - If process dead: service crash.
   - If process alive but delivery fails: provider/auth/network issue.
   - If disk >90%: storage issue may affect logs/session writes.

3. Act safely
   - Restart gateway only if process dead or health endpoint failed.
   - Do not edit config automatically.
   - Do not rotate tokens automatically.

4. Verify
   - Send Telegram test message.
   - Check health endpoint again.
   - Confirm no immediate restart loop.

5. Report
   - Signal.
   - Impact.
   - Action taken.
   - Verification result.
   - Next step if still failing.

Playbook seperti ini tidak glamour.

Tapi justru hal kecil seperti ini yang membuat automation bisa dipercaya.

Kenapa ini related ke Hermes

Hermes menarik bukan hanya karena dia bisa menjalankan tool.

Banyak agent bisa menjalankan tool.

Yang membuat Hermes relevan untuk AIOps adalah pola operatornya: punya memory, bisa menjalankan command, bisa mengikuti workflow, bisa memakai model berbeda untuk tugas berbeda, dan bisa dibuat punya guardrail operasional.

Dengan setup yang benar, Hermes bisa menjadi lapisan kerja harian untuk:

• membaca alert,
• mengurangi false alarm,
• menjelaskan dampak,
• menjalankan recovery aman,
• membuat ringkasan incident,
• mengingat pola masalah yang sering muncul,
• memperbaiki playbook dari pengalaman.

Tapi jangan salah.

Hermes bukan magic.

Kalau monitoring dasar tidak ada, log tidak rapi, permission terlalu luas, dan playbook tidak jelas, Hermes hanya akan menjadi agent yang bingung dengan akses terlalu besar.

Itu bahaya.

AIOps butuh AI, tapi lebih butuh disiplin operasional.

Operational takeaway

Kalau ingin memakai Hermes untuk AIOps, mulai dari hal paling sederhana.

Jangan mulai dari autonomous incident resolution yang terdengar keren.

Mulai dari alert yang lebih manusiawi:

Signal → Impact → Suggested action

Lalu tambah pelan-pelan:

1. fakta dan inference dipisah,
2. alert yang auto-recovered cukup masuk log,
3. action otomatis dibatasi ke tindakan kecil dan reversible,
4. setiap action wajib diverifikasi,
5. laporan ke manusia harus ringkas dan actionable,
6. playbook diperbaiki dari incident yang berulang.

Dengan pola ini, Hermes tidak menjadi mesin panik baru.

Dia menjadi operator yang membantu sistem lebih tenang.

Dan menurutku itulah definisi AIOps yang benar.

Bukan AI yang terlihat keren.

AI yang membuat manusia tidak perlu panik untuk hal-hal bodoh yang sebenarnya bisa ditangani sistem.