View a markdown version of this page

Perencanaan gelombang - AWS Panduan Preskriptif
Membuat rencana gelombangMengelola perubahan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perencanaan gelombang

Intinya, rencana gelombang adalah jadwal migrasi, dan mirip dengan kegiatan perencanaan proyek lainnya. Kami menyarankan Anda menggunakan gelombang migrasi sebagai sarana untuk membuat grup yang dapat dikelola, mengurangi risiko, dan mengatur aktivitas di sekitar grup tersebut.

Untuk membuat rencana gelombang migrasi yang efektif dan percaya diri tinggi, Anda harus mendapatkan tampilan lengkap dari portofolio aplikasi, infrastruktur terkait (komputasi, penyimpanan, jaringan), pemetaan ketergantungan, dan strategi migrasi.

Selain aplikasi bisnis, yang merupakan bentuk pengelompokan kumpulan komponen perangkat lunak dan infrastruktur, Anda dapat menggunakan level grup lainnya. Gelombang adalah level grup tertinggi. Dalam gelombang, Anda dapat membuat grup ketergantungan. Jenis sub-grup ini dapat berisi lebih dari satu aplikasi. Misalnya, dua atau lebih aplikasi yang perlu dimigrasikan pada saat yang sama karena ketergantungan teknis, seperti latensi rendah, atau faktor lainnya. Kemudian kelompok ketergantungan itu dikelola secara keseluruhan. Beberapa kelompok ketergantungan dapat ditugaskan ke gelombang. Selanjutnya, Anda dapat menetapkan tanggal migrasi ke seluruh gelombang atau ke grup ketergantungan individu dalam gelombang. Tanggal migrasi adalah tanggal dan waktu ketika grup tersebut akan dihentikan di lokasi saat ini dan dibuat aktif AWS.

Gelombang migrasi memiliki banyak aktivitas. Kami menyarankan Anda mengatur gelombang secara bertahap dan menetapkan durasi yang diharapkan untuk setiap fase. Fase di bawah ini berfungsi sebagai contoh:

  • Desain: Dalam fase gelombang ini, desain target untuk setiap aplikasi dalam gelombang dikonfirmasi dan disetujui.

  • Perencanaan cutover: Fase gelombang ini mencakup pembuatan atau iterasi runbook cutover dan perencanaan semua langkah yang diperlukan untuk mengalihkan aplikasi ke AWS (termasuk skenario rollback).

  • Pre-migration: Fase ini mencakup aktivitas penyebaran landing zone, seperti penyediaan akun, konfigurasi, pengujian premi, penyiapan perkakas migrasi, dan replikasi data.

  • Cutover: Fase ini adalah saat migrasi sebenarnya terjadi. Selama waktu ini, aplikasi dihentikan di lokasi saat ini, data disinkronkan untuk terakhir kalinya, pengujian bisnis dilakukan, dan migrasi diselesaikan. Fase ini termasuk serah terima operasional.

  • Hypercare atau Post-migration: Fase ini adalah periode waktu di mana tim migrasi tersedia untuk mendukung operasi jika terjadi masalah. Selain itu, optimasi dapat diterapkan sesuai kebutuhan.

  • Penutupan gelombang: Pada fase ini, Anda meninjau metrik dan pelajaran yang dipetik dan menutup gelombang secara formal.

Tidak ada durasi yang telah ditentukan untuk gelombang migrasi, dan itu akan tergantung pada tingkat upaya dan kompleksitas. Kami merekomendasikan untuk menjaga gelombang migrasi dalam waktu 6 hingga 10 minggu. Kasus di mana lebih banyak waktu diperlukan, misalnya, ketika benar-benar menulis ulang komponen aplikasi, biasanya lebih baik ditangani di luar gelombang migrasi.

Untuk mengukur keberhasilan dan melacak kemajuan, gelombang harus diselaraskan dengan hasil dan pendorong bisnis. Ini juga akan mempengaruhi durasi gelombang dan kelompok ketergantungan yang terkandung dalam gelombang. Penyelesaian gelombang harus mencerminkan pencapaian yang terukur.

Ada beberapa cara untuk mengatur gelombang migrasi. Tabel berikut menjelaskan opsi organisasi gelombang yang paling umum. Ini biasanya digabungkan.

Jenis organisasi gelombang

Deskripsi

Pro

Kontra

Dengan strategi migrasi atau tumpukan teknologi

Tetapkan aplikasi dengan strategi atau pola migrasi umum ke gelombang. Misalnya, gelombang yang hanya berisi aplikasi rehost.

Tim khusus per pola atau tumpukan dapat diberikan seluruh gelombang.

Durasi aktivitas yang homogen.

