Data Observability: Ngedeteksi Pipeline yang Diam-diam Rusak

Data observability adalah praktik mantau kesehatan data secara terus-menerus supaya kamu tau kapan angkanya mulai salah, bahkan waktu nggak ada satu pun pesan error yang muncul.

Pipeline yang mati total gampang ketahuan. Yang mahal itu pipeline yang tetap jalan, status tetap hijau, tapi satu kolom udah kosong sejak tiga minggu lalu.

Aku bakal jelasin lima hal yang dipantau, query yang bisa kamu pasang hari ini, dan cara nentuin ambang peringatan biar nggak jadi berisik.

Apa itu data observability?

Data observability adalah kemampuan tau kondisi data kamu tanpa harus nunggu ada yang komplain. Caranya dengan ngukur beberapa sinyal secara rutin, nyimpen riwayatnya, lalu ngasih peringatan waktu sinyalnya keluar dari kebiasaan.

Bedanya sama data quality: data quality ngomongin seberapa benar datanya sekarang, data observability ngomongin cara kamu ngawasin kebenaran itu dari hari ke hari.

Istilah ini muncul dari dunia analytics engineering, tapi praktiknya bisa dipakai siapa aja yang punya ETL jalan rutin. Termasuk kalau pipeline kamu cuma satu script Python yang jalan tiap subuh.

Kenapa pipeline bisa rusak tanpa nampilin error?

Karena sebagian besar kerusakan data itu sah secara teknis. Empat contoh yang paling sering aku temui.

Sumbernya ganti nama kolom. Tim aplikasi ubah kode_promo jadi promo_code. Query kamu masih jalan, kolom lamanya masih ada, isinya aja yang berhenti diisi.

Filter jadi kelewat ketat. Ada yang nambahin syarat di query sumber. Jumlah baris turun 30%, dan nggak ada yang error karena hasilnya tetap valid.

Zona waktu geser. Server pindah dari WIB ke UTC. Data harian jadi kepotong tujuh jam, dan angka hari terakhir selalu kelihatan rendah.

Muat data dobel. Job dijalankan dua kali karena percobaan ulang. Semua angka naik dua kali lipat, dan itu malah kelihatan kayak bulan yang bagus.

Nggak satu pun dari empat hal ini bikin pipeline gagal. Semuanya bikin angkanya salah.

Apa aja yang dipantau di data observability?

Pilar	Pertanyaan yang dijawab	Contoh sinyal buruk
Kesegaran	Kapan terakhir data masuk?	Baris terbaru umurnya 26 jam padahal jadwalnya tiap 6 jam
Volume	Berapa banyak baris masuk?	Hari ini 4.100 baris, rata-rata biasanya 9.800
Skema	Ada kolom yang berubah?	Tipe kolom berubah dari numeric jadi text
Sebaran nilai	Isinya masih masuk akal?	Proporsi nilai kosong naik dari 6% ke 41%
Asal-usul	Tabel ini dipakai siapa aja?	Nggak ada yang tau dashboard mana yang kena waktu tabel diubah

Empat pilar pertama bisa kamu ukur pakai SQL biasa. Pilar kelima butuh pencatatan hubungan antartabel, dan buat tim kecil biasanya cukup ditulis manual di satu dokumen.

Query pemantauan apa yang bisa dipasang hari ini?

Lima query ini pakai sintaks PostgreSQL. Jadwalkan tiap hari setelah pipeline selesai, kirim hasilnya ke chat kerja.

1. Kesegaran data

SELECT
  MAX(created_at) AS terakhir_masuk,
  NOW() - MAX(created_at) AS umur_data
FROM transaksi;

Kalau umur_data lebih besar dari dua kali jeda muat data normal, itu tanda bahaya.

2. Volume harian dibanding kebiasaan

WITH harian AS (
  SELECT DATE(created_at) AS tgl, COUNT(*) AS baris
  FROM transaksi
  WHERE created_at >= NOW() - INTERVAL '30 days'
  GROUP BY 1
)
SELECT
  tgl,
  baris,
  ROUND(AVG(baris) OVER (
    ORDER BY tgl ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING
  )) AS rata_7_hari
FROM harian
ORDER BY tgl DESC;

