

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

# Runbook cutover
<a name="create-cutover-runbook"></a>

Seperti disebutkan sebelumnya, migrasi bisa rumit, dengan banyak bagian bergerak yang menjangkau perangkat keras, perangkat lunak, orang, proses, dan organisasi. Untuk memastikan keberhasilan, konsistensi, dan percepatan akhirnya, rencana yang ditata dengan baik yang didokumentasikan dan disepakati oleh semua pemangku kepentingan sangat penting di semua tahap migrasi. Rencana semacam itu dapat didokumentasikan dengan menggunakan runbook cutover.

Runbook cutover mencakup semua aktivitas yang harus diselesaikan untuk migrasi tertentu. Ini adalah panduan yang komprehensif dan terperinci dari hal-hal berikut:
+ Aktivitas
+ Garis waktu yang direncanakan
+ Stempel waktu aktivitas aktual
+ Kriteria keberhasilan untuk setiap langkah
+ Kepemilikan untuk setiap langkah

Saat menyiapkan runbook cutover, tanyakan pada diri Anda pertanyaan-pertanyaan berikut dan berikan jawaban dalam rencana Anda.


| Pertanyaan | Mengapa itu penting | 
| --- | --- | 
|  Apakah cutover membutuhkan downtime?  |  Waktu henti yang diperpanjang akan memengaruhi pengalaman pengguna Anda. Saat menyiapkan paket cutover Anda, cobalah untuk meminimalkan waktu henti aplikasi atau sistem Anda.  | 
|  Apakah Anda perlu menyinkronkan data sebelum cutover?  |  Jika Anda memigrasikan lapisan penyimpanan, seperti volume Amazon Elastic Block Store (Amazon EBS) atau Amazon Simple Storage Service (Amazon S3) bucket sebelum cutover tanpa menggunakan mekanisme replikasi berkelanjutan, lapisan penyimpanan mungkin tidak sinkron. Dalam kasus seperti itu, pastikan untuk melakukan sinkronisasi akhir setelah Anda mematikan layanan sumber tetapi sebelum Anda memulai cutover.  | 
|  Siapa yang harus mengetahui pemotongan yang direncanakan?  |  Beri tahu semua pemangku kepentingan dan pengguna tentang waktu henti yang direncanakan.  | 
|  Apakah Anda ingin membagi migrasi menjadi bagian-bagian yang lebih kecil atau memigrasikan semuanya sekaligus?  |  Jika Anda memigrasikan sistem yang rumit, masuk akal untuk membagi migrasi menjadi beberapa fase dan melakukan beberapa pemotongan. Misalnya, Anda dapat memigrasikan lapisan data terlebih dahulu.  | 
|  Apakah Anda memerlukan dukungan vendor eksternal?  |  Anda mungkin perlu menghubungi vendor eksternal beberapa minggu sebelum pemotongan yang direncanakan untuk memastikan ketersediaannya. Periksa dengan vendor tentang pertimbangan lisensi apa pun yang harus diperhatikan.  | 
|  Apakah Anda memerlukan persetujuan khusus untuk setiap bagian dari proses?  |  Dapatkan persetujuan yang diperlukan beberapa minggu sebelum pemotongan yang direncanakan.  | 

# Templat runbook cutover
<a name="cutover-runbook-template"></a>

Runbook cutover harus mencakup semua aktivitas yang akan dilakukan selama cutover. Namun, sama pentingnya untuk menyiapkan templat atau daftar periksa pra-migrasi. Template harus menyertakan aktivitas yang harus diselesaikan sebelum migrasi.

Kedua templat (yang dapat digabungkan menjadi satu dokumen) harus memberikan jawaban untuk pertanyaan-pertanyaan berikut:
+ Kegiatan apa yang harus dilakukan?
+ Siapa yang akan melakukan kegiatan?
+ Kapan kegiatan harus dilakukan?

