Wawancara Linux: Kapan Sebaiknya Anda Menggunakan Monotonic Clock Alih-alih Wall-Clock Time?

Pertanyaan dan Di Mana Ini Berlaku

Sebuah layanan Linux membaca CLOCK_REALTIME saat permintaan dimulai dan memberlakukan timeout dua detik dengan "waktu saat ini dikurangi waktu mulai." Sumber yang sama memberi stempel waktu pada catatan audit, menjadwalkan tugas harian pada pukul 09:00 waktu setempat, dan mengurutkan peristiwa dari beberapa layanan. Setelah koreksi NTP atau perubahan jam manual, wall time dapat melompat maju atau mundur. Beberapa permintaan langsung kedaluwarsa; yang lain menunggu jauh lebih lama dari dua detik.

Pilih jam atau mekanisme pengurutan untuk waktu berlalu lokal dan timeout, sewa yang harus kedaluwarsa saat mesin ditangguhkan (suspend), jadwal kalender manusia, waktu audit yang tahan lama (durable), dan pengurutan kausalitas lintas mesin. Bahas mulai ulang proses, serialisasi, pergeseran jam (clock skew), dan rencana verifikasi.

Timeout dua detik, perilaku suspend, dan jadwal adalah asumsi wawancara. Jam utama Linux adalah CLOCK_REALTIME, CLOCK_MONOTONIC, dan CLOCK_BOOTTIME; sebuah runtime bahasa mungkin membungkusnya. Kategorinya adalah general karena keahlian intinya adalah semantik waktu sistem operasi dan penalaran keandalan alih-alih satu kerangka kerja aplikasi tertentu.

Sumber daya wawancara perancangan sistem yang diperbarui pada tahun 2026 memperlakukan wall clock, monotonic clock, koreksi jam, dan kegagalan pergeseran jam sebagai satu topik latihan. Dasar pemikiran POSIX.1-2024, Linux man-pages, dan dokumentasi Go menyediakan batasan API yang dapat diperiksa secara independen. Sumber-sumber ini menetapkan relevansi saat ini dan nilai persiapan yang berkelanjutan; mereka tidak menetapkan pertanyaan spesifik perusahaan atau frekuensi wawancara.

Apa yang Sedang Dievaluasi oleh Pewawancara

Pertama, dapatkah kandidat menanyakan pertanyaan apa yang harus dijawab oleh sebuah nilai waktu? Wall time menjawab "momen perdata (civil) atau UTC berapakah ini?" dan cocok untuk audit, masa berlaku sertifikat, dan jadwal kalender. Monotonic time menjawab "berapa banyak waktu yang telah berlalu dalam runtime ini?" dan cocok untuk durasi, backoff, dan timeout. Nama API atau presisi nanodetik tidak dapat menggantikan semantik.

Kedua, apakah kandidat mengetahui bahwa monotonik tidak berarti seragam secara sempurna, konsisten secara global, atau selalu bertambah maju? Linux CLOCK_MONOTONIC tidak mengalami lompatan diskontinu akibat pengaturan waktu sistem dan tidak bergerak mundur, tetapi penyesuaian NTP secara bertahap memengaruhi lajunya dan itu mengecualikan penangguhan sistem (suspend). Pembacaan berturut-turut bahkan dapat mengembalikan nilai yang sama.

Ketiga, dapatkah kandidat membedakan CLOCK_MONOTONIC, CLOCK_BOOTTIME, CLOCK_MONOTONIC_RAW, dan waktu CPU? BOOTTIME bersifat monotonik dan mencakup suspend. MONOTONIC_RAW menghindari penyesuaian bertahap NTP dan berguna untuk pengukuran jam tingkat rendah, tetapi ini bukan jawaban bawaan untuk timeout aplikasi. Jam CPU proses dan utas (thread) menghitung eksekusi pada CPU, bukan waktu yang dihabiskan untuk menunggu.

Keempat, akankah kandidat menghindari penyimpanan permanen atau transmisi pembacaan monotonik lokal seolah-olah itu adalah stempel waktu universal? Titik asalnya tidak memiliki arti kalender, dan itu bukan garis waktu yang tahan lama (durable) lintas mulai ulang (restart). Stempel waktu fisik saja tidak dapat membuktikan urutan lintas mesin. Urutan bisnis, posisi commit basis data, log konsensus, Lamport clock, atau hybrid logical clock harus menjamin kebenaran saat persyaratannya menuntut demikian.

