Bagaimanakah saya beralih ke sistem baharu tanpa menghentikan kerja?

Anda boleh beralih tanpa menghentikan kerja jika tidak menutup sistem lama sebelum sistem baharu membuktikan dirinya: jalankan kedua-duanya pada transaksi sebenar yang sama dan bandingkan hasilnya, uji kes jarang yang dinamakan oleh pemilik proses, wajibkan kelulusan manusia bagi setiap modul sebelum ia digunakan, dan pastikan sistem lama sedia untuk digunakan semula. Dalam panduan pelaksanaan migrasinya, Microsoft mengesyorkan pemantauan sistem baharu dalam tempoh 24 hingga 48 jam pertama selepas peralihan dan mengekalkan persekitaran sumber sebagai pilihan undur sepanjang tempoh penstabilan.

Dalam bahagian 5 anda telah memilih laluan bagi setiap sistem. Bahagian ini tidak mengulangi kaedah peralihan umum yang kami terangkan dalam Pemodenan sistem warisan tanpa henti. Ia memberi tumpuan kepada perkara baharu: apa yang perlu diuji apabila AI yang menulis atau menukar kod baharu.

Mengapa kod yang ditukar oleh AI memerlukan pengujian berbeza

Kod yang dihasilkan oleh alat penukaran kelihatan kemas dan berjalan pada cubaan pertama, dan itulah yang menyebabkan kesilapannya sukar dilihat. Kesilapan tidak muncul dalam urusan harian, tetapi dalam kes yang berlaku sebulan sekali atau setahun sekali. Amazon menerangkan dalam panduan transformasi aplikasi kerangka utama bahawa penukaran awal daripada COBOL kepada Java mengekalkan tingkah laku yang sama, kemudian satu langkah bernama Reforge menggunakan model bahasa besar untuk menyusun semula kod mengikut gaya Java moden. COBOL ialah bahasa pengaturcaraan lama yang masih menjalankan banyak sistem perbankan dan kerangka utama; kerangka utama (mainframe) ialah pelayan pusat yang besar tempat sistem teras organisasi besar dijalankan.

Setiap langkah yang menulis semula kod boleh mengubah perincian kecil. Oleh itu, tidak cukup jika pembangun membaca kod baharu dan berkata ia kelihatan betul. Pengurusan hanya ada satu soalan: adakah sistem baharu memberikan hasil yang sama seperti sistem lama pada data yang sama? Jawapannya datang daripada membandingkan hasil, bukan membaca kod.

Bandingkan hasil pada transaksi sebenar yang sama

Ambil satu tempoh perniagaan yang sudah ditutup, contohnya bulan yang akaunnya sudah ditutup, jalankan transaksinya dalam sistem baharu, kemudian bandingkan hasilnya dengan keluaran sistem lama. Perkara yang perlu dibandingkan:

• Angka akhir: jumlah invois, baki dan stok pada akhir tempoh.
• Laporan: laporan bulanan yang menjadi sandaran pengurusan, baris demi baris.
• Apa yang dihantar ke sistem lain: fail dan mesej yang dihantar ke bank, perakaunan atau portal kerajaan.
• Penolakan dan ralat: transaksi yang ditolak oleh sistem lama mesti ditolak juga oleh sistem baharu, atas sebab yang sama.

Sesetengah alat membantu persediaan, bukan penilaian. AWS Transform untuk kerangka utama, misalnya, membina pelan ujian berdasarkan ciri kod, kerumitan kerja dan laluan penjadual dalam 3 fasa (konfigurasi, penentuan skop dan semakan), kemudian menjana skrip untuk mengumpul data ujian daripada kerangka utama dalam 4 fasa. Namun Amazon mengingatkan dalam panduan yang sama bahawa skrip ini mesti dijalankan pada kerangka utama anda sendiri, dengan kebenaran pasukan anda. Alat itu menyediakan; pasukan anda yang menjalankan dan memutuskan. Untuk menyemak data itu sendiri, Microsoft mencadangkan perbandingan bilangan baris sebagai semakan pantas, kemudian jumlah semak (checksum) sebagai semakan lebih mendalam: jumlah semak ialah nombor yang dikira daripada data dan berubah jika satu aksara pun berubah.

Kes jarang: tanya mereka yang mengetahuinya

Transaksi sebenar selama sebulan tidak merangkumi segalanya. Kes yang merosakkan sistem diketahui oleh pemilik proses, bukan pembangun: penutupan akaun akhir tahun kewangan, pemulangan separa ke atas invois lama, pelanggan dengan harga istimewa, invois yang dibatalkan selepas dipos, gaji pekerja yang mula bekerja pada pertengahan bulan. Minta setiap pemilik proses menyenaraikan kes yang membimbangkan mereka, kemudian jadikan setiap kes satu ujian dengan hasil jangkaan yang ditulis sebelum dijalankan.

