Gesaan dan konteks
Soalan ini menguji sama ada anda boleh menukar simptom yang berselang-seli kepada rantaian bukti yang boleh diulang. Pepijat konkurensi mungkin melibatkan data race, susunan kunci (lock ordering), jalinan mesej, tamat masa (timeout) atau input luaran; satu log biasanya merekodkan hasil tanpa mengekalkan susunan yang menyebabkannya. Record/replay boleh mengekalkan peristiwa bukan deterministik daripada satu pelaksanaan dan memainkannya semula, tetapi ia dikekang oleh sokongan platform, panggilan sistem, overhed dan keadaan luaran yang tidak direkodkan. Liputi persampelan selamat, diagnosis berlapis, sempadan tayangan semula dan pemalsuan (falsification) selepas pembetulan.
Perkara yang dinilai oleh penemu duga
- Sama ada anda mentakrifkan invarian, impak dan pembiakan semula minimum sebelum mendayakan penjejakan penuh.
- Sama ada anda membezakan data race, race logik, kebuntuan (deadlock), livelock dan penghantaran luaran pendua.
- Sama ada anda boleh menyatakan perkara yang sebenarnya boleh dibuktikan oleh pengesan lumba, log biasa, garis masa dan record/replay.
- Sama ada anda boleh mereka bentuk pengesahan progresif di bawah kekangan privasi, overhed dan risiko pengeluaran.
Soalan penjelasan untuk ditanya terlebih dahulu
Jelaskan maksud "hilang", permintaan yang terjejas, tetingkap masa, versi, seni bina mesin dan sama ada berbilang proses atau perkhidmatan terlibat. Bolehkah anda memperoleh ID permintaan, ID thread atau goroutine, metrik kunci dan metrik giliran? Adakah simptom kelihatan seperti memori kongsi yang tidak disegerakkan, mesin keadaan (state machine) yang rosak, atau mesej pendua dan tidak mengikut urutan? Adakah kejayaan ditakrifkan oleh tiada laporan lumba, invarian yang dipelihara, atau kadar kerugian perniagaan di bawah ambang tertentu?
Rangka kerja jawapan 30 saat
Saya akan memelihara bukti dan mentakrifkan invarian data terlebih dahulu, kemudian menggunakan log dan metrik berkos rendah untuk mengecilkan pencetus. Dalam ujian terkawal, jalankan pengesan lumba, semakan thread, ujian tegasan dan gangguan penjadual (scheduler perturbation). Jika kegagalan masih sukar untuk dihasilkan semula dan platform disokong, rakam satu kegagalan dan tayang semula berulang kali sambil memeriksa kunci, operasi atomik dan susunan mesej untuk mencari invarian pertama yang dilanggar. Baiki pemilikan, penyegerakan atau mesin keadaan berbanding menambah jeda tidur (sleep). Tayang semula kegagalan asal, luaskan ujian jalinan dan sahkan dengan penyesuaian perniagaan serta suntikan kesalahan (fault injection). Redaksi, hadkan dan padamkan rakaman; tayangan semula ialah bukti dalam sempadan, bukan bukti muktamad tentang setiap platform dan kebergantungan.
Penyelaman mendalam langkah demi langkah
1. Tulis invarian dan sempadan bukti
Tulis semula "satu rekod telah hilang" sebagai penegasan (assertions) seperti nombor jujukan unik, baki akaun yang terpelihara atau mesej yang kekal boleh dicuba semula sehingga perakuan (acknowledgement). Tandakan keadaan kongsi, pemilik, protokol kunci atau atomik, kesan sampingan luaran dan laluan pemulihan. Asingkan fakta yang diperhatikan, hipotesis yang munasabah dan cabang yang masih perlu disahkan supaya satu log ralat tidak menjadi punca utama yang tidak wajar.
2. Kecilkan pencetus dengan isyarat berkos rendah
Tambahkan ID korelasi pada permintaan, tugas, thread atau goroutine dan rekodkan peralihan keadaan serta panjang giliran utama dan bukannya setiap arahan. Gunakan beban, suntikan kependaman, gangguan penjadual dan larian berulang untuk menguatkan jalinan. Dokumentasikan laluan kod yang diliputi oleh pengesan lumba dan yang tidak dapat diperhatikan; larian yang bersih tidak membuktikan bahawa logik perniagaan bebas daripada keadaan lumba.
3. Tentukan masa untuk menggunakan record/replay
Gunakan record/replay hanya apabila pelaksanaan yang gagal boleh ditangkap dalam platform dan sempadan input yang sama serta log biasa tidak dapat mengekalkan susunan yang menentukan. Alat boleh merekodkan hasil panggilan sistem, penjadualan thread atau input bukan deterministik lain supaya penyahpepijat boleh bergerak ke hadapan, ke belakang dan memeriksa keadaan. Sahkan seni bina yang disokong, model proses, sekatan kotak pasir (sandbox), kapasiti storan dan overhed sebelum mendayakannya pada trafik pengeluaran teras.
4. Jejak ke belakang daripada invarian pertama yang dilanggar
Semasa tayangan semula, tetapkan titik putus (breakpoints) atau titik tonton (watchpoints) dan bandingkan pemboleh ubah kongsi, pemilik kunci, jujukan mesej dan hasil komit antara pelaksanaan yang betul dan yang gagal. Cari capahan pertama dan bukannya meneka ke belakang daripada rekod akhir yang hilang. Untuk setiap jalinan calon, tulis hubungan happens-before: penulisan mana yang mesti mendahului pembacaan dan perakuan mana yang mesti menyusuli ketahanan (persistence). Jika perkhidmatan luaran tidak boleh dimainkan semula, sediakan olok-olok (mocks) deterministik atau input yang direkodkan dan nyatakan dengan tepat perkara yang dikecualikan oleh bukti tersebut.
5. Baiki reka bentuk, bukan sekadar jadual
Utamakan perubahan pemilikan, skop kunci, peralihan keadaan atomik atau protokol perakuan supaya ketepatan mengikut invarian yang jelas dan bukannya jeda tidur atau perubahan keutamaan thread. Pembaikan mungkin memerlukan kunci kedapemasaan (idempotency keys), penulis tunggal, sempadan transaksi, penyebaran pembatalan atau penanda jujukan. Semak semula pengecualian, tamat masa, percubaan semula, ranap proses dan laluan pemulihan supaya kecacatan tidak dipindahkan ke cabang lain.
6. Tutup dengan pengesahan berlapis
Tayang semula kegagalan asal dan sahkan invarian kekal utuh. Kemudian jalankan pengesanan lumba, ujian tegasan dan gangguan penjadual merentas input dan konfigurasi mesin. Tambahkan penyesuaian perniagaan, penyerahan pendua, suntikan kesalahan dan latih tubi undur balik (rollback); ukur kerugian, pertindihan, kependaman dan overhed sumber. Simpan surihan diredaksi terkecil dengan versi alat, bendera binaan dan kesimpulan untuk tempoh terhad. Jika liputan luaran tidak dapat dibuktikan, hadkan tuntutan kepada "tidak dihasilkan semula dalam sempadan ini."
Model jawapan berkualiti tinggi
Saya akan mentakrifkan invarian seperti pemuliharaan baki, nombor jujukan unik dan susunan perakuan, kemudian melindungi dan meredaksi sampel. Saya akan mengecilkan pencetus dengan ID korelasi, peralihan keadaan, metrik giliran, beban dan gangguan penjadual sebelum menjalankan pengesan lumba dalam persekitaran terkawal. Pengesan tersebut merangkumi keadaan lumba yang benar-benar dilaksanakan, bukan setiap jalinan logik. Jika platform menyokongnya dan pembiakan semula kekal sukar, rakam satu kegagalan dan gunakan record/replay untuk bergerak ke belakang dan ke hadapan dalam penyahpepijat sehingga invarian pertama dilanggar dan hubungan happens-before jelas. Baiki pemilikan, penguncian atau mesin keadaan dan bukannya menambah jeda tidur, serta semak semula percubaan semula, tamat masa, ranap sistem dan pemulihan. Akhir sekali tayang semula surihan yang gagal, jalankan ujian tegasan lumba dan jalinan, serta sahkan dengan penyesuaian dan suntikan kesalahan. Rakam platform, kebergantungan, overhed dan sempadan bukti, serta padamkan surihan selepas tempoh pengekalan yang ditetapkan.
Kesilapan biasa
- Meneka daripada ralat akhir tanpa mentakrifkan invarian.
- Menganggap larian pengesan lumba yang bersih sebagai bukti bahawa semua logik konkurensi adalah betul.
- Mendayakan rakaman pengeluaran penuh tanpa mempertimbangkan privasi, cakera, CPU dan risiko storan surihan.
- Merekodkan cap masa tetapi bukan keadaan atau input yang diperlukan untuk membezakan jalinan.
- Menyembunyikan keadaan lumba dengan jeda tidur, lebih banyak percubaan semula atau perubahan keutamaan thread.
- Memainkan semula laluan bahagia (happy path) sahaja dan mengabaikan ranap, tamat masa, pembatalan dan sempadan luaran.
- Melangkau penyesuaian perniagaan, ujian tegasan, suntikan kesalahan dan rekod regresi yang boleh dihasilkan semula selepas pembaikan.
Soalan susulan dan respons
Bolehkah record/replay membuktikan tiada pepijat konkurensi?
Tidak. Ia membuktikan bahawa satu rakaman boleh dimainkan semula dalam persekitaran dan sempadan input yang disokong serta membantu mengesan masalah dalam pelaksanaan tersebut. Jadual, platform, perkhidmatan luaran dan laluan lain masih memerlukan pengesanan lumba, ujian tegasan dan suntikan kesalahan.
Bagaimana jika tayangan semula mengubah pemasaan (timing)?
Rakaman boleh menambah overhed atau menyokong peristiwa terpilih sahaja. Bandingkan syarat pencetus dan metrik utama sebelum dan selepas rakaman, kemudian semak silang dengan berbilang surihan, gangguan penjadual dan ujian tegasan bebas. Jika keterwakilan tidak dapat dikekalkan, anggap tayangan semula sebagai petunjuk dan bukannya bukti tunggal.
Bagaimanakah surihan kegagalan sensitif harus dikendalikan?
Gunakan senarai benarkan medan, redaksi atau pentokenan semasa pengumpulan, hadkan skop penyewa dan akses, serta gunakan kawalan penyulitan, pengekalan dan pemadaman. Tayang semula input terkecil dalam persekitaran terpencil dan jangan sekali-kali menyalin kelayakan mentah atau data pelanggan ke dalam infrastruktur penyahpepijatan.
Bilakah isu ini perlu menjadi pembaikan seni bina?
Eskalasi apabila berbilang thread atau perkhidmatan mengekalkan invarian yang sama atau apabila tampalan kunci dan percubaan semula tidak dapat mewujudkan pemilikan yang jelas. Beralih kepada penulis tunggal, mesin keadaan eksplisit, sempadan transaksi atau protokol mesej yang boleh disahkan, dengan pelan penghijrahan, keserasian dan undur balik. Menggantikan penyahpepijat sahaja bukanlah pembaikan seni bina.