Pelajari cara merancang dan membangun aplikasi web yang melacak kepatuhan SLA: definisikan metrik, kumpulkan event, hitung hasil, beri peringatan saat pelanggaran, dan laporkan secara akurat.
Kepatuhan SLA berarti memenuhi janji yang dapat diukur dalam Service Level Agreement (SLA)—kontrak antara penyedia dan pelanggan. Tugas aplikasi Anda adalah menjawab satu pertanyaan sederhana dengan bukti: Apakah kita memenuhi yang dijanjikan, untuk pelanggan ini, selama periode waktu ini?
Ada baiknya memisahkan tiga istilah terkait:
Kebanyakan aplikasi pelacak SLA memulai dengan seperangkat metrik kecil yang dipetakan ke data operasional nyata:
Pengguna berbeda menginginkan kebenaran yang sama, disajikan berbeda:
Produk ini tentang pelacakan, bukti, dan pelaporan: mengumpulkan sinyal, menerapkan aturan yang disepakati, dan menghasilkan hasil yang audit-friendly. Ini tidak menjamin performa; ia mengukurnya—dengan akurat, konsisten, dan dengan cara yang bisa Anda pertahankan nanti.
Sebelum merancang tabel atau menulis kode, jelaskan dengan sangat rinci apa arti “kepatuhan” untuk bisnis Anda. Sebagian besar masalah pelacakan SLA bukanlah teknis—mereka adalah masalah persyaratan.
Mulailah dengan mengumpulkan sumber kebenaran:
Tulis aturan-aturan ini secara eksplisit. Jika sebuah aturan tidak bisa dinyatakan jelas, itu tidak bisa dihitung dengan andal.
Daftar “benda” dunia nyata yang dapat memengaruhi angka SLA:
Juga identifikasi siapa yang membutuhkan apa: support ingin risiko pelanggaran real-time, manajer ingin rollup mingguan, pelanggan ingin ringkasan sederhana (sering untuk halaman status).
Jaga ruang lingkup kecil. Pilih set minimum yang membuktikan sistem bekerja end-to-end, seperti:
Buat daftar periksa satu halaman yang bisa Anda uji nanti:
Sukses terlihat seperti ini: dua orang menghitung bulan contoh secara manual dan aplikasi Anda cocok persis.
Pelacak SLA yang benar dimulai dengan model data yang bisa menjelaskan mengapa sebuah angka seperti itu. Jika Anda tidak bisa menelusuri angka ketersediaan bulanan kembali ke event dan aturan yang tepat, Anda akan berdebat soal klaim pelanggan dan ketidakpastian internal.
Sebagai minimum, modelkan:
Relasi yang berguna: customer → service → SLA policy (mungkin via plan). Insiden dan event lalu merujuk ke service dan customer.
Bug terkait waktu adalah penyebab utama matematika SLA yang salah. Simpan:
occurred_at sebagai UTC (timestamp dengan semantik zona waktu)received_at (kapan sistem Anda melihatnya)source (nama monitor, integrasi, manual)external_id (untuk dedupe retry)payload (JSON mentah untuk debugging di masa depan)Juga simpan customer.timezone (string IANA seperti America/New_York) untuk tampilan dan logika “jam kerja”, tapi jangan gunakan untuk menulis ulang waktu event.
Jika SLA respons menghentikan perhitungan di luar jam kerja, modelkan kalender secara eksplisit:
working_hours per pelanggan (atau per region/service): hari-dalam-minggu + waktu mulai/akhirholiday_calendar terhubung ke region atau customer, dengan rentang tanggal dan labelBuat data aturan dapat diubah (data-driven) sehingga ops bisa memperbarui hari libur tanpa deploy.
Simpan event mentah di tabel append-only, dan simpan hasil terhitung secara terpisah (mis. sla_period_result). Setiap baris hasil harus menyertakan: batas periode, versi input (versi kebijakan + versi engine), dan referensi ke ID event yang digunakan. Ini membuat recompute aman dan memberi jejak audit saat pelanggan bertanya, “Menit outage mana yang Anda hitung?”
Angka SLA Anda hanya seakurat event yang Anda ingest. Tujuannya sederhana: tangkap setiap perubahan yang penting (outage dimulai, insiden diakui, layanan dipulihkan) dengan timestamp yang konsisten dan konteks yang cukup untuk menghitung kepatuhan nanti.
Kebanyakan tim menarik dari campuran sistem:
Webhooks biasanya terbaik untuk akurasi real-time dan beban lebih rendah: sistem sumber mendorong event ke endpoint Anda.
Polling berguna bila webhooks tidak tersedia: aplikasi Anda secara berkala mengambil perubahan sejak cursor terakhir. Anda perlu menangani rate-limit dan logika “since” dengan hati-hati.
Impor CSV membantu backfill dan migrasi. Perlakukan ini sebagai jalur ingest kelas satu agar Anda bisa memproses ulang periode historis tanpa hacks.
Normalisasikan semuanya ke satu bentuk “event” internal, walau payload upstream berbeda:
event_id (wajib): unik dan stabil terhadap retry. Prefer GUID sumber; jika tidak, buat hash deterministik.source (wajib): mis. datadog, servicenow, manual.event_type (wajib): mis. incident_opened, incident_acknowledged, service_down, service_up.occurred_at (wajib): waktu event terjadi (bukan saat Anda menerimanya), dengan zona waktu.received_at (sistem): saat aplikasi Anda menginsersinya.service_id (wajib): layanan yang relevan dengan SLA yang dipengaruhi.incident_id (opsional tapi direkomendasikan): menghubungkan beberapa event ke satu insiden.attributes (opsional): priority, region, customer segment, dll.Simpan event_id dengan unique constraint untuk membuat ingest idempotent: retry tidak akan membuat duplikat.
Tolak atau karantina event yang:
occurred_at sangat di masa depan.service_id yang dikenal (atau wajibkan workflow “unmapped”).event_id yang ada.Disiplin awal ini menyelamatkan Anda dari berdebat soal laporan SLA nanti—karena Anda bisa menunjuk input yang bersih dan terlacak.
Engine perhitungan adalah tempat “event mentah” menjadi hasil SLA yang bisa Anda pertahankan. Kuncinya adalah memperlakukan ini seperti accounting: aturan deterministik, input jelas, dan jejak yang bisa diputar ulang.
Konversikan semuanya ke satu aliran terurut per insiden (atau per dampak layanan):
Dari timeline ini, hitung durasi dengan menjumlahkan interval, bukan mengurangkan dua timestamp secara sembarangan.
Definisikan TTFR sebagai waktu berlalu “yang dikenakan biaya” antara incident_start dan first_agent_response (atau acknowledged, tergantung redaksi SLA Anda). Definisikan TTR sebagai waktu berlalu “yang dikenakan biaya” antara incident_start dan resolved.
“Dikenakan biaya” berarti Anda menghapus interval yang tidak boleh dihitung:
Detail implementasi: simpan fungsi kalender (jam kerja, hari libur) dan fungsi aturan yang mengambil timeline dan mengembalikan interval billable.
Putuskan lebih awal apakah Anda menghitung:
Untuk outage parsial, timbang berdasarkan dampak hanya jika kontrak SLA Anda mengharuskannya; kalau tidak, perlakukan “degradasi” sebagai kategori pelanggaran tersendiri.
Setiap perhitungan harus dapat direproduksi. Persist:
Saat aturan berubah, Anda bisa menjalankan ulang perhitungan berdasarkan versi tanpa menulis ulang sejarah—krusial untuk audit dan sengketa pelanggan.
Pelaporan adalah tempat pelacakan SLA mendapatkan kepercayaan—atau dipertanyakan. Aplikasi Anda harus membuat jelas range waktu yang diukur, menit mana yang dihitung, dan bagaimana angka akhir diturunkan.
Dukung periode pelaporan umum yang benar-benar digunakan pelanggan Anda:
Simpan periode sebagai timestamp mulai/akhir eksplisit (jangan hanya “bulan = 3”) agar Anda bisa memutar ulang perhitungan dan menjelaskan hasil.
Sumber kebingungan sering adalah apakah penyebut adalah seluruh periode atau hanya waktu “eligible”.
Definisikan dua nilai per periode:
Lalu hitung:
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
Jika eligible minutes bisa nol (mis. layanan hanya dimonitor saat jam kerja dan periode tidak mengandung jam kerja), definisikan aturan di depan: tampilkan “N/A” atau perlakukan sebagai 100%—tetapi konsisten dan dokumentasikan.
Sebagian besar SLA membutuhkan persentase dan hasil biner.
Juga simpan “jarak ke pelanggaran” (sisa anggaran downtime) agar dashboard dapat memperingatkan sebelum ambang dilintasi.
Terakhir, simpan input mentah (event yang termasuk/dikecualikan dan penyesuaian) sehingga setiap laporan bisa menjawab “kenapa angka ini seperti ini?” tanpa basa-basi.
Engine perhitungan Anda bisa sempurna dan tetap mengecewakan pengguna jika UI tidak menjawab pertanyaan dasar: “Apakah kita memenuhi SLA sekarang, dan kenapa?” Rancang aplikasi agar setiap layar dimulai dengan status jelas, lalu biarkan orang menggali angka dan event mentah yang menghasilkan angka tersebut.
Overview dashboard (untuk operator dan manajer). Awali dengan beberapa tile kecil: kepatuhan periode berjalan, availability, kepatuhan waktu-respons, dan “waktu tersisa sebelum pelanggaran” bila berlaku. Gunakan label eksplisit (mis. “Availability (this month)” daripada “Uptime”). Jika Anda mendukung beberapa SLA per pelanggan, tunjukkan status terburuk terlebih dahulu dan biarkan pengguna memperluas.
Detail pelanggan (untuk tim akun dan pelaporan ke pelanggan). Halaman pelanggan harus merangkum semua layanan dan tier SLA untuk pelanggan itu, dengan status sederhana lulus/peringatan/gagal dan penjelasan singkat (“2 insiden dihitung; 18m downtime dihitung”). Tambahkan tautan ke /status (jika Anda menyediakan halaman status yang terlihat pelanggan) dan ke ekspor laporan.
Detail layanan (untuk investigasi mendalam). Di sini tampilkan aturan SLA lengkap, jendela perhitungan, dan rincian bagaimana angka kepatuhan dibentuk. Sertakan grafik availability dari waktu ke waktu dan daftar insiden yang dihitung terhadap SLA.
Timeline insiden (untuk audit). Tampilan satu insiden harus menunjukkan timeline event (terdeteksi, diakui, dimitigasi, diselesaikan) dan timestamp mana yang dipakai untuk metrik “respons” dan “resolusi”.
Buat filter konsisten antar layar: rentang tanggal, pelanggan, layanan, tier, dan severity. Gunakan unit yang sama di mana-mana (menit vs detik; persentase dengan desimal yang konsisten). Saat pengguna mengubah rentang tanggal, perbarui setiap metrik di halaman agar tidak ada mismatch.
Setiap metrik ringkasan harus punya jalur “Kenapa?”:
Gunakan tooltip secara hemat untuk mendefinisikan istilah seperti “Excluded downtime” atau “Business hours,” dan tampilkan teks aturan persis pada halaman layanan agar orang tidak menebak.
Lebih suka bahasa biasa daripada singkatan (“Response time” daripada “MTTA” kecuali audiens Anda mengharapkannya). Untuk status, kombinasikan warna dengan label teks (“Berisiko: 92% anggaran error digunakan”) untuk menghindari ambiguitas. Jika aplikasi Anda mendukung log audit, tambahkan kotak kecil “Terakhir diubah” pada aturan SLA dan pengecualian yang menautkan ke /audit agar pengguna bisa memverifikasi kapan definisi berubah.
Alerting adalah tempat aplikasi pelacak SLA Anda berhenti jadi laporan pasif dan mulai membantu tim menghindari penalti. Alert terbaik adalah tepat waktu, spesifik, dan dapat ditindaklanjuti—berarti memberi tahu seseorang apa yang harus dilakukan selanjutnya, bukan hanya bahwa sesuatu “buruk.”
Mulai dengan tiga tipe trigger:
Buat trigger bisa dikonfigurasi per pelanggan/layanan/SLA, karena kontrak berbeda mentolerir ambang yang berbeda.
Kirim alert ke tempat orang benar-benar merespons:
Setiap alert harus menyertakan deep link seperti /alerts, /customers/{id}, /services/{id}, dan halaman detail insiden atau event sehingga responder bisa memverifikasi angka dengan cepat.
Implementasikan deduplication dengan mengelompokkan alert yang punya key sama (customer + service + SLA + period) dan menekan pengulangan selama jendela cooldown.
Tambahkan quiet hours (per zona waktu tim) sehingga alert “approaching breach” non-kritis menunggu sampai jam kerja, sementara “breach occurred” bisa menimpa quiet hours jika severity tinggi.
Terakhir, dukung aturan eskalasi (mis. beri tahu on-call setelah 10 menit, eskalasi ke manajer setelah 30) untuk mencegah alert terhenti di satu inbox.
Data SLA sensitif karena dapat mengekspos performa internal dan hak khusus pelanggan. Perlakukan kontrol akses sebagai bagian dari “matematika” SLA: insiden yang sama dapat menghasilkan hasil kepatuhan berbeda bergantung SLA yang diterapkan.
Sederhanakan peran, lalu kembangkan izin yang lebih rinci.
Default praktis adalah RBAC + tenant scoping:
Jadilah eksplisit tentang data khusus pelanggan:
Mulai dengan email/password dan wajibkan MFA untuk peran internal. Rencanakan SSO nanti (SAML/OIDC) dengan memisahkan identitas (siapa mereka) dari otorisasi (apa yang bisa diakses). Untuk integrasi, keluarkan API keys yang terkait akun service dengan scope sempit dan dukungan rotasi.
Tambahkan entri audit immutable untuk:
Simpan siapa, apa yang berubah (sebelum/sesudah), kapan, di mana (IP/user agent), dan correlation ID. Buat log audit bisa dicari dan diekspor (mis. /settings/audit-log).
Aplikasi pelacak SLA jarang berdiri sendiri. Anda ingin API yang membiarkan tool monitoring, sistem tiket, dan workflow internal membuat insiden, mendorong event, dan mengambil laporan tanpa kerja manual.
Gunakan base path ber-version (mis. /api/v1/...) sehingga Anda bisa mengembangkan payload tanpa memecah integrasi yang ada.
Endpoint esensial untuk menutupi kebanyakan use case:
POST /api/v1/events untuk ingest perubahan status (up/down, sampel latensi, jendela pemeliharaan). GET /api/v1/events untuk audit dan debugging.POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (acknowledge, resolve, assign), GET /api/v1/incidents.GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} untuk mengelola kontrak dan threshold.GET /api/v1/reports/sla?service_id=...&from=...&to=... untuk ringkasan kepatuhan.POST /api/v1/alerts/subscriptions untuk mengelola webhook/target email; GET /api/v1/alerts untuk riwayat alert.Pilih satu konvensi dan gunakan di mana-mana. Misalnya: pagination limit, cursor, plus filter standar seperti service_id, sla_id, status, from, dan to. Buat sorting predictable (mis. sort=-created_at).
Kembalikan error terstruktur dengan field stabil:
{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": { "service_id": "missing" } } }
Gunakan HTTP status yang jelas (400 validation, 401/403 auth, 404 not found, 409 conflict, 429 rate limit). Untuk ingest event, pertimbangkan idempotensi (Idempotency-Key) sehingga retry tidak menduplikasi insiden.
Terapkan rate limit wajar per token (dan limit lebih ketat untuk endpoint ingest), sanitasi input, dan validasi timestamp/zona waktu. Prefer token API yang di-scope (read-only reporting vs write access ke incidents), dan selalu log siapa memanggil endpoint untuk keterlacakan (detail ada di bagian audit log di /blog/audit-logs).
Angka SLA berguna hanya jika orang mempercayainya. Pengujian untuk aplikasi pelacak SLA harus fokus lebih pada “apakah matematika waktu berperilaku persis seperti kontrak” daripada sekadar “apakah halaman dimuat”. Perlakukan aturan perhitungan sebagai fitur produk dengan test suite sendiri.
Mulai dengan unit test engine perhitungan SLA menggunakan input deterministik: timeline event (insiden dibuka, diakui, dimitigasi, diselesaikan) dan set aturan SLA yang jelas.
Gunakan timestamp tetap dan “freeze time” sehingga test tidak bergantung pada jam. Tutupi kasus tepian yang sering merusak pelaporan SLA:
Tambahkan beberapa end-to-end test yang menjalankan aliran penuh: ingest event → hitung kepatuhan → hasilkan laporan → render UI. Ini menangkap mismatch antara “apa yang dihitung engine” dan “apa yang ditampilkan dashboard.” Simpan skenario sedikit tapi bernilai tinggi, dan assert pada angka akhir (availability %, breach ya/tidak, waktu-ke-ack).
Buat test fixture untuk jam kerja, hari libur, dan zona waktu. Anda butuh kasus yang dapat diulang seperti “insiden terjadi Jumat 17:55 waktu lokal” dan “hari libur menggeser perhitungan waktu respons.”
Pengujian tidak berhenti saat deploy. Tambahkan monitoring untuk kegagalan job, ukuran antrean/backlog, durasi recalculation, dan rate error. Jika ingest tertunda atau job nightly gagal, laporan SLA bisa salah walau kode benar.
Mengirim aplikasi pelacak SLA kurang soal infrastruktur canggih dan lebih soal operasi yang dapat diprediksi: perhitungan harus berjalan tepat waktu, data harus aman, dan laporan harus dapat direproduksi.
Mulai dengan layanan terkelola sehingga Anda bisa fokus pada kebenaran.
Jaga lingkungan minimal: dev → staging → prod, masing-masing dengan database dan secret sendiri.
Pelacakan SLA bukan murni request/response; ia bergantung pada pekerjaan terjadwal.
Jalankan job lewat proses worker + queue, atau scheduler terkelola yang memanggil endpoint internal. Buat job idempotent (aman di-retry) dan log setiap run untuk auditability.
Tentukan retensi berdasarkan tipe data: simpan hasil kepatuhan turunan lebih lama daripada stream event mentah. Untuk ekspor, tawarkan CSV dulu (cepat, transparan), lalu template PDF nanti. Jelaskan: ekspor adalah “formatasi best-effort,” sementara database tetap sumber kebenaran.
Jika Anda ingin memvalidasi model data, alur ingest, dan UI pelaporan dengan cepat, platform vibe-coding seperti Koder.ai dapat membantu Anda mencapai prototipe end-to-end tanpa komitmen siklus engineering penuh. Karena Koder.ai menghasilkan aplikasi lengkap via chat (UI web plus backend), ini cara praktis untuk memutar:
Setelah requirement dan perhitungan terbukti (bagian tersulit), Anda bisa iterasi, ekspor source code, dan pindah ke workflow build-and-operate tradisional—sambil mempertahankan fitur seperti snapshot dan rollback selama iterasi cepat.
Aplikasi pelacak SLA menjawab satu pertanyaan dengan bukti: apakah Anda memenuhi komitmen kontraktual untuk pelanggan tertentu dan periode waktu tertentu?
Dalam praktiknya, ini berarti mengonsumsi sinyal mentah (monitoring, tiket, pembaruan manual), menerapkan aturan pelanggan (jam kerja, pengecualian), dan menghasilkan hasil audit-friendly berupa lulus/gagal beserta rincian pendukung.
Gunakan:
Modelkan ketiganya secara terpisah agar Anda bisa meningkatkan keandalan (SLO) tanpa secara tidak sengaja mengubah pelaporan kontraktual (SLA).
MVP yang baik biasanya melacak 1–3 metrik secara end-to-end:
Metrik-metrik ini mudah dipetakan ke sumber data nyata dan memaksa Anda mengimplementasikan bagian rumit (periode, kalender, pengecualian) sejak awal.
Kegagalan requirement biasanya datang dari aturan yang tak tertulis. Kumpulkan dan catat:
Jika sebuah aturan tidak bisa dinyatakan dengan jelas, jangan coba “menginfer” di kode—tandai dan minta klarifikasi.
Mulailah dengan entitas yang membosankan dan eksplisit:
Tujuannya adalah keterlacakan: setiap angka yang dilaporkan harus menautkan kembali ke dan tertentu.
Simpan waktu dengan benar dan konsisten:
occurred_at dalam UTC dengan semantik zona waktureceived_at (kapan Anda menerimanya)Selanjutnya buat periode eksplisit (timestamp mulai/akhir) sehingga Anda bisa mereproduksi laporan nanti—termasuk saat adanya perubahan DST.
Normalisasikan semuanya ke dalam satu bentuk event internal dengan ID unik yang stabil:
event_id (unik, stabil terhadap retry)source, event_type, , Hitung durasi dengan menjumlahkan interval pada timeline, bukan sekadar mengurangkan dua timestamp.
Definisikan waktu “dikenakan biaya” (chargeable) secara eksplisit dengan mengeluarkan interval yang tidak dihitung, seperti:
Simpan interval turunan dan kode alasan sehingga Anda dapat menjelaskan tepat apa yang dihitung.
Lacak dua penyebut secara eksplisit:
Lalu hitung:
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
Juga tentukan apa yang terjadi bila eligible minutes bernilai nol (mis. tampilkan ). Dokumentasikan aturan ini dan terapkan secara konsisten.
Buat UI yang menjawab “apakah kita memenuhi SLA, dan kenapa?” dalam sekali lihat:
Untuk alert, prioritaskan pemicu yang dapat ditindaklanjuti: approaching breach, breach occurred, dan pelanggaran berulang—masing-masing menautkan ke halaman relevan seperti atau .
occurred_atservice_idincident_id dan attributesTerapkan idempotensi dengan constraint unik pada event_id. Untuk pemetaan yang hilang atau kedatangan out-of-order, karantina/tandai—jangan “memperbaiki” data secara diam-diam.
/customers/{id}/services/{id}