Runbook Membaca Sinyal Rilis: Dashboard, Log, dan Keputusan Rollback

Runbook membaca sinyal rilis membantu tim backend dan DevOps menjawab satu pertanyaan operasional: setelah deployment, apakah perubahan ini aman untuk diteruskan? Jawabannya tidak boleh hanya bergantung pada satu grafik CPU atau satu pesan error. Tim perlu membaca dashboard, log, trace, dan metrik bisnis dengan sengaja: memahami baseline sebelum rilis, mencari perubahan yang bertepatan dengan waktu deploy, lalu menguji apakah perubahan tersebut benar-benar disebabkan oleh rilis.

Tujuannya bukan membuat rollback menjadi respons otomatis terhadap setiap anomali. Rollback adalah tindakan pengurangan risiko yang berguna, tetapi dapat memiliki konsekuensi pada kompatibilitas skema, data yang sudah diproses, atau kontrak antarlayanan. Runbook yang baik memberi jalur keputusan yang jelas: lanjutkan rollout, tahan rollout, rollback, atau lakukan mitigasi terbatas sambil mengumpulkan bukti.

1. Siapkan Baseline Sebelum Rilis

Sinyal pascarilis hanya bermakna jika ada pembanding. Baseline adalah kondisi layanan sebelum perubahan, diukur pada konteks yang sebanding: jam operasional, pola trafik, wilayah, jenis klien, dan volume pekerjaan asinkron. Membandingkan trafik pukul 09.00 hari kerja dengan pukul 02.00 akhir pekan dapat menghasilkan kesimpulan yang salah.

Data baseline minimum

• Traffic: request per detik, throughput job queue, atau jumlah transaksi.
• Error rate: rasio respons gagal terhadap total request, termasuk pemisahan kode 4xx dan 5xx bila relevan.
• Latency: p50 untuk pengalaman umum serta p95/p99 untuk ekor lambat yang sering menunjukkan bottleneck.
• Saturation: utilisasi resource yang membatasi, misalnya connection pool database, queue lag, worker aktif, CPU throttling, atau ruang disk.
• Sinyal bisnis: checkout berhasil, pembayaran terotorisasi, order dibuat, pengguna berhasil login, atau pekerjaan domain selesai.
• Dependensi: error dan latency database, cache, message broker, gateway pembayaran, atau API pihak ketiga.

Simpan snapshot baseline di tiket rilis atau dashboard rilis. Catat juga kondisi yang dapat mengubah interpretasi, seperti kampanye pemasaran, pekerjaan backfill, insiden pada dependensi, atau perubahan konfigurasi yang dirilis bersamaan.

Prinsip pembacaan: jangan hanya bertanya “apakah metrik merah?”. Tanyakan “apa yang berubah dibanding kondisi normal, sejak kapan berubah, siapa yang terkena, dan apakah waktunya selaras dengan deploy?”

Label rilis yang aman untuk korelasi

Setiap instance aplikasi sebaiknya mengetahui identitas build atau rilisnya, misalnya release=2025-03-08.2. Identitas tersebut dapat dipasang sebagai anotasi deploy pada dashboard, atribut resource pada trace, dan field pada log. Pada metrik, gunakan label rilis dengan hati-hati: nilai label harus terbatas dan berumur pendek agar tidak menimbulkan cardinality tinggi. Jangan menjadikan request ID, user ID, atau URL mentah sebagai label metrik.

2. Baca Dashboard dengan Golden Signals dan Dampak Bisnis

Golden signals memberi urutan pemeriksaan yang konsisten. Empat sinyal klasik—traffic, errors, latency, dan saturation—tidak menggantikan metrik bisnis, tetapi membantu membedakan masalah aplikasi, kapasitas, dan perilaku pengguna.

Traffic: apakah volume atau komposisi request berubah?

