Belajar Platform Engineer - Platform Reliability & SLO

#Pendahuluan

Setelah di episode 16 platform aman dan patuh, masih ada satu fondasi yang belum kita singgung sebagai produk: apakah platform itu sendiri andal? SLO selama ini identik dengan aplikasi. Episode ini membahas platform reliability & SLO — menetapkan target keandalan untuk platform, mengelola error budget, dan mendesain availability sejak awal.

Mengapa ini penting? Platform adalah multiplier: jika portal down, ratusan developer berhenti kerja; jika provisioning lambat, semua pipeline ikut lambat. Tanpa SLO, keandalan platform diukur dari keluhan subjektif ("rasanya makin lambat") dan perbaikan dilakukan saat api sudah membakar — bukan saat pelanggaran target terjadi. SLO mengubah keandalan dari perasaan menjadi angka yang bisa diawasi dan diperjuangkan.

#SLI, SLO, dan Error Budget

Sebelum masuk ke platform, segarkan tiga konsep dasar:

Konsep	Definisi	Contoh untuk platform
SLI	Pengukuran nyata dari suatu perilaku	Persentase request API portal sukses dalam 5 detik
SLO	Target yang disepakati untuk SLI	99.9% request portal sukses per bulan
Error budget	Jatah kegagalan yang tersisa	0.1% x total request = jatah downtime bulanan

Error budget adalah bagian yang paling sering disalahpahami: ia bukan izin untuk lalai, melainkan anggaran untuk berinovasi. Selama budget masih tersisa, tim boleh mengerjakan perbaikan besar; jika budget habis, prioritas kembali ke stabilitas. Ini yang membuat perdebatan "fitur vs stabilitas" berakhir dengan angka, bukan adu keras suara.

#SLO untuk Platform: Lebih dari Sekadar "Up"

Platform bukan satu komponen — ia banyak layer. SLO platform perlu menutupi pengalaman developer, bukan hanya status pod:

Lapisan	SLI	SLO target
Portal (Backstage)	Request sukses < 5 detik	99.5%
Provisioning	Environment siap < 15 menit setelah request	99% dalam 15 menit
Cluster API	API request sukses	99.9%
Deployment path	Deploy dari commit ke prod < 30 menit	99%
Secrets/Config	Serve konfigurasi sukses	99.99%

Perhatikan dua SLO yang tidak biasa: provisioning time dan deploy time. Itulah yang dirasakan developer sebagai "platform cepat/lambat". SLO yang hanya menghitung "portal up" gagal menangkap pengalaman nyata.

#Praktik: Menulis SLO sebagai Kode

SLO ditulis sebagai kode agar bisa di-review dan diterapkan seragam. Contoh memakai Sloth (generator SLO untuk Prometheus):

slo/platform-provisioning.yaml

version: prometheus/v1
service: platform
slos:
  - name: provisioning-fast-enough
    objective: 99
    description: Environment siap kurang dari 15 menit
    sli:
      events:
        error_query: |
          sum(rate(provision_errors_total[5m]))
        total_query: |
          sum(rate(provision_requests_total[5m]))
    alerting:
      page_alert:
        labels:
          severity: page

Dengan SLO sebagai kode, alerting burn rate bisa dibangun: jika pembakaran error budget berlangsung terlalu cepat, tim platform di-notify lebih awal — bukan menunggu akhir bulan.

Alur error budget alerting

burn-rate > 14.4x (2 jam)   -> page: incident, ini krisis
burn-rate > 6x (6 jam)      -> warning: segera intervensi
burn-rate > 3x (30 hari)    -> review: kecenderungan memburuk

#Desain Availability

SLO hanya berguna jika arsitekturnya mendukung. Tiga prinsip desain:

Redundansi di setiap layer — multi-AZ untuk workload, kontrol plane dan data plane terpisah, replicas yang nyata (bukan sekadar dua pod di node sama).
Failure isolation — satu service yang meledak tidak boleh membawa seluruh portal; gunakan circuit breaker dan degradasi (episode 8: service mesh).
Data durability — database yang adalah sumber kebenaran wajib punya replika + backup teruji (episode 14); RPO/RTO dihitung dari sini.

Hukum sederhana: SLO yang ketat tanpa desain yang mendukung hanyalah target untuk meleset. Naikkan SLO secara bertahap sambil memperkuat arsitektur.

#Common Pitfalls

SLO 100% — mustahil secara matematis dan menciptakan budaya menyalahkan; mulai dari 99% dan turunkan secara sadar.
SLI yang mengukur hal yang salah — "uptime pod" tinggi tapi developer tetap mengeluh; ukur pengalaman (waktu provisioning, deploy time).
Error budget tanpa mekanisme tindak lanjut — angka dicatat tapi tidak mengubah prioritas apa pun.
SLO untuk aplikasi tapi tidak untuk platform — platform dianggap "infrastruktur" yang tak perlu target, padahal ia produk pertama.
Membuat banyak SLO sekaligus — mulai dari 3-5 SLI yang paling dirasakan, pelajari, lalu perluas.

Note

SLO platform adalah janji publik tim platform ke developer — dan error budget adalah bahasanya. Saat budget habis, tim platform menang (stabilitas diprioritaskan); saat budget tersisa, developer menang (inovasi jalan). Keduanya diukur dengan angka, bukan dengan siapa yang berteriak paling keras.

#Penutup

Inti yang harus dibawa pulang:

SLI mengukur, SLO menargetkan, error budget mengatur prioritas.
SLO platform menutupi pengalaman developer: provisioning time dan deploy time lebih relevan daripada uptime pod.
Tulis SLO sebagai kode untuk review dan penerapan seragam di seluruh fleet.
Desain availability (redundansi, isolasi, durability) mendukung SLO yang ditetapkan.
Mulai dari sedikit SLI, pelajari, lalu perluas — dan pastikan error budget benar-benar mengubah prioritas.

Di episode 18 selanjutnya kita menutup sisi keamanan jaringan dan akses: zero trust platform — identity-aware access, mTLS secara default, dan least privilege yang menjadikan lokasi jaringan bukan lagi alasan untuk percaya!