Belajar Site Reliability Engineer - AI-assisted Operations

#Pendahuluan

Di episode 6 kalian belajar bahwa alert fatigue membunuh on-call: aturan statis yang salah-set menghasilkan terlalu banyak alarm palsu, dan aturan statis yang terlalu longgar membiarkan kegagalan nyata lewat. Masalahnya sederhana — sistem produksi tidak konstan. Traffic naik di pagi hari, turun di malam, melonjak saat event, dan mengecil saat weekend. Threshold statis tidak mengerti konteks itu; AI-assisted operations lahir untuk mengerti.

Episode 22 membahas tiga cara AI menolong SRE: anomaly detection (menemukan yang tidak biasa di data normal), auto-remediation (memperbaiki otomatis dengan aman), dan predictive scaling (menyiapkan kapasitas sebelum dibutuhkan) — lengkap dengan batas kepercayaan yang jujur terhadap model.

#Anomaly Detection: Menemukan Ketidaknormalan di Data yang Normal

Konsep inti: sistem punya baseline perilaku yang berubah seiring waktu. Anomaly detection mencari titik di mana perilaku menyimpang dari baseline untuk kondisi saat itu — bukan dari angka statis.

#Tiga Pendekatan Utama

Statistical / rule-based: z-score, moving average, standard deviation. Sederhana, bisa dijelaskan, jadi titik awal yang baik.
Time series / forecasting: ARIMA, Prophet, atau model deep learning memperkirakan "seharusnya berapa", lalu membandingkan dengan nilai nyata. Menangkap musiman (pola harian/mingguan) dengan baik.
Unsupervised clustering: mendeteksi kelompok perilaku abnormal tanpa label. Berguna saat tidak tahu bentuk anomali yang dicari.

#Trade-off yang Harus Diketahui

Anomaly detection yang sensitif menghasilkan false positive; yang longgar menghasilkan false negative. Perbedaan dengan alerting statis (episode 6): parameter model, bukan threshold manual, yang menentukan keseimbangan. Dan keunggulan terbesarnya — model menyesuaikan diri dengan perubahan musiman otomatis, sehingga beban tinggi yang normal di jam sibuk tidak lagi dibunyikan sebagai alarm.

Important

Model anomaly detection hanya sebaik data latih dan data baru yang ia lihat. Jika traffic berubah drastis karena fitur baru atau kampanye pemasaran, model butuh waktu menyesuaikan diri — periode di mana ia menghasilkan alarm palsu. Jangan deploy model "baru saja dilatih" langsung ke alerting produksi; beri periode observasi dan kalibrasi seperti yang kalian lakukan pada alert biasa di episode 6.

#Auto-remediation: Memperbaiki Tanpa Menunggu Manusia

Banyak insiden bersifat berulang dan mekanis — dan di episode 9 kalian belajar bahwa pekerjaan berulang adalah toil. Auto-remediation adalah otomasi respons terhadap insiden yang sudah dipahami, dengan satu prinsip yang tidak bisa ditawar: hanya apa yang bisa diverifikasi boleh diotomasi.

Tangga kematangan auto-remediation:

Deteksi + notifikasi otomatis (sudah kalian punya sejak episode 6).
Runbook otomatis dengan persetujuan: sistem menyarankan langkah, manusia menekan tombol. Aman untuk mulai.
Remediasi otomatis untuk kelas masalah yang jelas (restart pod yang crash-loop, expand disk yang penuh, hapus kunci lock yang basi) — dengan log penuh dan mudah di-revert.
Self-healing penuh hanya untuk kasus yang telah terbukti ribuan kali tanpa efek samping.

Aturan auto-remediation sederhana

rules:
  - name: restart-crashlooping-pod
    match:
      condition: pod crashloop backoff > 5 dalam 10m
      namespace: "!production-critical"   # pengecualian service paling penting
    action:
      restart: true
      require_approval: false
    guardrails:
      max_actions_per_hour: 3
      notify: "#oncall"

