Belajar Site Reliability Engineer - Platform Reliability

#Pendahuluan

Di episode 19, kalian bekerja sama dengan tim security. Di episode 22-23, kalian menjaga AI. Sekarang muncullah kustomers paling penting sekaligus paling menuntut: para engineer di tim kalian sendiri. Setiap platform internal — pipeline CI, environment staging, secret manager, template scaffolding — adalah layanan yang melayani mereka. Dan layanan tanpa SLO adalah layanan yang tidak tahu kapan ia mengecewakan.

Platform reliability adalah penerapan seluruh disiplin series ini pada internal developer platform (IDP): keandalan yang diukur, jalan yang dipelihara (golden path), dan kontrak yang disepakati dengan pengguna internal. Episode 24 membahas bagaimana tim platform menjadi tim layanan yang serius.

#IDP: Platform Internal sebagai Produk

Internal Developer Platform (IDP) adalah kumpulan layanan, tooling, dan proses yang dipakai developer untuk membangun dan mengirim perangkat lunak: CI/CD, environment provisioning, secret store, registry image, observability stack, dan layanan lain yang sudah kalian gunakan sepanjang series ini.

Titik balik mental yang paling penting: developer adalah pelanggan platform, bukan pengecualian dari operasi. Sebuah pipeline yang meledak tiap hari adalah insiden — persis seperti service yang down. Sebuah environment staging yang butuh 3 hari untuk diprovisoning adalah kegagalan layanan, bukan "harga yang biasa".

#Dua Kesalahan Umum Platform

1. Platform dibangun sekali, tidak dipelihara — tooling dibuat "untuk sekarang", lalu ditinggalkan; ketidakandalan menumpuk sampai developer mencari jalan lain (dan jalan lain itu lebih buruk).
2. Platform memperlakukan developer seperti alat — proses diserahkan manual, dokumentasi bertebaran, tidak ada yang bertanggung jawab atas pengalaman.

#Golden Path: Jalan yang Dipelihara, Bukan Jalan yang Dilarang

Golden path adalah jalur yang didukung penuh oleh platform — kombinasi template, tooling, dan konfigurasi yang diketahui berhasil. Konsep kuncinya adalah default yang benar: mengikuti golden path seharusnya menjadi pilihan paling mudah, bukan pilihan yang dipaksakan.

Golden path yang baik memiliki tiga sifat:

• Dipelihara: bukan template yang dibekukan; diperbarui seiring perubahan pola.
• Diukur: kalian tahu berapa lama dari repo kosong ke produksi lewat jalur ini.
• Realistis: jalur yang lebih mudah secara nyata daripada menyimpang — kalau developer tetap lebih suka menyimpang, jalurnya belum golden.

Perhatikan sifat ujungnya: observability dan SLO otomatis terpasang sejak scaffolding. Inilah cara membuat default yang benar — developer baru tidak perlu ingat memasang metric, trace, dan alert; jalur yang mereka tempuh sudah menyediakannya (ini perwujudan praktis dari episode 14, SLO-as-code).

#Developer SLA: Kontrak yang Diukur dengan Pengguna

Jika developer adalah pelanggan, mereka berhak atas janji layanan — dan tim platform harus diukur oleh janji itu. Developer SLA menjawab pertanyaan yang biasanya tidak pernah dijawab: berapa lama normalnya mendapat environment? Seberapa sering CI boleh gagal karena infrastruktur?

Contoh target yang masuk akal:

Dua prinsip penting: developer SLA adalah keputusan bersama (di-negosiasikan dengan pengguna, bukan ditetapkan sepihak oleh tim platform — persis semangat episode 3), dan pelanggaran SLA dipantau dengan error budget — jika budget CI platform habis, perbaikan CI adalah prioritas, bukan kegiatan sisa waktu.

#Mendorong Adopsi: Pengaruh Tanpa Paksaan

Platform yang andal tidak otomatis dipakai. Adopsi platform adalah perubahan budaya (materi mendalam di episode 25), dan untuk itu platform perlu tiga hal:

• Menghapus fiksi: setiap masalah yang berulang di tim developer seharusnya menjadi masalah platform — bukan alasan untuk membiarkan mereka berjuang sendiri.
• Menunjukkan bukti: angka yang nyata ("waktu ke produksi turun dari 5 hari ke 1 jam") lebih persuasif daripada slogan.
• Menjadi mudah dilawan: developer yang punya keberatan harus bisa menyuarakannya lewat saluran yang jelas — platform yang defensif mendorong developer mencari jalan gelap.

#Praktik: SLO untuk Platform Internal

Terapkan siklus SLO (episode 3-4) pada satu layanan platform:

1. Pilih satu layanan platform yang paling dikeluhkan — biasanya CI atau provisioning environment.
2. Definisikan SLI yang jujur: misal "durasi build sukses" untuk CI, "waktu dari request sampai ready" untuk environment.
3. Negosiasikan target dengan perwakilan developer — jangan tentukan sendirian.
4. Tetapkan error budget dan cara memakainya (budget habis = fokus perbaikan, budget sisa = boleh eksperimen fitur).
5. Dashboardkan untuk tim platform dan developer — siapa pun bisa melihat kesehatan platformnya.

service: env-provisioning
slos:
  - name: provision-within-15m-30d
    objective: 95.0
    indicator:
      good: jumlah env ready dalam 15 menit
      total: jumlah permintaan env
    error_budget_policy:
      exhausted: "prioritas: perbaiki provisioning"

#Penutup

Pada episode 24 ini, kalian telah belajar mengoperasikan platform dengan standar layanan yang serius.

Inti yang harus dibawa pulang:

• Developer adalah pelanggan platform; masalah mereka adalah insiden.
• Golden path membuat jalan yang benar menjadi jalan yang paling mudah — dengan observability terpasang sejak awal.
• Developer SLA adalah kontrak yang di-negosiasikan dan diukur dengan error budget.
• Adopsi didorong oleh bukti dan kemudahan, bukan paksaan.
• Mulailah dari satu layanan dan satu metrik yang paling menyakitkan.

Di episode 25 selanjutnya, kalian akan berurusan dengan hal yang paling sulit diubah: SRE culture & team — SRE vs DevOps, blameless culture, dan pengaruh tanpa otoritas. Sampai jumpa di episode 25!