Cara Membangun Aplikasi Web yang Melacak Kepatuhan SLA Secara Akurat

Tetapkan Kepatuhan SLA dan Apa yang Akan Anda Bangun

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:

• SLI (Service Level Indicator): pengukuran mentah (misalnya, “persentase pemeriksaan sukses,” “waktu ke respons pertama,” atau “waktu untuk memulihkan layanan”).
• SLO (Service Level Objective): target internal untuk sebuah SLI (seringkali lebih ketat daripada SLA). Contoh: “target uptime 99,95%.”
• SLA: komitmen eksternal yang disepakati, sering terkait kredit atau penalti. Contoh: “99,9% uptime bulanan.”

Metrik SLA umum yang akan Anda lacak

Kebanyakan aplikasi pelacak SLA memulai dengan seperangkat metrik kecil yang dipetakan ke data operasional nyata:

• Uptime / availability: persentase waktu layanan “up” selama periode pelaporan.
• Waktu respons (support): waktu dari pembuatan tiket pelanggan hingga respons manusia pertama.
• Waktu penyelesaian: waktu dari pembuatan insiden/tiket hingga penutupan atau pemulihan.
• Jendela ketersediaan: aturan seperti “hitung hanya jam kerja,” “kecualikan pemeliharaan terjadwal,” atau “ukur hanya dari 08:00–18:00 di zona waktu pelanggan.”

Siapa yang menggunakan aplikasi—dan kenapa

Pengguna berbeda menginginkan kebenaran yang sama, disajikan berbeda:

• Tim Operasi/SRE: mendeteksi pelanggaran lebih awal dan memvalidasi timeline insiden.
• Tim Support: melacak komitmen respons dan penyelesaian per pelanggan.
• Manajer: melihat tren, risiko, dan apakah tim konsisten memenuhi target.
• Pelanggan: melihat laporan transparan (dan kadang halaman status) yang menunjukkan apa yang terjadi.

Apa yang Anda bangun (dan apa yang bukan)

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.

Persyaratan: Metrik, Aturan, dan Siapa Butuh Apa

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.

Kumpulkan input (dan jangan hanya mengandalkan ingatan)

Mulailah dengan mengumpulkan sumber kebenaran:

• Kontrak pelanggan dan MSA (termasuk lampiran dan addenda tiket)
• Tier layanan (mis. Basic vs. Premium), dan pelanggan mana yang masuk tiap tier
• Jam kerja dan zona waktu per pelanggan (atau per layanan)
• Pengecualian dan aturan khusus: jendela pemeliharaan terjadwal, force majeure, keterlambatan yang disebabkan pelanggan, ketergantungan pihak ketiga, masa tenggang

Tulis aturan-aturan ini secara eksplisit. Jika sebuah aturan tidak bisa dinyatakan jelas, itu tidak bisa dihitung dengan andal.

Tentukan apa yang harus dilacak

Daftar “benda” dunia nyata yang dapat memengaruhi angka SLA:

• Insiden/outage (mulai, berakhir, severity, layanan terdampak)
• Permintaan/tiket (dibuat, respons pertama, penyelesaian, menunggu pelanggan)
• Pemeliharaan (terjadwal vs darurat; apakah dihitung terhadap availability)
• Outage parsial (degradasi performa) dan apakah dihitung sama sekali

Juga identifikasi siapa yang membutuhkan apa: support ingin risiko pelanggaran real-time, manajer ingin rollup mingguan, pelanggan ingin ringkasan sederhana (sering untuk halaman status).

Pilih 1–3 metrik untuk rilis pertama

Jaga ruang lingkup kecil. Pilih set minimum yang membuktikan sistem bekerja end-to-end, seperti:

• Persentase availability per layanan per bulan
• Waktu respons insiden (respons manusia pertama) selama jam kerja
• Waktu penyelesaian untuk insiden severity-1

Daftar periksa persyaratan dan kriteria sukses

Buat daftar periksa satu halaman yang bisa Anda uji nanti:

• Definisi metrik yang jelas (timestamp mulai/berhenti, zona waktu, pembulatan)
• Aturan inklusi/eksklusi (pemeliharaan, waktu menunggu pelanggan)
• Ambang target per tier (mis. 99,9%, respons 1 jam)
• Keluaran yang dibutuhkan (laporan pelanggan, dashboard internal, ekspor)

Sukses terlihat seperti ini: dua orang menghitung bulan contoh secara manual dan aplikasi Anda cocok persis.

Model Data untuk SLA, Layanan, Insiden, dan Event

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.

Entitas inti (buat sesederhana dan sejelas mungkin)

Sebagai minimum, modelkan:

