Wawancara umum: Kapan konvensi semantik OpenTelemetry harus dinyatakan stabil?

Petunjuk dan konteks

Anda memelihara kontrak observabilitas lintas bahasa yang digunakan oleh SDK, collector, dasbor, dan peringatan (alerts). Tim ingin memindahkan konvensi dari pengembangan ke stabil agar pengguna hilir (downstream) dapat mengandalkannya; tim platform mengkhawatirkan makna yang belum tuntas, penulisan ganda (dual writes), dan biaya kardinalitas tinggi. Asumsikan data telemetri nyata selama tiga bulan dan dua layanan percontohan (pilot) telah tersedia.

Hal yang dievaluasi oleh pewawancara

Pewawancara menguji apakah Anda menjelaskan "stabil" sebagai janji kompatibilitas dan bukan sekadar kelengkapan dokumentasi. Jawaban yang kuat memeriksa nama, tipe data, unit, tingkat kebutuhan (requirement levels), enum, dan batasan privasi; mengukur adopsi, kebenaran kueri, kardinalitas, dan biaya migrasi; serta mempertahankan jalur transisi untuk perubahan yang tidak kompatibel.

Klarifikasi yang perlu ditanyakan terlebih dahulu

• Peringatan hilir, laporan penagihan, atau laporan kepatuhan mana yang sudah bergantung pada bidang (fields) ini? Ketergantungan yang lebih banyak memerlukan standar stabilitas yang lebih tinggi.
• Sinyal dan bahasa apa saja yang dicakup? Nilai bawaan (defaults) harus selaras di seluruh SDK.
• Apakah ada nilai berkardinalitas tinggi, data sensitif, atau enum yang ambigu? Selesaikan ini sebelum stabilisasi.
• Berapa lama kompatibilitas harus dipertahankan? Collector yang ada saat ini mungkin memerlukan pemilihan versi atau migrasi berbasis opt-in.
• Apakah tolok ukur keberhasilannya adalah adopsi, kueri yang dapat digunakan kembali, atau pengurangan bidang kustom? Tujuannya akan mengubah metrik percontohan.

Kerangka jawaban 30 detik

"Saya tidak akan menaikkan status suatu konvensi hanya karena bidangnya sudah cukup lengkap. Saya akan mengaudit semantik, tipe data, unit, tingkat kebutuhan, enum, privasi, dan perilaku lintas SDK, lalu memvalidasi kueri hilir yang sebenarnya. Saya hanya akan menaikkan statusnya setelah layanan percontohan menggunakan versi stabil, pengujian kompatibilitas lolos, kardinalitas dan biaya tetap berada dalam batas aman, serta jalur migrasi dan penghentian penggunaan (deprecation) telah ditentukan secara eksplisit. Jika tidak, saya akan mempertahankannya di tahap pengembangan atau alpha dan mencatat gerbang keputusan berikutnya."

Jawaban mendalam langkah demi langkah

1. Definisikan janjinya. Konvensi OpenTelemetry menggunakan tingkat development, alpha, beta, release candidate, dan stable. Stabil berarti pengguna hilir dapat mengandalkan jaminan kompatibilitas.
2. Audit semantik. Periksa konsistensi nama, tipe nilai, unit, tingkat kebutuhan, enum, dan contoh. Kembalikan atribut yang terdengar berguna namun kasus penggunaannya belum jelas ke tahap diskusi.
3. Validasi penggunaan nyata. Ambil sampel data tiga bulan dan putar ulang (replay) dasbor, peringatan, korelasi log, dan kueri lintas bahasa. Catat nilai yang hilang dan tidak diketahui.
4. Kendalikan biaya dan privasi. Ukur kardinalitas, penyimpanan, dan biaya kueri dari atribut baru. Jangan pernah memasukkan pengenal pengguna, konten mentah, atau rahasia ke dalam atribut; gunakan hashing atau kategori yang terkontrol jika sesuai.
5. Rancang pembuatan versi (versioning). Simpan konvensi eksperimental dalam namespace pengembangan. Selama stabilisasi, sediakan pemilihan versi atau opt-in, bandingkan hasil lama dan baru selama penulisan ganda, serta publikasikan tanggal penghentian penggunaan.
6. Tetapkan gerbang (gates) dan pembatalan (rollback). Naikkan status hanya setelah dua layanan percontohan memenuhi uji kompatibilitas, kebenaran kueri 99.9%, tingkat kehilangan data di bawah 1%, dan pertumbuhan kardinalitas di bawah 20% selama dua siklus rilis. Pelanggaran apa pun akan mengembalikannya ke skema opt-in.

