Prompt dan cakupan
Platform microservice multibahasa menggunakan API OpenTracing, shim vendor, dan SDK OpenTelemetry. Sejak Maret 2026, spesifikasi OpenTelemetry tidak lagi mewajibkan implementasi baru untuk menyediakan kompatibilitas OpenTracing, sementara shim yang ada tetap dibutuhkan selama masa transisi. Rancang migrasi yang mempertahankan trace, mengendalikan biaya, dan memungkinkan satu service untuk melakukan rollback.
Hal yang diuji oleh pewawancara
Pewawancara menguji apakah Anda memisahkan kompatibilitas API, semantik data, dan protokol backend; menangani pemetaan atribut trace dan span, propagasi konteks, konsistensi sampling, biaya dual-write, serta vendor lock-in. Jawaban yang kuat memberikan urutan migrasi, metrik penerimaan, dan isolasi kegagalan, bukan sekadar mengganti dependensi.
Pertanyaan klarifikasi awal
- Bahasa dan framework mana saja yang menggunakan OpenTracing, dan apakah shim telah mengubah semantiknya?
- Apakah backend menerima OTLP, dan apakah data historis serta dimensi kueri harus tetap stabil?
- Apakah prioritasnya adalah zero loss, overhead rendah, semantik terpadu, atau kemudahan penggantian vendor?
- Apakah dual-write sementara diizinkan, dan berapa batas sampling serta batas biaya per service?
Jawaban 30 detik
"Saya akan membagi migrasi menjadi lapisan API, semantik, transport, dan operasional. Pertama, bekukan dependensi OpenTracing baru dan inventarisasi shim, format propagasi, serta atribut utama. Pada satu service, tambahkan OpenTelemetry native sambil mempertahankan shim sebagai entry point kompatibilitas, lalu bandingkan keduanya dengan satu keputusan konteks dan sampling. Setelah kontinuitas trace, tingkat error, cakupan atribut, latensi, dan biaya memenuhi batasan gerbang (gates), perluas berdasarkan bahasa dan topologi dependensi. Jika terjadi kegagalan, rollback hanya dilakukan pada rute entry atau ekspor satu service tersebut, bukan pada platform Collector bersama."
Solusi langkah demi langkah
1. Inventarisasi panggilan dan semantik
Buat inventarisasi service, bahasa, paket OpenTracing, versi shim, format propagasi, dan jalur ekspor. Tandai custom tag, log, baggage, dan nama span, lalu petakan masing-masing ke atribut, event, link, dan baggage OpenTelemetry. Mulailah dari service stateless yang batasannya jelas, bukan dari tracer yang paling banyak dikustomisasi.
2. Tentukan batas kompatibilitas
Arahkan kode aplikasi ke tracer OpenTelemetry native. Pertahankan shim untuk library yang belum dapat diubah, tetapi bekukan fitur shim baru. Propagasi konteks harus tetap konsisten pada ingress, antrean asinkron, RPC, dan batasan batch; nama API yang serupa tidak membuktikan sampling atau relasi parent yang setara.
3. Terapkan dual-write yang terkontrol
Pilih perutean terkontrol pada batas ekspor SDK atau Collector alih-alih menghasilkan dua set span dalam kode bisnis. Jika dual-write diperlukan, tetapkan batas sampling per service, batas antrean, percobaan ulang (retries), dan metrik drop, yang membedakan antara "span bisnis tidak dibuat" dan "ekspor gagal." Berikan kondisi keluar yang eksplisit untuk periode dual-write.
4. Pastikan backend tetap dapat dikueri
Bekukan nama untuk service, operasi, status, dan atribut bisnis penting selama migrasi. Kirim rangkaian permintaan yang sama melalui jalur lama dan baru, lalu bandingkan jumlah trace, hubungan parent-child, status error, persentil latensi, dan exemplar. Jika semantik kueri backend berubah, sediakan adaptor atau dua versi dasbor sebelum mengubah tampilan default.
5. Rilis canary dengan guardrail biaya
Migrasikan secara bertahap berdasarkan bahasa, tim, atau pohon dependensi. Lacak kontinuitas trace end-to-end, kehilangan span, antrean Collector, CPU dan memori, egress data, serta biaya per sejuta span. Jika ambang batas terlampaui, hentikan penerimaan service baru sambil tetap mempertahankan service yang sudah dimigrasi dan bukti mentahnya.
6. Rollback dengan kontrol siklus hidup
Simpan switch inisialisasi tracer, versi dependensi, dan snapshot konfigurasi untuk setiap service. Lakukan rollback dengan mengalihkan rute entry atau ekspor service tersebut, bukan dengan menghapus resource Collector bersama. Sebelum menghapus shim, pastikan tidak ada downstream library yang masih memperoleh konteks melalui tracer global, dan pertahankan pemantauan kompatibilitas selama periode yang ditentukan.
Jawaban model
Saya akan membekukan pekerjaan kompatibilitas OpenTracing baru dan menginventarisasi panggilan, semantik, propagasi, dan ekspor. API OpenTelemetry native diterapkan service demi service; library yang tidak dapat diubah tetap berjalan melalui shim, dengan Context, sampling, dan pemetaan atribut yang dipastikan melalui contract test. Dual-write dibatasi pada SDK atau batas ekspor, dengan metrik untuk kontinuitas, cakupan atribut, antrean Collector, latensi, dan biaya. Canary dijalankan berdasarkan bahasa dan topologi dependensi. Jika terjadi kegagalan, nonaktifkan rute baru satu service dan pulihkan ekspor lamanya sambil mempertahankan konfigurasi, event, dan data perbandingan; hapus shim hanya setelah semua service stabil.
Kesalahan umum
- Hanya mengganti import → semantik parent, baggage, atau atribut berubah → uji propagasi dan kontrak semantik.
- Melakukan dual-write pada setiap panggilan bisnis → volume span dan biaya melonjak → pusatkan dan batasi perutean pada batas SDK atau ekspor.
- Hanya memantau keberhasilan Collector → aplikasi telah kehilangan span sebelum sampai di sana → pisahkan metrik pembuatan, antrean, ekspor, dan backend.
- Memigrasikan semua service sekaligus → blast radius terlalu besar → lakukan canary berdasarkan bahasa dan topologi dependensi.
- Menghapus shim secara langsung → library yang belum dimodifikasi gagal dijalankan → bekukan dependensi baru dan verifikasi bahwa semua referensi telah hilang.
Pertanyaan lanjutan dan jawaban
Mengapa tidak mewajibkan setiap tim untuk beralih sekaligus?
Library bersama, jadwal rilis, dan SDK bahasa berbeda-beda, sehingga cutover yang tersinkronisasi menciptakan blast radius yang besar. Kompatibilitas berlapis menjaga service tetap berjalan sementara API native menjadi fokus pengembangan baru.
Bagaimana Anda membuktikan bahwa tidak ada trace yang hilang?
Sisipkan identifier yang stabil ke dalam permintaan yang dapat diulang, bandingkan ingress, propagasi antar-service, penerimaan Collector, dan jumlah kueri backend, lalu lakukan pemeriksaan sampel pada link parent, status, dan atribut utama.
Bisakah dual-write mengubah sampling?
Ya. Melakukan sampling secara independen pada dua tracer dapat memutus trace atau menggandakan biaya. Tentukan keputusan sampling dalam konteks bersama dan buat kedua rute mewarisi keputusan tersebut.
Kapan lapisan kompatibilitas dapat dihapus?
Setelah pemindaian dependensi tidak lagi menemukan entry point OpenTracing, contract test mencakup propagasi dan semantik, metrik canary memenuhi gerbang penerimaan, dan tidak ada rollback selama periode retensi. Setelah itu, hapus shim dan simpan catatan audit.