Belajar Site Reliability Engineer - Data Reliability

#Pendahuluan

Di episode 10 kita meng-hardening aplikasi, di episode 11 kita mengamankan proses rilis — sekarang tiba giliran lapisan yang paling membuat jantung SRE berdebar: data. Ada alasan mengapa database sering menjadi sumber insiden paling menyakitkan: aplikasi bisa di-rollback dalam menit, tapi data yang hilang atau korup tidak bisa di-rollback dengan mudah.

Data reliability berlapis tiga: ketersediaan (database tetap melayani saat node/zona mati), pemulihan (backup benar-benar bisa dipulihkan saat malapetaka), dan kebenaran (data yang sampai ke pengguna utuh dan sesuai harapan — termasuk untuk pipeline data). Episode ini membahas ketiganya, dengan praktik SLO untuk pipeline data.

#Database HA: Arsitektur yang Bertahan

#Prinsip: Jangan Ada Single Point of Failure

Database HA berarti kegagalan satu komponen tidak menghentikan layanan. Pola standarnya:

• Primary-Replica — semua write ke primary, read bisa disebar ke replica.
• Automatic failover — saat primary mati, replica terpromosi menjadi primary secara otomatis (misal pg_auto_failover di Postgres, atau managed seperti RDS Multi-AZ).
• Quorum/consensus — untuk konsistensi kuat, gunakan sistem consensus (etcd, ZooKeeper, atau database berbasis Raft seperti CockroachDB).

#Pertanyaan Kritis untuk Arsitektur HA

1. Apa yang terjadi saat primary mati? Siapa yang mendeteksi, siapa yang mempromosikan, berapa lama downtime write-nya?
2. Apa yang terjadi saat dua node mati? Apakah masih ada quorum?
3. Bagaimana aplikasi tahu primary baru? Connection string statis adalah jebakan — gunakan endpoint yang mengikuti failover otomatis.
4. Apakah replikasi selalu sinkron? Replikasi asinkron bisa kehilangan data saat primary mati mendadak (RPO bukan nol) — sadari trade-off-nya.

#Backup & Restore: Yang Tidak Pernah Diuji Tidak Pernah Ada

Aturan pertama backup: backup tanpa restore yang diuji adalah delusi. Insiden paling menyedihkan di industri bukan "kita tidak punya backup" — melainkan "kita punya backup, tapi tidak bisa mengembalikannya".

#Hirarki Strategi

#Praktik yang Benar

1. 3-2-1 rule: 3 salinan data, 2 media berbeda, 1 di luar lokasi.
2. Enkripsi backup — backup yang bocor lebih buruk daripada tidak punya backup.
3. Otomasi + monitoring — backup yang gagal harus berbunyi seperti alert P2, bukan ditemukan setahun kemudian.
4. Uji restore berkala — jadwalkan restore ke environment terpisah minimal sebulan sekali, dan ukur waktu sebenarnya.

# minggu pertama tiap bulan: restore backup ke staging
pg_restore -h staging-db -d appdb -c latest_backup.dump
# lalu verifikasi baris kritis
psql -h staging-db -d appdb -c "SELECT count(*) FROM orders;"

#Reliability Pipeline Data (DataOps)

Era modern: data bukan hanya database transaksional, tetapi juga pipeline — batch ETL/ELT, streaming, dan warehouse. Di sinilah SRE bertemu DataOps: prinsip reliability yang sama diterapkan pada jalur data.

#SLO untuk Pipeline Data

Data pipeline punya SLI sendiri yang jarang terpantau:

Contoh SLO pipeline: "Freshness p95 ≤ 30 menit, completeness ≥ 99,9% per hari". Ini sama validnya dengan SLO API, dan justru sering lebih mudah dilanggar karena pipeline berjalan di balik layar.

#Data Quality: SLI yang Tidak Bisa Ditipu

Pipeline bisa "sukses" sambil mengirim data yang salah: kolom null, duplikat, atau nilai meleset karena bug transformasi. Tambahkan data quality checks sebagai SLI:

expectations:
  - expectation: expect_column_values_to_not_be_null
    column: order_id
  - expectation: expect_column_values_to_be_between
    column: amount
    min_value: 0
    max_value: 1000000
  - expectation: expect_column_values_to_be_unique
    column: event_id
  - expectation: expect_table_row_count_to_be_between
    min_value: 100000
    max_value: 5000000

#Idempotency & Backfill

Pipeline yang andal harus bisa dijalankan ulang tanpa efek ganda (idempotent): kalau job gagal di tengah, menjalankan ulang tidak menggandakan data. Praktik pendukungnya: partisi berdasarkan tanggal, watermark untuk posisi streaming, dan mekanisme backfill yang jelas.

#Praktik: SLO untuk Data Pipeline

Langkah konkret:

1. Definisikan SLI freshness — misal time since max(ts) per tabel partition, ekspor ke Prometheus.
2. Definisikan SLO — freshness p95 ≤ 30 menit per hari dan completeness ≥ 99,9%.
3. Integrasikan quality checks ke pipeline — gagalkan job saat check melanggar, bukan hanya catat di log.
4. Alert burn rate — persis pola episode 6, tapi untuk metrik pipeline.
5. Uji restore — jadwalkan drill bulanan dan catat RTO aktual.

max by (pipeline) (data_freshness_seconds)

#Penutup

Pada episode 12 ini, kalian telah memperluas prinsip SRE ke lapisan data.

Inti yang harus dibawa pulang:

• Database HA = replikasi + failover otomatis + tidak ada single point of failure; ketahui RPO/RTO trade-off sinkron vs asinkron.
• Backup tanpa uji restore = delusi; 3-2-1 rule, enkripsi, dan drill restore bulanan.
• Pipeline data punya SLO sendiri: freshness, completeness, latency, success rate.
• Data quality checks adalah SLI yang tidak bisa ditipu — gagalkan job yang menghasilkan data salah.
• Pipeline harus idempotent agar bisa dijalankan ulang dengan aman.

Di episode 13 selanjutnya, kita sengaja akan memecahkan sistem — chaos engineering: prinsip, game days, dan tools seperti Chaos Mesh dan Litmus untuk membuktikan bahwa sistem kalian bertahan dari kegagalan yang tak terduga. Sampai jumpa di episode 13!