# SLA Adalah: Pengertian, Komponen, dan Contohnya

> SLA adalah perjanjian tingkat layanan berisi target terukur dan konsekuensinya. Pahami bedanya dengan SLI dan SLO, arti uptime 99,9%, komponen, dan contohnya.

**URL:** https://www.ciptadusa.com/blog/sla-adalah  
**Type:** blog  
**Author:** PT Cipta Dua Saudara  
**Category:** Teknologi  
**Published:** 2026-11-15  
**Cover:** https://www.ciptadusa.com/media/uploads/blog/2026-11/1794709334307-sla-adalah-20261115.webp  

## Article

SLA (service level agreement) adalah perjanjian tingkat layanan antara penyedia layanan dan pelanggannya, berisi target kualitas layanan yang terukur beserta konsekuensinya jika target itu tidak tercapai. Buku Site Reliability Engineering dari Google mendefinisikan SLA sebagai kontrak, baik tertulis maupun tidak, dengan pengguna yang mencakup konsekuensi jika target (SLO) di dalamnya terpenuhi atau tidak terpenuhi. Konsekuensi yang paling mudah dikenali adalah konsekuensi finansial, seperti potongan biaya atau denda ([sumber](https://sre.google/sre-book/service-level-objectives/)).

Di dunia software dan IT, SLA sering muncul di kontrak layanan cloud, hosting, aplikasi SaaS, dan kontrak maintenance aplikasi. Artikel ini membahas pengertian SLA, bedanya dengan SLI dan SLO, arti angka uptime seperti 99,9%, contoh SLA nyata dari penyedia cloud, isi yang perlu ada di dokumen SLA, dan cara menyusun SLA yang realistis untuk aplikasi bisnis.

## Pengertian SLA, SLI, dan SLO

Tiga istilah ini sering tertukar. Buku SRE Google membedakannya dengan jelas ([sumber](https://sre.google/sre-book/service-level-objectives/)):

| Istilah | Kepanjangan | Arti |
|---|---|---|
| SLI | Service level indicator | Ukuran kuantitatif dari satu aspek layanan, misalnya latensi request, tingkat error, atau throughput |
| SLO | Service level objective | Nilai target atau rentang nilai untuk sebuah SLI, misalnya rata-rata latensi pencarian di bawah 100 milidetik |
| SLA | Service level agreement | Kontrak dengan pengguna yang mencakup konsekuensi jika SLO terpenuhi atau tidak |

Cara mudah membedakan SLO dan SLA, menurut buku yang sama: tanyakan "apa yang terjadi jika SLO tidak tercapai?". Jika tidak ada konsekuensi yang jelas, itu hampir pasti SLO, bukan SLA ([sumber](https://sre.google/sre-book/service-level-objectives/)).

Contoh ilustrasi CDS untuk aplikasi pemesanan online:

- **SLI:** persentase request checkout yang berhasil, dan waktu respons halaman checkout.
- **SLO:** 99,9% request checkout berhasil setiap bulan, dan 95% halaman checkout terbuka di bawah 1 detik.
- **SLA:** jika ketersediaan bulanan di bawah 99,9%, penyedia memberi potongan biaya layanan bulan itu sesuai tabel di kontrak.

Buku SRE juga mencatat bahwa tim teknis biasanya tidak menyusun SLA, karena SLA sangat terkait dengan keputusan bisnis dan produk. Tim teknis membantu mendefinisikan SLI, karena harus ada cara objektif untuk mengukur SLO di dalam perjanjian agar tidak terjadi perselisihan ([sumber](https://sre.google/sre-book/service-level-objectives/)).

## Arti Angka Uptime: 99%, 99,9%, dan 99,99%

Angka ketersediaan di SLA terlihat mirip, tetapi selisihnya besar jika diubah menjadi waktu downtime yang diizinkan. Tabel berikut diambil dari lampiran buku SRE Google ([sumber](https://sre.google/sre-book/availability-table/)):

| Tingkat ketersediaan | Downtime per tahun | Downtime per bulan | Downtime per minggu |
|---|---|---|---|
| 99% | 3,65 hari | 7,2 jam | 1,68 jam |
| 99,5% | 1,83 hari | 3,6 jam | 50,4 menit |
| 99,9% | 8,76 jam | 43,2 menit | 10,1 menit |
| 99,95% | 4,38 jam | 21,6 menit | 5,04 menit |
| 99,99% | 52,6 menit | 4,32 menit | 60,5 detik |

Artinya, SLA 99,9% memberi ruang downtime sekitar 43 menit per bulan, sedangkan 99,99% hanya sekitar 4 menit. Setiap tambahan angka 9 biasanya membutuhkan arsitektur, pemantauan, dan biaya operasional yang jauh lebih besar. Ini panduan internal CDS.

## Contoh SLA Nyata: Amazon EC2

Salah satu contoh SLA publik adalah Amazon Compute Service Level Agreement untuk Amazon EC2 (terakhir diperbarui 25 Mei 2022). AWS berkomitmen membuat EC2 tersedia di setiap region dengan Monthly Uptime Percentage minimal 99,99% per siklus tagihan bulanan ([sumber](https://aws.amazon.com/compute/sla/)). Jika target itu tidak tercapai, pelanggan berhak atas service credit ([sumber](https://aws.amazon.com/compute/sla/)):

| Monthly Uptime Percentage (level region) | Service credit |
|---|---|
| Di bawah 99,99% tetapi minimal 99,0% | 10% |
| Di bawah 99,0% tetapi minimal 95,0% | 30% |
| Di bawah 95,0% | 100% |

Beberapa hal yang bisa dipelajari dari SLA ini:

- **Ada pengecualian.** SLA tidak berlaku untuk gangguan yang disebabkan faktor di luar kendali AWS, termasuk force majeure, atau akibat tindakan pelanggan sendiri ([sumber](https://aws.amazon.com/compute/sla/)).
- **Kompensasi harus diklaim.** Untuk mendapat service credit, pelanggan harus mengajukan klaim lewat AWS Support Center, paling lambat akhir siklus tagihan kedua setelah insiden, lengkap dengan bukti seperti log request ([sumber](https://aws.amazon.com/compute/sla/)).
- **Kompensasi berupa kredit, bukan ganti rugi penuh.** Kompensasinya berupa persentase kredit layanan. Kerugian bisnis akibat downtime tidak otomatis diganti.

Poin terakhir penting bagi bisnis: SLA dari penyedia infrastruktur tidak menggantikan rencana Anda sendiri untuk menghadapi gangguan.

## Komponen yang Perlu Ada di Dokumen SLA

Daftar berikut adalah panduan internal CDS saat menyusun SLA untuk aplikasi atau layanan maintenance:

1. **Lingkup layanan.** Aplikasi, modul, dan lingkungan apa saja yang dicakup (misalnya hanya produksi, bukan staging).
2. **Definisi ketersediaan.** Cara menghitung uptime, periode pengukuran (bulanan), dan apa yang dianggap "tidak tersedia".
3. **Target layanan (SLO).** Uptime, waktu respons aplikasi, dan target lain yang terukur.
4. **Waktu respons dan penyelesaian insiden.** Dibedakan berdasarkan tingkat keparahan, misalnya kritis (aplikasi mati), tinggi (fitur utama error), sedang, dan rendah.
5. **Jam layanan dan saluran kontak.** Jam dukungan, kanal pelaporan, dan eskalasi.
6. **Jadwal maintenance terencana.** Kapan maintenance boleh dilakukan dan apakah dihitung sebagai downtime.
7. **Pengecualian.** Gangguan dari pihak ketiga, force majeure, atau perubahan yang dilakukan pelanggan.
8. **Pelaporan.** Laporan ketersediaan dan insiden berkala.
9. **Konsekuensi.** Service credit atau bentuk kompensasi lain jika target tidak tercapai, beserta cara mengklaimnya.

Contoh tabel waktu respons insiden (ilustrasi CDS, bukan angka standar):

| Tingkat keparahan | Contoh kondisi | Waktu respons awal | Target pemulihan |
|---|---|---|---|
| Kritis | Aplikasi tidak bisa diakses semua pengguna | 30 menit | 4 jam |
| Tinggi | Fitur utama seperti checkout error | 2 jam | 1 hari kerja |
| Sedang | Fitur pendukung error, ada jalan pintas | 1 hari kerja | 3 hari kerja |
| Rendah | Pertanyaan atau perbaikan tampilan kecil | 2 hari kerja | Dijadwalkan di rilis berikutnya |

Angka di tabel ini hanya contoh format. Nilai sebenarnya harus disepakati sesuai kebutuhan bisnis dan anggaran, karena target yang lebih ketat berarti tim jaga yang lebih besar. Kaitan SLA dengan biaya dibahas di artikel [biaya maintenance aplikasi](/blog/biaya-maintenance-aplikasi).

## Cara Menyusun SLA yang Realistis

Buku SRE Google memberi beberapa prinsip memilih target ([sumber](https://sre.google/sre-book/service-level-objectives/)):

- **Jangan menetapkan target hanya dari performa saat ini.** Target yang diambil begitu saja bisa memaksa tim bekerja "heroik" untuk mempertahankannya.
- **Hindari target absolut.** Permintaan sistem yang "selalu" tersedia tidak realistis, mahal dioperasikan, dan sering lebih baik dari yang sebenarnya dibutuhkan pengguna.
- **Pakai sesedikit mungkin SLO.** Pilih cukup SLO untuk mencakup atribut penting sistem, dan pastikan setiap SLO bisa dipertahankan saat menentukan prioritas.
- **Mulai longgar, lalu perketat.** Lebih baik memulai dengan target longgar yang diperketat bertahap daripada target terlalu ketat yang terpaksa dilonggarkan.
- **Sisakan margin aman.** Gunakan SLO internal yang lebih ketat dari SLO yang dijanjikan ke pengguna, agar tim punya waktu menangani masalah sebelum terlihat oleh pelanggan.

Buku yang sama juga memperkenalkan konsep error budget, yaitu batas seberapa sering SLO boleh terlewat, yang bisa dipantau harian atau mingguan dan dipakai untuk memutuskan kapan rilis baru boleh dilakukan ([sumber](https://sre.google/sre-book/service-level-objectives/)). Praktik ini erat kaitannya dengan [DevOps](/blog/devops-adalah).

## Kesalahan Umum Saat Menyusun SLA

Beberapa kesalahan yang sering ditemui tim CDS saat meninjau kontrak layanan klien:

- **Uptime tanpa definisi.** Angka 99,9% tertulis, tetapi tidak dijelaskan diukur dari mana, periode berapa, dan apakah maintenance terencana dihitung.
- **Tidak ada pengukuran objektif.** Tanpa pemantauan otomatis, kedua pihak hanya berdebat berdasarkan perasaan, persis masalah yang diingatkan buku SRE soal perlunya SLI yang objektif ([sumber](https://sre.google/sre-book/service-level-objectives/)).
- **Waktu respons disamakan dengan waktu penyelesaian.** "Direspons dalam 1 jam" tidak sama dengan "selesai dalam 1 jam". Keduanya perlu ditulis terpisah.
- **Performa jauh di atas janji tanpa disadari.** Buku SRE mengingatkan bahwa pengguna akan bergantung pada performa nyata yang Anda berikan, bukan pada angka yang Anda tuliskan. Jika performa nyata jauh lebih baik dari SLO, pengguna akan terbiasa dan kecewa saat performa turun ke angka yang sebenarnya dijanjikan ([sumber](https://sre.google/sre-book/service-level-objectives/)).

## Apa yang Dibutuhkan Secara Teknis untuk Memenuhi SLA?

SLA hanya bisa dipenuhi jika sistemnya dirancang untuk itu. Dari pengalaman tim CDS, beberapa hal yang biasanya dibutuhkan:

- **Pemantauan dan alert.** Uptime dan error harus terukur otomatis, bukan menunggu laporan pengguna.
- **Redundansi.** Lebih dari satu server di belakang [load balancer](/blog/load-balancer-adalah), agar satu server mati tidak membuat aplikasi mati.
- **Backup dan prosedur pemulihan yang sudah diuji.**
- **Proses rilis yang aman,** misalnya dengan staging dan rollback cepat.
- **Tim jaga dan prosedur eskalasi** yang sesuai dengan jam layanan di SLA.

Semakin tinggi angka uptime yang dijanjikan, semakin banyak komponen di atas yang harus ada dan teruji.

## FAQ Seputar SLA

### SLA adalah singkatan dari apa?

SLA adalah singkatan dari service level agreement, yaitu perjanjian tingkat layanan yang mencakup konsekuensi jika target layanan terpenuhi atau tidak ([sumber](https://sre.google/sre-book/service-level-objectives/)).

### Apa bedanya SLA dan SLO?

SLO adalah target nilai untuk sebuah indikator layanan, sedangkan SLA adalah kontrak yang memuat konsekuensi jika SLO tidak tercapai. Jika tidak ada konsekuensi yang jelas, itu SLO ([sumber](https://sre.google/sre-book/service-level-objectives/)).

### Berapa downtime yang diizinkan untuk SLA 99,9%?

Sekitar 43,2 menit per bulan atau 8,76 jam per tahun ([sumber](https://sre.google/sre-book/availability-table/)).

### Apa itu service credit?

Service credit adalah kompensasi berupa potongan biaya layanan jika SLA tidak tercapai. Pada SLA Amazon EC2, besarnya 10%, 30%, atau 100% tergantung tingkat uptime bulanan, dan harus diklaim oleh pelanggan ([sumber](https://aws.amazon.com/compute/sla/)).

### Apakah SLA hanya untuk layanan cloud?

Tidak. SLA juga dipakai untuk kontrak maintenance aplikasi, layanan helpdesk, dan layanan IT internal. Yang penting, targetnya terukur dan konsekuensinya jelas.

### Apakah SLA 100% mungkin?

Buku SRE Google menyebut permintaan sistem yang "selalu" tersedia tidak realistis dan sangat mahal ([sumber](https://sre.google/sre-book/service-level-objectives/)). Karena itu SLA yang wajar selalu menyisakan ruang downtime.

## Butuh Aplikasi dengan SLA yang Jelas?

Tim CDS membangun dan merawat aplikasi web, API, dan sistem internal dengan pemantauan, backup, dan target layanan yang tertulis jelas lewat [jasa pembuatan software custom](/services/software). Jika Anda sedang menyusun kontrak maintenance atau ingin meninjau kesiapan sistem untuk target uptime tertentu, mulai dari [konsultasi IT](/services/consulting). Anda juga bisa melihat [karya CDS](/works) untuk proyek yang sudah kami kerjakan.


---

*Markdown version of https://www.ciptadusa.com/blog/sla-adalah — generated for AI agents and LLM crawlers.*