Bandingin kolom baris sama rata_7_hari. Selisih lebih dari 40% layak dicek.

3. Proporsi nilai kosong

SELECT
  DATE(created_at) AS tgl,
  COUNT(*) AS total,
  COUNT(*) FILTER (WHERE kode_promo IS NULL) AS kosong,
  ROUND(100.0 * COUNT(*) FILTER (WHERE kode_promo IS NULL)
        / COUNT(*), 1) AS persen_kosong
FROM transaksi
WHERE created_at >= NOW() - INTERVAL '14 days'
GROUP BY 1
ORDER BY 1 DESC;

Klausa FILTER ini fitur standar PostgreSQL, penjelasannya ada di dokumentasi resmi PostgreSQL.

4. Duplikat kunci utama

SELECT id_pesanan, COUNT(*) AS jumlah
FROM transaksi
GROUP BY id_pesanan
HAVING COUNT(*) > 1
ORDER BY jumlah DESC
LIMIT 20;

Hasil kosong itu yang kamu mau. Begitu ada isinya, kemungkinan besar ada muat data dobel.

5. Perubahan skema

SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_name = 'transaksi'
ORDER BY ordinal_position;

Simpan hasilnya tiap hari di tabel riwayat. Bandingin sama hasil kemarin, dan kamu langsung tau ada kolom yang berubah.

Contoh kasus: kolom promo yang diam-diam kosong

Di pipeline latihan toko_berkah, kolom kode_promo biasanya kosong di sekitar 6% baris. Angka itu wajar, karena nggak semua pembeli pakai promo.

Mulai 12 Mei 2025, proporsinya melompat ke 41%. Penyebabnya sepele: aplikasi kasir versi baru nulis kode promo ke kolom berbeda, dan kolom lama dibiarin kosong.

Nggak ada error. Dashboard penjualan tetap normal, karena nilai transaksi tetap masuk lengkap.

Yang salah cuma laporan kampanye. Selama 19 hari, transaksi senilai Rp 84.300.000 kecatat sebagai penjualan tanpa promo. Tim marketing sempat mau matiin dua kampanye yang datanya kelihatan mati total.

Kalau query nomor tiga tadi udah jalan sejak awal, peringatannya keluar di hari pertama. Bukan di hari ke-19.

Tanggal	Persen kode_promo kosong	Status
9 Mei 2025	5,8%	Normal
11 Mei 2025	6,3%	Normal
12 Mei 2025	40,9%	Harusnya sudah kena peringatan
31 Mei 2025	41,4%	Baru ketahuan manual

Gimana nentuin ambang peringatan biar nggak berisik?

1. Kumpulin riwayat 30 hari dulu. Jangan pasang ambang di hari pertama. Kamu belum tau apa yang normal buat data kamu.
2. Pakai rentang, bukan satu angka. Contohnya volume harian dianggap normal kalau ada di antara 60% dan 160% rata-rata tujuh hari sebelumnya.
3. Bedain hari kerja dan akhir pekan. Di toko online Indonesia, volume Sabtu Minggu biasanya beda pola. Bandingkan Senin sama Senin.
4. Kasih tingkat keparahan. Kesegaran telat 2 jam cukup catat di log. Telat 12 jam baru kirim notifikasi ke orang.
5. Tinjau tiap bulan. Kalau satu peringatan udah tiga kali ternyata bukan masalah, ambangnya salah. Perbaiki atau matikan.

Aturan praktis yang aku pakai: maksimal dua peringatan per minggu per tim. Lebih dari itu, orang berhenti baca dan pemantauannya jadi percuma.

Kesalahan umum waktu mulai data observability

• Mantau semua tabel sekaligus. Mulai dari tiga sampai lima tabel yang angkanya keluar ke luar tim.
• Cuma mantau kesegaran. Data yang datang tepat waktu tapi isinya salah tetap bikin keputusan salah.
• Ambang statis selamanya. Bisnis tumbuh, volume normal ikut naik. Ambang yang nggak ditinjau bakal terus bunyi.
• Peringatan tanpa pemilik. Notifikasi yang masuk ke grup umum nggak ada yang ngerasa tanggung jawab. Tunjuk satu nama per tabel.
• Nggak nyimpen riwayat pemeriksaan. Tanpa riwayat, kamu nggak bisa jawab pertanyaan sejak kapan angkanya mulai salah.
• Lupa nyatet definisi metriknya. Pemantauan teknis bagus tapi definisi bisnisnya kabur tetap bikin ribut. Simpan definisinya di semantic layer.

