Belajar System Engineer - Capacity & Lifecycle Management

#Pendahuluan

Episode 21 membangun layanan agar selalu hidup. Ada pertanyaan yang lebih strategis: berapa banyak kapasitas yang dibutuhkan — sekarang dan nanti? Terlalu kecil berarti down saat trafik naik; terlalu besar berarti uang terbuang. Episode 22 ini membahas capacity & lifecycle management: seni merencanakan sumber daya berdasarkan data, dan disiplin mengelola aset dari lahir sampai mati.

Mengapa episode ini penting? Karena sumber daya adalah biaya. Di data center maupun cloud, setiap CPU, RAM, dan disk yang menganggur adalah uang yang terbakar. System Engineer senior bukan yang paling banyak membeli server, melainkan yang paling tepat menghitung kebutuhannya — dan paling tegas mematikan yang tidak lagi dipakai.

#Capacity Planning: Ilmu, Bukan Tebakan

#Metrik yang Dipakai

Capacity planning dimulai dari pengamatan tren, bukan proyeksi yang dibuat-buat. Metrik yang perlu diukur:

Sumber data utama: Prometheus/Grafana (episode 10). Tanpa data historis, kapasitas hanyalah tebakan.

#Forecasting Sederhana

Metode paling praktis: gunakan linier trend dari data historis.

Pemakaian disk saat ini   : 60% dari 100 GB
Pertumbuhan per bulan     : 3% (dari data 6 bulan terakhir)
Proyeksi 12 bulan         : 60% + (3% x 12) = 96%
Keputusan                 : perluas ke 150 GB sebelum bulan ke-10

Di Grafana, buat query dengan predict_linear dari Prometheus untuk otomasi estimasi:

predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[1h], 30*24*3600) < 5e9

Alert di atas berbunyi ketika kapasitas diprediksi tinggal di bawah 5 GB dalam 30 hari — memberi waktu bertindak sebelum penuh.

#Right-Sizing

Right-sizing adalah mencocokkan kapasitas dengan kebutuhan nyata:

• Di cloud: pindah instance m5.2xlarge → m5.large jika pemakaian CPU konsisten rendah (episode 13).
• Di on-prem: kurangi alokasi RAM VM yang menganggur.
• Gunakan utilization report berkala (mingguan/bulanan) dari monitoring.

Untuk beban yang berfluktuasi, pertimbangkan autoscaling (cloud) atau jadwal naik-turun instance — membayar kapasitas puncak sepanjang waktu adalah pemborosan klasik.

#Decommission: Disiplin Mengakhiri

#Kenapa Decommission Penting

Server yang terlupakan terus membayar dan terus berisiko:

• Biaya: listrik, sewa cloud, lisensi, backup.
• Keamanan: patch yang tidak dirawat = sasaran empuk.
• Kompleksitas: aset ghost menyulitkan audit dan capacity planning.

#Prosedur yang Benar

Ikuti langkah dari episode 2, dengan penekanan untuk skala:

# 1. Verifikasi tidak ada trafik (cek monitoring beberapa minggu)
# 2. Backup terakhir data penting sesuai retention
# 3. Cabut integrasi: monitoring, backup, SSO, DNS
# 4. Matikan sumber daya
# 5. Update asset management + dokumentasi

Di cloud, jangan lupa sumber daya yang "tersembunyi": volume EBS yang terpisah, snapshot lama, IP elastis yang tidak dipakai. Cek berkala:

# Volume yang tidak terpasang (unattached) = biaya mubazir
aws ec2 describe-volumes --filters "Name=status,Values=available"
# Snapshot lama
aws ec2 describe-snapshots --owner-ids $(aws sts get-caller-identity --query Account --output text)

#Asset Management

Asset management adalah catatan lengkap semua aset infrastruktur: server, VM, perangkat jaringan, lisensi, dan cloud resources. Minimal harus berisi:

Praktik yang baik: inventory sebagai kode — generate dari cloud API (aws ec2 describe-instances) atau CMDB (NetBox, GLPI, atau spreadsheet yang dijaga). Prinsipnya sama: aset yang tidak tercatat tidak bisa dikelola.

#Praktik: Capacity Plan

Buat capacity plan 12 bulan untuk sebuah layanan:

# Capacity Plan
## 1. Beban saat ini (dari Prometheus)
   - CPU puncak 45%, memori 60%, disk 58%, bandwidth 30%
## 2. Tren 6 bulan
   - Pertumbuhan trafik +5%/bulan, data +3%/bulan
## 3. Proyeksi 12 bulan
   - CPU puncak ~90% (dari 45% + 5%/bulan)
   - Disk akan penuh di bulan ke-10
## 4. Tindakan
   - Q2: scale-out web ke 3 instance (autoscaling min 2 max 5)
   - Q3: perluas volume DB +100 GB
   - Terus pantau predict_linear; review setiap kuartal

#Kesalahan Umum

1. Capacity planning tanpa data historis — proyeksi mengarang.
2. Membeli kapasitas puncak sepanjang tahun — padahal puncak hanya 2 jam/hari.
3. Tidak pernah decommission — ghost server menguras biaya dan menambah risiko.
4. Lupa resource tersembunyi di cloud — volume, snapshot, IP yang tidak terpakai.
5. Asset tidak tercatat — auditor (episode 20) bertanya "berapa server yang kalian punya?" dan tidak ada yang bisa menjawab.

#Penutup

Inti yang harus dibawa pulang:

• Capacity planning berbasis data historis + trend; gunakan predict_linear untuk peringatan dini.
• Right-sizing dan autoscaling menghindari pemborosan kapasitas puncak.
• Decommission adalah disiplin: verifikasi → backup → cabut integrasi → matikan → catat.
• Asset management memastikan setiap aset tercatat, ber-owner, dan dalam siklus yang sehat.

Di episode 23 selanjutnya kita memasuki area yang sedang naik drastis: AI systems & GPU ops — mengelola server GPU, toolchain AI, dan inference. Sampai jumpa di episode 23!