Soalan dan konteks
Soalan ini menguji sama ada anda boleh mengubah pertukaran teknikal yang penting menjadi memori pasukan yang boleh dicari, disemak dan dikembangkan. Huraikan bila ADR wajar digunakan, cara merekodkan pilihan yang ditolak, bagaimana rekod tersebut menyokong semakan kod dan penyelesaian masalah, serta cara mengendalikan keputusan yang digantikan oleh keputusan baharu.
Ini sesuai untuk peranan bahagian belakang (backend), platform, SRE, jurutera staf dan peranan rentas fungsi. Andaikan pasukan mempunyai repositori dan proses semakan tetapi tiada konvensyen rekod keputusan yang dikongsi; pilihan tersebut mungkin melibatkan kebolehpercayaan, keselamatan, antara muka, kebergantungan atau pertukaran kos yang tidak boleh diubah.
Perkara yang dinilai oleh penemu duga
Pertama, bolehkah anda mengenal pasti keputusan yang signifikan dari segi seni bina dan bukannya mendokumenkan setiap butiran pelaksanaan? Kedua, bolehkah anda menerangkan pilihan tersebut dengan konteks, kekangan, pilihan dan akibat yang neutral? Ketiga, bolehkah anda meletakkan ADR dalam kitaran hayat proposed, reviewed, accepted dan superseded? Keempat, bolehkah anda menjadikan rekod tersebut berguna dalam semakan kod, onboarding dan tindak balas insiden?
Soalan penjelasan untuk ditanya
- Adakah keputusan ini mempengaruhi struktur sistem, atribut kualiti utama, antara muka awam, atau hanya pelaksanaan tempatan?
- Apakah kekangan tegar yang dikenakan: kependaman (latency), ketersediaan, pematuhan, kemahiran, tempoh migrasi, atau kos?
- Adakah pilihan tersebut telah digunakan (deployed), atau adakah ADR masih berstatus Proposed? Siapakah yang boleh menerima atau menolaknya?
- Adakah ADR akan berada di dalam repositori, sistem dokumentasi, atau kedua-duanya? Bagaimanakah pasukan yang terjejas akan mencari kemas kini?
- Apakah isyarat yang akan mencetuskan penilaian semula: trafik, kadar kegagalan, kos, atau perubahan kawal selia?
Kerangka jawapan 30 saat
“Saya mula-mula menyemak sama ada pilihan tersebut mengubah struktur sistem, atribut kualiti utama atau antara muka yang sukar diubah balik. Jika ya, saya mencipta ADR yang ringkas. Ia merekodkan konteks, kekangan, pilihan yang dipertimbangkan, alternatif yang ditolak, keputusan, pertukaran, risiko dan status, kemudian pasukan yang terjejas menyemaknya semasa berstatus Proposed. Selepas penerimaan, saya menganggapnya sebagai sejarah yang tidak boleh diubah (immutable); apabila keperluan berubah, saya mencipta ADR pengganti, memautkan rekod lama dan mengemas kini indeks. Saya menyimpan rekod tersebut dalam repositori berversi yang mudah diakses dan merujuknya dalam semakan reka bentuk, semakan kod, onboarding dan penyelesaian masalah.”
Jawapan langkah demi langkah
Langkah 1: Tetapkan ambang rakaman
Cipta ADR apabila sesuatu pilihan mempengaruhi struktur sistem, atribut kualiti utama, antara muka awam, kebergantungan penting atau kos yang sukar diubah balik. Penamaan, butiran pemfaktoran semula sekali sahaja, atau pilihan yang telah dikawal oleh piawaian yang jelas biasanya tidak memerlukan rekod tersendiri. Ambang ini mengekalkan keputusan yang akan mengubah pertimbangan masa depan tanpa mewujudkan lambakan dokumentasi yang tidak perlu.
Langkah 2: Terangkan masalah secara neutral
Nyatakan masalah, impak pengguna atau perniagaan, keperluan fungsian dan bukan fungsian, tarikh akhir serta kekangan yang tidak boleh dirunding. Jangan masukkan pilihan yang digemari secara terselindung ke dalam konteks atau menggantikan fakta dengan "pasukan X bertegas." Penyumbang baharu sepatutnya memahami mengapa sesuatu keputusan diperlukan sekarang.
Langkah 3: Bandingkan pilihan dan pertukaran (trade-offs)
Senaraikan pilihan yang benar-benar dipertimbangkan, termasuk pilihan yang ditolak dan sebab ia ditolak. Bandingkan kependaman, ketersediaan, radius impak (blast radius), keselamatan, kos migrasi, beban operasi dan keupayaan pasukan; jika nilai tidak pasti, nyatakan andaian dan tahap keyakinan. Pastikan ADR fokus pada keputusan dan pautkan kajian terperinci (spikes) atau reka bentuk secara berasingan.
Langkah 4: Nyatakan keputusan dan akibatnya
Tulis keputusan yang boleh berdiri sendiri, seperti “Kami akan menggunakan barisan gilir wilayah dan menerima kelulusan manual untuk failover rentas wilayah.” Kemudian rekodkan faedah yang dijangkakan, kos, risiko, kawalan yang diperlukan dan komponen yang terjejas. “Pilih pilihan A” adalah tidak mencukupi kerana penyemak masa depan tidak dapat melihat sebab atau harga yang perlu dibayar.
Langkah 5: Tetapkan status, pemilikan dan semakan
Gunakan status seperti Proposed, Accepted, Rejected, Deprecated dan Superseded. Tetapkan pemilik dan jemput pasukan yang terjejas untuk membaca dan memberi komen semasa Proposed; selepas penerimaan, tambahkan tarikh, pihak berkepentingan dan versi. Semakan mengesahkan bahawa fakta, kekangan, pilihan dan akibat adalah jelas, bukan memastikan semua orang akan bersetuju selama-lamanya.
Langkah 6: Masukkan ADR ke dalam aliran kerja kejuruteraan
Versikan ADR bersama repositori atau sistem dokumentasi dan kekalkan indeks yang boleh dicari. Apabila semakan reka bentuk atau kod mendapati perubahan yang bercanggah dengan keputusan yang telah diterima, pautkan ADR tersebut dan wajibkan rekod perubahan yang jelas. Onboarding, penyerahan tugas dan tindak balas insiden juga harus menggunakan ADR untuk menjawab "mengapa dibuat begini", sekali gus mengurangkan perdebatan yang berulang.
Langkah 7: Tambah rekod baharu apabila keputusan berubah
Kekalkan ADR yang telah diterima atau ditolak sebagai tidak boleh diubah (immutable). Jika bukti baharu, skala, kos atau peraturan mengubah kesimpulan, tulis ADR baharu yang menerangkan konteks baharu, batasan lama dan pertukaran baharu. Setelah diterima, tandakan rekod lama sebagai Superseded dan pautkan kedua-dua rekod. Ini mengekalkan sejarah sambil menjadikan keputusan semasa mudah dicari.
Contoh jawapan yang mantap
“Saya mula-mula menyemak sama ada ini mempengaruhi struktur sistem, atribut kualiti utama, antara muka atau kos yang tidak boleh diubah balik; jika ia hanya pelaksanaan tempatan, saya tidak akan menambah ADR. Sebaik sahaja ia memenuhi ambang, saya menulis rekod Proposed dengan konteks masalah, keperluan pengguna dan bukan fungsian, kekangan, pilihan, alternatif yang ditolak, keputusan, pertukaran, risiko dan keyakinan.
Saya menjemput pasukan yang terjejas untuk membaca sebelum perbincangan semakan, dan merekodkan status, pemilik, tarikh dan pihak berkepentingan. Selepas penerimaan, saya menyimpan ADR dalam repositori berversi yang boleh dicari dan merujuknya dalam semakan reka bentuk, semakan kod, onboarding dan penyelesaian masalah. Ia kekal ringkas dan berfakta dan bukannya menggantikan dokumen reka bentuk yang lengkap.
Jika keperluan atau bukti berubah, saya tidak mengedit rekod yang telah diterima. Saya mencipta ADR baharu yang menerangkan sebab keputusan lama tidak lagi sesuai, pilihan baharu dan akibatnya. Selepas penerimaan, saya menandakan rekod lama sebagai Superseded dan memautkan kedua-duanya, supaya pasukan melihat pilihan semasa tanpa kehilangan sejarah pertimbangan.”
Kesilapan lazim
- Menulis panduan reka bentuk penuh → keputusan sukar dicari → kekalkan konteks, pilihan, keputusan dan akibat; pautkan butiran.
- Merekodkan pemenang sahaja → perdebatan berulang kemudian hari → sertakan pilihan yang ditolak dan kekangan pada masa itu.
- Menggantikan kekangan dengan keutamaan peribadi → rekod tidak boleh disemak secara objektif → gunakan fakta dan andaian yang neutral dan boleh diperhatikan.
- Mengedit rekod yang diterima secara langsung → sejarah hilang → tambah rekod baharu dan tandakan yang lama sebagai Superseded.
- Meninggalkan status dan pemilik → tiada siapa tahu sama ada ia terpakai → jejaki kitaran hayat, pemilik dan tarikh penerimaan.
- Tidak pernah memetik ADR → dokumentasi tiada nilai operasi → hubungkannya dengan semakan reka bentuk, semakan kod, onboarding dan tindak balas insiden.
Soalan susulan dan jawapan
Soalan susulan 1: Bolehkah pasukan menerima ADR semasa ada pihak yang tidak bersetuju?
Ya. Rekodkan bantahan yang belum diselesaikan, risiko dan pihak yang boleh menerima keputusan tersebut. Semakan menjadikan pilihan dan kosnya jelas; ia bukan bertujuan mencipta konsensus kekal secara paksa. Jika bukti tiada, kekalkan ADR sebagai Proposed dan jadualkan tugas pengesahan.
Soalan susulan 2: Bilakah anda patut mengisi kembali (backfill) ADR yang lalu?
Isi kembali apabila struktur sedia ada, antara muka atau pertukaran kualiti adalah penting tetapi tiada siapa yang dapat menerangkannya. Gunakan komit, data insiden dan temu bual penyelenggara, serta labelkan hasilnya sebagai rekod retrospektif supaya inferens tidak dipersembahkan sebagai fakta sezaman.
Soalan susulan 3: Repositori atau wiki?
Utamakan repositori berversi yang berdekatan dengan kod yang terjejas supaya rekod disemak bersama pelaksanaan. Jika pihak berkepentingan perniagaan atau keselamatan memerlukan akses yang lebih luas, cerminkan (mirror) indeks atau ringkasan sambil mengekalkan satu sumber sahih untuk mengelakkan percanggahan.
Soalan susulan 4: Bagaimanakah anda menunjukkan nilai ADR?
Jejaki masa yang diambil oleh ahli baharu untuk memahami pilihan utama, perdebatan yang berulang, pelanggaran keputusan yang diterima yang ditemui dalam semakan, dan berapa cepat pasukan tindak balas insiden mencari konteks. Metrik mendedahkan jurang; jumlah bilangan dokumen bukanlah matlamatnya.