• Customer (tenant/account): pemilik layanan, kalender, kontak, dan preferensi pelaporan.
• Service: objek yang diukur (API, aplikasi web, komponen per-region). Sertakan relasi parent/child opsional jika Anda akan merangkum beberapa komponen.
• Plan: pembungkus komersial (mis. “Gold”), digunakan untuk melampirkan set kebijakan SLA default.
• SLA policy: aturan terukur: target uptime, target waktu respons, jendela pengukuran, dan apa yang dianggap “dikecualikan.”
• Incident: pengelompokan yang mudah dibaca manusia (judul, severity, timeline) yang merujuk ke event dasar.
• Event: fakta tak berubah (perubahan status, sinyal monitoring, acknowledgement) yang mendorong perhitungan.

Relasi yang berguna: customer → service → SLA policy (mungkin via plan). Insiden dan event lalu merujuk ke service dan customer.

Skema minimal untuk pelacakan berbasis waktu

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.

Jam kerja dan hari libur

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/akhir
• holiday_calendar terhubung ke region atau customer, dengan rentang tanggal dan label

Buat data aturan dapat diubah (data-driven) sehingga ops bisa memperbarui hari libur tanpa deploy.

Auditability: raw vs calculated

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?”

Ingest Event: Bagaimana Data Masuk ke Aplikasi Anda

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.

Sumber event umum

Kebanyakan tim menarik dari campuran sistem:

• Ticketing / incident tools (Jira Service Management, ServiceNow, Zendesk): timestamp dibuat/diakui/diselesaikan, perubahan prioritas, perubahan assignee.
• Monitoring tools (Pingdom, Datadog, CloudWatch, Prometheus Alertmanager): sinyal up/down, alert fired/cleared, hasil pemeriksaan sintetis.
• Log infrastruktur dan aplikasi: event deploy, lonjakan error, kegagalan health check (berguna saat monitoring bising atau kurang).
• Entri manual: UI kecil untuk “outage diverifikasi bisnis mulai/akhir” atau “pemeliharaan dimulai” saat otomasi tidak tahu kebenaran.

Opsi ingest (dan kapan dipakai)

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.

Format event yang direkomendasikan (dengan idempotensi)

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.

Aturan validasi yang mencegah data buruk

Tolak atau karantina event yang:

• Memiliki timestamp hilang/invalid, atau occurred_at sangat di masa depan.
• Tidak memetakan ke service_id yang dikenal (atau wajibkan workflow “unmapped”).
• Menggandakan event_id yang ada.
• Datang out-of-order sehingga merusak aturan Anda (tetap simpan, tapi tandai sebagai “perlu review” daripada menimpa tanpa jejak).

Disiplin awal ini menyelamatkan Anda dari berdebat soal laporan SLA nanti—karena Anda bisa menunjuk input yang bersih dan terlacak.

Engine Perhitungan SLA: Mengubah Event Menjadi Kepatuhan

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.

Mulai dengan timeline yang dinormalisasi

Konversikan semuanya ke satu aliran terurut per insiden (atau per dampak layanan):

• timestamp (UTC) untuk: insiden dimulai, diakui/respons pertama, dimitigasi, diselesaikan, dibuka kembali
• perubahan status: paused/unpaused, menunggu pelanggan, jendela pemeliharaan aktif
• lingkup: layanan(s) dan pelanggan yang terdampak, dan pada severity berapa

Dari timeline ini, hitung durasi dengan menjumlahkan interval, bukan mengurangkan dua timestamp secara sembarangan.

Time-to-first-response (TTFR) dan time-to-resolution (TTR)

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:

• di luar jam kerja (untuk SLA jam kerja)
• jeda eksplisit (mis. “menunggu pelanggan”)
• pengecualian seperti pemeliharaan terjadwal atau keterlambatan yang disebabkan pelanggan

Detail implementasi: simpan fungsi kalender (jam kerja, hari libur) dan fungsi aturan yang mengambil timeline dan mengembalikan interval billable.

Outage parsial dan insiden multi-layanan

Putuskan lebih awal apakah Anda menghitung:

• SLA per-layanan (direkomendasikan): satu insiden dapat menghasilkan beberapa record dampak layanan, masing-masing dengan TTFR/TTR sendiri
• SLA per-pelanggan: outage yang sama mungkin hanya memengaruhi subset tenant

Untuk outage parsial, timbang berdasarkan dampak hanya jika kontrak SLA Anda mengharuskannya; kalau tidak, perlakukan “degradasi” sebagai kategori pelanggaran tersendiri.

Keterlacakan: simpan input, output, dan replay

Setiap perhitungan harus dapat direproduksi. Persist:

• event tepat yang digunakan (dengan id, timestamp, dan sumber)
• interval turunan (apa yang dikecualikan dan kenapa)
• hasil akhir (TTFR, TTR, flag pelanggaran, dan versi aturan)

Saat aturan berubah, Anda bisa menjalankan ulang perhitungan berdasarkan versi tanpa menulis ulang sejarah—krusial untuk audit dan sengketa pelanggan.

