SLI dan SLA untuk Website Bisnis Indonesia: Cara Janji Kualitas yang Realistis di 2026

TL;DR: SLI mengukur kualitas layanan secara kuantitatif, SLO menjadi target internal yang ingin dicapai, dan SLA menjadi janji formal ke pelanggan yang biasanya disertai konsekuensi finansial. Untuk website bisnis Indonesia, mulailah dari 2-3 SLI yang paling dirasakan pengguna, set SLO realistis, dan tulis SLA dengan margin keamanan minimal 0,05 persen di bawah SLO.

Banyak bisnis Indonesia menulis "uptime 99,99 persen" di halaman penjualan tanpa pernah mengukurnya. Ketika pelanggan komplain, tidak ada angka yang bisa dirujuk, dan tidak ada batasan jelas kapan tim engineering wajib bertindak.

Dalam beberapa proyek terakhir, saya melihat pola yang sama: tim teknologi mengejar fitur baru, tim sales menjual janji ambisius, dan ketika insiden terjadi, semua pihak menebak siapa yang salah.

Kerangka SLI, SLO, dan SLA ada untuk memutus pola ini. Tiga konsep ini bukan jargon konsultan, tapi alat operasional yang sudah dipakai tim platform di Google, Netflix, dan Shopify selama lebih dari satu dekade.

Tiga Konsep yang Sering Tertukar

SLI adalah angka. Misalnya, persentase request yang dijawab di bawah 500 ms dalam satu jam terakhir. SLI bersifat netral, hanya melaporkan apa yang terjadi.

SLO adalah target untuk SLI. Misalnya, "95 persen request harus di bawah 500 ms diukur per minggu". SLO bersifat aspiratif tapi terukur, menjadi rujukan internal tim engineering.

SLA adalah janji eksternal yang biasanya lebih longgar dari SLO. Misalnya, "kami menjamin 99,9 persen uptime per bulan, dengan kredit 10 persen biaya bila tidak terpenuhi". SLA punya konsekuensi kontraktual.

Ketiganya membentuk hierarki: SLI → SLO → SLA. Tanpa SLI, tidak ada cara mengukur SLO. Tanpa SLO, SLA jadi tebakan.

Memilih SLI yang Tepat untuk Website Bisnis

Tidak semua metrik layak menjadi SLI. Pilih yang paling dirasakan pengguna saat layanan terganggu.

Hindari godaan mengukur 10 SLI sekaligus. Saat insiden terjadi, tim akan kebingungan menentukan prioritas. Praktik standar di industri adalah 2-4 SLI inti per layanan kritis.

Menyusun SLO yang Realistis

SLO yang terlalu ketat membuat tim engineering kelelahan dan menolak rilis fitur baru. SLO yang terlalu longgar membuat kualitas layanan tidak terjaga. Cara aman: ukur SLI selama 4-8 minggu di kondisi normal, ambil persentil 95 sebagai baseline, lalu tetapkan SLO sedikit di atas baseline tersebut.

Untuk e-commerce Nalesha (proyek brand parfumery yang saya bantu) misalnya, jika baseline availability checkout selama dua bulan tercatat 99,7 persen, SLO realistis adalah 99,8 persen, bukan 99,99 persen yang sering ditulis di pitch deck. Selisih 0,1 persen ini terdengar kecil, tetapi bisa berarti puluhan jam downtime per tahun.

Error budget menjadi konsekuensi alami dari SLO. Jika SLO availability 99,9 persen per bulan, error budget adalah 43,2 menit downtime yang masih ditoleransi. Selama error budget belum habis, tim boleh agresif merilis fitur. Ketika habis, fokus pindah ke stabilitas.

SLA: Janji yang Aman ke Pelanggan

SLA harus selalu lebih longgar dari SLO. Aturan praktis: SLA = SLO dikurangi margin keamanan 0,05 sampai 0,1 persen. Bila SLO internal 99,95 persen, SLA eksternal sebaiknya 99,9 persen.

Komponen SLA yang sering terlewat oleh bisnis Indonesia:

• Measurement window yang jelas (per bulan kalender, bukan per minggu)
• Exclusion untuk maintenance terjadwal yang diumumkan minimal 48 jam sebelumnya
• Remedy dalam bentuk kredit layanan, bukan refund tunai penuh
• Reporting cadence: kapan dan bagaimana laporan SLA dikirim ke pelanggan

Referensi SLA standar industri yang baik dapat dilihat di dokumentasi SRE Google dan whitepaper Atlassian SLA yang sering dipakai sebagai template di komunitas DevOps Indonesia.

Kesalahan Umum yang Saya Lihat di Lapangan

Pertama, mengiklankan "uptime 99,99 persen" tanpa SLI yang aktif diukur. Ketika diaudit, tidak ada data historis yang membuktikannya. Per April 2026, beberapa hosting Indonesia masih menulis klaim ini di halaman pricing tanpa dashboard publik.

Kedua, SLA yang lebih ketat dari SLO. Tim engineering tidak punya ruang aman, dan setiap insiden minor langsung memicu denda kontraktual.

Ketiga, mencampur kualitas user-facing dengan kualitas teknis internal. Database uptime tidak relevan dengan pelanggan jika halaman checkout tetap bisa diakses dengan cache.

Keempat, lupa memasukkan dependency pihak ketiga. Jika layanan Anda bergantung pada Midtrans, Xendit, atau Supabase, SLA Anda secara matematis tidak boleh lebih ketat dari SLA komposit dependency tersebut.

Pertanyaan Umum

Apakah bisnis kecil butuh SLA?

Tidak harus. SLA biasanya relevan untuk layanan B2B berbayar dengan kontrak formal. Bisnis B2C cukup punya SLO internal sebagai standar kerja tim.

Berapa lama sampai SLI mulai memberi nilai?

Umumnya 4-8 minggu untuk mendapat baseline yang valid, dan 3-6 bulan sebelum SLO mulai dipakai sebagai dasar pengambilan keputusan rilis.

Apakah Cloudflare atau Vercel sudah menyediakan SLI bawaan?

Ya. Vercel Analytics dan Cloudflare Analytics menyediakan metrik availability dan latency dasar yang bisa langsung dipakai sebagai SLI awal sebelum tim membangun observability sendiri.

Apakah SLO harus diumumkan ke pelanggan?

Tidak wajib. SLO adalah target internal, sementara yang diumumkan ke pelanggan adalah SLA yang lebih longgar. Mengumumkan SLO bisa menjadi bumerang ketika gagal terpenuhi sesaat.

Mulai dari Mana?

Pilih satu layanan paling kritis. Tentukan satu SLI yang paling dirasakan pelanggan. Ukur selama satu bulan. Tetapkan SLO awal yang realistis. Baru pertimbangkan SLA setelah punya tiga bulan data. Tanpa urutan ini, semua dokumen SLA hanya akan menjadi pajangan kontrak yang tidak pernah dipakai.