Gesaan dan skop
Penyebaran konteks (context propagation) boleh menjadikan sesuatu permintaan dapat difahami merentasi sempadan perkhidmatan, namun setiap perkhidmatan hiliran (downstream) mungkin menerima dan mencatat nilai yang disebarkan ke dalam log. OpenTelemetry mendokumenkan Baggage sebagai konteks nama/nilai yang bersebelahan dengan konteks surih dan memberi amaran tentang implikasi keselamatan. Kemahiran teras di sini ialah reka bentuk sempadan teragih, jadi ini adalah soalan system-design.
Perkara yang dinilai oleh penemu duga
Jawapan yang mantap memisahkan konteks surih daripada metadata aplikasi, mentakrifkan senarai dibenarkan (allowlist) dan pemilikan untuk medan, serta menghalang nilai sensitif daripada merentasi sempadan yang tidak dipercayai. Mereka merangkumi saiz pengepala, pengekodan kanonik, pensampelan, percubaan semula (retries), mesej tak segerak (asynchronous), dan perkara yang berlaku apabila konteks tidak terbentuk dengan betul (malformed) atau hilang. Mereka juga menyertakan metrik yang membuktikan bahawa penyebaran adalah berguna tanpa menjadikannya saluran data yang tidak terkawal.
Soalan untuk dijelaskan terlebih dahulu
- Protokol manakah yang membawa konteks: HTTP, gRPC, barisan gilir (queues), atau tugas berjadual?
- Medan manakah yang bersifat diagnostik, yang manakah mempengaruhi tingkah laku, dan siapa pemilik setiap medan?
- Apakah sempadan kepercayaan yang wujud antara penyewa, rantau, dan perkhidmatan pihak ketiga?
- Adakah nilai dibenarkan dalam log, label metrik, atau surihan sahaja?
- Apakah belanjawan saiz maksimum pengepala, kependaman (latency), dan ketersediaan?
- Patutkah konteks yang tidak terbentuk dengan betul ditolak, dilucutkan (stripped), atau digantikan dengan punca (root) baharu?
Kerangka jawapan 30 saat
"Saya akan mentakrifkan sampul (envelope) kecil berversi dengan konteks surih yang diasingkan daripada medan perniagaan yang diluluskan. Pada setiap sempadan, pustaka dasar mengesahkan nama, saiz, pengekodan, skop penyewa, dan kepercayaan destinasi; ia melucutkan atau menolak nilai yang tidak dibenarkan dan tidak sekali-kali memajukan rahsia. Penyebaran mesti berfungsi untuk pinggir segerak dan tak segerak, dengan pengepala yang dihadkan dan tingkah laku kehilangan konteks yang jelas. Saya akan mengukur kegagalan pengekstrakan, pemangkasan (truncation), liputan penyebaran, pelanggaran rentas penyewa, dan kadar penyertaan surih (trace join rate)."
Jawapan langkah demi langkah
Langkah 1: Tentukan kontrak konteks
Cipta daftaran medan dengan pemilik, jenis, panjang maksimum, kepekaan, pengekalan, dan destinasi yang dibenarkan. Simpan pengecam surih dalam protokol penyurihan dan letakkan hanya metadata perniagaan yang diluluskan dalam pembawa (carrier) berasingan seperti baggage. Versikan sampul supaya pengguna boleh menolak medan kritikal yang tidak diketahui.
Langkah 2: Kuat-kuasakan dasar sempadan
Gunakan perisian tengah (middleware) kongsi atau dasar sidecar yang menghurai pembawa, mengesahkan pengekodan dan saiz, menyemak penyewa dan zon kepercayaan, serta mengeluarkan pembawa yang telah disanitasikan. Jangan sekali-kali menyalin pengepala masuk yang sewenang-wenangnya ke dalam permintaan keluar. Layan panggilan pihak ketiga dan rentas penyewa sebagai punca kepercayaan baharu melainkan dasar yang jelas membenarkan pemajuan.
Langkah 3: Kendalikan pengangkutan dan percubaan semula
Takrifkan pembawa yang setara untuk HTTP, metadata gRPC, dan atribut mesej. Kekalkan hanya medan yang diperlukan untuk mengaitkan tugasan tak segerak; jangan siri rahsia ke dalam barisan gilir. Semasa percubaan semula, kekalkan hubungan surih yang asal sambil menghalang keputusan perniagaan yang pendua atau lapuk daripada dipercayai tanpa pengesahan semula.
Langkah 4: Reka bentuk tingkah laku kegagalan
Konteks yang tidak terbentuk dengan betul atau bersaiz lebih patut dilucutkan atau ditolak mengikut risiko titik akhir (endpoint), manakala permintaan itu sendiri kekal boleh dicerap dengan punca surih tempatan baharu apabila selamat. Dedahkan pembilang berkod sebab (reason-coded counters), bukan nilai mentah. Jadikan versi dasar dan hasil penguatkuasaan dapat dilihat oleh pengendali.
Langkah 5: Kendalikan dan buktikan nilai
Jejak kadar penyertaan surih, kegagalan pengekstrakan dan suntikan, bait yang ditambah, pemangkasan, penolakan dasar, pelanggaran rentas sempadan, dan ralat pensiratan barisan gilir. Lakukan pensampelan secara selamat dan elakkan label metrik berkardinaliti tinggi yang tidak terhad. Tambahkan ujian kontrak untuk setiap protokol yang disokong dan pelancaran dasar kenari (canary) sebelum menguatkuasakan penolakan.
Contoh jawapan model
"Saya akan menganggap konteks yang disebarkan sebagai saluran data yang tidak dipercayai. Daftaran berversi mentakrifkan medan diagnostik dan perniagaan yang boleh dibawa, kepekaan dan saiznya. Perisian tengah mengesahkan dan mensanitasikan setiap lompatan (hop), dengan peraturan yang lebih ketat untuk panggilan pihak ketiga dan rentas penyewa; rahsia tidak sekali-kali memasuki pembawa atau barisan gilir. Konteks surih kekal berasingan daripada baggage perniagaan. Saya akan menyokong atribut HTTP, gRPC, dan tak segerak, mentakrifkan pelucutan berbanding penolakan, serta mengukur kadar penyertaan, kegagalan dasar, bait, dan pelanggaran. Pelancaran kenari dan metrik berkod sebab membolehkan kami mengetatkan dasar tanpa kehilangan kebolehcerapan."
Kesilapan biasa
- Memajukan setiap pengepala masuk → data yang tidak dipercayai merentasi sempadan → gunakan senarai dibenarkan dan pensanitasi.
- Meletakkan token atau PII dalam baggage → log dan perkhidmatan hiliran boleh mendedahkannya → asingkan data sensitif daripada masuk.
- Menggunakan baggage sebagai label metrik → kardinaliti dan kos meletup → rekod dimensi dan kod sebab yang terhad.
- Mengabaikan barisan gilir dan percubaan semula → kerja tak segerak kehilangan atau mempercayai konteks lapuk → takrifkan kontrak khusus pengangkutan dan sahkan semula.
- Menolak setiap permintaan yang tidak terbentuk dengan betul → kebolehcerapan dan ketersediaan terjejas → pilih pelucutan atau penolakan mengikut risiko titik akhir.
- Tiada belanjawan saiz → pengepala menyebabkan kegagalan proksi → hadkan setiap medan dan jumlah keseluruhan pembawa.
Soalan susulan
Soalan susulan 1: Patutkah ID penyewa disebarkan?
Hanya apabila destinasi dibenarkan untuk penyewa tersebut dan nilainya disahkan terhadap identiti yang disahkan. Ia tidak sepatutnya menjadi pihak berkuasa dengan sendirinya.
Soalan susulan 2: Apakah perbezaan antara konteks surih dan baggage?
Konteks surih menghubungkan span dan status penyebaran. Baggage membawa data nama/nilai yang ditakrifkan oleh aplikasi dan oleh itu memerlukan dasar kepekaan, pemilikan, dan destinasi yang lebih ketat.
Soalan susulan 3: Bagaimanakah anda menghalang pertambahan saiz pengepala?
Tetapkan belanjawan bagi setiap medan dan jumlah keseluruhan, tolak atau pangkas dengan metrik berkod sebab, dan utamakan rujukan terhad kepada keadaan sebelah pelayan apabila konteks yang lebih besar tidak dapat dielakkan.
Soalan susulan 4: Apakah yang berlaku pada sempadan yang tidak dipercayai?
Lucutkan medan yang tidak diluluskan, cipta atau teruskan hanya maklumat surih yang dibenarkan oleh dasar, dan catatkan keputusan dasar ke dalam log tanpa merekodkan nilai sensitif.