Logika Pelaporan: Periode, Ketersediaan, dan Kasus Tepian

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.

Periode: kalender, penagihan, dan rolling windows

Dukung periode pelaporan umum yang benar-benar digunakan pelanggan Anda:

• Bulanan/kuartalan kalender (mis. 1–31 Maret)
• Siklus penagihan (mis. 15–14, disinkronkan ke faktur)
• Rolling windows (mis. “30 hari terakhir” yang diperbarui harian)

Simpan periode sebagai timestamp mulai/akhir eksplisit (jangan hanya “bulan = 3”) agar Anda bisa memutar ulang perhitungan dan menjelaskan hasil.

Ketersediaan: total minutes vs eligible minutes

Sumber kebingungan sering adalah apakah penyebut adalah seluruh periode atau hanya waktu “eligible”.

Definisikan dua nilai per periode:

• Eligible minutes: menit yang dihitung untuk SLA (seringkali mengecualikan pemeliharaan terjadwal, outage yang disebabkan pelanggan, atau waktu di luar jam support)
• Downtime minutes: menit eligible saat layanan dianggap down

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.

Mengubah angka menjadi lulus/gagal yang jelas

Sebagian besar SLA membutuhkan persentase dan hasil biner.

• Persentase: mis. 99,95% untuk periode
• Pass/Fail: bandingkan dengan target SLA (mis. lulus jika ≥ 99,9%)

Juga simpan “jarak ke pelanggaran” (sisa anggaran downtime) agar dashboard dapat memperingatkan sebelum ambang dilintasi.

Kasus tepian yang harus Anda tangani dengan sengaja

• Zona waktu: pilih zona laporan per pelanggan/kontrak (sering zona pelanggan) dan konversi event secara konsisten.
• Daylight saving time: jangan pernah mengasumsikan satu hari selalu 1440 menit. Gunakan timestamp aware timezone agar panjang periode benar pada transisi DST.
• End time yang hilang: insiden kadang tidak memiliki timestamp resolved. Perlakukan sebagai “terbuka” dan batasi pada waktu akhir laporan, sambil menandai record untuk pembersihan.

Terakhir, simpan input mentah (event yang termasuk/dikecualikan dan penyesuaian) sehingga setiap laporan bisa menjawab “kenapa angka ini seperti ini?” tanpa basa-basi.

UI dan Dashboard yang Membuat Status SLA Jelas

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.

Tampilan utama yang perlu dibangun

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”.

Filter yang cocok untuk pertanyaan nyata

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.

Drill-down tanpa kehilangan kepercayaan

Setiap metrik ringkasan harus punya jalur “Kenapa?”:

• Dari persentase kepatuhan → daftar insiden yang dihitung dalam periode itu.
• Dari sebuah insiden → event mentah dan timestamp turunan yang dipakai dalam perhitungan.
• Dari availability → interval downtime dengan sumber (event monitoring vs penyesuaian manual).

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.

Jaga sederhana, tetapi tak salah-salah

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 dan Notifikasi untuk Pelanggaran

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.”

Definisikan trigger alert yang cocok untuk keputusan nyata

Mulai dengan tiga tipe trigger:

• Approaching breach: mis. “Anda memiliki 30 menit tersisa untuk memenuhi SLA waktu-respons,” atau “Availability bulan ini turun ke 99.92% sedangkan SLA 99.9%.” Alert ini paling berharga karena memungkinkan pemulihan.
• Breach occurred: terpicu ketika engine perhitungan mengonfirmasi SLA terlewat untuk window terkait.
• Pelanggaraan berulang: deteksi pola seperti “3 pelanggaran dalam 30 hari” atau “layanan sama melanggar dua kali minggu ini,” yang sering menandakan masalah sistemik.

Buat trigger bisa dikonfigurasi per pelanggan/layanan/SLA, karena kontrak berbeda mentolerir ambang yang berbeda.

Pilih channel dan buat pesan bisa ditindaklanjuti

Kirim alert ke tempat orang benar-benar merespons:

• Email untuk notifikasi audit-friendly dan stakeholder eksternal.
• Slack untuk koordinasi internal cepat.
• SMS (opsional) untuk eskalasi severity tinggi.

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.

Kurangi noise: deduplikasi, quiet hours, eskalasi

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.

Kontrol Akses, Autentikasi, dan Log Audit

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.

Peran yang perlu didukung sejak awal

Sederhanakan peran, lalu kembangkan izin yang lebih rinci.

• Admin: mengonfigurasi pengaturan global, mengelola layanan, SLA, pengguna, integrasi, dan item terkait billing.
• Agent: membuat/memperbarui insiden dan jendela pemeliharaan, melampirkan event, dan menambahkan catatan postmortem.
• Manager: membaca semua hal dalam scope mereka, menyetujui definisi SLA, dan mengekspor laporan.
• Customer viewer: hanya melihat layanan mereka sendiri, target SLA, riwayat insiden, dan laporan yang terlihat pelanggan.