Periksa total traffic dan distribusinya per endpoint, metode HTTP, region, tenant, atau versi klien bila tersedia. Kenaikan error rate dapat terlihat besar ketika denominator traffic kecil. Sebaliknya, error rate total yang tampak stabil dapat menyembunyikan kegagalan pada endpoint kritis dengan volume kecil, seperti endpoint pembayaran atau aktivasi akun.

Error rate per endpoint, bukan hanya agregat layanan

Gunakan rasio error pada endpoint yang sudah dinormalisasi, misalnya /orders/:id, bukan path mentah seperti /orders/12345. Bedakan setidaknya:

• 5xx: kegagalan yang umumnya menjadi tanggung jawab layanan atau dependensinya.
• 4xx: dapat menunjukkan regresi kontrak API, validasi terlalu ketat, token kedaluwarsa, atau klien yang belum kompatibel; jangan otomatis mengabaikannya.
• Error domain: misalnya pembayaran ditolak, stok habis, atau kuota terlampaui. Ini mungkin respons HTTP sukses tetapi tetap berdampak pada bisnis.

Contoh query PromQL berikut bersifat ilustratif; sesuaikan nama metrik dan label dengan instrumentasi Anda.

sum by (route, release) (
  rate(http_server_requests_total{service="checkout",status=~"5.."}[5m])
)
/
sum by (route, release) (
  rate(http_server_requests_total{service="checkout"}[5m])
)

Baca hasilnya bersama jumlah request. Sebuah endpoint dengan dua kegagalan dari sepuluh request perlu investigasi, tetapi tingkat keyakinannya berbeda dari ribuan kegagalan pada traffic tinggi.

Latency: lihat distribusi dan jalur kritis

Periksa p95 atau p99 per endpoint kritis, bukan hanya rata-rata. Rata-rata dapat tetap rendah ketika sebagian kecil pengguna mengalami timeout panjang. Bandingkan latency aplikasi dengan latency dependensi: jika database atau API eksternal melambat pada waktu yang sama, rilis aplikasi belum tentu penyebab utama.

Untuk operasi asinkron, latency pengguna mungkin tidak tampak pada request HTTP. Tambahkan metrik seperti usia pesan tertua, queue lag, durasi job, retry rate, dead-letter queue, dan tingkat job berhasil.

Saturation: cari resource yang menjadi batas

Saturation menjawab mengapa latency dan error meningkat. Contohnya adalah pool koneksi database yang habis, worker queue penuh, replica database tertinggal, atau CPU yang mengalami throttling. Kenaikan CPU saja belum cukup untuk rollback; korelasikan dengan latency, error, serta perubahan jumlah instance dan traffic.

Bandingkan perubahan bisnis

Rilis bisa sehat secara teknis tetapi merusak alur bisnis. Bandingkan conversion funnel dan hasil domain sebelum serta sesudah rilis. Contoh: request POST /checkout tetap 2xx, tetapi jumlah order berstatus dibuat turun karena validasi baru mengembalikan respons sukses dengan status bisnis gagal. Metrik teknis perlu dipasangkan dengan metrik hasil, seperti checkout_started, payment_authorized, dan order_created.

3. Konfirmasi dengan Log Terstruktur dan Trace

Dashboard menunjukkan apa yang berubah. Log dan trace membantu menjawab di mana serta mengapa perubahan terjadi. Jangan memulai investigasi dengan pencarian log tanpa hipotesis; gunakan lonjakan endpoint, rentang waktu, release ID, dan trace ID dari dashboard sebagai titik masuk.

Format log yang dapat dicari

Log terstruktur dalam JSON memudahkan filter dan agregasi. Field minimum yang berguna adalah timestamp, severity, service, release, request ID atau trace ID, route, status code, durasi, serta nama error. Hindari memasukkan password, token, nomor kartu, alamat lengkap, atau data pribadi lain ke log.

{
  "timestamp": "2025-03-08T10:17:32.481Z",
  "level": "error",
  "service": "checkout-api",
  "release": "2025-03-08.2",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "route": "POST /checkout",
  "status_code": 500,
  "duration_ms": 842,
  "error_type": "DatabaseTimeout",
  "dependency": "orders-db"
}