Di sinilah peraturan yang anda sahkan dalam bahagian 4 kembali berguna: setiap peraturan yang disahkan menjadi sekurang-kurangnya satu kes ujian. Peraturan tanpa ujian ialah peraturan yang tidak dapat anda pastikan terselamat daripada penukaran. Mengenai jenis pengujian itu sendiri, lihat panduan pengujian perisian dan jaminan kualiti kami.

Kelulusan manusia bagi setiap modul

Contoh terbitan yang paling jelas bagi prinsip ini ialah saluran migrasi sistem perbankan yang diumumkan oleh Thought Machine bersama Amazon pada 29 September 2026. Ia melalui 4 peringkat: mengekstrak logik perniagaan daripada aplikasi warisan dengan AWS Transform, menyatukan variasi berulang menjadi spesifikasi bersepadu, menjana produk kewangan baharu dan set ujiannya dengan ejen AI, dan peringkat pengesahan yang memberi pasukan kejuruteraan dan pasukan risiko bank kuasa kelulusan yang jelas sebelum apa-apa diterima. Malah selepas diluluskan, hasilnya masuk ke persekitaran kotak pasir yang terasing untuk penilaian lanjut, bukan terus ke pengeluaran.

Pengajaran untuk syarikat anda tidak memerlukan bank mahupun Amazon: setiap modul sistem, seperti pengebilan, penggajian atau inventori, menerima dua tandatangan sebelum digunakan. Satu daripada pihak teknikal, yang mengesahkan semua ujian telah dijalankan, dan satu daripada pemilik proses, yang mengesahkan hasilnya betul dari segi perniagaan. Microsoft meminta perkara yang sama selepas peralihan: pemilik aplikasi mengesahkan semua fungsi utama berjalan dengan betul.

Operasi selari dan pelan undur

Operasi selari bermaksud kedua-dua sistem berjalan seiring untuk tempoh yang ditetapkan, dengan sistem lama kekal sebagai rujukan rasmi. Sebelum bermula, tentukan bila tempoh itu tamat dan syarat apa yang membenarkannya tamat, contohnya hasil yang sepadan sepanjang satu kitaran perniagaan penuh. Kemudian aturkan peralihan seperti berikut:

Pelan undur bukan pengakuan kegagalan; ia ialah insurans. Tulis lebih awal perkara yang akan membuat anda berundur, seperti kesilapan dalam invois atau proses teras yang terhenti, siapa yang memegang keputusan itu dan bagaimana pengguna kembali ke sistem lama. Jangan tutup sistem lama secara kekal sebelum tempoh penstabilan tamat. Apa yang biasanya gagal dalam minggu-minggu pertama selepas peralihan telah kami huraikan dalam Tiga puluh hari pertama selepas migrasi.

Pandangan Origami

Kami menganggap peralihan sebagai keputusan pengurusan, bukan peristiwa teknikal. Oleh itu kami membina perbandingan antara kedua-dua sistem sebelum membina sistem baharu itu sendiri, dan bersetuju awal dengan pemilik proses tentang kes jarang serta hasil jangkaannya, supaya takrif kejayaan sudah ditulis sebelum sesiapa melihat hasilnya.

Kami menggunakan AI untuk mempercepat penukaran dan menjana ujian, tetapi kelulusan setiap modul kekal pada individu yang dinamakan dalam pasukan anda. Untuk melihat cara kami bekerja, lihat perkhidmatan kami.

Latihan minggu ini: helaian peralihan bagi setiap modul

Bagi setiap sistem yang anda pilih untuk ditukar atau dibina semula dalam bahagian 5, isi helaian ini bersama pemilik proses sebelum menetapkan sebarang tarikh peralihan:

Ini contoh ilustrasi; helaian anda akan berbeza. Yang penting, jangan tetapkan tarikh peralihan sehingga setiap modul mempunyai dua penandatangan yang dinamakan dan pencetus undur yang bertulis.

Seterusnya

Masih ada satu soalan yang ditanya oleh setiap pengurus sebelum menghantar kod dan data kepada alat AI: ke mana data saya pergi semasa pemodenan? Bahagian 7, bahagian terakhir, menjawabnya dan menghimpunkan latihan seluruh siri dalam pelan 90 hari.

Sumber

• Microsoft: Melaksanakan migrasi, Cloud Adoption Framework — mesyuarat kriteria undur, pembekuan perubahan, pengesahan data, pemantauan 24 hingga 48 jam dan pengekalan persekitaran sumber sebagai pilihan undur.
• Amazon: Transformasi aplikasi kerangka utama dalam AWS Transform — pelan ujian, skrip pengumpulan data ujian dan langkah Reforge.
• Amazon: pengumuman Thought Machine dan AWS tentang migrasi sistem perbankan warisan — empat peringkat dan kelulusan oleh pasukan kejuruteraan dan pasukan risiko.
• AWS Transform: halaman rasmi.