SRE: SLO, SLA & Error Budget Explained

Site Reliability Engineering, atau SRE, adalah disiplin yang menjembatani rekayasa perangkat lunak dan operasional. Dicetuskan di Google pada tahun 2003, SRE menjawab pertanyaan mendasar: bagaimana menjalankan sistem perangkat lunak berskala besar secara andal tanpa mengorbankan kecepatan pengembangan fitur? Jawabannya terletak pada kerangka target keandalan yang terukur — SLI, SLO, SLA — dan konsep error budget yang mengubah keandalan menjadi sumber daya rekayasa bersama.

SLI, SLO, dan SLA: Hierarki Keandalan

Ketiga istilah ini membentuk hierarki. Service Level Indicator (SLI) adalah pengukuran mentah — persentase request HTTP yang mengembalikan status code 2xx, atau fraksi request yang selesai dalam waktu kurang dari 200ms. Service Level Objective (SLO) adalah target internal yang dibangun di atas SLI — misalnya, 99,9% request harus berhasil dalam rolling window 30 hari. Service Level Agreement (SLA) adalah komitmen kontraktual kepada pelanggan, biasanya ditetapkan di bawah SLO dengan penalti finansial jika dilanggar.

Menulis SLO yang Baik dengan Alert Prometheus

SLO yang baik bersifat spesifik, terukur, dan berbatas waktu. Alert burn-rate multi-window Prometheus adalah implementasi standar industri: window cepat (1 jam) menangkap lonjakan tiba-tiba, sementara window lambat (6 jam atau 24 jam) menangkap penurunan bertahap. Alert aktif saat burn rate melebihi threshold yang memprediksi habisnya seluruh error budget dalam sisa window.

# Prometheus alerting rule — SLO burn rate alert
groups:
  - name: slo-alerts
    rules:
      # Availability SLO: 99.9% uptime over 30 days
      - alert: HighErrorBudgetBurnRate
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[1h]))
            /
            sum(rate(http_requests_total[1h]))
          ) > 0.001   # 0.1% error rate threshold
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High error budget burn rate"
          description: >
            Error budget is burning at {{ $value | humanizePercentage }}
            — SLO at risk if this continues.

      # Latency SLO: p99 < 500ms
      - alert: LatencySLOViolation
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
          ) > 0.5
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "p99 latency exceeds 500ms SLO"

Error Budget: Keandalan sebagai Sumber Daya Bersama

Error budget adalah jumlah ketidakandalan yang diizinkan per window SLO. Untuk SLO 99,9% selama 30 hari, error budget adalah 43,2 menit downtime. Saat budget masih sehat, tim dapat melakukan deployment sesering mungkin dan mengambil risiko yang diperhitungkan. Saat budget hampir habis, upaya rekayasa beralih ke pekerjaan keandalan — memperbaiki test yang flaky, mengurangi toil, meningkatkan keamanan deployment. Error budget mengubah keandalan dari urusan ops menjadi metrik rekayasa bersama.

Menghitung dan Melacak Error Budget

Pelacakan error budget paling baik diimplementasikan sebagai dashboard Grafana yang didukung Prometheus. Dashboard menampilkan nilai SLI saat ini, target SLO, sisa budget sebagai persentase, dan grafik burn-rate. Saat sisa budget turun di bawah 10%, alert otomatis menghubungi tim on-call dan memicu kebijakan feature freeze — tidak ada deployment baru hingga keandalan dipulihkan.

# Error Budget Calculation
# SLO target: 99.9% availability
SLO_TARGET=0.999
WINDOW_DAYS=30

total_minutes=$((WINDOW_DAYS * 24 * 60))   # 43200
allowed_downtime=$(echo "$total_minutes * (1 - $SLO_TARGET)" | bc)
# => 43.2 minutes of allowed downtime per 30 days

# Remaining budget query (Prometheus / Grafana)
# error_budget_remaining =
#   1 - (
#     sum(increase(http_requests_total{status=~"5.."}[30d]))
#     /
#     sum(increase(http_requests_total[30d]))
#   ) / (1 - SLO_TARGET)
#
# If result < 0 → budget exhausted, freeze feature releases

Mengurangi Toil Melalui Otomatisasi

Toil adalah pekerjaan yang bersifat manual, repetitif, dapat diotomatisasi, dan skalanya bertumbuh seiring layanan. Buku SRE Google merekomendasikan agar toil tetap di bawah 50% waktu seorang SRE. Sumber toil yang umum di environment Kubernetes meliputi restart pod yang crash secara manual, scaling deployment secara manual untuk lonjakan traffic, dan menjalankan database migration secara manual. Semuanya dapat dan harus diotomatisasi.

Mengotomatisasi Tugas On-Call yang Umum

Otomatisasi runbook adalah langkah pertama untuk mengurangi toil. Daripada seseorang membaca runbook dan menjalankan langkah-langkah secara manual, enkode runbook sebagai skrip yang dipicu oleh alert. Restart pod, pembersihan cache, dan override health check semuanya adalah kandidat yang baik. Otomatisasi yang lebih canggih menggunakan Kubernetes Operator untuk mengenkode pengetahuan operasional langsung ke dalam cluster.

# Toil reduction: automate repetitive restarts with a runbook
#!/usr/bin/env bash
# on-call-runbook: auto-restart crashlooping pods

NAMESPACE=production
THRESHOLD=5   # CrashLoopBackOff restart count before auto-remediation

kubectl get pods -n "$NAMESPACE" -o json | jq -r '
  .items[] |
  select(.status.containerStatuses[].restartCount > '"$THRESHOLD"') |
  .metadata.name' | while read -r pod; do
    echo "Restarting pod $pod (restarts > $THRESHOLD)"
    kubectl rollout restart deployment/"$(kubectl get pod "$pod" -n "$NAMESPACE"       -o jsonpath='{.metadata.labels.app}')" -n "$NAMESPACE"
done

Manajemen Insiden dan Blameless Postmortem

Saat sistem mengalami kegagalan — dan itu pasti terjadi — SRE mengandalkan manajemen insiden yang terstruktur untuk meminimalkan mean time to recovery (MTTR) dan belajar dari setiap kejadian. Blameless postmortem adalah landasan utamanya: dokumen yang mencatat timeline insiden, faktor-faktor yang berkontribusi, dan action item tanpa menyalahkan individu. Tujuannya adalah memperbaiki sistem, bukan manusia. Setiap insiden severity-1 harus menghasilkan postmortem dalam 48 jam, dengan action item yang dipantau hingga selesai.

Terminologi Inti SRE

Menguasai SRE membutuhkan pemahaman mendalam tentang istilah-istilah kunci berikut: SLO, SLA, SLI, error budget, toil, and blameless postmortem.

Perjalanan menuju praktik SRE yang matang bersifat bertahap. Mulailah dengan mengidentifikasi dua atau tiga metrik terpenting yang menghadap pengguna — tingkat keberhasilan request, latency, dan throughput adalah titik awal yang baik. Definisikan SLO untuk metrik-metrik tersebut, bangun dashboard Prometheus/Grafana, dan siapkan alert paging. Tinjau error budget dalam rapat rekayasa mingguan Anda. Seiring tim mendapat kepercayaan diri, perluas ke lebih banyak layanan dan perhalus threshold alert Anda. Tujuannya bukan uptime sempurna — melainkan tingkat keandalan yang tepat untuk pengguna dan bisnis Anda.

Artikel Terkait

• DevSecOps: Mengintegrasikan Keamanan ke dalam CI/CD
• Loki + Prometheus: Stack Observability untuk Production