Jika logger mendukung context per request, tetapkan field yang sama pada awal request sehingga semua event terkait dapat dikorelasikan. Pastikan route sudah dinormalisasi dan error memiliki klasifikasi stabil; pesan exception mentah sering berubah dan buruk untuk agregasi.

Gunakan trace untuk mengisolasi dependensi

Pilih trace dari request lambat atau gagal pada rilis baru, lalu bandingkan dengan trace rilis sebelumnya untuk endpoint yang sama. Cari span yang dominan, retry berulang, timeout, query database yang bertambah, atau panggilan ke dependensi baru. Trace juga berguna untuk membedakan regresi lokal dari masalah dependensi bersama.

• Jika span aplikasi baru bertambah sebelum query database, periksa serialisasi, validasi, atau algoritme baru.
• Jika waktu habis pada span database dan pool koneksi penuh, periksa query, indeks, transaksi panjang, dan kapasitas pool.
• Jika timeout berasal dari API eksternal, cek status dependensi, retry policy, timeout, dan circuit breaker sebelum menyimpulkan deploy sebagai penyebab.

Sampling trace dapat membuat insiden bertraffic rendah sulit dilihat. Untuk operasi kritis, gunakan sampling yang mempertahankan trace error dan trace lambat, dengan kebijakan privasi dan biaya penyimpanan yang jelas.

4. Runbook Keputusan Rollout, Tahan, Rollback, atau Mitigasi

Jalankan pemeriksaan ini setelah canary atau batch rollout, lalu ulangi pada interval yang disepakati tim. Ambang angka harus berasal dari SLO, error budget, dan risiko layanan Anda; jangan menyalin angka generik dari layanan lain.

1. Tandai waktu dan identitas deploy. Pastikan dashboard, log, dan trace dapat difilter berdasarkan release.
2. Bandingkan dengan baseline yang relevan. Periksa golden signals dan metrik bisnis pada endpoint atau workflow kritis.
3. Validasi korelasi. Apakah perubahan dimulai setelah canary? Apakah hanya instance rilis baru yang terdampak? Apakah dependensi juga mengalami masalah?
4. Nilai blast radius. Tentukan pengguna, endpoint, region, tenant, dan transaksi bisnis yang terkena.
5. Pilih tindakan terkecil yang aman. Hentikan ekspansi rollout sebelum melakukan tindakan yang lebih luas.
6. Verifikasi pemulihan. Setelah tindakan, tunggu metrik kembali mendekati baseline dan periksa backlog, retry, serta dampak bisnis tertunda.

Rollback bukan selalu langkah pertama. Jika rilis memuat migrasi database, perubahan format event, atau perubahan kontrak API, rollback biner dapat gagal atau memperburuk keadaan. Karena itu, rancang migrasi secara backward-compatible, gunakan pola expand/contract, dan siapkan prosedur pemulihan data terpisah. Jangan menghapus kolom, mengganti makna field event, atau memaksa klien memakai kontrak baru dalam rilis yang sama tanpa masa kompatibilitas.

5. Contoh Timeline Insiden Singkat

Berikut contoh bagaimana runbook diterapkan tanpa menyimpulkan terlalu cepat.

1. 10.00: Rilis 2025-03-08.2 masuk ke 10% instance checkout.
2. 10.05: Dashboard menunjukkan p95 POST /checkout naik pada instance rilis baru. Error 5xx belum meningkat secara material.
3. 10.08: Trace menunjukkan waktu tambahan berada pada span query penyimpanan order. Log menampilkan DatabaseTimeout pada request lambat.
4. 10.10: Metrik pool koneksi database mendekati batas dan queue retry mulai bertambah. Metrik pembayaran tetap normal.
5. 10.12: Tim menahan rollout. Setelah membandingkan perubahan kode, ditemukan query baru dijalankan di jalur checkout untuk setiap request.
6. 10.16: Karena checkout adalah alur kritis dan latency terus meningkat, tim rollback aplikasi sambil mempertahankan migrasi yang backward-compatible.
7. 10.22: p95, pool koneksi, dan queue retry kembali mendekati baseline. Tim memeriksa ulang order yang diproses selama periode insiden.