Alternatif lainnya mencakup merilis versi beta terlebih dahulu, hanya menstabilkan kumpulan atribut inti, membuat versi terpisah untuk setiap sinyal, atau memetakan bidang lama dalam transformasi collector. Stabilisasi tidak boleh menyembunyikan masalah sampling, otorisasi, atau kualitas data yang belum terselesaikan.

Contoh jawaban model

"Saya memperlakukan 'stabil' sebagai janji produk terkait kompatibilitas. Pertama, saya menginventarisasi peringatan, laporan, collector, dan SDK yang bergantung pada konvensi tersebut, kemudian mengaudit nama, tipe data, unit, tingkat kebutuhan, enum, dan privasi. Saya memutar ulang kueri penting terhadap telemetri nyata selama tiga bulan dan membandingkan nilai yang hilang, nilai yang tidak diketahui, kardinalitas, dan biaya pada dua layanan dalam bahasa berbeda. Saya mewajibkan kebenaran kueri 99.9%, tingkat kehilangan data di bawah 1%, pertumbuhan kardinalitas di bawah 20% selama dua siklus rilis, ditambah tanggal penghentian penggunaan, rencana penulisan ganda, dan jalur rollback sebelum menandainya sebagai stabil. Jika maknanya masih diperdebatkan, saya akan mempertahankannya di development atau beta dan menyatakan bukti yang diperlukan untuk tinjauan berikutnya."

Kesalahan umum

• Kesalahan: Menggunakan adopsi atau jumlah bidang sebagai bukti stabilitas → Alasan gagal: Stabilitas adalah janji kompatibilitas → Solusi: Tambahkan pengujian lintas SDK, kueri, dan migrasi.
• Kesalahan: Memasukkan setiap bidang bisnis ke dalam konvensi → Alasan gagal: Risiko kardinalitas dan privasi meningkat dengan cepat → Solusi: Hanya pertahankan atribut dengan kasus penggunaan yang jelas dan biaya yang terukur.
• Kesalahan: Mengganti bidang lama secara langsung → Alasan gagal: Kueri hilir dapat mengalami perubahan makna secara diam-diam → Solusi: Sediakan pemilihan versi, penulisan ganda, perbandingan, dan penghentian penggunaan bertahap.
• Kesalahan: Mengabaikan nilai yang tidak diketahui dan hilang → Alasan gagal: Dasbor terlihat lengkap padahal kesimpulannya tidak dapat diandalkan → Solusi: Jadikan kualitas data sebagai gerbang penentu stabilisasi.

Pertanyaan lanjutan dan tanggapan

Bisakah konvensi yang stabil mempertahankan bidang inti yang telah diganti namanya?

Jika penggantian nama tersebut mengubah semantik kueri hilir, pertahankan bidang lama, tambahkan versi, publikasikan pemetaannya, dan tetapkan batas waktu penghentian penggunaan. Pertimbangkan alias kompatibilitas hanya jika kesetaraan semantik dan biaya migrasi telah terbukti.

Bagaimana Anda menangani perbedaan nilai bawaan pada SDK?

Bangun pengujian kontrak lintas bahasa dengan input yang sama dan verifikasi nama bidang, tipe data, unit, dan tingkat kebutuhan. Jangan memperluas cakupan stabil selama nilai bawaan belum selaras.

Bagaimana jika kardinalitas meningkat tetapi kueri bisnis menjadi lebih akurat?

Evaluasi peningkatan akurasi bersama dengan batas atas penyimpanan, latensi kueri, dan biaya secara bersamaan. Terapkan opt-in pada layanan bernilai tinggi terlebih dahulu dan tambahkan sampling, agregasi, atau reduksi dimensionalitas.

Kapan stabilisasi harus dihentikan?

Hentikan dan kembalikan ke development atau beta jika perselisihan semantik masih terjadi, tingkat kehilangan data atau kardinalitas melanggar batas aman, tinjauan privasi gagal, atau kueri percontohan tidak dapat direproduksi. Catat bukti yang belum terpenuhi tersebut.