Wawancara system design: Bagaimana Anda memigrasikan OpenTelemetry multi-bahasa ke konfigurasi deklaratif?

Perintah dan konteks yang berlaku

Perusahaan Anda menjalankan layanan Java, Go, JavaScript, dan PHP. Saat ini layanan tersebut bergantung pada environment variable dan flag startup SDK spesifik bahasa. Tim platform ingin mengadopsi file konfigurasi deklaratif OpenTelemetry yang dipilih dengan OTEL_CONFIG_FILE, secara bertahap menstandarisasi atribut resource, sampling, exporter, dan processor. Rancang rencana migrasi, kompatibilitas, validasi, dan rollback.

Pada Maret 2026, OpenTelemetry mengumumkan bagian stabil dari skema JSON konfigurasi deklaratif, representasi file YAML, model in-memory, mekanisme plugin-component, operasi parse/create, dan OTEL_CONFIG_FILE; implementasi bahasa masih memiliki tingkat kematangan yang berbeda. Wawancara ini menguji tata kelola konfigurasi lintas versi, bukan hafalan YAML.

Hal yang dievaluasi oleh pewawancara

Apakah Anda membedakan spesifikasi yang stabil dari implementasi yang belum tentu sama stabilnya di setiap bahasa.
Apakah Anda dapat menentukan matriks kompatibilitas untuk skema, versi SDK, endpoint exporter, dan izin akses.
Apakah Anda dapat mencegah environment variable lama dan file baru menyebabkan penimpaan implisit atau duplikasi exporter.
Apakah Anda dapat membuktikan kelengkapan migrasi tanpa kehilangan trace, membuat data ber-kardinalitas tinggi, atau melipatgandakan biaya.

Jawaban yang kuat memperlakukan konfigurasi sebagai artefak berversi dengan linting, pengujian sintetis, canary, perbandingan, dan rollback cepat. Jawaban yang lemah hanya mengatakan "masukkan semuanya ke dalam YAML."

Pertanyaan klarifikasi sebelum menjawab

Bahasa mana yang mendukung field target, dan mana yang harus mempertahankan environment variable? Hal ini menentukan tahapan batch migrasi.
Apakah file tersebut dimasukkan ke dalam image, di-mount sebagai volume, atau diunduh saat runtime? Sumber menentukan penandatanganan (signing), izin akses, dan kecepatan rollback.
Apakah kode aplikasi membaca environment variable yang ada? Jika ya, penghapusan tidak aman sampai urutan prioritas dan jendela depresiasi tersedia.
Apakah penulisan ganda (dual writing) sementara diizinkan selama migrasi? Biayanya lebih tinggi tetapi memberikan bukti perbandingan.

Kerangka jawaban 30 detik

"Saya akan menginventarisasi status implementasi dan sumber konfigurasi setiap bahasa, lalu menetapkan skema minimum berversi dan matriks kompatibilitas. Generator akan me-render YAML netral bahasa, sementara CI memeriksa skema, izin, endpoint, dan kardinalitas; bahasa yang belum didukung tetap menggunakan jalur environment variable lama. Saya akan memvalidasi dengan layanan sintetis tanpa lalu lintas bisnis, lalu melakukan canary berdasarkan bahasa dan risiko, membandingkan metrik data terkirim, terbuang, tersampel, latensi, dan biaya. Setiap artefak akan menyertakan versi dan pointer rollback. Jika parsing gagal, launcher akan mempertahankan artefak sebelumnya atau flag lama alih-alih berjalan tanpa telemetri secara diam-diam."

Jawaban mendalam langkah demi langkah

1. Bangun matriks kapabilitas dan batasan

Bagi konfigurasi menjadi resource, sampling, receiver, processor, exporter, dan plugin component. Untuk setiap bahasa, catat versi SDK, field yang didukung, nilai default, pemetaan environment variable, dan perilaku terhadap field yang tidak dikenal. Model data dan mekanisme parse/create yang stabil tidak berarti implementasi bahasa memiliki kematangan yang sama.

2. Tentukan satu sumber dan urutan prioritas

Jadikan file deklaratif sebagai sumber utama untuk layanan baru sementara layanan lama mempertahankan environment variable. Selama migrasi, tentukan urutan prioritas secara eksplisit: field file eksplisit menimpa default bawaan platform; field yang tidak didukung akan ditolak atau ditandai oleh adaptor daripada diabaikan secara diam-diam. Keluarkan snapshot konfigurasi efektif yang telah disanitasi untuk audit.

text

repo template -> rendered config -> schema validation -> signed artifact
       |                                       |
   env defaults --------------------------> runtime loader

Jangan biarkan setiap layanan menyusun YAML-nya sendiri. Template platform mengelola pengaturan umum; layanan hanya boleh mendeklarasikan penimpaan kecil yang telah ditinjau.

3. Rancang artefak dan jalur rilis

Artefak memerlukan versi, bahasa target, rentang SDK, endpoint exporter, referensi secret, dan deklarasi kompatibilitas. CI memvalidasi skema, lalu menjalankan layanan minimal untuk memuatnya dan membuat koneksi exporter. Produksi menggunakan digest dan tanda tangan yang tidak dapat diubah (immutable); rollback beralih ke digest yang telah diverifikasi sebelumnya.

4. Tangani variabel lama dan exporter duplikat