Bagian ini mencakup contoh daftar periksa pra-migrasi, template runbook cutover, dan rencana rollback. Tugas IDs membantu membuat komunikasi lebih cepat dan lebih efektif.

## Daftar periksa pra-migrasi
<a name="pre-migration"></a>


| ID Tugas | Tugas | Dependensi | Tim | Pemilik | Tanggal penyelesaian | Status | Catatan | 
| --- | --- | --- | --- | --- | --- | --- | --- | 
|  P1  |  Dokumen arsitektur target disetujui.  |     |     |     |     |     |     | 
|  P2  |  Akun target untuk aplikasi ada.  |     |     |     |     |     |     | 
|  P3  |  Virtual private cloud (VPC) dan subnet untuk aplikasi ada.  |     |     |     |     |     |     | 
|  P4  |  Tim migrasi memiliki akses ke akun aplikasi target dan memiliki izin yang diperlukan AWS Identity and Access Management (IAM).  |     |     |     |     |     |     | 
|  P5  |  Tim aplikasi memiliki akses yang diperlukan ke akun aplikasi target dan sumber dayanya.  |     |     |     |     |     |     | 
|  P6  |  Permintaan Perubahan diajukan dan disetujui.  |     |     |     |     |     |     | 
|  P7  |  Konektivitas antara sumber dan lingkungan target ditetapkan dan diuji.  |     |     |     |     |     |     | 
|  P8  |  Daftar kontak tim aplikasi didokumentasikan.  |     |     |     |     |     |     | 
|  P9  |  Rencana pemotongan ditinjau dengan pemangku kepentingan utama.  |     |     |     |     |     |     | 
|  P10  |  Kegiatan pencadangan pra-migrasi selesai.  |     |     |     |     |     |     | 
|  P11  |  Konfirmasikan apakah kontak dukungan tambahan harus diberlakukan.  |     |     |     |     |     |     | 
|  P12  |  Konfirmasikan sumber daya untuk setiap aplikasi: Siapa yang akan memulai dan mematikan setiap aplikasi individu.  |     |     |     |     |     |     | 
|  P13  |  Rencana pemotongan akhir dikeluarkan untuk semua tim yang berkontribusi.  |     |     |     |     |     |     | 
|  P14  |  Komunikasi awal cutover yang dikeluarkan untuk pemangku kepentingan utama.  |     |     |     |     |     |     | 
|  P15  |  Pertemuan retrospektif pasca-cutover dijadwalkan.  |     |     |     |     |     |     | 

Sama pentingnya untuk mendokumentasikan item sebelumnya dalam log masalah agar tetap di jalurnya atau, jika ada yang tidak beres, membawanya kembali ke jalurnya.

## Runbook cutover
<a name="cutover-runbook-example"></a>


