Belajar Site Reliability Engineer - Cost-aware Reliability

#Pendahuluan

SLO ditepati, insiden terkendali, dan semua proses berjalan — lalu datang invoice cloud yang membuat manajemen bertanya dengan nada berbeda: "apakah semuanya ini harus semahal itu?" Di episode 16 kalian menaikkan duplikasi untuk DR. Redundansi memang menambah reliability, tetapi juga menambah biaya secara langsung. Jika hubungan keduanya tidak dikelola, tim SRE akan terus meminta lebih banyak sumber daya, sementara manajemen terus memotongnya — tanpa pernah ada bahasa yang sama.

Cost-aware reliability menyediakan bahasa itu: biaya diperlakukan sebagai metrik operasional yang diukur, dialokasikan, dan dipertukarkan secara eksplisit dengan reliability. Episode 17 membahas FinOps, right-sizing, dan kerangka trade-off yang membuat keputusan "berapa mahal" menjadi keputusan bersama yang bisa dipertanggungjawabkan.

#FinOps: Biaya sebagai Metrik Operasional

FinOps adalah disiplin mengelola biaya cloud seperti metrik lain: diukur, di-monitor, dan dipertanggungjawabkan. Tiga pilar utamanya adalah Inform (biaya terlihat dan dialokasikan ke pemilik), Optimize (keputusan mengurangi biaya tanpa melukai tujuan bisnis), dan Operate (evaluasi kontinu untuk menjaga pengeluaran tetap selaras).

Yang membedakan FinOps dari sekadar "berhemat" adalah akuntabilitas: setiap tim tahu berapa biaya yang mereka hasilkan. Tanpa alokasi biaya, tidak ada pemilik — dan tanpa pemilik, tidak ada keputusan yang bisa dibuat.

#Metrik yang Harus Dipantau

• Cost per unit of traffic: biaya dibagi jumlah request, bukan total absolut — metrik yang bisa dibandingkan antar rilis.
• Cost per SLO: berapa rupiah yang dibayar untuk satu poin persentase ketersediaan.
• Waste: resource yang terpakai kurang dari 20% dalam 7 hari terakhir — kandidat utama right-sizing.
• Unit economics per environment: biaya production vs staging vs dev (dev yang menganggur adalah pemborosan paling umum).

#Right-sizing: Menghentikan Pemborosan Diam-diam

Mayoritas instance cloud terpasang dengan kapasitas yang jauh di atas kebutuhan. Right-sizing adalah menyelaraskan kapasitas dengan beban nyata — tanpa menunggu episode 8-nya, karena right-sizing adalah kapasitas dalam skala kecil.

Langkah praktisnya:

1. Ukur pemanfaatan riil selama 30 hari: CPU, memory, throughput I/O — jangan pakai angka vendor.
2. Turunkan bertahap: turunkan satu level instance, amati SLO dan error budget (episode 4) selama 1-2 minggu.
3. Otomasi: gunakan workload yang bisa naik-turun otomatis (episode 8 & 10) alih-alih mengunci kapasitas.
4. Rutin: lakukan audit kuartalan — kebutuhan berubah, ukuran yang diatur sekali tidak pernah tetap benar.

Service         Instance      Utilisasi  Rekomendasi     Hemat
checkout-api    t3.2xlarge    12% CPU    t3.large        -62%/bln
billing-worker  m5.xlarge     78% mem    tetap + HPA     -
search-cache    r6g.xlarge    9% mem     cachegroup kecil -58%/bln

#Kerangka Trade-off: Biaya vs Ketersediaan

Pertanyaan "berapa mahal reliability-nya?" sering dijawab dengan dua sikap ekstrem: tanpa batas (semua harus HA) atau tanpa peduli (yang penting hemat). Keduanya salah. Yang benar adalah trade-off eksplisit yang dihitung per metrik:

#Harga Satu Poin Ketersediaan

Ubah reliability menjadi angka yang bisa dibandingkan: berapa biaya untuk naik dari 99% ke 99.9%? Tambahan 0.9% ketersediaan mungkin memerlukan replikasi multi-AZ, DR active-passive, dan SLA vendor — biaya bisa 2-3 kali lipat. Pertanyaan berikutnya adalah bisnis: apakah nilai 0.9% tersebut melebihi biayanya?

#Error Budget sebagai Batas Pengeluaran

Error budget (episode 4) menjadi alat yang elegan untuk menahan biaya: selama budget belum habis, kapasitas ekstra adalah kemewahan yang bisa ditunda. Budget yang habis justru menjadi justification untuk menambah kapasitas tanpa perang argumen — datanya sudah bicara.

#Menghindari Overtime Ganda

Satu pola yang haram dalam cost-aware reliability: membayar dua kali — over-provision untuk memenuhi SLO, lalu membayar juga untuk layanan yang menganggur. Kombinasi autoscaling yang sehat (naik-turun mengikuti beban) dengan SLO yang terukur menghentikan pola ini.

#Praktik: Optimasi Cost Tanpa Mengorbankan SLO

Terapkan siklus pada satu service lab:

1. Tetapkan baseline biaya & SLO: catat cost/bulan, p95 latency, dan availability 30 hari.
2. Audit right-sizing: 30 hari metrik utilasi; tandai instance di bawah 20% atau di atas 85%.
3. Turunkan instance yang jelas mubazir, dan naikkan batas autoscaling untuk yang rawan.
4. Terapkan FinOps tagging: beri tag biaya per service (cost:checkout) agar alokasi terlihat.
5. Pantau error budget 2 minggu: pastikan penghematan tidak membuat budget meledak.

resource "aws_instance" "app" {
  instance_type = "t3.large"
  tags = {
    cost = "checkout"
    sla  = "p95-500ms"
  }
}

#Penutup

Pada episode 17 ini, kalian telah belajar memperlakukan biaya sebagai metrik, bukan kutukan.

Inti yang harus dibawa pulang:

• FinOps: biaya diukur, dialokasikan ke pemilik, dan dioptimasi berkelanjutan.
• Right-sizing adalah siklus rutin, bukan proyek sekali jalan.
• Trade-off biaya vs ketersediaan dihitung per poin SLO dan diatur oleh error budget.
• Setiap penghematan dibuktikan dengan SLO yang tidak melanggar — bukan dengan asumsi.

Di episode 18 selanjutnya, kita akan turun ke lapisan yang menghubungkan semua service: network reliability — DNS, TLS, CDN, load balancer, hingga service mesh, dan cara mengukur SLO jaringan. Sampai jumpa di episode 18!