Membutuhkan lebih banyak analisis dependensi, terutama untuk aplikasi yang mengikuti pola yang berbeda.

Berdasarkan domain bisnis

Buat gelombang per domain bisnis. Misalnya, gelombang manajemen pesanan atau gelombang pembayaran.

Data bersama biasanya dalam domain tertentu.

Keterlibatan tim yang konsisten.

Peningkatan risiko karena seluruh domain bisnis terpengaruh.

Dengan kemampuan teknis

Kelompokkan aplikasi yang menggunakan satu atau lebih kemampuan. Misalnya, gelombang komputasi saja atau gelombang penyeimbang beban komputasi+.

Migrasi dimulai lebih cepat karena kemampuan teknis diaktifkan dari waktu ke waktu. Menghapus ketergantungan untuk landing zone yang beroperasi penuh.

Menciptakan kantong kompleksitas di gelombang selanjutnya.

Berdasarkan lingkungan

Gelombang berisi lingkungan tertentu untuk satu set aplikasi. Misalnya, gelombang pengembangan atau gelombang produksi.

Non-production Gelombang mendapat manfaat dari fleksibilitas selama eksekusi.

Mengurangi risiko migrasi produksi.

Membutuhkan fokus pada analisis ketergantungan untuk menghindari dependensi yang hilang yang tidak ada di lingkungan non-produksi.

Berdasarkan prioritas bisnis

Membuat grup murni berdasarkan kriteria prioritas yang diberikan.

Mengatasi hasil bisnis.

Biasanya banyak tim yang terlibat; sulit untuk dikoordinasikan.

Bagian tentang menetapkan garis dasar untuk portofolio aplikasi menjelaskan empat kategori dependensi teknis. Dependensi ini berkontribusi pada penciptaan gelombang migrasi dan definisi kelompok ketergantungan. Kelompok ketergantungan akan ditentukan oleh kekritisan ketergantungan. Selain itu, dependensi nonteknis harus dipertimbangkan. Misalnya, jadwal rilis aplikasi, jendela pemeliharaan, dan tanggal bisnis utama (seperti pemrosesan akhir bulan atau akhir kuartal) dapat memengaruhi rencana gelombang.

Tentukan apakah ketergantungannya lunak atau keras. Ketergantungan lunak adalah hubungan antara dua atau lebih aset, atau dari aset ke kendala, yang tidak tergantung pada lokasi komponen. Misalnya, dua sistem yang beroperasi di jaringan lokal yang sama (atau infrastruktur yang sama) dapat dipisahkan dengan memindahkan salah satu sistem tersebut ke cloud sementara yang lain tetap di tempat. Ketergantungan keras adalah hubungan antara dua atau lebih aset, atau dari aset ke kendala, yang bergantung pada lokasi. Misalnya, dua sistem yang beroperasi di jaringan lokal yang sama, dan yang sangat bergantung pada latensi rendah untuk komunikasi antara server aplikasi dan server database, memiliki ketergantungan keras. Memindahkan hanya satu dari sistem ini ke cloud akan menyebabkan masalah fungsionalitas atau kinerja yang tidak dapat diselesaikan. Demikian juga, alasan nonteknis, seperti ketersediaan sumber daya (seperti tim yang melakukan migrasi) atau kendala operasional (seperti jendela pemeliharaan di mana dua sistem hanya dapat dimigrasikan dalam jendela waktu tertentu), dapat membuat ketergantungan keras untuk aset ini.

Untuk membuat rencana gelombang migrasi, tentukan grup dependensi Anda dengan menganalisis dependensi, idealnya dari sumber data yang sangat tepercaya seperti alat penemuan khusus. Gabungkan informasi ini dengan kriteria prioritas aplikasi Anda dan keadaan operasional.

Menentukan dependensi teknis itu menantang. Beberapa titik data diperlukan, dan tidak ada sumber data yang berisi semuanya. Misalnya, meskipun Anda dapat memperoleh informasi komunikasi proses-ke-proses dari alat penemuan, sulit untuk mengklasifikasikannya menjadi dependensi lunak dan keras. Toleransi latensi juga sulit ditentukan dari data jaringan saja.

