Belajar Data Center Engineer - Capacity & Utilization Mgmt

#Pendahuluan

Setelah di episode 11 kita membangun disiplin maintenance dan operasi, sekarang kita belajar menjawab pertanyaan yang selalu diajukan manajemen: "masih muat berapa lagi?" — dan pertanyaan yang lebih berbahaya: "kapan kita kehabisan?". Capacity management adalah seni menjawab keduanya dengan angka, bukan firasat.

Kesalahan kapasitas punya dua wajah sama buruknya: kehabisan (proyek bisnis tertahan) atau kebanyakan (aset menganggur, capex terbuang, PUE jelek). Episode ini menyusun kerangka lima dimensi kapasitas, kebijakan headroom, konsep stranded capacity, dan praktik membuat capacity model otomatis dari data NetBox.

#Lima Dimensi Kapasitas

Kapasitas DC bukan satu angka — ia lima dimensi yang saling mengikat:

Kunci pentingnya: kapasitas efektif = dimensi paling ketat. Rack bisa punya 10U kosong tapi power feed sudah 85% — maka kapasitas nyatanya nol. Menjawab "masih ada tempat" hanya dari jumlah U adalah kesalahan klasik pemula.

#Utilization vs Capacity

Bedakan dua istilah ini sejak awal:

Utilization : pemakaian SAAT INI (misal PDU A menarik 4.1 kW)
Capacity    : batas aman jangka panjang (misal 5.6 kW aturan 80%)
Headroom    : Capacity - Utilization = 1.5 kW

#Kebijakan Headroom dan Trigger

Tanpa kebijakan tertulis, tiap orang punya versi sendiri tentang "masih cukup". Kebijakan minimal yang layak diadopsi:

thresholds:
  warning_utilization: 0.70      # mulai rencana tambah kapasitas
  deploy_block: 0.85             # instalasi baru butuh approval
  critical_utilization: 0.90     # eskalasi manajemen, mitigasi
lead_time:
  new_rack_install: "2 minggu"
  ups_capacity_upgrade: "3 bulan"
  chiller_upgrade: "6-9 bulan"

Logika lead time itulah alasan threshold warning ada di 70%: upgrade chiller bisa butuh sembilan bulan — alarm di 90% berarti kalian sudah telat setahun.

#Stranded Capacity: Kapasitas Hantu

Stranded capacity adalah kapasitas yang secara teori ada tapi tak bisa dipakai. Penyebab umumnya:

• Server single-corded menumpuk di satu feed → feed A penuh, feed B kosong; total tampak 50% tapi tak bisa diterima beban baru.
• Perangkat lama low-density menduduki rack high-density → banyak U terpakai untuk sedikit watt.
• VLAN/port tercatat dipakai tapi device-nya sudah lama dibongkar.
• Replikasi disk thin-provisioned yang tidak pernah direclaim.

Obatnya konsisten: audit dual-cording (ep.3), refresh/consolidation (ep.16), rekonsiliasi CMDB-vs-reality berkala, dan space reclamation rutin.

#Praktik: Capacity Model dari Data NetBox

Sekarang bangun modelnya. Data struktur ada di NetBox (rack, device, power feed); data kondisi ada di monitoring/PDU. Skrip Python berikut menggabungkan keduanya — hitung utilisasi power per rack dan tandai status:

import requests
 
NETBOX = "http://localhost:8000/api"
TOKEN = "0123456789abcdef0123456789abcdef01234567"
HEADERS = {"Authorization": f"Token {TOKEN}"}
RACK_LIMIT_KW = {"R01": 5.6, "R02": 5.6}   # dari desain ep.3
BLOCK = 0.85
 
def get_racks():
    r = requests.get(f"{NETBOX}/dcim/racks/", headers=HEADERS, timeout=10)
    return r.json()["results"]
 
def get_power_usage(rack_name):
    """Ambil kW real-time dari API PDU/monitoring - stub lab."""
    return {"R01": 3.9, "R02": 4.8}.get(rack_name, 0)
 
for rack in get_racks():
    name = rack["name"]
    used = get_power_usage(name)
    limit = RACK_LIMIT_KW.get(name, 0)
    if not limit:
        continue
    ratio = used / limit
    status = "OK" if ratio < 0.7 else \
             "PLAN" if ratio < BLOCK else "BLOCKED"
    print(f"{name}: {used:.1f}/{limit} kW "
          f"({ratio:.0%}) -> {status}")

Jalankan dan baca outputnya:

pip3 install requests
python3 script/capacity-report.py

R01: 3.9/5.6 kW (70%) -> PLAN
R02: 4.8/5.6 kW (86%) -> BLOCKED

Interpretasi langsung: R02 menolak instalasi baru tanpa approval; R01 masuk periode perencanaan. Laporan inilah yang kalian kirim bulanan — dan karena datanya dari sistem, tidak ada debat subjektif.

Tambahkan dimensi lain dengan pola sama: u_used/u_height untuk space (NetBox menyediakannya), port count dari interface API, dan bobot dari device type weight. Model lengkap pertama kalian cukup spreadsheet + formula; otomasi Python menyusul saat datanya rapi.

#Forecasting: Proyeksi ke Depan

Capacity report memberi potret; forecasting memberi film. Metode paling pragmatis: tren linier dari historis:

Pertumbuhan R01 6 bulan terakhir: 3.1 -> 3.9 kW (±133 W/bulan)
Sisa headroom                    : 5.6 - 3.9 = 1.7 kW
Proyeksi habis                   : 1.7 / 0.133 ≈ 13 bulan
Keputusan                        : ajukan upgrade feed Q1 tahun depan

Angka proyeksi tidak perlu sempurna — ia perlu cukup baik untuk memulai pengadaan tepat waktu. Kalikan dengan skenario (agresif/moderat/konservatif) dan sajikan ketiganya.

#Common Pitfalls Capacity Management

• Mengukur sekali lalu tidur — kapasitas itu fungsi waktu; report harus regenerasi otomatis (cron bulanan).
• Lupa dimensi cooling — power feed besar tapi CRAH zona sudah max = kapasitas nyata tetap nol.
• CMDB basi — model secanggih apa pun salah jika datanya usang; rekonsiliasi fisik vs NetBox masuk PM kuartalan (ep.11).
• Headroom dihitung dari nama, bukan metering — "PDU 32A berarti 32A" mengabaikan derating 80%; selalu pakai angka aman.

#Penutup

Inti yang harus dibawa pulang:

• Kapasitas DC lima dimensi: space, power, cooling, network, bobot — yang mengikat adalah paling ketat.
• Bedakan utilization, capacity, dan headroom; tetapkan threshold 70/85/90% sebagai kebijakan tertulis.
• Stranded capacity menjelaskan kenapa "tampak ada" tapi "nyatanya nol" — audit dan reclaim berkala.
• Capacity model otomatis dari NetBox + metering mengubah debat menjadi angka; forecasting tren memicu pengadaan tepat waktu.

Di episode 13 selanjutnya kita siapkan payung terakhir fasilitas: backup & disaster recovery — RTO/RPO sebagai bahasa kontrak, strategi replikasi sync vs async beserta batas jaraknya, pola failover active-passive dan active-active, serta praktik DR plan yang benar-benar pernah diuji. Sampai jumpa di episode 13!