Permintaan dan konteks
Pewawancara menginginkan bukti bahwa Anda telah mendorong perubahan dengan beban historis yang nyata. Sistem lawas (legacy system) mungkin masih berjalan sambil menghabiskan waktu on-call, gagal memenuhi persyaratan keamanan, atau memblokir produk baru. Jelaskan bagaimana Anda memutuskan untuk memensiunkannya, memigrasikan pengguna, dan menangani ketidaksepakatan.
Ini bukan permintaan untuk penulisan ulang teknis (technical rewrite) atau cerita yang mengaitkan segalanya dengan "kerja tim". Jawabannya harus membuat penilaian, tindakan, bukti, dan hasil Anda terdengar jelas.
Apa yang sedang diuji oleh pewawancara
Mereka menguji apakah Anda memulai dari alur kerja pengguna alih-alih usia sistem, menggunakan data untuk menemukan orang yang terdampak, membuat risiko dan kepemilikan terlihat jelas, serta menjaga tujuan pengguna tetap utuh melalui ketidaksepakatan dan eksekusi. Panduan wawancara Amazon menekankan STAR, kontribusi individu yang spesifik, dan hasil yang terukur; studi kasus pemensiunan Google SRE menekankan alur kerja pengguna, komunikasi, dan perkakas migrasi.
Pertanyaan untuk diklarifikasi terlebih dahulu
Klarifikasi apakah "memensiunkan" berarti menghentikan pengguna baru, mempertahankan arsip read-only, mematikan sepenuhnya, atau mengganti proses internal. Kemudian klarifikasi peran, cakupan, tenggat waktu, pengganti yang tersedia, dan risiko yang tidak dapat diubah (irreversible risks). Jika data perusahaan tidak dapat dibagikan, beri label pada angka sebagai pengukuran riil yang dianonimkan atau asumsi wawancara.
Struktur jawaban 30 detik
Gunakan lima kalimat: konteks dan biaya; tujuan yang saya miliki; bagaimana saya menggunakan data akses dan wawancara pengguna untuk memilih kohort migrasi; bagaimana saya merancang dual-run, rollback, dan komunikasi; serta hasil, pelajaran, dan perubahan berikutnya. Gunakan kata "saya" untuk tindakan dan angka untuk hasil.
Analisis langkah demi langkah
Langkah 1: Terjemahkan "lawas" menjadi masalah yang dapat diuji
Jangan mengumumkan penghentian hanya karena stack teknologi sudah tua. Kuantifikasi jam pemeliharaan, insiden, biaya, celah kepatuhan, dan alur kerja penting yang masih menggunakannya. Segmentasikan berdasarkan pengguna, alur kerja, ukuran data, dan frekuensi akses untuk menemukan pengecualian yang belum dapat ditangani oleh pengganti. Google SRE menggunakan pola akses untuk memahami alur kerja alih-alih memutuskan hanya dari statistik sistem.
Langkah 2: Bangun bukti migrasi dan jalur aman terkecil
Tentukan status target untuk setiap kelompok pengguna: migrasi langsung, perkakas konversi, arsip read-only, atau perpanjangan waktu terbatas (time-boxed extension). Sediakan daftar periksa kompatibilitas, rekonsiliasi data, lingkungan uji coba (rehearsal environment), dan kondisi penghentian yang eksplisit. Mulailah dengan kohort berisiko rendah sehingga kemampuan pengganti dan biaya migrasi dapat diukur dalam penggunaan nyata.
Langkah 3: Tangani ketidaksepakatan dan pemangku kepentingan
Ubah keberatan menjadi risiko mengenai kehilangan data, gangguan kerja, kepemilikan yang tidak jelas, atau kemampuan pengganti yang belum lengkap. Buat daftar risiko dan catatan keputusan mingguan bersama tim support, layanan pelanggan, keamanan, dan pemilik sistem pengganti. Berdebatlah dengan bukti; setelah keputusan diambil, tentukan pelaksana dan otoritas jeda sehingga ketidaksepakatan tidak menjadi penundaan tanpa batas.
Langkah 4: Rancang dual-run, rollback, dan komunikasi
Pertahankan sistem lama dalam status read-only atau dapat dibatalkan (reversible) selama migrasi dan berikan sinyal penyelesaian yang dapat diverifikasi kepada setiap kohort. Komunikasikan dampak, alasan, tenggat waktu, langkah-langkah, dan saluran bantuan sejak dini; jika suatu batch gagal, nyatakan faktanya, pemulihannya, dan pembaruan berikutnya. Positif palsu yang membuat panik pengguna yang tidak terdampak dan negatif palsu yang melewatkan pengguna yang terdampak sama-sama mengikis kepercayaan dan menciptakan beban kerja layanan.
Langkah 5: Tentukan hasil dan pembelajaran
Lacak penyelesaian migrasi, keberhasilan alur kerja penting, rollback, jam insiden, permintaan bantuan, dan jam pemeliharaan. Jangan hanya melaporkan bahwa "sistem lama telah dimatikan"; tunjukkan apakah pengguna yang terdampak dapat menyelesaikan pekerjaan, beban operasional menurun, dan pengecualian apa yang tersisa. Retrospektif harus mencatat asumsi yang salah, sinyal awal, dan validasi untuk bertindak lebih awal di lain waktu.
Contoh jawaban berkualitas tinggi
Saya pernah memimpin pemensiunan alur kerja pelaporan yang masih digunakan oleh sekelompok kecil pelanggan. Proses ini menghabiskan sekitar 20 jam pemeliharaan manual setiap minggu. Sistem pengganti mencakup sebagian besar kueri, tetapi pelanggan bervolume tinggi khawatir akan adanya ketidakcocokan data historis. Saya menyegmentasikan pengguna berdasarkan log akses dan alur kerja: 82% dapat dimigrasikan secara langsung, sementara 18% memerlukan konversi historis.
Saya menetapkan tujuan untuk menyelesaikan kohort berisiko rendah terlebih dahulu, bukan langsung mematikannya. Tim rekayasa membuat laporan rekonsiliasi untuk kedua output, tim support menyiapkan pemberitahuan yang dikelompokkan menurut pelanggan, dan saya memegang kendali atas papan migrasi mingguan dengan kriteria jeda. Setelah uji coba dua minggu, konsistensi laporan penting mencapai 99,9% tanpa adanya rollback. Untuk pengguna yang tersisa, kami menyediakan perkakas konversi dan arsip read-only serta memperpanjang tenggat waktu akhir satu kali.
Pemeliharaan turun dari sekitar 20 jam menjadi 4 jam per minggu, dan setiap pelanggan dengan akses tersisa memiliki jalur pengganti. Retrospektif menemukan bahwa kami telah meremehkan format ekspor satu wilayah, jadi kami menambahkan wilayah dan jenis ekspor ke segmentasi awal alih-alih baru mengetahuinya menjelang tenggat waktu.
Kesalahan umum dan perbaikan
- Hanya mengatakan "sistemnya sudah tua": tambahkan dampak pengguna, biaya pemeliharaan, dan bukti pengganti.
- Menceritakan kisah penulisan ulang kode: jelaskan penemuan alur kerja, kohort, dan komunikasi.
- Menyebut pihak yang skeptis sebagai penghambat: tunjukkan bukti risiko di balik kekhawatiran mereka dan respons Anda.
- Hanya melaporkan persentase migrasi: tambahkan keberhasilan tugas penting, rollback, dan volume bantuan.
- Mengklaim risiko nol: sebutkan jalur read-only, rollback, atau perpanjangan.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika pengganti belum siap untuk semua pengguna?
Pertahankan jalur pengecualian yang terdokumentasi: arsip read-only, perkakas konversi, atau perpanjangan waktu terbatas. Tentukan pemilik dan kondisi keluar untuk setiap pengecualian daripada memaksakan cutover yang berisiko.
Bagaimana Anda meyakinkan pemangku kepentingan yang menentang pemensiunan?
Saya menanyakan kegagalan apa yang mereka coba cegah, mengukur alur kerja tersebut, dan menjalankan migrasi kecil untuk menguji pengganti. Jika keputusan tetap bertentangan dengan preferensi mereka, saya mencatat risikonya dan berkomitmen pada rencana yang disepakati dengan kondisi jeda.
Apa yang akan Anda lakukan jika migrasi menyebabkan kehilangan data?
Hentikan batch tersebut, amankan sumber lama, identifikasi rekaman yang terdampak, dan komunikasikan jadwal pemulihan yang konkret. Setelah memulihkan layanan, tambahkan pemeriksaan rekonsiliasi otomatis dan revisi kriteria gerbang batch berikutnya.
Bagaimana Anda tahu proyek tersebut berhasil?
Gunakan metrik hasil pengguna dan metrik operasional secara bersamaan: keberhasilan alur kerja penting, penyelesaian migrasi, volume rollback dan support, ditambah jam pemeliharaan. Sistem yang ditutup tanpa jalur pengguna yang aman bukanlah pemensiunan yang sukses.