Terakhir, dapatkah kandidat menyuntikkan kegagalan jam yang sebenarnya? Menunggu dua detik sekali saja tidak mencakup langkah lompatan wall-clock, slewing, suspend, restart, atau pergeseran jam jarak jauh (remote skew).

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Apakah dua detik berarti waktu aktif runtime atau waktu riil yang telah berlalu? Timeout permintaan saat proses berjalan normal menggunakan CLOCK_MONOTONIC. Sewa lokal yang harus hangus setelah suspend selama satu menit harus mempertimbangkan CLOCK_BOOTTIME.
• Haruskah tenggat waktu bertahan setelah proses dimulai ulang? Tenggat waktu monotonik dalam memori adalah milik satu instans yang sedang berjalan. Simpan secara persisten kedaluwarsa wall-time otoritatif atau status bisnis, lalu tetapkan alokasi batas lokal setelah proses menyala.
• Zona waktu mana yang mendefinisikan "harian pukul 09:00", dan apa yang terjadi pada jeda atau lipatan DST? Tugas kalender memerlukan zona IANA dan kebijakan untuk momen lokal yang hilang atau berulang. Monotonic time tidak dapat menyatakan aturan tersebut.
• Apa yang harus dibuktikan oleh catatan audit? Momen UTC yang dapat dibaca mendukung pencarian dan kepatuhan, tetapi kesamaan nilai (ties), pemutaran balik jam (rollback), dan pergeseran multihost juga memerlukan ID yang stabil, urutan commit, atau bidang kausal.
• Apakah pengurutan lintas layanan ditujukan untuk tampilan, deduplikasi, kausalitas, atau pengurutan total yang ketat? Tampilan mungkin mentoleransi pergeseran jam. Buku besar (ledger) atau replicated state machine biasanya membutuhkan otoritas commit atau log konsensus alih-alih "stempel waktu lebih besar yang menang."
• Bagaimana platform target menangani suspend dan migrasi VM? Linux mendefinisikan semantik jamnya, tetapi runtime bahasa yang sebenarnya, host, lapisan virtualisasi, dan resolusi masih memerlukan verifikasi spesifik versi.
• Apakah sinkronisasi melompatkan (step) atau menggeser perlahan (slew) jam? Langkah lompatan wall-clock secara langsung merusak pengurangan durasi. Slewing mempertahankan monotonic time tidak menurun tetapi sedikit mengubah lajunya relatif terhadap penghitung perangkat keras mentah.

Kerangka Jawaban 30 Detik

"Saya memilih jam berdasarkan pertanyaannya. Stempel waktu audit dan jadwal harian pukul 09:00 membutuhkan wall time yang tahan lama. Durasi dua detik atau timeout di dalam satu proses menggunakan monotonic clock sehingga langkah lompatan wall-clock tidak dapat membuatnya kedaluwarsa lebih cepat atau terlambat. Jika suspend harus menghabiskan masa sewa, Linux menyediakan CLOCK_BOOTTIME. Saya tidak melakukan serialisasi pembacaan monotonik maupun membandingkannya lintas mulai ulang atau lintas mesin. Wall time lintas layanan bersifat observasional; versi bisnis, commit log, atau logical clock menyediakan kebenarannya. Saya akan menyuntikkan langkah lompatan wall-clock maju dan mundur, lalu menguji slewing, suspend, restart, dan pergeseran jam host terhadap invarian terpisah untuk setiap kasus penggunaan."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Pisahkan Satu Nilai Waktu menjadi Lima Persyaratan

Buat tabel keputusan alih-alih menetapkan satu sumber untuk seluruh sistem:

Satu catatan dapat membawa dua dimensi waktu. Sebagai contoh, log permintaan menyimpan observed_at UTC untuk pengambilan data sementara proses menghitung duration_ms dari pembacaan awal monotonik. Bidang-bidang ini menjawab pertanyaan yang berbeda dan tidak saling menggantikan.

Langkah 2: Jelaskan Mengapa Wall Time Merusak Pengurangan Durasi

Misalkan kode mengevaluasi elapsed = realtime_now - realtime_start. Jika wall time melompat maju 90 detik setelah permintaan dimulai, pemeriksaan berikutnya secara keliru menyatakan timeout. Jika melompat mundur 90 detik, elapsed dapat menjadi negatif dan permintaan dapat menunggu sampai wall time mengejar. NTP juga dapat mengoreksi waktu secara bertahap dengan mengubah laju jam. Wall time harus selaras dengan waktu perdata eksternal, sehingga aplikasi tidak dapat mengasumsikan pembacaan berturut-turut yang meningkat secara ketat.

