Prompt dan konteks
Penemu duga mahukan bukti bahawa anda telah memacu perubahan yang mempunyai beban sejarah yang nyata. Sistem legasi mungkin masih berjalan sambil menggunakan masa on-call, gagal memenuhi keperluan keselamatan, atau menghalang produk baharu. Terangkan cara anda memutuskan untuk menamatkannya, memigrasikan pengguna dan mengendalikan perselisihan faham.
Ini bukan permintaan untuk penulisan semula teknikal atau cerita yang mengkreditkan "kerja berpasukan" untuk segala-galanya. Jawapan tersebut harus memperdengarkan pertimbangan, tindakan, bukti dan hasil anda dengan jelas.
Perkara yang dinilai oleh penemu duga
Mereka menguji sama ada anda bermula daripada aliran kerja pengguna dan bukannya usia sistem, menggunakan data untuk mencari orang yang terjejas, menjadikan risiko dan pemilikan jelas kelihatan, serta mengekalkan matlamat pengguna sepanjang perselisihan faham dan pelaksanaan. Panduan temu duga Amazon menekankan STAR, sumbangan individu yang spesifik dan hasil yang boleh diukur; kes penamatan Google SRE menekankan aliran kerja pengguna, komunikasi dan alatan migrasi.
Soalan untuk dijelaskan terlebih dahulu
Jelaskan sama ada "menamatkan" bermaksud menghentikan pengguna baharu, mengekalkan arkib baca sahaja (read-only), menutup sepenuhnya, atau menggantikan proses dalaman. Kemudian jelaskan peranan, skop, tarikh akhir, pengganti yang tersedia dan risiko yang tidak boleh diubah. Jika data syarikat tidak boleh dikongsi, labelkan angka sebagai ukuran sebenar yang dianonimkan atau andaian temu duga.
Struktur jawapan 30 saat
Gunakan lima ayat: konteks dan kos; matlamat yang saya kendalikan; cara saya menggunakan data akses dan temu bual pengguna untuk memilih kohort migrasi; cara saya mereka bentuk larian dwi (dual-run), pengunduran (rollback) dan komunikasi; serta hasil, pengajaran dan perubahan seterusnya. Gunakan "saya" untuk tindakan dan nombor untuk hasil.
Analisis langkah demi langkah
Langkah 1: Terjemahkan "legasi" kepada masalah yang boleh diuji
Jangan umumkan penutupan hanya kerana timbunan teknologi sudah lama. Nilaikan jam penyelenggaraan, insiden, kos, jurang pematuhan dan aliran kerja kritikal yang masih menggunakannya. Bahagikan mengikut pengguna, aliran kerja, saiz data dan kekerapan akses untuk mencari pengecualian yang belum dapat ditampung oleh pengganti. Google SRE menggunakan corak akses untuk memahami aliran kerja dan bukannya membuat keputusan berdasarkan statistik sistem semata-mata.
Langkah 2: Bina bukti migrasi dan laluan selamat yang terkecil
Tentukan keadaan sasaran bagi setiap kumpulan pengguna: migrasi terus, alatan penukaran, arkib baca sahaja, atau pelanjutan dengan had masa (time-boxed extension). Sediakan senarai semak keserasian, penyesuaian data (reconciliation), persekitaran latihan dan syarat henti yang jelas. Mulakan dengan kohort berisiko rendah supaya keupayaan pengganti dan kos migrasi diukur dalam penggunaan sebenar.
Langkah 3: Kendalikan perselisihan faham dan pihak berkepentingan
Tukarkan bantahan kepada risiko mengenai kehilangan data, gangguan kerja, pemilikan yang tidak jelas, atau keupayaan pengganti yang hilang. Bina senarai risiko dan rekod keputusan mingguan bersama sokongan, khidmat pelanggan, keselamatan dan pemilik pengganti. Berhujah dengan bukti; selepas keputusan dibuat, namakan pelaksana dan pihak berkuasa jeda supaya perselisihan faham tidak menjadi kelewatan yang berpanjangan.
Langkah 4: Reka bentuk larian dwi, pengunduran dan komunikasi
Kekalkan sistem lama sebagai baca sahaja atau boleh dipulihkan semasa migrasi dan berikan isyarat penyiapan yang boleh disahkan kepada setiap kohort. Berikan komunikasi awal tentang impak, sebab, tarikh akhir, langkah dan saluran bantuan; jika sesuatu kelompok (batch) gagal, nyatakan fakta, penyelesaian dan kemas kini seterusnya. Positif palsu yang mencemaskan pengguna yang tidak terjejas dan negatif palsu yang terlepas pandang pengguna yang terjejas kedua-duanya menghakis kepercayaan dan mewujudkan beban kerja perkhidmatan.
Langkah 5: Tentukan hasil dan pembelajaran
Jejak penyiapan migrasi, kejayaan aliran kerja kritikal, pengunduran, jam insiden, permintaan bantuan dan jam penyelenggaraan. Jangan hanya melaporkan bahawa "sistem lama telah ditutup"; tunjukkan sama ada pengguna yang terjejas berjaya menyelesaikan kerja, beban operasi menurun dan pengecualian apa yang tinggal. Retrospektif harus merekodkan andaian yang salah, isyarat awal dan pengesahan untuk bertindak lebih awal pada masa akan datang.
Contoh jawapan berkualiti tinggi
Saya pernah bertanggungjawab ke atas penamatan aliran kerja pelaporan yang masih digunakan oleh sekumpulan kecil pelanggan. Ia menggunakan kira-kira 20 jam penyelenggaraan manual setiap minggu. Sistem pengganti merangkumi kebanyakan pertanyaan, tetapi pelanggan volum tinggi bimbang tentang ketidakpadanan data sejarah. Saya membahagikan pengguna mengikut log akses dan aliran kerja: 82% boleh berhijrah secara terus, manakala 18% memerlukan penukaran sejarah.
Saya menetapkan matlamat untuk melengkapkan kohort berisiko rendah terlebih dahulu, bukannya menutup sistem serta-merta. Pasukan kejuruteraan menghasilkan laporan penyesuaian untuk kedua-dua output, sokongan menyediakan notis yang dikelompokkan mengikut pelanggan, dan saya mengendalikan papan migrasi mingguan dengan kriteria jeda. Selepas percubaan dua minggu, ketekalan laporan kritikal mencapai 99.9% tanpa sebarang pengunduran. Bagi pengguna selebihnya, kami membekalkan alatan penukaran dan arkib baca sahaja serta melanjutkan tarikh akhir akhir sekali sahaja.
Penyelenggaraan menurun daripada kira-kira 20 jam kepada 4 jam seminggu, dan setiap pelanggan dengan akses yang tinggal mempunyai laluan penggantian. Retrospektif mendapati bahawa kami telah memandang rendah format eksport satu wilayah, jadi kami menambah wilayah dan jenis eksport ke dalam pembahagian awal dan bukannya menemuinya hampir pada tarikh akhir.
Kesilapan biasa dan penambahbaikan
- Hanya menyatakan "sistem itu sudah lama": tambahkan impak pengguna, kos penyelenggaraan dan bukti penggantian.
- Menceritakan kisah penulisan semula kod: terangkan penemuan aliran kerja, kohort dan komunikasi.
- Memanggil mereka yang ragu-ragu sebagai penghalang: tunjukkan bukti risiko di sebalik kebimbangan mereka dan respons anda.
- Hanya melaporkan peratusan migrasi: tambahkan kejayaan tugas kritikal, pengunduran dan jumlah bantuan.
- Mendakwa sifar risiko: namakan laluan baca sahaja, pengunduran atau pelanjutan.
Soalan susulan dan respons
Bagaimana jika pengganti belum bersedia untuk setiap pengguna?
Kekalkan laluan pengecualian yang didokumenkan: arkib baca sahaja, alatan penukaran, atau pelanjutan dengan had masa. Tentukan pemilik dan syarat keluar untuk setiap pengecualian daripada memaksa peralihan (cutover) yang berisiko.
Bagaimanakah anda meyakinkan pihak berkepentingan yang menentang penamatan?
Saya bertanya tentang kegagalan yang cuba mereka elakkan, mengukur aliran kerja tersebut dan menjalankan migrasi kecil untuk menguji pengganti. Jika keputusan masih bertentangan dengan pilihan mereka, saya merekodkan risiko tersebut dan komited kepada pelan yang dipersetujui dengan syarat jeda.
Apakah yang akan anda lakukan jika migrasi menyebabkan kehilangan data?
Hentikan kelompok tersebut, pelihara sumber lama, kenal pasti rekod yang terjejas dan komunikasikan garis masa pemulihan yang konkrit. Selepas memulihkan perkhidmatan, tambahkan semakan penyesuaian automatik dan semak semula kriteria laluan kelompok seterusnya.
Bagaimanakah anda tahu projek itu berjaya?
Gunakan metrik hasil pengguna dan operasi secara bersama: kejayaan aliran kerja kritikal, penyiapan migrasi, volum pengunduran dan sokongan, serta jam penyelenggaraan. Sistem yang ditutup tanpa laluan pengguna yang selamat bukanlah penamatan yang berjaya.