Sebelum migrasi, kumpulkan injeksi environment, sidecar, dan konfigurasi di dalam kode. Jika file dan variabel hidup berdampingan, uji prioritas di staging dan larang dua exporter untuk sinyal yang sama. Pertahankan variabel lama sebagai fallback eksplisit dengan tanggal depresiasi dan peringatan; jika tidak, dua sistem konfigurasi akan berjalan berdampingan tanpa batas waktu.

5. Verifikasi semantik dengan telemetri sintetis

Hasilkan sampel trace, metric, dan log tetap untuk setiap bahasa. Periksa nama layanan, atribut resource, nama span, sampling, ukuran batch, dan target exporter. Jangan berhenti pada "proses berhasil dimulai"; bandingkan jumlah input dan output, latensi, alasan penolakan, dan label kardinalitas tinggi di Collector atau backend.

6. Lakukan canary secara bertahap dan tentukan kondisi henti

Pilih satu alur bisnis, satu bahasa, dan instance dengan lalu lintas rendah terlebih dahulu, dengan mempertahankan kontrol versi lama. Hentikan jika terjadi error parsing, hilangnya telemetri, kegagalan ekspor, lonjakan CPU/RSS, biaya penulisan backend, atau penurunan p99 bisnis. Jika implementasi suatu bahasa belum lengkap, pertahankan jalur lama dan catat kesenjangannya daripada memaksakan keseragaman visual semata.

7. Lakukan rollback dan tata kelola jangka panjang

Launcher harus mendukung tiga status: file baru, variabel lama, dan penonaktifan telemetri secara eksplisit. Kegagalan parsing tidak boleh menjadi SDK yang "kosong tetapi sukses"; beralihlah ke artefak bertanda tangan sebelumnya atau variabel lama dan kirimkan peringatan. Jalankan kembali matriks pada setiap peningkatan SDK dan hentikan penggunaan environment variable secara bertahap.

Contoh jawaban berkualitas tinggi

Saya akan mulai dengan matriks kapabilitas bahasa dan SDK, memisahkan skema deklaratif yang stabil dari kematangan implementasi. Platform akan menyediakan template berversi dan penimpaan kecil di tingkat layanan. Setelah di-render, CI akan memeriksa skema, izin, endpoint, kardinalitas, dan startup minimal, menghasilkan artefak bertanda tangan yang tidak dapat diubah. Selama migrasi, environment variable lama tetap menjadi fallback eksplisit dan konfigurasi efektif dicatat sehingga pengaturan file dan variabel tidak membuat exporter duplikat. Saya akan memvalidasi sampel telemetri tetap untuk keempat bahasa, lalu melakukan canary berdasarkan bahasa dan risiko bisnis. Kondisi henti mencakup kegagalan parse, tingkat data terbuang (drop rate), kegagalan ekspor, overhead resource, dan kenaikan biaya. Jika file gagal, launcher kembali ke artefak sebelumnya atau variabel lama, tidak pernah beralih ke instance tanpa instrumentasi secara diam-diam; peningkatan SDK mengevaluasi ulang matriks dan melanjutkan depresiasi.

Kesalahan umum

Kesalahan → memigrasikan setiap bahasa hanya karena skemanya stabil → spesifikasi yang stabil tidak berarti field lengkap di setiap implementasi; solusi: pertahankan matriks kapabilitas bahasa dan SDK.
Kesalahan → mengizinkan file dan variabel tanpa urutan prioritas → exporter atau sampler dapat diinisiasi dua kali; solusi: deklarasikan prioritas dan keluarkan snapshot efektif yang disanitasi.
Kesalahan → hanya memeriksa apakah proses berhasil dimulai → span mungkin terbuang, kardinalitas bisa melonjak, atau data terkirim ke endpoint yang salah; solusi: bandingkan jumlah dan biaya dengan telemetri sintetis tetap.
Kesalahan → diam-diam menggunakan konfigurasi kosong setelah parsing gagal → insiden pemadaman berubah menjadi titik buta observabilitas; solusi: beralih ke artefak bertanda tangan sebelumnya atau variabel lama dan kirimkan peringatan.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika suatu bahasa tidak memiliki field exporter yang diperlukan?

Jangan memaksakan keseragaman. Pertahankan layanan tersebut pada jalur variabel lama, catat kesenjangan field dan risikonya, dan migrasikan hanya melalui adaptor yang telah diaudit jika diperlukan. Beri label hasilnya kompatibel sebagian daripada berpura-pura mendukung skema lengkap.

Bagaimana Anda mencegah tim menimpa kebijakan sampling platform?

Buat daftar izin (allowlist) untuk field yang dapat ditimpa, jalankan pemeriksaan kebijakan setelah rendering, dan catat ringkasan efektif serta pemilik perubahan. Platform harus menegakkan batas exporter mahal, endpoint sensitif, dan batas atas sampling.

Bagaimana jika konfigurasi berhasil dimuat tetapi biaya backend berlipat ganda?

Bagi analisis berdasarkan bahasa, versi, sampling, batching, retry, dan atribut resource. Periksa exporter duplikat dan label kardinalitas tinggi terlebih dahulu. Jeda canary, lakukan rollback artefak, perbaiki konfigurasi, dan jalankan kembali beban kerja sintetis yang sama alih-alih langsung menambah kapasitas backend.