Lewati ke konten utama

Change Data Playbook (Aman)

Playbook ini wajib dipakai untuk setiap perubahan schema/data yang berdampak ke produksi.

1) Impact Analysis

Sebelum menulis migration, jawab ini:

  1. Tabel/kolom mana yang berubah?
  2. Endpoint/service mana yang membaca/menulis kolom itu?
  3. Apakah perubahan bersifat breaking untuk aplikasi berjalan?
  4. Estimasi volume data untuk backfill?
  5. Risiko locking, downtime, atau data race?

Template ringkas:

Perubahan:
Entitas terdampak:
API/modul terdampak:
Potensi breaking:
Strategi mitigasi:
Rollback strategy:
Owner verifikasi:

2) Expand/Contract Migration Strategy

Gunakan pola ini untuk perubahan aman tanpa downtime signifikan.

Fase Expand (aman, backward compatible)

  • Tambah kolom/tabel baru.
  • Pertahankan kolom lama tetap berfungsi.
  • Update kode supaya bisa baca dari jalur lama + baru (dual-read bila perlu).
  • Mulai tulis ke struktur baru (dual-write jika dibutuhkan).

Fase Backfill

  • Isi data lama ke struktur baru bertahap (batch/chunk).
  • Pantau error dan performa.
  • Jangan jalankan backfill besar saat jam puncak.

Fase Contract

  • Setelah verifikasi lengkap, hentikan baca/tulis jalur lama.
  • Drop kolom/tabel lama di rilis terpisah.

3) Backfill Strategy

Pilih strategi sesuai volume:

  • Kecil (<100k rows): batch sederhana + checkpoint.
  • Menengah (100k-5M): chunk + progress log + retry.
  • Besar (>5M): worker terjadwal + throttle + observability ketat.

Prinsip backfill:

  • Idempotent (aman dijalankan ulang).
  • Bisa pause/resume.
  • Simpan checkpoint offset/id terakhir.
  • Catat metrik: processed, success, failed.

4) Rollback Plan

Rollback wajib ditulis sebelum deploy:

  1. Code rollback: versi commit/tag yang aman.
  2. Schema rollback: apakah migration down aman? Jika tidak, tulis manual rollback.
  3. Data rollback: snapshot/backup yang dipakai + prosedur restore.
  4. Decision gate: kapan rollback diputuskan (error rate, mismatch data, latency).

Jika rollback schema berisiko tinggi, tandai perlu verifikasi dan wajib approval senior.

5) Post-Deploy Validation Checklist

  • Endpoint utama sukses (2xx) dan tidak ada lonjakan 5xx.
  • Error log terkait migration/backfill tidak naik signifikan.
  • Jumlah record lama vs baru konsisten (sampling + aggregate).
  • Jalur tulis data baru berjalan.
  • Dashboard/monitoring tidak menunjukkan degradasi parah.
  • Stakeholder bisnis mengonfirmasi flow kritikal tetap normal.

Contoh query verifikasi (sesuaikan nama tabel):

-- 1) Cek data null yang seharusnya sudah terisi setelah backfill
SELECT COUNT(*) AS kosong
FROM target_table
WHERE new_column IS NULL;

-- 2) Cek konsistensi jumlah berdasarkan status
SELECT status, COUNT(*)
FROM target_table
GROUP BY status
ORDER BY status;

-- 3) Sampling silang kolom lama vs baru
SELECT id, old_column, new_column
FROM target_table
WHERE old_column IS NOT NULL
ORDER BY id DESC
LIMIT 50;

6) Kapan harus stop deployment

Stop/rollback segera jika:

  • error rate meningkat tajam,
  • query kritikal timeout berkali-kali,
  • mismatch data signifikan,
  • transaksi bisnis utama gagal.

7) Catatan ketidakpastian

Jika ada asumsi yang belum tervalidasi environment production, tulis jelas: perlu verifikasi.