Teknik-teknik berikut dapat membantu Anda menangani ambiguitas dalam menentukan dependensi nyata:

  • Kumpulkan semua data seperti yang dijelaskan di bagian persyaratan data dan titik data lainnya yang Anda pertimbangkan sesuai kebutuhan.

  • Filter informasi ketergantungan (atau data komunikasi) dan kecualikan layanan bersama, seperti Active Directory, cadangan, dan pemantauan lalu lintas. Layanan bersama teknis cenderung merekatkan seluruh ruang lingkup.

  • Klasifikasi semua informasi. Jika tersedia, gunakan frekuensi jaringan dan volume transfer data antar komponen.

  • Bertemu dengan pemilik aplikasi, arsitek, dan tim pendukung. Diskusikan jenis koneksi. Apakah mereka sinkron atau asinkron? Apakah mereka menyadari persyaratan latensi minimum? Apa koneksi kritis, dan apa yang terjadi jika tidak tersedia? Apakah Anda kehilangan koneksi penting? Pertimbangkan bahwa proses batch mungkin terjadi secara sporadis dan hilang dalam kumpulan data.

  • Jika alat penemuan Anda menyediakan grafik data, cari aplikasi tunggal yang menjembatani kelompok besar aplikasi. Titik koneksi tunggal ini dapat membantu memecah data menjadi kelompok-kelompok yang lebih kecil.

AWS Transform dapat membantu Anda menganalisis dependensi dan melakukan perencanaan gelombang.

Membuat rencana gelombang

Prasyarat untuk memigrasikan gelombang aplikasi adalah data portofolio aplikasi dan penilaian aplikasi terperinci dari kelompok aplikasi yang akan dimigrasikan dalam gelombang. Penilaian terperinci harus mencakup daftar aplikasi dalam gelombang, detail infrastruktur terkait, desain target, dan strategi migrasi untuk setiap aplikasi. 

Menetapkan kepemilikan dan tata kelola gelombang adalah kunci untuk mengelola dan melacak pekerjaan gelombang, ketergantungan program, manajemen perubahan, masalah, dan risiko. Pastikan bahwa kerangka kerja tata kelola ada untuk mengelola rencana.

Untuk menguraikan rencana gelombang, mulailah dengan konstruksi gelombang default. Apa yang terjadi dalam gelombang? Setelah input awal ditentukan, gelombang dapat dimulai. Biasanya, kegiatannya adalah: 

  1. Perbaiki rencana cutover. Kegiatan ini harus menguraikan runbook dan langkah-langkah yang harus diambil pada saat migrasi, termasuk koordinasi dengan tim internal dan eksternal lainnya.

  2. Perbaiki rencana rollback. Apa yang harus dilakukan untuk memutar kembali aplikasi jika ada yang salah?

  3. Siapkan infrastruktur target. Misalnya, Anda dapat membuat atau memperluas AWS landing zone (Akun AWS, keamanan, jaringan, layanan infrastruktur, infrastruktur pendukung lainnya).

  4. Uji infrastruktur target.

  5. Mengoperasikan perkakas migrasi. Misalnya, instal agen replikasi dan mulai transfer data.

  6. Lakukan rencana cutover dan runbook dry run. Kelompokkan semua anggota tim yang berpartisipasi, dan tinjau semua langkah sebelumnya.

  7. Memantau replikasi data dan penyebaran infrastruktur.

  8. Konfirmasikan kesiapan untuk pengoperasian infrastruktur dan aplikasi di AWS.

  9. Konfirmasikan kesiapan keamanan.

  10. Konfirmasikan kepatuhan dan persyaratan peraturan (misalnya, validasi beban kerja sebelum migrasi dan pasca-migrasi) jika berlaku.

  11. Migrasikan aplikasi ke AWS dan lakukan pengujian pra go-live.

  12. Berikan dukungan pasca-migrasi untuk jangka waktu tertentu, seperti 3 hari, saat tim operasi dan tim migrasi sepenuhnya tersedia untuk menyelesaikan masalah, dan menerapkan pengoptimalan.

  13. Lakukan tinjauan pasca-migrasi. Dokumentasikan pelajaran yang dipetik, dan gabungkan ke dalam gelombang masa depan.

  14. Lakukan penutupan gelombang dengan mengonfirmasi serah terima operasional dan perolehan metrik untuk pelaporan.

Berapa lama masing-masing kegiatan ini akan ditentukan oleh kompleksitas ruang lingkup, kapasitas gelombang, orang-orang yang terlibat, dan keadaan unik Anda. Jika memungkinkan, gelombang yang lebih kecil lebih disukai karena itu akan mengurangi dampak penundaan atau penghambat migrasi. Tentukan, dengan tim Anda, berapa durasi default gelombang.

Selanjutnya, lanjutkan untuk menganalisis tanggal untuk membuat struktur gelombang kosong tingkat tinggi awal (tanpa aplikasi yang ditetapkan). Pertimbangkan pertanyaan-pertanyaan berikut:

  • Berapa total panjang program migrasi? 

  • Apa tenggat waktu?

  • Apakah ada tanggal keluar pusat data tetap? 

  • Apakah ada tanggal akhir kontrak kolokasi? 

  • Apa siklus penyegaran aplikasi dan infrastruktur? 

  • Apa siklus pemeliharaan dan rilis aplikasi? 

  • Apakah ada tanggal ketika migrasi harus dihindari (misalnya, siklus rilis dan pemeliharaan, akhir tahun, hari libur, pemrosesan akhir bulan)?