Ambil pembacaan awal dan saat ini dari monotonic clock yang sama, atau gunakan API timer/deadline yang secara eksplisit didasarkan padanya. Jangan pernah mengurangkan satu pembacaan realtime dari satu pembacaan monotonik; titik asal keduanya berbeda. Jangan memilih MONOTONIC_RAW hanya karena kata "raw" terdengar lebih akurat. Timeout aplikasi biasanya diuntungkan dari jam tidak menurun yang detiknya tetap diselaraskan mendekati detik riil, yaitu apa yang disediakan oleh jam monotonik POSIX/Linux biasa.

Langkah 3: Tentukan Apakah Suspend Menghabiskan Alokasi Waktu

Linux CLOCK_MONOTONIC berhenti berakumulasi saat sistem ditangguhkan. Jika laptop tidur selama satu menit, timer MONOTONIC lokal berdurasi 30 detik mungkin masih memiliki sisa waktu setelah dilanjutkan (resume). Itu bisa cocok untuk pekerjaan yang didefinisikan dalam waktu proses berjalan (runnable time), tetapi tidak untuk sesi atau sewa keamanan yang harus kedaluwarsa saat mesin tidur.

CLOCK_BOOTTIME mencakup suspend dan cocok dengan aturan yang terakhir. Membangunkan mesin yang ditangguhkan untuk melakukan pekerjaan tambahan memerlukan kemampuan dan izin alarm yang sesuai; memilih BOOTTIME saja tidak akan membangunkannya secara otomatis. Sewa yang melintasi reboot tetap tidak dapat menyimpan angka BOOTTIME saja secara persisten karena boot baru tidak menyediakan kelanjutan portabel dari titik asal yang lama.

Langkah 4: Tangani Batas Waktu Kalender dan Persistensi Secara Terpisah

"Harian pukul 09:00" adalah aturan kalender. Ini memerlukan wall time, zona waktu bernama, dan kebijakan DST. Waktu 09:00 suatu tanggal dapat dipetakan ke offset UTC yang berbeda setelah terjadi perubahan aturan; beberapa waktu lokal berulang atau tidak ada sama sekali. Simpan ekspresi kalender dan zona alih-alih mengonversinya sekali saat startup menjadi durasi monotonik yang tidak pernah dihitung ulang. Setelah satu kemunculan terpicu, pewaktuan monotonik dapat mengatur batas waktu eksekusi untuk proses berjalan tersebut.

Data audit harus menyimpan momen UTC yang dinormalisasi, zona atau offset asli saat bisnis membutuhkannya, ID catatan, dan urutan commit yang otoritatif. Wall time dapat dibaca manusia tetapi tidak unik dan tidak meningkat secara ketat. Stempel waktu yang sama atau lebih rendah selama rollback NTP tidak boleh merusak primary key, kursor, atau urutan saldo.

Langkah 5: Batasi Propagasi Lintas Proses dan Lintas Mesin

Pembacaan monotonik absolut hanya bermakna di dalam lingkungan runtime yang telah ditentukan. Dokumentasi resmi Go secara eksplisit menghapus pembacaan monotonik selama serialisasi. Protokol tidak dapat mengirimkan monotonic_deadline=8374921 ke host lain dan memintanya untuk membandingkan secara langsung; host tersebut mungkin memiliki titik asal lain, siklus boot lain, atau kontrak API yang berbeda.

RPC dapat mempropagasi sisa batas waktu yang dibatasi atau tenggat waktu UTC, tetapi komprominya harus eksplisit. Setiap lompatan (hop) menghabiskan batas waktu tersebut dengan monotonic clock lokal dan menyisakan ruang aman untuk transit, antrean, dan pergeseran jam. Sewa berisiko tinggi tidak dapat mempercayai waktu klien saja. Otoritas server, epoch sewa, dan token fencing menentukan apakah penulisan tetap valid.

Pengurutan peristiwa mengikuti metode berbasis persyaratan yang sama. UI log dapat menampilkan wall time dan menandai dugaan pergeseran jam. Kausalitas dapat menggunakan trace parents, urutan pesan, atau logical clock. Urutan mesin status yang ketat menggunakan posisi commit basis data atau log konsensus. Mengurutkan setiap peristiwa berdasarkan created_at hanya memberikan urutan pengamatan, bukan bukti urutan kejadian nyata.

Langkah 6: Ubah Pengujian menjadi Invarian Jam

Gunakan jam yang dapat disuntikkan (injectable clock) atau namespace waktu platform/virtual clock di lingkungan pengujian untuk mencakup:

