Belajar Site Reliability Engineer - Release Reliability

#Pendahuluan

Jika kalian bertanya ke SRE mana pun "apa sumber insiden terbesar?", salah satu jawaban yang selalu muncul: deployment. Rilis adalah momen paling berisiko dalam siklus layanan — perubahan kode, konfigurasi, dan data bertemu dalam satu gerakan. Episode 11 mengubah rilis dari "momen menegangkan" menjadi proses yang bisa dikendalikan dengan gradasi risiko.

Ini hubungan langsung dengan pelajaran episode 4: error budget memberi izin untuk bergerak, dan release reliability adalah cara menggerakkan perubahan dalam batas budget itu. Semakin aman proses rilis, semakin sering kalian bisa rilis — dan semakin sedikit ruang error yang terbakar. Inilah paradoks yang indah: keandalan yang lebih baik membuat tim lebih cepat, bukan lebih lambat.

#Empat Strategi Rilis: Perbandingan

#Big Bang (All at Once)

Semua traffic berpindah ke versi baru dalam satu langkah. Sederhana, tetapi risiko penuh: jika versi baru bermasalah, semua pengguna kena pada saat yang sama. Rollback-nya juga penuh — seluruh versi lama harus di-restore.

#Blue-Green

Dua environment identik: blue (versi lama, menerima traffic) dan green (versi baru, kosong). Setelah green dites, switch traffic ke green dalam satu langkah. Rollback semudah memindahkan traffic kembali ke blue.

#Canary

Versi baru diluncurkan ke sebagian kecil traffic (misal 5%), dipantau, lalu diperbesar bertahap sambil dibandingkan metrik error/latency-nya dengan versi lama. Risiko terkecil dan bukti terkuat — keputusan "lanjut" dibuat berdasarkan data nyata, bukan harapan.

#Progressive Delivery

Payung yang mencakup semua: canary, feature flags, dan otomasi promosi berdasarkan metrik. Inilah cara pandang modern — rilis bukan satu peristiwa, melainkan proses yang dikontrol sepanjang jalan.

Keputusan di setiap titik cabang diambil dari perbandingan metrik, bukan dari perasaan. Persentase dan durasi tiap langkah sebaiknya dikonfigurasi sebagai parameter yang bisa diubah per rilis — skala risiko diatur, bukan dikira-kira.

#Feature Flags: Memisahkan Deploy dari Release

Konsep kunci yang sering disalahartikan: deploy ≠ release. Deploy adalah kode baru masuk ke production; release adalah saat fitur benar-benar terlihat pengguna. Feature flags memisahkan keduanya: kode berisi fitur di belakang saklar (flag) yang bisa diubah kapan saja tanpa deployment baru.

Manfaat untuk SRE:

• Rollback tanpa redeploy — matikan flag, fitur hilang dalam detik.
• Rilis bertahap per segmen — internal dulu, lalu beta user, lalu semua.
• Eksperimen terkendali — bandingkan dua versi pada traffic nyata.
• Kill switch untuk fitur yang tiba-tiba bermasalah — persis "stop the bleeding" di episode 7.

features:
  checkout-v2:
    enabled: true
    percentage: 5
    rules:
      - segment: internal
  dark-mode:
    enabled: false

#Cara Mengukur Rilis: Metrik yang Harus Dipantau

Canary tanpa metrik hanyalah "deploy beruntun dengan nama keren". Sebelum canary jalan, pastikan kalian membandingkan:

Aturan mainnya: bandingkan pada periode yang sama (bukan canary siang vs baseline malam) dan otomatiskan keputusannya — manusia terlalu lambat dan subjektif untuk perbandingan 5 menit.

#Praktik: Canary Deployment dengan Argo Rollouts

Kita praktikkan canary di Kubernetes memakai Argo Rollouts, yang menggantikan mekanisme rolling update Deployment standar:

Rollout canary

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: demo
spec:
  replicas: 6
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 5m }
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 100
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: demo
          image: demo:2.5.0

Alur yang terjadi: rilis 2.5.0 menerima 5% traffic selama 5 menit, lalu 25% selama 10 menit, lalu 100%. Bila di tengah jalan metrik melanggar (Argo Rollouts terhubung ke Prometheus untuk analysis), canary otomatis di-rollback:

Pantau dan promosikan

kubectl argo rollouts get rollout demo
kubectl argo rollouts promote demo

Name:            demo
Strategy:        Canary
Status:          ✔ Healthy
STEP  WEIGHT  STATUS     DURATION
1     5       ✔ Progressing  5m
2     25      ✔ Progressing  10m
3     100     ✔ Succeeded    30s

#Penutup

Pada episode 11 ini, kalian telah menguasai seni rilis yang aman.

Inti yang harus dibawa pulang:

• Empat strategi: big bang, blue-green, canary, progressive — gradasi risiko dari penuh ke terkontrol.
• Deploy ≠ release; feature flags memisahkan keduanya dan memberi rollback instan.
• Canary tanpa metrik adalah tebakan — bandingkan error, latency, dan sinyal bisnis.
• Argo Rollouts mengotomasi canary + analysis + rollback di Kubernetes.
• Rilis yang aman membuat tim lebih cepat, karena mengurangi ketakutan — bukan menambah aturan.

Di episode 12 selanjutnya, kita akan membahas area yang paling ditakuti banyak SRE: data reliability — database HA, backup & restore yang benar-benar berfungsi, dan keandalan data pipeline dengan SLO untuk data. Sampai jumpa di episode 12!