Default praktis adalah RBAC + tenant scoping:

• Setiap record (service, SLA policy, laporan) memiliki owner tenant/customer.
• Pengguna internal bisa di-scope ke banyak tenant; viewer pelanggan ke tepat satu.
• Izin edit lebih sempit daripada view: mis. agent bisa mengedit insiden tapi tidak bisa mengubah aturan SLA.

Apa yang bisa dilihat/diedit tiap peran

Jadilah eksplisit tentang data khusus pelanggan:

• Viewer pelanggan tidak boleh melihat field internal (hipotesis root cause, severity internal, catatan on-call, tag privat).
• SLA policy harus versioned sehingga pelanggan bisa melihat ketentuan SLA yang berlaku pada saat suatu insiden.

Opsi autentikasi yang tidak membuat Anda terjebak

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.

Log audit yang akan Anda syukuri

Tambahkan entri audit immutable untuk:

• Perubahan aturan SLA (threshold, kalender, pengecualian, pemetaan ke layanan/pelanggan)
• Edit insiden (timestamp, transisi status, override downtime manual)
• Perubahan permission dan API key

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).

Desain API untuk Integrasi dan Otomasi

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.

Mulai dengan surface kecil dan terduga

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:

• Events: POST /api/v1/events untuk ingest perubahan status (up/down, sampel latensi, jendela pemeliharaan). GET /api/v1/events untuk audit dan debugging.
• Incidents: POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (acknowledge, resolve, assign), GET /api/v1/incidents.
• SLAs: GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} untuk mengelola kontrak dan threshold.
• Reports: GET /api/v1/reports/sla?service_id=...&from=...&to=... untuk ringkasan kepatuhan.
• Alerts: POST /api/v1/alerts/subscriptions untuk mengelola webhook/target email; GET /api/v1/alerts untuk riwayat alert.

Buat pagination dan filtering konsisten

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).

Definisikan response error yang bisa diandalkan integrator

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.

Rate limit dan keamanan dasar

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).

Strategi Pengujian: Buktikan Angka Tepat

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.

Unit-test aturan dengan timeline tetap

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:

• Insiden mulai sebelum periode pelaporan dan berakhir di dalamnya
• Insiden yang tumpang tindih (haruskah downtime bergabung atau menumpuk?)
• Beberapa jeda (pemeliharaan, keterlambatan yang disebabkan pelanggan)
• Batas menit/detik (tepat pada 00:00, akhir bulan, leap day)

End-to-end test untuk seluruh pipeline

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).

Bangun fixtures yang dapat digunakan ulang untuk kalender dan zona waktu

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.”

Pantau aplikasi SLA itu sendiri

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.

Deployment, Operasi, dan Roadmap MVP Praktis

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.

Jalur deployment sederhana dan andal

Mulai dengan layanan terkelola sehingga Anda bisa fokus pada kebenaran.

• Database terkelola (PostgreSQL): backup otomatis, point-in-time recovery, enkripsi.
• Hosting container untuk web/API (mis. platform container terkelola): rollback mudah dan lingkungan konsisten.
• Object storage untuk ekspor (CSV/PDF) dan artefak besar, dengan lifecycle rules.

Jaga lingkungan minimal: dev → staging → prod, masing-masing dengan database dan secret sendiri.

Background job yang Anda butuhkan sejak hari pertama

Pelacakan SLA bukan murni request/response; ia bergantung pada pekerjaan terjadwal.

• Calculation jobs: recompute window SLA dari event baru, dan rerun setelah data terlambat tiba.
• Report generation: ringkasan harian/bulanan, ekspor siap pelanggan.
• Data hygiene: arsip event mentah lama, kompaks derived tables, verifikasi integritas referensial.

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.

Retensi dan ekspor (tanpa berlebihan janji)

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.

Roadmap bertahap yang menjaga scope terkendali

1. MVP: satu layanan, satu SLA, satu zona waktu, dashboard dasar + laporan bulanan.
2. Lebih banyak metrik: SLA waktu-respons, jendela pemeliharaan, pengecualian, banyak kalender.
3. Portal pelanggan: tampilan per-pelanggan, kontrol akses, laporan yang dapat diunduh.
4. Halaman status: halaman publik/private yang didukung availability terhitung Anda (lihat /blog/status-pages).

Prototyping lebih cepat dengan Koder.ai (opsional)

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:

• dashboard React untuk kepatuhan, anggaran error, dan timeline drill-down,
• backend Go + PostgreSQL untuk menyimpan event mentah dan hasil periode,
• endpoint ekspor/laporan dan tampilan portal pelanggan sederhana.

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.