1. Lompatkan wall time maju 90 detik setelah 500 ms; timeout monotonik dua detik tidak boleh langsung terpicu.
2. Lompatkan wall time mundur 90 detik; timeout tetap terpicu setelah kira-kira dua detik berlalu, sementara log UTC dapat bergerak mundur tanpa tabrakan ID.
3. Simulasikan koreksi bertahap, verifikasi tidak ada durasi negatif, dan catat toleransi kesalahan pengukuran yang diizinkan.
4. Tangguhkan sistem lebih lama dari durasi sewa. Tugas MONOTONIC mempertahankan alokasi batas yang ditentukan; sewa BOOTTIME telah kedaluwarsa.
5. Mulai ulang proses. Tidak ada pembacaan monotonik lama yang dipulihkan; status kedaluwarsa yang dipersistensikan ditetapkan kembali sesuai kontraknya.
6. Berikan offset jam yang berlawanan pada dua node pengujian. State machine tetap menerapkan peristiwa berdasarkan versi atau posisi log, bukan besaran wall-clock.
7. Simulasikan jeda dan lipatan DST, lalu verifikasi kebijakan eksplisit untuk harian-09:00.

Minimal, pantau jumlah durasi negatif, kesalahan timeout, kedaluwarsa terlalu cepat atau terlambat, peristiwa lompatan/slewing jam, offset host, eksekusi DST duplikat, dan penulisan yang ditolak karena tabrakan stempel waktu. Offset 90 detik adalah nilai injeksi kesalahan, bukan klaim tentang pergeseran jam di lingkungan produksi.

Contoh Jawaban Berkualitas Tinggi

"Implementasi ini menaruh tiga arti ke dalam satu nilai CLOCK_REALTIME. Wall time harus menerima perubahan manual dan sinkronisasi. Langkah lompatan maju membuat now - start tiba-tiba melebihi dua detik; pemutaran balik (rollback) membuat selisihnya lebih kecil atau negatif. Saya akan menghitung durasi permintaan dan backoff dalam satu domain waktu monotonik, sebaiknya melalui API deadline yang terikat pada jam tersebut.

Saya kemudian akan memisahkan persyaratan lainnya. Catatan audit menyimpan wall time UTC ditambah ID catatan yang stabil. Harian pukul 09:00 mempertahankan zona IANA dan kebijakan DST yang eksplisit. Jika sewa lokal harus kedaluwarsa selama suspend, Linux CLOCK_BOOTTIME cocok; jika hanya waktu proses berjalan yang dihitung, CLOCK_MONOTONIC cocok. Baik waktu CPU maupun MONOTONIC_RAW bukanlah pengganti langsung untuk timeout permintaan biasa.

Saya tidak akan menyimpan pembacaan monotonik dalam basis data, mengirimkannya ke host lain, atau memulihkannya setelah proses dimulai ulang. Log lintas layanan dapat membawa wall time untuk observasi, tetapi versi, urutan pesan, commit log, atau logical clock yang memegang kendali urutan bisnis. Setiap lompatan RPC menghabiskan sisa anggaran waktu yang dibatasi dengan monotonic clock lokalnya, sementara sewa keamanan juga menggunakan otoritas server dan fencing.

Terakhir, saya akan menyuntikkan lompatan maju 90 detik, rollback 90 detik, dan koreksi bertahap, kemudian menguji suspend, mulai ulang proses, dua node dengan pergeseran waktu berlawanan, dan batas-batas DST. Lulus berarti tidak ada durasi negatif, tidak ada timeout permintaan yang langsung terjadi atau terlambat 90 detik akibat langkah lompatan wall-clock, perilaku suspend berjalan sesuai yang dijanjikan, dan urutan status lintas host tidak berubah oleh pergeseran jam fisik."

Kesalahan Umum

