Perintah dan konteks
Metrik pendapatan inti memerlukan koreksi pada perlakuan pengembalian dana (refund), sementara ratusan dasbor, peringatan, dan produk data masih menggunakan definisi lama. Rancang kontrak penerapan versi dan deprecate metrik yang membuat perubahan tersebut dapat dijelaskan, dapat dimigrasikan, dan dapat dikembalikan (reversible).
Jangan membatasi jawaban pada satu vendor katalog atau lapisan semantik tertentu. Fokuslah pada definisi, dependensi, jendela kompatibilitas, gerbang rilis (release gates), pemberitahuan konsumen, dan bukti penghentian (retirement evidence).
Hal yang dievaluasi pewawancara
Batasan semantik
Dapatkah Anda mengubah nama metrik menjadi kontrak yang berisi formula, filter, semantik waktu, grain, unit, zona waktu, versi, dan pemilik, alih-alih mengubah SQL secara diam-diam?
Analisis dampak
Dapatkah Anda menginventarisasi dasbor, peringatan, ekspor, model, dan API, serta membedakan dependensi langsung dari dependensi tidak langsung?
Tata kelola migrasi
Dapatkah Anda menjalankan versi lama dan baru secara bersamaan dengan tenggat waktu, pemberi persetujuan, dan status migrasi, alih-alih menyebabkan kerusakan mendadak yang tersembunyi (big-bang break)?
Penghentian yang dapat diverifikasi
Dapatkah Anda membuktikan penghentian dengan penggunaan, rekonsiliasi, pemutaran ulang peringatan, dan bukti bahwa panggilan lama telah hilang?
Pertanyaan klarifikasi yang perlu diajukan
- Apakah perubahan tersebut merupakan perbaikan bug, perubahan definisi bisnis, atau migrasi sumber data?
- Apakah bagian keuangan, audit, komputasi ulang historis, atau retensi hukum memerlukan metrik lama?
- Apakah konsumen menggunakan SQL, BI, API, ekspor, atau fitur machine learning?
- Apakah ada SLA lintas tim atau pelanggan eksternal?
- Berapa lama kedua versi boleh berjalan bersamaan, dan siapa yang dapat memperpanjang jendela tersebut?
- Jika nilai berbeda, apakah kita melakukan rollback pada definisi, data, atau lapisan presentasi?
Kerangka jawaban 30 detik
“Saya akan memperlakukan definisi metrik sebagai kontrak berversi yang berisi formula, filter, grain, semantik waktu, dan pemilik. Pertama, saya akan membangun grafik dependensi dan snapshot penggunaan, kemudian memublikasikan versi baru sambil mempertahankan versi lama; setiap respons akan menampilkan versi dan waktu efektif. Migrasi akan memprioritaskan konsumen berisiko tinggi dan menggunakan sampel tetap, pemutaran ulang historis, serta rekonsiliasi. Selama masa deprecation, saya akan memberi tahu pemilik dan memblokir penggunaan baru. Saya hanya akan menghentikannya setelah panggilan lama mencapai nol, konsumen kritis memberikan konfirmasi, dan catatan audit lengkap, sambil tetap mempertahankan definisi yang dapat dipulihkan dan snapshot hasil.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Bekukan kontrak saat ini
Catat nama versi lama, formula, filter, grain, unit, zona waktu, sumber, kebaruan (freshness), pemilik, sensitivitas, dan waktu efektif. Buat versi yang tidak dapat diubah (immutable) untuk setiap perubahan; jangan pernah menimpa secara diam-diam.
Langkah 2: Bangun grafik dependensi dan risiko
Kumpulkan dependensi dari lapisan semantik, log kueri, metadata BI, pekerjaan terjadwal, definisi peringatan, dan panggilan API. Tandai konsumen keuangan, konsumen yang terlihat oleh pelanggan, konsumen mendekati waktu nyata (near-real-time), dan konsumen machine learning, lalu urutkan migrasi berdasarkan dampak dan penggunaan.
Langkah 3: Tentukan kompatibilitas
Perubahan alias atau perubahan khusus tampilan dapat menggunakan alias kompatibilitas. Perubahan formula, grain, atau semantik waktu mendapatkan versi baru. Respons, metadata ekspor, dan dokumentasi mengembalikan versi, unit, dan referensi definisi sehingga konsumen tidak perlu menebak-nebak.
Langkah 4: Terapkan gerbang rilis baru
Jalankan versi baru di lingkungan sandbox dan dengan kelompok kecil konsumen. Gerbang memeriksa penguraian ekspresi, nilai sampel, pemutaran ulang historis, nilai null, unit, izin, latensi, dan biaya. Pemilik dan konsumen yang terdampak menyetujui sebelum dilakukan ekspansi.
Langkah 5: Migrasikan dan beri tahu
Tetapkan pemilik, tenggat waktu, dan status untuk setiap dependensi. Gunakan status katalog, pemeriksaan CI, petunjuk kueri (query hints), dan laporan berkala untuk memberi tahu pengguna versi lama. Blokir dasbor baru agar tidak mereferensikan versi lama; pengecualian memerlukan masa kedaluwarsa.
Langkah 6: Terima, lakukan rollback, dan hentikan
Bandingkan versi pada sampel tetap, jendela historis, dan dasbor kritis, dengan menjelaskan perubahan yang disebabkan oleh pengembalian dana, data yang terlambat, atau zona waktu. Simpan definisi lama dan snapshot hasil; jeda penghentian atau beralih kembali jika muncul anomali. Hentikan hanya setelah panggilan lama mencapai nol dan materi audit, konfirmasi konsumen, serta materi rollback telah lengkap.
Contoh jawaban yang kuat
“Saya akan membekukan definisi pendapatan saat ini sebagai v1, mendokumentasikan secara eksplisit waktu pengakuan, perlakuan pengembalian dana, mata uang, zona waktu, grain, dan pemilik. Log kueri dan metadata katalog akan menghasilkan grafik dependensi, dengan laporan keuangan, faktur pelanggan, dan peringatan ditandai sebagai risiko tinggi.
Jika perbaikan pengembalian dana mengubah formula, saya akan memublikasikan v2 daripada menimpa v1. Kedua versi akan berjalan secara paralel, dan nilai akan mencakup versi, unit, dan kebaruan. CI akan memblokir referensi v1 baru, sementara daftar migrasi mencatat pemilik dan tenggat waktu. Saya akan merekonsiliasi pesanan yang diketahui dan bulan-bulan tetap, kemudian memutar ulang peringatan, ekspor, dan API; setiap perbedaan harus memiliki penjelasan.
Setelah konsumen berisiko tinggi mengonfirmasi, penggunaan v1 terus-menerus bernilai nol, serta dokumentasi dan catatan audit lengkap, saya akan membekukan v1 menjadi hanya-baca dan menetapkan tanggal penonaktifan akhir. Saya akan mempertahankan definisi dan snapshot hasilnya sehingga laporan historis tetap dapat dilacak dan anomali dapat dipulihkan.”
Kesalahan umum
- Mengedit SQL bernama sama sehingga laporan historis secara diam-diam berubah makna.
- Hanya memeriksa referensi katalog dan melewatkan log kueri, peringatan, ekspor, atau API.
- Menggunakan kembali satu kunci cache atau tabel hasil yang sama untuk versi lama dan baru.
- Menghilangkan bidang unit, zona waktu, grain, atau versi dan memaksa konsumen untuk menebak.
- Mengirimkan pengumuman tanpa pemilik, tenggat waktu, atau penegakan aturan.
- Menggunakan perbedaan rata-rata untuk menyembunyikan perbedaan pada bulan kritis atau pelanggan berisiko tinggi.
- Menghapus definisi lama sebelum penjelasan historis atau rollback dapat dilakukan.
- Menganggap satu kali penurunan penggunaan sebagai bukti sambil melewatkan pekerjaan batch dan kueri audit yang jarang dilakukan.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Apa yang dianggap sebagai breaking change?
Perubahan pada formula, filter, grain, unit, zona waktu, keandalan sumber, atau semantik izin adalah breaking change. Pengeditan alias atau deskripsi bersifat kompatibel hanya jika kontrak hasil tetap tidak berubah.
Pertanyaan lanjutan 2: Bagaimana cara mencegah dasbor baru menggunakan versi lama?
Tandai versi lama sebagai tidak digunakan lagi (deprecated), dan buat CI serta lapisan semantik menolak referensi baru. Petunjuk kueri menampilkan penggantinya; pengecualian memerlukan pemilik, alasan, dan masa kedaluwarsa.
Pertanyaan lanjutan 3: Bagaimana Anda menunjukkan bahwa perbedaan numerik bukanlah sebuah bug?
Putar ulang sampel tetap, jendela historis, pesanan batas, dan total rekonsiliasi. Uraikan perbedaan berdasarkan pengembalian dana, keterlambatan data, mata uang, dan zona waktu, lalu dapatkan persetujuan resmi dari pemilik bisnis.
Pertanyaan lanjutan 4: Bagaimana jika konsumen berfrekuensi rendah tidak pernah bermigrasi?
Tetapkan batas waktu akhir yang ketat berdasarkan risiko dan berikan laporan migrasi serta kueri pengganti. Izinkan perpanjangan terkontrol untuk konsumen kepatuhan atau penagihan, dengan mencatat alasan, pemberi persetujuan, dan tanggal baru.
Pertanyaan lanjutan 5: Bisakah Anda menjawab pertanyaan historis setelah penghentian?
Pertahankan definisi yang tidak dapat diubah, versi, snapshot input, atau materi yang dapat diputar ulang, dan catat versi yang digunakan oleh setiap laporan historis. Menghapus endpoint aktif tidak menghapus bukti audit.