Apa yang dilakukan setelah peringatan bunyi?

Urutan yang aku pakai: cek apakah datanya salah atau memang bisnisnya berubah. Volume turun 40% bisa berarti pipeline rusak, bisa juga berarti ada libur nasional.

Cara paling cepat mastiin: bandingin dengan sumber di luar pipeline. Cek jumlah pesanan di panel marketplace langsung, lalu bandingin sama isi tabel.

Kalau ternyata data yang salah, catat tiga hal: kapan mulai, kolom mana, dan laporan apa aja yang kena. Catatan ini yang bikin perbaikan berikutnya jauh lebih cepat.

Angka yang keluar dari peringatan juga bisa masuk ke struktur pemantauan yang lebih luas. Cara nyusunnya ada di tulisan soal metric tree. Kalau nilai yang aneh cuma muncul di satu dua baris, kemungkinan itu outlier biasa, bukan kerusakan pipeline.

FAQ

Apa bedanya data observability dan data quality?

Data quality itu ukuran seberapa benar datanya, misalnya nggak ada duplikat dan formatnya sesuai. Data observability itu praktik memantau ukuran-ukuran tadi terus-menerus supaya kamu tau kapan mulai memburuk. Satu ngomongin kondisi, satu lagi ngomongin cara mengawasi kondisi itu dari waktu ke waktu.

Perlu tool berbayar buat mulai data observability?

Nggak. Lima query di artikel ini bisa dijadwalkan pakai cron atau penjadwal bawaan warehouse kamu, hasilnya dikirim ke email atau chat kerja. Tool berbayar mulai masuk akal waktu kamu punya puluhan tabel penting dan butuh pelacakan asal-usul data otomatis. Untuk lima sampai sepuluh tabel, query terjadwal udah cukup.

Berapa sering pemeriksaan ini sebaiknya dijalankan?

Samakan dengan irama pipeline kamu. Kalau data masuk tiap jam, jalankan pemeriksaan kesegaran tiap jam dan pemeriksaan sebaran sekali sehari. Kalau data masuk harian, semua pemeriksaan cukup sekali sehari setelah jadwal muat data selesai. Menjalankan pemeriksaan lebih sering dari pipeline-nya cuma bikin peringatan palsu.

Gimana biar peringatannya nggak dianggap angin lalu?

Batasi jumlahnya. Kalau tim kamu dapat lebih dari dua peringatan seminggu yang ternyata bukan masalah, ambangnya kelewat ketat dan orang bakal berhenti baca. Naikin ambangnya, lalu tinjau tiap bulan. Peringatan yang jarang muncul tapi selalu benar jauh lebih berguna daripada peringatan harian yang diabaikan.

Tabel mana yang harus dipantau duluan?

Tabel yang kalau salah, angkanya langsung nyampe ke luar tim, misalnya tabel yang ngisi laporan direksi atau tagihan pelanggan. Urutkan tabel berdasarkan siapa yang kena kalau angkanya salah. Biasanya cuma ada tiga sampai lima tabel di kategori itu, dan itu tempat kamu mulai.

Penutup

Tiga hal yang perlu kamu bawa. Kerusakan data yang paling mahal itu yang nggak nampilin error, kayak kolom promo yang diam-diam kosong 19 hari tadi. Lima query di atas udah nutup empat dari lima pilar pemantauan tanpa tool tambahan. Dan ambang peringatan baru boleh dipasang setelah kamu punya riwayat 30 hari.

Coba pasang satu query dulu minggu ini, mulai dari pemeriksaan kesegaran di tabel yang paling sering dipakai. Jadwalkan tiap pagi, kirim hasilnya ke chat kerja kamu.

Mau lebih lancar nulis query pemantauan kayak gini? Kulik latihan window function dan agregasi di NgulikSQL, langsung praktek di browser.