• Memindahkan setiap stempel waktu ke monotonic clock → nilai monotonik tidak memiliki makna kalender yang dapat dipertukarkan dan tidak dapat menyatakan harian pukul 09:00 → pilih secara terpisah untuk durasi, kalender, audit, dan pengurutan.
• Terus mengurangkan CLOCK_REALTIME untuk timeout → lompatan maju kedaluwarsa terlalu cepat dan rollback kedaluwarsa terlambat → hitung waktu mulai, tenggat waktu, dan waktu saat ini dalam satu domain monotonik.
• Mengklaim waktu monotonik sama sekali tidak terpengaruh oleh NTP → Linux MONOTONIC menghindari lompatan diskontinu tetapi menerima penyesuaian frekuensi bertahap → pisahkan "tidak pernah bergerak mundur" dari "seragam sempurna."
• Mengasumsikan CLOCK_MONOTONIC mencakup suspend → Linux mengecualikan waktu yang ditangguhkan → tentukan semantik suspend terlebih dahulu dan gunakan BOOTTIME saat waktu tersebut harus dihitung.
• Memperlakukan CLOCK_MONOTONIC_RAW sebagai opsi bawaan yang ditingkatkan → mengabaikan disiplin jam dapat membuat pengukuran detik riil menjadi lebih buruk → gunakan waktu monotonik biasa untuk timeout aplikasi dan evaluasi raw untuk pengukuran tingkat rendah.
• Melakukan serialisasi tenggat waktu monotonik ke host lain → penerima tidak memiliki titik asal bersama yang portabel → propagasikan anggaran waktu yang ditentukan atau tenggat waktu UTC, konversikan secara lokal, dan batasi risiko pergeseran jam.
• Menggunakan created_at sebagai urutan bisnis lintas host → pergeseran jam dan rollback dapat membalikkan urutan peristiwa → tempatkan kebenaran pada versi, posisi commit, log konsensus, atau logical clock.
• Hanya menguji satu perubahan jam manual → slewing, suspend, restart, dan DST tetap tidak teruji → gunakan matriks jam yang dapat disuntikkan dan verifikasi invarian independen.

Pertanyaan Lanjutan dan Tanggapan

Apakah koreksi NTP bertahap membuat interval CLOCK_MONOTONIC dua detik menjadi tidak akurat?

Hal itu dapat sedikit menyesuaikan laju jam, tetapi tidak menghasilkan pemutaran balik diskontinu seperti pada langkah lompatan wall-clock. Timeout biasa biasanya menginginkan jam yang tidak menurun dan terdisiplin oleh sistem yang detiknya tetap mendekati detik riil, sehingga penyesuaian tersebut tepat. Kode sinkronisasi jam, pembandingan perangkat keras, atau analisis frekuensi dapat mengevaluasi CLOCK_MONOTONIC_RAW dan menangani suspend serta drift secara terpisah.

Sebuah sewa harus bertahan setelah mulai ulang dan kedaluwarsa saat mesin offline selama satu menit. Apa yang berubah?

Jangan menyimpan nilai lokal absolut MONOTONIC atau BOOTTIME secara persisten. Server menyimpan momen kedaluwarsa wall-time, epoch sewa, dan token fencing, dan klien melakukan validasi ulang dengan otoritas tersebut setelah terhubung kembali. Selama satu proses berjalan, sisa waktu yang diberikan dapat menjadi tenggat waktu BOOTTIME lokal. Sekalipun proses lama secara keliru meyakini sewanya masih aktif, lapisan penyimpanan akan menolak token fencing-nya yang sudah usang.

Jika kedua layanan menggunakan NTP, bisakah stempel waktu milidetik menentukan urutan peristiwa?

Tidak. Sinkronisasi mempersempit ketidakpastian tetapi tidak membuktikan kausalitas antara dua pembacaan fisik, dan latensi jaringan mengubah urutan pengamatan. Untuk tampilan log, pertahankan kedua nilai dan tampilkan ketidakpastiannya. Untuk mencegah status lama menimpa status baru, gunakan versi per-entitas, urutan pesan, posisi commit basis data, atau logical clock. Urutan ketat global memerlukan konsensus atau jalur pengurut tunggal (single-sequencer).

Mengapa tidak mengukur latensi permintaan dengan waktu CPU proses?

Permintaan mungkin menunggu pada jaringan, disk, kunci (lock), atau kolam koneksi (connection pool). Waktu tunggu tersebut memengaruhi latensi pengguna meskipun hampir tidak mengonsumsi CPU. Waktu CPU mengukur biaya komputasi; jam waktu berlalu mengukur latensi menyeluruh (end-to-end) dan timeout. Keduanya dapat dicatat, tetapi keduanya menjawab pertanyaan yang berbeda.

Bagaimana seharusnya perilaku harian pukul 09:00 saat transisi daylight saving time?

Tentukan aturan produk terlebih dahulu. Untuk waktu lokal yang tidak ada, lewati atau pindah ke momen valid berikutnya. Untuk waktu yang berulang, jalankan sekali atau sekali untuk setiap offset. Simpan zona IANA dan kunci deduplikasi alih-alih hanya menyimpan offset UTC saat ini. Setelah kemunculan kalender berikutnya dipilih, waktu tunggu lokal dan batas waktu eksekusi masih dapat menggunakan monotonic time.