Poin penting pada contoh ini adalah urutannya: amati, korelasikan, batasi rollout, pilih tindakan, lalu verifikasi. Lonjakan latency saja tidak langsung dianggap sebagai bukti; trace, log, dan saturation memperkuat diagnosis.

6. Operasionalisasi: Dashboard per Rilis dan Pencegahan

Dashboard khusus rilis

Buat dashboard rilis yang menjawab pertanyaan keputusan dalam satu tempat, bukan dashboard umum yang memaksa operator berpindah-pindah. Sertakan anotasi deploy, filter service/release/region, golden signals, top endpoint error, latency per route, saturation, status dependensi, queue, dan satu atau dua metrik bisnis utama. Tampilkan perbandingan rilis baru terhadap rilis sebelumnya bila platform observabilitas mendukungnya.

Alert dengan konteks deploy

Alert sebaiknya menyertakan service, environment, route atau workflow terdampak, nilai saat ini, tautan dashboard, dan deploy terbaru. Alert yang hanya berbunyi “CPU tinggi” memindahkan beban diagnosis kepada on-call. Hindari membuat alert khusus untuk setiap fluktuasi kecil; gunakan alert yang terkait dengan dampak pengguna, SLO, atau risiko kapasitas.

Feature flag dan rollout bertahap

Feature flag memungkinkan mitigasi lebih sempit daripada rollback penuh, terutama untuk perubahan perilaku yang dapat dipisahkan dari kode dasar. Namun flag juga menambah state dan kombinasi pengujian. Tetapkan pemilik, tanggal evaluasi atau penghapusan, default yang aman, serta audit perubahan flag. Untuk rollout bertahap, definisikan ukuran batch, durasi observasi, metrik evaluasi, dan kondisi berhenti sebelum deploy dimulai.

Latihan rollback

Rollback yang belum pernah dilatih sering gagal saat dibutuhkan. Uji prosedur di lingkungan nonproduksi dan, bila aman, melalui game day terkontrol. Verifikasi bahwa artefak versi sebelumnya masih tersedia, konfigurasi dapat dikembalikan, migrasi kompatibel, cache atau queue ditangani, dan akses operator tidak menjadi hambatan. Catat waktu pemulihan dan langkah manual yang perlu dihilangkan.

7. Template Catatan Postmortem Ringan

Setelah stabil, buat catatan singkat untuk meningkatkan sistem, bukan mencari kesalahan individu. Gunakan bahasa yang menjelaskan kondisi dan keputusan berdasarkan bukti.

Judul: Regresi latency checkout pada rilis 2025-03-08.2

Ringkasan:
- Dampak pengguna dan bisnis:
- Periode insiden:
- Layanan, endpoint, atau workflow terdampak:

Timeline:
- Waktu deploy:
- Sinyal pertama:
- Keputusan tahan/mitigasi/rollback:
- Waktu pemulihan terverifikasi:

Bukti:
- Perubahan baseline pada traffic, error, latency, saturation:
- Temuan log dan trace:
- Dependensi atau kondisi eksternal yang diperiksa:

Faktor sistem:
- Perubahan teknis yang berkontribusi:
- Guardrail yang tidak ada atau tidak cukup:

Tindak lanjut:
- Perbaikan kode atau konfigurasi:
- Perbaikan dashboard/alert/runbook:
- Pengujian atau latihan yang perlu ditambahkan:
- Pemilik tindakan dan target waktu:

Hasil akhir runbook bukan sekadar keputusan rollback. Hasil yang lebih penting adalah kemampuan tim untuk membaca bukti secara konsisten, membatasi blast radius lebih cepat, dan mengubah temuan insiden menjadi guardrail pada rilis berikutnya.