Perhatikan guardrails: batas jumlah aksi per jam, pengecualian untuk service kritis, dan notifikasi yang selalu menyala. Ini mengubah remediasi otomatis dari petualangan menjadi prosedur yang bisa dipertanggungjawabkan.

#Predictive Scaling: Kapasitas Sebelum Dibutuhkan

Autoscaling reaktif (episode 8) bekerja setelah metrik naik — dan metrik naik butuh waktu. Predictive scaling memakai forecast: "pukul 09.00 traffic selalu naik 3x, siapkan 30 instance di 08.30". Dengan data historis yang cukup, model memprediksi lonjakan sebelum terjadi, menghilangkan jeda antara lonjakan dan penambahan kapasitas.

Strategi gabungan yang umum: predictive sebagai basis, reaktif sebagai koreksi. Model menyiapkan perkiraan; autoscaling reaktif memperbaiki jika forecast meleset. Kombinasi ini lebih aman daripada mengandalkan salah satunya saja.

Contoh jadwal prediktif vs reaktif

08:30  prediktif: scale 10 -> 30 instance (ramalan lonjakan 09.00)
09:15  reaktif:  koreksi 30 -> 34 instance (forecast kurang sedikit)
10:00  prediktif: 34 -> 22 instance (ramalan turun)

Warning

Predictive scaling membawa satu bahaya tersembunyi: feedback loop. Jika forecast dipakai untuk menambah kapasitas yang lalu membuat metrik naik (karena lebih banyak request dilayani), model bisa belajar memperbesar dirinya sendiri. Pantau akurasi forecast sebagai metrik tersendiri, dan pasang batas maksimum yang tidak bisa dilampaui model — apa pun yang diprediksinya.

#Praktik: Membangun Anomaly Detection Pipeline

Bangun pipeline sederhana di lab dengan data metrik yang kalian miliki (misal metrik http_request_duration dari Prometheus):

Ekstrak data historis: query Prometheus 30 hari (misal per 5 menit) via API.
Latih model baseline: hitung moving average + standard deviation per jam-dalam-sehari (menangkap musiman tanpa library berat).
Deteksi: nilai di atas baseline + 3σ (3 standard deviation) adalah anomali.
Alert: kirim anomali sebagai alert terpisah (episode 6), bukan mencampur dengan alert statis.
Evaluasi: selama 2 minggu, bandingkan anomali terdeteksi vs insiden nyata; hitung precision & recall, lalu sesuaikan sensitivitas.

anomaly.py (contoh konsep)

import numpy as np
 
def detect(series, hour_means, hour_stds, z=3):
    anomalies = []
    for ts, value in series:
        h = ts.hour
        zscore = (value - hour_means[h]) / hour_stds[h]
        if zscore > z:
            anomalies.append((ts, value, zscore))
    return anomalies

Tip

Jangan mulai dari deep learning. Mulai dari statistik sederhana yang bisa dijelaskan (moving average + z-score) — ia cepat, transparan, dan cukup untuk sebagian besar kasus. Naikkan kompleksitas model hanya ketika bukti menunjukkan yang sederhana tidak memadai, bukan karena tren.

#Penutup

Pada episode 22 ini, kalian telah belajar menggandeng AI untuk mempercepat operasi — tanpa kehilangan kendali.

Inti yang harus dibawa pulang:

Anomaly detection memahami konteks musiman yang membuat alert statis buta.
Auto-remediation hanya untuk masalah yang bisa diverifikasi, dengan guardrails dan log.
Predictive scaling menyiapkan kapasitas sebelum dibutuhkan, dikoreksi oleh scaling reaktif.
AI adalah alat dengan batas kepercayaan yang jujur: model butuh kalibrasi, bisa salah, dan harus diukur akurasinya.
Mulai dari statistik yang bisa dijelaskan; naikkan kompleksitas hanya saat diperlukan.

Di episode 23 selanjutnya, objek yang dijaga akan berubah: reliability of ML/AI systems — model monitoring, drift detection, dan SLO untuk inference. Sampai jumpa di episode 23!