Seorang asisten berbasis AI menangani tugas on-call saya selama tujuh hari, memproses 11 peringatan dan memangkas waktu rata-rata saya untuk memperbaiki masalah dari 45 menit menjadi 20 menit. Eksperimen ini penting karena model bahasa dengan cakupan moderat dapat menghemat setengah jam dalam respons insiden, namun tetap memerlukan pengawasan manusia yang ketat.

Mengapa saya menugaskan AI untuk on-call

Tim cloud menghabiskan sebagian besar shift mereka untuk memeriksa log, mengecek deployment terbaru, dan memastikan bahwa permintaan penskalaan aman. Tugas-tugas "membosankan" tersebut bersifat berulang, padat data, dan rentan terhadap kelelahan manusia. Kemajuan terbaru dalam large language model menjanjikan otomatisasi pada pekerjaan pencocokan pola seperti itu, tetapi sebagian besar demo publik berjalan di lingkungan sandbox. Saya ingin melihat apakah hype tersebut bertahan dalam klaster kelas produksi yang benar-benar melayani pelanggan berbayar.

Pengaturan pengujian

  • Akses – Agen dapat membaca setiap metrik, log, dan definisi deployment. Ia hanya dapat menulis ke whitelist yang sempit: memulai ulang pod, menambah jumlah replika, atau menskalakan deployment. Segala sesuatu di luar tindakan tersebut memerlukan persetujuan eksplisit dari saya.
  • Peran – Saya memperlakukan model tersebut sebagai insinyur junior pada shift on-call pertamanya. Ia menerima peringatan, menjalankan analisisnya, dan mengirimkan rekomendasi di saluran insiden.
  • Jaring pengaman – Semua tindakan tulis dibatasi oleh perintah manual "ya/tidak". Saya juga membatasi penggunaan token model agar biaya tetap dapat diprediksi.

Di mana AI menunjukkan keunggulannya

Kecepatan agen adalah peningkatan yang paling nyata. Segera setelah peringatan muncul, ia mengambil log yang relevan, memplot metrik terbaru, dan mencantumkan tiga deployment terakhir. Pada saat saya membuka laptop, investigasi awal sudah selesai dilakukan. Dari 11 peringatan:

  • 8 adalah masalah rutin (lonjakan memori, restart kontainer, kesalahan konfigurasi sederhana). AI berhasil mengidentifikasi akar masalah setiap saat.
  • Ia menandai peningkatan memori secara bertahap pada sebuah microservice sebelum masalah tersebut berkembang menjadi gangguan (outage) pada jam 2 pagi, memberikan kesempatan bagi tim untuk melakukan intervensi lebih dini.
  • Konsumsi token selama seminggu penuh tetap berada di sekitar $30, jauh di dalam anggaran on-call tipikal jika dibatasi.

Hasil ini menghasilkan pengurangan yang terukur pada mean time to resolution (MTTR) dari 45 menit menjadi 20 menit, sehingga membebaskan engineer untuk fokus pada pekerjaan yang berdampak lebih tinggi.

Di mana ia mengalami kendala

Kepercayaan diri tidak sama dengan kebenaran. AI salah dengan penuh percaya diri pada 3 dari 11 peringatan:

  1. Ia menyalahkan deployment kode terbaru atas kegagalan konektivitas database, padahal penjelasan tersebut salah.
  2. Saat menghadapi anomali jaringan yang tidak dikenal, ia menawarkan perbaikan generik yang tidak menyelesaikan masalah mendasar.
  3. Selama peringatan terkait beban (load), ia menyarankan penskalaan layanan dari 3 menjadi 30 replika. Masalahnya bukan pada beban, melainkan pada konfigurasi yang buruk.

Karena guardrails saya memerlukan persetujuan manual untuk setiap operasi tulis, kesalahan model dapat tertangkap sebelum menyebabkan kerusakan. Namun, episode ini menyoroti risiko inti: model dapat menghasilkan rekomendasi yang terdengar masuk akal tetapi tidak akurat, terutama untuk masalah baru.

Manajemen biaya dan risiko

Tagihan token sebesar $30 menunjukkan bahwa menjalankan LLM dalam loop produksi bisa murah jika penggunaannya dipantau. Namun, biaya sebenarnya adalah risiko operasional. Salah menskalakan deployment dapat menyebabkan pengeluaran cloud yang tidak terkendali, dan melakukan rollback pada rilis yang bagus dapat mengikis kepercayaan pelanggan. Eksperimen ini memperkuat dua langkah pengamanan:

  • Pembatasan tindakan (Action gating) – Hanya izinkan model untuk memberi saran, jangan pernah membiarkannya mengeksekusi perubahan berdampak tinggi tanpa klik manual dari manusia.
  • Batas anggaran (Budget caps) – Tetapkan batas keras pada konsumsi token dan beri peringatan kepada tim saat model mendekati batas tersebut.

Apa yang perlu diperhatikan selanjutnya

Hingga saat itu, tim sebaiknya:

  • Memantau proporsi saran buatan AI yang memerlukan intervensi manual.
  • Mengukur dampak pada MTTR di berbagai kategori insiden (rutin vs. baru).
  • Menguji model di lingkungan staging dengan peringatan sintetis sebelum memberikan hak tulis produksi apa pun.

Pelajaran bagi tim ops

  • Otomatiskan 80% tugas yang membosankan – Gunakan AI untuk agregasi log, korelasi metrik, dan pembuatan hipotesis awal.
  • Sisihkan 20% yang berisiko untuk manusia – Penskalaan di luar ambang batas moderat, rollback, dan penghapusan harus tetap melalui langkah persetujuan manual.
  • Anggap model sebagai mitra, bukan pengganti – Seorang engineer yang memahami sistem dapat memvalidasi output AI lebih cepat daripada pendatang baru, mengubah asisten ini menjadi sebuah force multiplier.

Agen AI belum bisa menjalankan operasi cloud sendirian, tetapi sebagai mitra triase, ia sudah memberikan peningkatan kecepatan yang nyata. Kuncinya adalah menjaga tingkat kepercayaan tetap terkendali, menerapkan batasan yang ketat, dan membiarkan model menangani pekerjaan kasar yang berulang sementara keahlian manusia mengarahkan keputusan-keputusan kritis.