Dengan pertimbangan ini, plot gelombang ke dalam rencana. Untuk mempercepat proses migrasi, kami merekomendasikan gelombang yang tumpang tindih jika memungkinkan. Kunci untuk gelombang yang tumpang tindih adalah mendefinisikan dan mempertimbangkan apa yang terjadi dalam gelombang. Biasanya, aktivitas penyebaran, validasi infrastruktur target, dan sinkronisasi data akan terjadi selama paruh pertama gelombang. Babak kedua akan fokus pada migrasi aktual, pengujian, dan serah terima operasional. Ini berarti bahwa tim yang berbeda terlibat dalam setiap setengah proses, dan Anda dapat memperoleh beberapa efisiensi. Misalnya, segera setelah tim yang terlibat dalam persiapan infrastruktur target menyelesaikan pekerjaan mereka, mereka dapat mulai mengerjakan persyaratan gelombang berikutnya. Secara umum, lebih disukai bahwa sebagian besar gelombang memiliki panjang dan struktur yang sama untuk memfasilitasi pendekatan migrasi seperti pabrik. Namun, selama proses perencanaan gelombang, ukuran gelombang tertentu dapat diperpanjang untuk memenuhi dependensi atau persyaratan operasional. 

Selanjutnya, berdasarkan kelompok ketergantungan yang telah diidentifikasi, tentukan ukuran maksimum gelombang dalam hal jumlah kelompok ketergantungan yang dapat dikandungnya. Ukuran gelombang biasanya ditentukan oleh selera risiko (misalnya, berapa banyak perubahan paralel yang dapat ditoleransi), dan ketersediaan sumber daya (misalnya, berapa banyak perubahan paralel yang dapat dilakukan dengan sumber daya, keterampilan, dan anggaran yang tersedia). Namun, selama perencanaan awal, jangan dibatasi oleh persyaratan dan ketersediaan sumber daya. Gelombang yang mengandung lebih dari satu kelompok ketergantungan dapat didekomposisi menjadi gelombang yang lebih kecil dalam iterasi future.

Setelah kelompok dependensi untuk gelombang tertentu telah dikonfirmasi, tinjau persyaratan sumber daya untuk memigrasikan gelombang. Pertimbangkan untuk menyesuaikan ukuran gelombang (jumlah kelompok ketergantungan yang dikandungnya) berdasarkan kebutuhan sumber daya. Hal ini dapat menyebabkan gelombang yang lebih kecil atau lebih besar. Ulangi rencana gelombang sesuai kebutuhan sampai semua gelombang telah ditentukan. Pertimbangkan untuk bekerja dengan Layanan AWS Profesional atau Mitra Kompetensi AWS Migrasi, yang dapat menyediakan spesialis untuk membantu Anda selama proses berlangsung.

Mengelola perubahan

Portofolio aplikasi dan infrastruktur terkait akan berubah selama siklus hidup program migrasi. Long-running Program migrasi hidup berdampingan dengan evolusi dan perubahan bisnis normal. Aplikasi terus berkembang saat menunggu untuk dimigrasi. Server ditambahkan atau dihapus, infrastruktur baru digunakan di tempat. Diharapkan bahwa ruang lingkup gelombang atau kelompok ketergantungan akan membutuhkan perubahan. Perubahan diperlukan terutama ketika, lebih dekat ke tanggal migrasi, ketergantungan yang sebelumnya tidak diketahui diidentifikasi, atau server baru disertakan dalam inventaris. Terkadang ini bisa terjadi selama migrasi itu sendiri.

Perubahan lingkup mempengaruhi kelompok ketergantungan dan gelombang. Untuk menangani perubahan dan meminimalkan dampak, penting untuk menetapkan mekanisme kontrol ruang lingkup. Mekanisme kontrol perubahan ruang lingkup membutuhkan definisi satu sumber kebenaran untuk ruang lingkup. Ini bisa menjadi alat untuk mengelola ruang lingkup, atau file.csv, spreadsheet, atau database, seperti yang didefinisikan oleh tata kelola program migrasi. Anda harus mengidentifikasi perubahan, menganalisis dampak, dan mengkomunikasikan perubahan kepada pemangku kepentingan yang relevan sehingga mereka dapat mengambil tindakan. Rencana gelombang akan diulang sebagai hasilnya.