Belajar Site Reliability Engineer - Reliability-as-Code

#Pendahuluan

Sepanjang series ini kalian membangun banyak hal: SLO, alert, dashboard, runbook, konfigurasi chaos, rencana kapasitas. Sekarang muncul pertanyaan yang sama pentingnya dengan membangunnya: siapa yang bisa mengubahnya, dan bagaimana perubahannya direview? Jika SLO diedit langsung di UI Prometheus, jika alert dimatikan dari dashboard tanpa jejak, jika runbook hanya ada di kepala satu orang — maka semua yang kalian bangun bukan aset, melainkan utang.

Reliability-as-code menjawab ini dengan satu prinsip yang sederhana dan radikal: semua pengaturan reliability diperlakukan seperti kode. Disimpan di git, di-review lewat pull request, di-version, dan di-render ke sistem target oleh otomasi. Episode 14 merangkum dan mempraktikkan pola ini.

#SLO-as-Code: Target yang Bisa Di-review

#Alasan: SLO Adalah Keputusan, Bukan Catatan

SLO adalah keputusan bisnis (episode 3-4). Keputusan yang baik perlu direview oleh manusia yang berwenang, disertai alasan, dan bisa ditelusuri siapa yang mengubahnya kapan. Menyimpan SLO sebagai YAML di repo melakukan semua itu — dan sekaligus menjadi single source of truth yang bisa di-render ke mana pun.

#Format Standar: OpenSLO

OpenSLO adalah spesifikasi terbuka untuk mendefinisikan SLO sebagai kode. Contoh:

version: 1.0.0
service: payments
slos:
  - name: availability-30d
    description: Availability payment API 99.9% per 30 hari
    objective: 99.9
    indicator:
      thresholdMetric:
        source: prometheus
        queryType: promql
        promql:
          good: >-
            sum(rate(http_requests_total{service="payments",code=~"2..|3.."}[30d]))
          total: >-
            sum(rate(http_requests_total{service="payments"}[30d]))
    timeWindow:
      - duration: 30d
        isRolling: true

#Alat Rendering: Sloth / Pyrra

YAML OpenSLO sendiri tidak dipahami Prometheus. Sloth dan Pyrra membaca YAML ini dan menghasilkan recording rules + alert Prometheus yang siap pakai. Alurnya:

Ubah SLO di git → generator menjalankan ulang → rules baru di-deploy → dashboard ikut ter-update. Tidak ada lagi SLO yang "terlupakan" di UI.

#Alert-as-Code: Alert yang Punya Pemilik

#Masalah Alert yang Dibuat di UI

Alert yang dibuat lewat UI Prometheus/Grafana punya tiga penyakit: tidak ada review (siapa pun bisa menambah tanpa tahu konteks), tidak ada riwayat (kenapa alert ini ada?), dan tidak sinkron dengan kode (service dihapus, alert menganggur).

#Pola yang Sehat

sre/
├── slo/
│   └── payments-api.yaml
├── alerts/
│   ├── payments-errorbudget.yaml
│   └── infra-disk.yaml
├── dashboards/
│   └── payments-overview.json
└── runbooks/
    └── payments-errorbudget.md

Setiap perubahan lewat pull request: reviewer melihat dif dan bisa menanyakan "kenapa thresholdnya diubah?" — diskusi terekam, bukan dihapus dari ingatan. Ketika alert digabung, CI menjalankan generator dan men-deploy ke Prometheus.

#IaC untuk Recovery: Infrastruktur yang Bisa Dibangun Ulang

SLO dan alert menjamin pengukuran; yang menjamin pemulihan adalah kemampuan membangun kembali infrastruktur secara otomatis. Dua pola recovery berbasis kode:

#1. Rebuild dari Kode (IaC)

Seluruh lingkungan di-deklarasikan sebagai kode (Terraform, Pulumi, CloudFormation). Saat disaster, lingkungan baru dibuat dari repo — bukan dari "ingatan orang yang dulu menyetup server". Ini mengubah recovery dari restore manual menjadi apply ulang:

resource "aws_instance" "app" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  user_data     = file("scripts/bootstrap.sh")
 
  tags = {
    Name    = "app-${var.environment}"
    Managed = "terraform"
  }
}

#2. Environment as Code untuk Recovery

Practice DR yang sehat: environment recovery dibangun & diuji terus-menerus, bukan disimpan untuk "saat dibutuhkan". Jika pipeline yang sama yang men-deploy production juga bisa membangun environment kosong dari nol, maka recovery menjadi aktivitas biasa, bukan panik dadakan.

#Runbook-as-Code

Runbook disimpan sebagai Markdown di repo, di-review seperti kode, dan — yang paling penting — dieksekusi sebagian: langkah-langkah yang bisa otomasi diubah menjadi script yang bisa dijalankan langsung. Runbook yang "dibaca lalu diketik manual" adalah toil (episode 9).

#Praktik: SLO & Alert dalam Git

Bangun alur lengkap untuk service payments kalian:

1. Buat repo sre-config dengan struktur di atas (slo/, alerts/, runbooks/).
2. Tulis SLO payments-api.yaml (contoh OpenSLO di atas).
3. Buat alert burn rate (pola episode 6) di alerts/payments-errorbudget.yaml.
4. Tulis runbook satu halaman: gejala, langkah pertama, rollback, link dashboard.
5. Setup CI: saat PR digabung ke main, jalankan generator dan sync ke Prometheus.
6. Buat PR untuk mengubah SLO dari 99.9% ke 99.95% — dan perhatikan alasan perubahan itu muncul dalam review, bukan hilang dalam percakapan.

#Penutup

Pada episode 14 ini, kalian telah mengubah reliability menjadi kode.

Inti yang harus dibawa pulang:

• Reliability-as-code: semua pengaturan reliability diperlakukan sebagai kode — di git, di-review, di-version.
• SLO-as-code dengan OpenSLO, di-render ke Prometheus oleh Sloth/Pyrra.
• Alert-as-code: alert punya pemilik, runbook, dan riwayat perubahan via pull request.
• IaC untuk recovery: lingkungan dibangun ulang dari kode, dan uji pembangunan ulang terus-menerus.
• Semua ini menyatu menjadi satu repo yang menjadi sumber kebenaran tim.

Di episode 15 selanjutnya, kita akan membidik performa: performance engineering — profiling, optimasi latency, dan load testing dengan k6 untuk membuktikan bahwa SLO performa benar-benar bisa dicapai. Sampai jumpa di episode 15!