Belajar DevOps Engineer - AI-assisted Operations (AIOps)

#Pendahuluan

Setiap sistem yang kalian bangun — observability, alerting, pipeline, GitOps — menghasilkan data dalam jumlah besar dan alert yang semakin banyak. Pada 2026, AI tidak lagi menjadi fitur masa depan di operasional; ia sudah dipakai untuk mengurangi noise alert, mempercepat triase, menulis perbaikan, dan menemukan akar masalah. AIOps adalah penerapan AI/ML pada operasi IT.

Namun AIOps juga penuh kesalahpahaman. AI bukan pengganti engineer yang mengerti sistem, melainkan multiplier: ia bekerja paling baik pada sistem yang sudah terukur, terotomasi, dan terinstrumentasi dengan baik. Episode ini membahas tiga area penerapan AIOps — deteksi insiden, auto-remediation, dan pendamping pipeline — plus cara mempraktikkannya tanpa mengorbankan keandalan.

#Deteksi dan Triase: Menjinakkan Alert Fatigue

Masalah pertama yang diselesaikan AIOps adalah volume alert. Tim yang menerima 200 alert per hari pada akhirnya mengabaikan semuanya (episode 11: alert fatigue). AI membantu dalam dua cara:

1. Anomaly detection — model belajar dari data metrics historis dan menandai penyimpangan dari baseline normal, bukan sekadar threshold statis. Serangan traffic yang naik 30% dalam 10 menit terdeteksi sebagai anomali sebelum threshold "naik 5x" tercapai.
2. Alert correlation — banyaknya alert yang berasal dari satu akar masalah (misal satu node down men-trigger 50 alert) dikelompokkan menjadi satu insiden. Engineer membaca satu masalah, bukan lima puluh gejalanya.

Alat-alatnya: penyedia observability modern (Grafana, Datadog, Dynatrace) kini menyertakan deteksi anomali dan AI triase sebagai fitur standar. Triase modern juga memanfaatkan LLM: alert digabungkan dengan konteks (deployment terakhir, perubahan config, log terkait) dan dirangkum menjadi insiden yang bisa dibaca manusia.

BEFORE: 47 alert terpisah (CPU, latency, 5xx, error log...)
AFTER:  1 insiden — "deploy v1.4.0 ke prod (12:03) menaikkan
        error rate pada service billing sejak 12:05; deploy terakhir
        berisi perubahan query DB" + link ke runbook + rollout status

#Auto-Remediation: Perbaikan dengan Guardrail

Auto-remediation adalah menjalankan perbaikan secara otomatis: restart Pod yang crash-looping, menaikkan replica saat autoscaling terlambat, memutar secret yang bocor. AI membantu memilih remediasi yang tepat dari runbook, lalu mengeksekusinya dengan aman.

Prinsip yang tidak bisa ditawar:

• Human-in-the-loop untuk aksi berisiko tinggi (failover, drop traffic, hapus data).
• Guardrail — remediasi berjalan dalam batas yang ditentukan (nama service tertentu, jam tertentu, dengan approval gate).
• Kegagalan yang aman — jika remediasi tidak bekerja, sistem harus jatuh ke posisi aman, bukan membuat keadaan lebih buruk.

remediation:
  condition:
    metric: http_error_rate
    threshold: 0.15
    duration: 10m
  actions:
    - rollback: last_good_release       # kembalikan ke rilis yang sehat
  guardrails:
    allowed_services: [billing, auth]
    max_failures_per_day: 3
    require_approval: true

#AI Coding Assistant dalam Pipeline

AI juga masuk ke dalam cara software dibangun dan dirilis:

• Code review otomatis — PR di-scan untuk menemukan bug, celah keamanan, dan gaya kode sebelum review manusia.
• Ringkasan PR dan commit — dif yang panjang dirangkum menjadi konteks yang bisa dipahami reviewer.
• Menulis tes — dari perubahan kode, AI menyarankan unit test dan test case tepi.
• Membuat commit message dan changelog — konsisten dengan Conventional Commits.
• Deteksi kesalahan konfigurasi — manifest Kubernetes dan pipeline yang aneh bisa ditandai sebelum diterapkan.

git diff | ai review                    # tinjau perubahan sebelum commit
ai generate-test --file src/billing.ts  # usulkan unit test
ai explain-failure --log trace.json     # analisis kegagalan dengan konteks

Ini memperpendek feedback loop dari episode 21 — tetapi hasilnya tetap wajib diverifikasi manusia; AI yang mengoreksi kode bisa menghasilkan solusi yang terlihat benar dan berbahaya.

#Praktik: AI-Assisted Troubleshooting

Alur troubleshooting yang bisa kalian tiru — AI sebagai analis, manusia sebagai pengambil keputusan:

1. Kumpulkan konteks — alert, log terkait, deployment history, perubahan config terakhir.
2. Biarkan AI menyusun hipotesis — beri data mentah, minta daftar kemungkinan akar masalah dengan bukti pendukung.
3. Verifikasi secara mandiri — cek hipotesis dengan query dan perintah nyata; jangan percaya bulat.
4. Ambil tindakan dengan runbook — remediasi mengikuti prosedur yang teruji, bukan saran improvisasi AI.
5. Beri umpan balik — catat apa yang benar dan salah; model/tool menjadi lebih baik seiring data.

$ ai explain "error rate billing naik 25% sejak 12:05, deploy v1.4.0 jam 12:03"
Hipotesis utama: perubahan query pada billing-service (PR #4821)
  memicu full table scan. Bukti: query latency 98th pct naik 6x
  sejak deploy; log menunjukkan "seq scan" pada tabel transactions.
Verifikasi: `kubectl logs deploy/billing --since=1h | grep seqscan`
Rekomendasi: rollback v1.4.0 ke v1.3.2 (rollback teruji), lalu
  tambahkan index; lengkapi dengan load test (episode 25).

#Pitfall Umum

• Mengotomasikan remediasi untuk masalah yang belum dipahami — resep downtime.
• Percaya output AI tanpa verifikasi — AI membuat jawaban yang meyakinkan dan salah; verifikasi selalu.
• AI di atas sistem yang tidak terukur — tanpa observability yang baik (episode 11), AI hanya menggoreng data yang tidak lengkap.
• Memasukkan data sensitif ke tool AI — log bisa memuat data pengguna; pastikan redaksi dan kebijakan sebelum memasukkan ke model.
• Mengukur AI dari jumlah alert "tertutup" — ukur dampak: MTTR turun? Lead time turun? Uptime naik?

#Penutup

Inti yang harus dibawa pulang:

• AIOps = AI untuk deteksi, triase, remediasi, dan pengembangan — multiplier, bukan pengganti.
• Alert correlation + anomaly detection mengubah 50 alert menjadi 1 insiden yang bisa dibaca.
• Auto-remediation wajib punya guardrail, human-in-the-loop untuk aksi berisiko, dan kegagalan yang aman.
• AI coding assistant mempercepat review dan perbaikan, tetapi hasilnya tetap diverifikasi manusia.

Di episode 24 selanjutnya kita membahas Multi-Cloud & Hybrid — abstraksi cloud-agnostic, portabilitas workload, dan strategi hybrid yang seimbang antara fleksibilitas dan kompleksitas.