Belajar Performance Test Engineer - Performance & Compliance SLO

#Pendahuluan

Setelah di episode 19 kita memahami security dalam load testing, kini saatnya membahas komponen yang menghubungkan performa teknis dengan keputusan bisnis: Service Level Objectives (SLO). SLO adalah kontrak antara tim engineering dan stakeholders tentang kualitas performa yang dijanjikan — dan performance testing adalah cara memvalidasi apakah kontrak itu dipenuhi.

Tanpa SLO yang jelas, performance testing kehilangan arah — "apakah 200ms itu bagus?" tidak bisa dijawab tanpa konteks SLO. Episode ini membawa kalian memahami cara mendefinisikan, mengukur, dan melaporkan SLO.

#SLO, SLA, dan SLI

#Perbedaan Konsep

Konsep	Deskripsi	Contoh
SLI (Service Level Indicator)	Metrik yang diukur	p95 latency, error rate
SLO (Service Level Objective)	Target internal	p95 ≤ 300ms
SLA (Service Level Agreement)	Kontrak eksternal	99.9% uptime, penalty jika gagal

#Hubungan Antar Konsep

SLI adalah angka aktual dari monitoring. SLO adalah target internal yang harus dipenuhi. SLA adalah komitmen ke customer — biasanya lebih longgar dari SLO untuk memberikan buffer.

plaintext

SLI (aktual): p95 = 250ms
SLO (target): p95 ≤ 300ms → TERCAPAI
SLA (kontrak): p95 ≤ 500ms → TERCAPAI

#Mendefinisikan SLO

#Langkah-langkah

Pahami user experience: apa yang user harapkan?
Baseline performance: berapa performa saat ini?
Tentukan target: SLO harus challenging tetapi achievable
Tentukan window: per-bulan? per-kuartal?
Dokumentasikan: tulis secara formal dan komunikasikan

#Contoh SLO Document

plaintext

Service: E-commerce API
Measurement Window: 30 days rolling
 
Availability SLO:
- Target: 99.95% successful requests
- SLI: rate(http_requests_total{status!~"5.."}[30d])
- Error Budget: 0.05% = 21.6 menit downtime per bulan
 
Performance SLO:
- Target: p95 latency ≤ 300ms untuk GET /products
- Target: p95 latency ≤ 1000ms untuk POST /checkout
- SLI: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
 
Throughput SLO:
- Target: melayani 1000 RPS sustained during peak hours
- SLI: rate(http_requests_total[5m])

#Sinyal yang Realistis

SLO harus berdasarkan data, bukan harapan. Jalankan baseline performance test untuk memahami performa saat ini, lalu tentukan SLO yang achievable dengan optimasi yang wajar.

#Error Budget

#Konsep Error Budget

Error budget = 100% - SLO%. Jika SLO = 99.9%, error budget = 0.1%. Ini berarti sistem boleh mengalami 0.1% kegagalan sebelum ada konsekuensi.

#Menghitung Error Budget

plaintext

Error Budget = (1 - SLO) × Total Requests
 
Contoh:
- SLO: 99.9%
- Total requests per bulan: 10,000,000
- Error budget: 0.001 × 10,000,000 = 10,000 requests
- Atau dalam waktu: 0.001 × 30 hari × 24 jam × 60 menit = 43.2 menit

#Error Budget Policies

Ketika error budget habis:

Freeze new feature deployment
Prioritaskan reliability work
Post-mortem untuk incident yang menghabiskan budget
Investigasi root cause

#Performance Testing dengan SLO

#Thresholds Berdasarkan SLO

javascript

// k6: thresholds yang align dengan SLO
export const options = {
  thresholds: {
    'http_req_duration{endpoint:products}': ['p(95)<300'],  // SLO: p95 ≤ 300ms
    'http_req_duration{endpoint:checkout}': ['p(99)<1000'],  // SLO: p99 ≤ 1000ms
    'http_req_failed': ['rate<0.001'],  // SLO: error rate < 0.1%
  },
};

#SLO Validation Test

javascript

// k6: test khusus untuk validasi SLO
export const options = {
  vus: 100,
  duration: '10m',  // Long enough untuk representatif
  thresholds: {
    http_req_duration: ['p(95)<300', 'p(99)<500', 'p(999)<1000'],
  },
};
 
export default function () {
  const res = http.get('https://api.example.com/products');
  check(res, {
    'meets SLO: status 200': (r) => r.status === 200,
  });
}

#Reporting untuk Stakeholder

#Laporan Teknis

Untuk tim engineering:

Metrik SLO: SLI aktual vs target
Error budget consumption: berapa yang tersisa
Trend: apakah performa membaik atau memburuk
Rekomendasi: optimasi yang dibutuhkan

#Laporan Bisnis

Untuk stakeholder non-technical:

Uptime percentage: "99.97% uptime bulan ini"
User impact: "0.03% user mengalami error"
Business impact: " estimated revenue loss dari downtime"
Improvement: "p95 latency turun 15% dari bulan lalu"

#Dashboard Grafana

Buat dashboard yang menampilkan:

promql

# SLO Dashboard
# Availability
1 - (rate(http_requests_total{status=~"5.."}[30d]) / rate(http_requests_total[30d]))
 
# Error budget remaining
1 - (rate(http_requests_total{status=~"5.."}[30d]) / rate(http_requests_total[30d])) / 0.001
 
# p95 Latency
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

#Compliance dan Audit

#Compliance Requirements

Beberapa industri punya compliance requirements untuk performa:

PCI DSS: payment processing harus memenuhi latency tertentu
HIPAA: healthcare systems harus available 24/7
SOC 2: availability dan performance monitoring wajib

#Audit Trail

Simpan hasil performance test untuk audit:

bash

# Simpan hasil test dengan metadata
k6 run --out json=results-$(date +%Y%m%d).json script.js
git add results-$(date +%Y%m%d).json
git commit -m "chore: performance test results $(date +%Y-%m-%d)"

#Penutup

Di episode 20 ini kalian telah memahami performance & compliance SLO:

SLO/SLA/SLI: konsep dasar dan perbedaannya.
Error budget: konsep yang menghubungkan performa dengan keputusan bisnis.
Testing dengan SLO: thresholds yang align dengan target.
Reporting: laporan teknis dan bisnis.
Compliance: audit trail dan requirements industri.

Di episode 21 selanjutnya, kita akan membahas Performance Engineering (Shift-Left) — bagaimana memasukkan performa sejak design phase, bukan hanya saat testing. Siapkan architecture review kalian!