Belajar Site Reliability Engineer - Capacity Planning

#Pendahuluan

Setelah di episode 7 kita belajar menangani insiden, kini kita beralih ke kemampuan yang membuat insiden tidak perlu terjadi: capacity planning. Kegagalan kapasitas punya ciri khas yang menipu: sistem tidak error di satu titik, melainkan melambat perlahan di bawah beban yang terus tumbuh — dan saat kita sadar, sudah telat.

Ini keterampilan yang membedakan SRE sejati dari sekadar "orang yang memantau CPU". Capacity planning bukan tentang menambah mesin saat dashboard merah, melainkan menjawab pertanyaan di waktu tenang: berapa kapasitas yang kita butuhkan 3 bulan lagi? Di mana titik patahnya? Berapa banyak headroom yang kita mau bayar? Episode ini membangun jawaban sistematisnya.

#Load Forecasting: Membaca Masa Depan dari Data

#Pola Beban

Sebelum memprediksi, kenali dulu bentuk beban. Beberapa pola dasar:

#Ekstrapolasi dari Metrik

Teknik paling sederhana yang tetap berguna: ambil metrik penggunaan (CPU, koneksi DB, bandwidth) dalam 90 hari, hitung tren, proyeksikan ke 90 hari berikutnya. Contoh kasar dengan PromQL:

predict_linear(node_cpu_seconds_total[2h], 14*24*3600)

predict_linear menghitung regresi linier dari data 2 jam lalu memproyeksikannya 14 hari ke depan. Kasar, tapi cukup untuk menjawab "kapan kita kehabisan?". Untuk akurasi lebih, gabungkan dengan data seasonality (hari vs malam, hari kerja vs libur).

#Headroom: Ruang Bernapas yang Sadar Biaya

Headroom adalah kelebihan kapasitas di atas kebutuhan — dan ia punya harga. Menentukan jumlah headroom berarti menjawab: berapa cepat kita bisa menambah kapasitas saat dibutuhkan?

Rumus intuitifnya:

• Bila provisioning lambat (minggu untuk tambah server) → butuh headroom besar.
• Bila auto-scaling hidup dan cepat (menit) → headroom bisa kecil, karena mesin baru muncul segera.
• Bila kegagalan satu node memindahkan beban ke node lain → headroom harus menutup penurunan kapasitas, bukan hanya pertumbuhan.

Praktik yang sehat: definisikan target utilization per resource. Contoh kebijakan:

Target ini bukan "berapa yang dipakai", melainkan "berapa yang tersisa sebelum berbahaya" — perbedaan sudut pandang yang menandai SRE.

#Strategi Scaling: Vertical vs Horizontal

#Vertical Scaling (Scale Up)

Menambah resource satu mesin: CPU, RAM, disk. Kelebihan: sederhana, tidak mengubah arsitektur, dan beberapa workload (database single-node) memang butuh ini. Kekurangan: ada batas fisik mesin, titik tunggal kegagalan tetap ada, dan menambah mesin besar sering lebih mahal per unit daripada menambah banyak mesin kecil.

#Horizontal Scaling (Scale Out)

Menambah jumlah instance: dari 2 menjadi 5 pod/replica. Kelebihan: skala hampir tak terbatas, resilience (satu node mati tidak melumpuhkan), dan pembelian fleksibel di cloud. Kekurangan: butuh desain stateless (atau sesi bersama di Redis/DB), dan setiap lapis baru (load balancer, koneksi DB) punya batasnya sendiri.

#Aturan Praktis

1. Stateless workload → horizontal scaling adalah pilihan default.
2. Database & stateful → vertikal dulu untuk menghindari komplikasi, lalu sharding/replication saat benar-benar butuh.
3. Kombinasi: mulai dari jumlah instance yang benar (headroom), baru perbesar instance type bila perlu.

#Auto-Scaling: Pengaman, Bukan Pengganti

Auto-scaling (HPA di Kubernetes, ASG di cloud) menjawab variabilitas beban jangka pendek. Kesalahan paling umum: mengandalkannya sebagai perencana utama, sehingga kapasitas di-budget "sesedikit mungkin" dan cluster dibiarkan mengejar ekor beban.

Kenyataannya, auto-scaling selalu tertinggal sedikit (butuh waktu untuk menambah instance) dan sering bereaksi terlambat pada ledakan mendadak. Kombinasi yang benar:

• Baseline planning (perencanaan kuartalan) menetapkan jumlah minimum yang mencukupi.
• Auto-scaling menangani fluktuasi di sekitar baseline.
• Surge protection (buffer/rate limiting) menahan lonjakan yang melebihi kapasitas terbesar sekalipun.

#Praktik: Rencana Kapasitas & Scaling

Terapkan pada service demo:

1. Ukur — pastikan Prometheus punya metrik utilization (container_cpu, container_memory) untuk semua pod.
2. Proyeksikan — query predict_linear 14 hari, catat kapan utilization menyentuh target 70%.
3. Tetapkan baseline — jumlah replica minimum berdasarkan proyeksi, bukan berdasarkan "yang sekarang terpasang".
4. Pasang auto-scaling sebagai lapis kedua:

HPA untuk service demo

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: demo-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo
  minReplicas: 3
  maxReplicas: 12
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65

5. Dokumentasikan keputusan — target utilization, alasan headroom, dan review bulanan, semua di repo (ini menjadi bagian dari reliability-as-code di episode 14).

#Penutup

Pada episode 8 ini, kalian telah mengubah capacity planning dari tebakan menjadi proses.

Inti yang harus dibawa pulang:

• Forecast dari metrik: kenali pola beban, proyeksikan dengan predict_linear atau model sederhana.
• Headroom adalah biaya sadar: kaitkan dengan kecepatan provisioning dan risiko failover.
• Vertical untuk stateful, horizontal untuk stateless; kombinasi keduanya untuk hasil terbaik.
• Auto-scaling adalah pengaman, bukan pengganti perencanaan — dan waspadai thrashing.
• Dokumentasikan keputusan kapasitas sebagai artefak yang direview berkala.

Di episode 9 selanjutnya, kita akan membereskan musuh paling diam-diam dari SRE: toil — cara mengidentifikasi pekerjaan manual yang menggerogoti tim, mengotomasinya secara bertahap, dan menjaga agar tim tidak kembali tenggelam. Sampai jumpa di episode 9!