| ID Tugas | Tugas | Dependensi | Tim | Pemilik | Tanggal mulai/waktu yang direncanakan | Tanggal berakhir/waktu yang direncanakan | Tanggal/waktu mulai aktual | Waktu tanggal akhir aktual | Status | Catatan | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
|  C1  |  Kirim catatan informasi ke semua pemangku kepentingan yang menginformasikan bahwa aplikasi akan turun seperti yang ditentukan dalam CR.  |     |     |     |     |     |     |     |     |     | 
|  C2  |  Konfirmasikan cadangan server sumber dan database.  |     |     |     |     |     |     |     |     |     | 
|  C3  |  Hentikan aplikasi dan layanan DB di server sumber.  |     |     |     |     |     |     |     |     |     | 
|  C4  |  Matikan server sumber.  |     |     |     |     |     |     |     |     |     | 
|     |  **Tonggak sejarah 1** **Kegiatan pra-pemotongan selesai**  |     |     |     |     |     |     |     |     |     | 
|  C5  |  Lakukan migrasi berdasarkan pendekatan migrasi Anda (seperti AWS Application Migration Service untuk lift-and-shift).  |     |     |     |     |     |     |     |     |     | 
|  C6  |  Verifikasi infrastruktur (server target aktif dan berjalan).  |     |     |     |     |     |     |     |     |     | 
|     |  **Miilestone 2** **Migrasi selesai**  |     |     |     |     |     |     |     |     |     | 
|  C7  |  Perbarui server DNS untuk menunjuk ke titik akhir yang baru dibuat.  |     |     |     |     |     |     |     |     |     | 
|  C8  |  Verifikasi perubahan DNS.  |     |     |     |     |     |     |     |     |     | 
|     |  **Miilestone 3** **Kegiatan pasca migrasi — Infrastruktur selesai**  |     |     |     |     |     |     |     |     |     | 
|  C9  |  Mulai aplikasi dan layanan DB di server target.  |     |     |     |     |     |     |     |     |     | 
|  C10  |  Terapkan perubahan konfigurasi khusus aplikasi (misalnya, arahkan ke alamat IP baru).  |     |     |     |     |     |     |     |     |     | 
|     |  **Tonggak sejarah 3** **Kegiatan pasca-migrasi — Aplikasi selesai**  |     |     |     |     |     |     |     |     |     | 
|  C11  |  Lakukan pengujian aplikasi pasca-migrasi — Verifikasi teknis.  |     |     |     |     |     |     |     |     |     | 
|  C12  | Lakukan pengujian aplikasi pasca-migrasi — Verifikasi bisnis |     |     |     |     |     |     |     |     |     | 
|  C13  |  Komunikasikan kepada semua pemangku kepentingan utama bahwa migrasi telah selesai.  |     |     |     |     |     |     |     |     |     | 
|     |  **Tonggak sejarah 4** **Pengujian pasca-migrasi selesai**  |     |     |     |     |     |     |     |     |     | 

## Rencana rollback
<a name="rollback"></a>


| ID Tugas | Tugas | Dependensi | Tim | Pemilik | Status | Catatan | 
| --- | --- | --- | --- | --- | --- | --- | 
|  R1  |  Hentikan aplikasi dan layanan DB pada server target.  |   |   |   |   |   | 
|  R2  |  Matikan server target.  |   |   |   |   |   | 
|  R3  |  Kembalikan pembaruan pada server DNS (untuk menunjuk kembali ke server sumber).  |   |   |   |   |   | 
|  R4  |  Verifikasi perubahan DNS.  |   |   |   |   |   | 
|  R5  |  Mulai server sumber.  |   |   |   |   |   | 
|  R6  |  Sinkronisasi data kembali ke server sumber (jika diperlukan).  |   |   |   |   |   | 
|  R7  |  Mulai aplikasi dan layanan DB di server sumber.  |   |   |   |   |   | 
|  R8  |  Lakukan pengujian aplikasi — Verifikasi teknis.  |   |   |   |   |   | 
|  R9  |  Lakukan pengujian aplikasi pasca-migrasi — Verifikasi bisnis.  |   |   |   |   |   | 
|  R10  |  Komunikasikan kepada semua pemangku kepentingan utama bahwa migrasi telah dibatalkan.  |   |   |   |   |   | 

## Contoh template untuk strategi rehost
<a name="example"></a>

Salah satu strategi migrasi tipe R yang paling umum digunakan di lapangan adalah strategi rehost, dengan Layanan Migrasi Aplikasi sebagai alat migrasi pilihan. Anda dapat menggunakan [template sampel](samples/cutover-runbook_template.zip) sebagai dokumen dasar dalam skenario rehost. Template menggabungkan aktivitas penting yang ditemui selama keterlibatan pelanggan yang sebenarnya. Ini juga mencakup ruang bagi tim aplikasi untuk menambahkan tugas dan aktivitas mereka. Langkah-langkah di bagian sebelumnya dapat memberikan panduan awal untuk membuat runbook cutover khusus Anda sendiri sesuai kebutuhan.