Modul 12Term 4 · Operasional produksi11 item poster

Observability dan SRE

Masuk untuk menyimpan progres Anda di semua perangkat. Sampai saat itu, progres disimpan di browser ini.

Mengapa ini penting

Jika pelanggan memberi tahu Anda ada yang rusak sebelum alert Anda berbunyi, Anda tidak punya monitoring, Anda punya pelanggan yang mengerjakan QA. Observability juga yang membuat kode tulisan AI bisa di-debug: ketika bukan Anda yang menulis kodenya, Anda butuh sistem yang memberi tahu apa yang sedang dikerjakannya.

Capaian pembelajaran

  1. Menghasilkan log, metrik, dan trace yang terstruktur dengan OpenTelemetry.
  2. Mendefinisikan SLI dan SLO yang mencerminkan kepuasan pengguna, serta memakai error budget.
  3. Menulis alert yang bisa ditindaklanjuti dan tidak menimbulkan kelelahan.
  4. Membangun dashboard untuk empat golden signal.
  5. Mengamati perilaku, biaya, dan kualitas LLM serta agen.

Materi

12.1 Tiga sinyal (58 sampai 61, 66)

  • Log (59): JSON terstruktur, satu event per baris, dengan request_id, user_id/tenant_id (bukan PII), level, event, durasi. Jangan pernah mencatat secret, token, password, nomor kartu lengkap, atau data pribadi mentah. Tetapkan masa retensi.
  • Metrik (61): time series numerik yang murah. RED untuk service (Rate, Errors, Duration); USE untuk resource (Utilisation, Saturation, Errors).
  • Trace (60): satu request diikuti melintasi service, queue, dan panggilan LLM, lengkap dengan span dan waktunya. Teruskan trace context melalui queue dan webhook.
  • Monitoring (58) mengawasi mode kegagalan yang sudah diketahui. Observability (66) memungkinkan Anda mengajukan pertanyaan baru ke sistem yang sedang berjalan tanpa merilis kode baru. Anda butuh keduanya.
  • Gunakan OpenTelemetry agar Anda tidak terkunci pada satu vendor.

12.2 Empat golden signal

Latensi, traffic, error, saturasi (dari praktik SRE Google). Satu dashboard per service, di bagian paling atas halaman.

12.3 SLI, SLO, dan error budget (63, 64, 65)

  • SLI (64): rasio terukur dari event yang baik: "request yang berhasil dilayani dalam waktu di bawah 500 ms / total request."
  • SLO (63): target untuk SLI dalam suatu rentang waktu: "99.9% selama 28 hari."
  • Error budget (65): kegagalan yang diizinkan: 0.1% dari 28 hari kira-kira 40 menit. Budget masih tersisa: rilis dengan leluasa. Budget habis: perlambat dan perbaiki reliabilitas.
  • Pilih SLO per perjalanan pengguna (login, checkout, jawaban AI), bukan per server. 100% adalah target yang salah: biayanya tak terjangkau dan menghentikan semua perubahan.

12.4 Alert (62)

  • Panggil (page) manusia hanya ketika pengguna sedang dirugikan sekarang atau sebentar lagi (berbasis gejala), bukan di setiap lonjakan CPU.
  • Utamakan burn-rate alert pada SLO (burn cepat memicu page, burn lambat membuat tiket).
  • Setiap alert terhubung ke runbook: apa artinya, cara mengeceknya, cara memitigasinya.
  • Alert bisnis juga: nol pendaftaran dalam satu jam, turunnya tingkat keberhasilan pembayaran, lonjakan pengeluaran LLM, DLQ yang membengkak, heartbeat cron yang terlewat.
  • Tinjau kebisingan alert setiap bulan; hapus alert yang tidak pernah ditindaklanjuti siapa pun.

12.5 Health check dan probe (56, 57)

Lihat 07 · Pola Resiliensi. Tambahkan synthetic monitoring eksternal atas perjalanan pengguna yang nyata dari beberapa region.

12.6 Observability LLM dan agen

Lacak setiap panggilan model: model, versi, versi prompt, token masuk/keluar, biaya, latensi (time to first token dan total), pemanggilan tool, sumber retrieval, feedback pengguna, dan skor eval. Tool: Langfuse, Helicone, Braintrust, atau konvensi OpenTelemetry GenAI ke backend yang sudah Anda miliki. Waspadai pergeseran kualitas setelah perubahan model atau prompt.

12.7 Error tracking dan RUM

Pelacakan exception dengan source map dan tag rilis (Sentry atau yang setara). Real-user monitoring untuk Core Web Vitals.

Lab 12: Tahu lebih dulu dari mereka

  1. Instrumentasikan aplikasi dengan OpenTelemetry (log, metrik, trace) dari ujung ke ujung, termasuk satu lompatan queue dan satu panggilan LLM.
  2. Definisikan 3 SLO untuk perjalanan kritis; bangun dashboard dan burn-rate alert-nya.
  3. Tulis runbook untuk setiap alert.
  4. Rusak sesuatu di staging; ukur waktu dari kerusakan sampai alert.
  5. Bangun panel biaya dan kualitas LLM.

Definition of Done

Paket prompt AI

  • "Tambahkan instrumentasi OpenTelemetry ke service ini. Teruskan context melalui queue. Tambahkan span di sekitar setiap panggilan LLM dan tool dengan atribut token dan biaya."
  • "Audit pemanggilan logging kita dan tandai yang berpotensi mencatat secret, token, atau data pribadi."