Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Praktik terbaik
Memilih untuk menghentikan aplikasi bisa menjadi keputusan yang rumit, terutama selama migrasi ke AWS Cloud. Bagian berikut memberikan praktik terbaik untuk digunakan dalam proses pengambilan keputusan Anda.
**Topics**
+ [Pertimbangkan pendekatan pabrik migrasi](best-practice-1.md)
+ [Identifikasi dan pensiunkan aplikasi di awal migrasi](best-practice-2.md)
+ [Berbasis data dan gunakan alat penemuan untuk menghindari gangguan](best-practice-3.md)
+ [Jadwalkan pemberhentian yang terkontrol](best-practice-4.md)
+ [Menilai kembali apakah aplikasi harus dimigrasikan](best-practice-5.md)
+ [Pensiun aplikasi](best-practice-6.md)
# Pertimbangkan pendekatan pabrik migrasi
Bagian penting dari setiap migrasi skala besar adalah mendirikan *pabrik migrasi* setelah beban kerja pilot awal dimigrasikan.
Pabrik migrasi terdiri dari tim, alat, dan proses yang bekerja sama untuk merampingkan migrasi secara sistematis, menggabungkan pelajaran dari gelombang migrasi sebelumnya. Pabrik migrasi menerapkan pola, yang mempercepat migrasi beban kerja dan meningkatkan hasil akhir.
Berdasarkan ukuran portofolio TI yang Anda butuhkan untuk pensiun, ada baiknya mempertimbangkan apakah ada nilai dalam menerapkan pendekatan pabrik migrasi. Metodologi dan prinsip yang diuraikan dalam panduan ini juga akan melengkapi pendekatan ini dan dapat disematkan ke dalam mekanismenya.
Biasanya, dua puluh hingga lima puluh persen dari portofolio aplikasi perusahaan terdiri dari pola berulang yang dapat dioptimalkan dengan menggunakan pendekatan pabrik migrasi. Untuk contoh pola, lihat [solusi AWS Cloud Migration Factory](https://aws.amazon.com//solutions/implementations/cloud-migration-factory-on-aws/), yang dapat diterapkan oleh tim migrasi untuk mengoordinasikan dan mengotomatiskan migrasi.
Tim harus mulai dengan aplikasi yang memiliki kekritisan bisnis terendah, sebelum secara bertahap bergerak menuju sistem yang lebih kritis. Pada saat tim mulai memigrasikan sistem bisnis yang kritis, mereka akan bermigrasi ratusan, jika tidak ribuan, beban kerja dan belajar banyak pelajaran.
Sebelum fase penilaian dimulai, Anda dapat membuat proses untuk menangkap satu bulan data ketergantungan untuk aplikasi yang diidentifikasi untuk pensiun. Sebuah tim diberi tahu dan diberi akses ke data ketika sudah siap. Tim kemudian memberikan data skor berdasarkan potensi aplikasi untuk menimbulkan dampak. Pemilik aplikasi kemudian dapat melakukan analisis koneksi yang lebih dalam sebelum langkah selanjutnya dimulai.
Untuk informasi selengkapnya tentang metodologi pabrik migrasi, lihat [Panduan untuk migrasi AWS besar](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/).
# Identifikasi dan pensiunkan aplikasi di awal migrasi
Mengidentifikasi dan kemudian menghentikan aplikasi di awal proses migrasi adalah penting dan harus dilakukan saat beban kerja sedang dimigrasikan.
Proyek migrasi sering memprioritaskan beban kerja yang bermigrasi, jadi biasanya sistem yang diidentifikasi akan pensiun (dan tidak dimigrasi) untuk menerima fokus menjelang akhir proyek. Namun, ada risiko bahwa meninggalkan aplikasi ini sampai akhir proyek akan menyisakan sedikit waktu untuk memasukkannya ke dalam migrasi jika aplikasi kemudian dianggap penting.
Pensiunan beban kerja lebih awal selama proyek migrasi mengurangi beban kerja tim yang memeliharanya. Misalnya, menghentikan server selama fase awal proyek migrasi berarti bahwa tim sistem operasi memiliki lebih sedikit server untuk menambal, meningkatkan, memelihara, atau mendukung. Tim-tim tersebut kemudian dapat fokus pada proyek migrasi itu sendiri.
Akhirnya, beberapa praktik terbaik panduan ini paling efektif ketika Anda mengikutinya untuk jangka waktu yang lebih lama. Jika Anda memulai proses pensiun lebih awal tetapi kemudian menentukan bahwa aplikasi benar-benar diperlukan oleh layanan lain, Anda akan dapat memodifikasi rencana migrasi Anda dan memasukkannya ke dalam gelombang migrasi masa depan.
# Berbasis data dan gunakan alat penemuan untuk menghindari gangguan
Menjadi data-driven sangat penting ketika mempertimbangkan pensiun aplikasi. Diagram arsitektur dan pengetahuan kelembagaan dapat dengan mudah menjadi usang atau tidak lengkap. Terkadang masalah yang tidak terduga juga dapat muncul, seperti aplikasi lain menjadi tergantung pada sistem Anda tanpa keterlibatan formal karena skenario break-fix.
Pendekatan berbasis data memberikan dasar di mana Anda dapat membuat keputusan atau memvalidasi suatu pendekatan. Saat menilai apakah aplikasi dapat dihentikan, Anda harus mengonfirmasi bahwa beban kerja yang Anda migrasi tidak bergantung padanya. Memigrasikan beban kerja tersebut dan kemudian menghentikan ketergantungan dapat menyebabkan degradasi layanan, atau lebih buruk lagi, gangguan layanan.
Untungnya, cukup mudah untuk memahami dependensi ini dengan menggunakan data untuk memantau koneksi masuk dan keluar jaringan pada server yang dijadwalkan untuk pensiun. Koneksi masuk jaringan, seperti aplikasi yang terhubung ke aplikasi Anda, dan koneksi keluar, seperti unggahan file ke berbagi Sistem File Jaringan (NFS), menunjukkan potensi ketergantungan hulu. Ketergantungan ini perlu diselidiki, karena jika beban kerja yang akan dimigrasikan ke AWS Cloud terhubung ke aplikasi, ada potensi gangguan layanan jika aplikasi dihentikan nanti. Proses ini mungkin memerlukan menyelam lebih dalam untuk mengikuti rantai ketergantungan. Mengikuti contoh sebelumnya, jika aplikasi mengunggah file ke berbagi NFS, langkah selanjutnya adalah menentukan sistem mana yang mengkonsumsi file itu dan status aplikasi itu.
Anda mungkin memutuskan untuk menyelidiki koneksi tersebut dan menilai tingkat dampaknya. Untuk melakukan ini, Anda dapat menggunakan alat penemuan untuk menunjukkan koneksi yang sedang dimulai ke server yang dijadwalkan untuk pensiun. Anda mungkin memperhatikan bahwa sebagian besar koneksi berasal dari server manajemen dan dapat diabaikan, karena mereka adalah alat yang mengumpulkan metrik kinerja atau instance proxy administrator sistem. Namun, jika ada aplikasi yang terhubung ke server yang dijadwalkan untuk migrasi, Anda harus menyelam lebih dalam dan memeriksa potensi dampak migrasi pada aplikasi tersebut.
[AWS Application Discovery Service](https://aws.amazon.com/application-discovery/)membantu pelanggan merencanakan proyek migrasi dengan mengumpulkan informasi tentang pusat data lokal yang mereka rencanakan untuk pensiun. Setelah Anda menyebarkan agen ke server Anda, Application Discovery Service mencatat aktivitas jaringan masuk dan keluar untuk setiap server, bersama dengan informasi lainnya. Dengan menggunakan [Amazon Athena](https://aws.amazon.com/athena/) untuk menganalisis data ini, Anda dapat mengidentifikasi apakah aplikasi lain bergantung pada server yang direncanakan untuk pensiun. [AWS Mitra Kompetensi Migrasi](https://aws.amazon.com//migration/partner-solutions/) juga dapat menyediakan alat penemuan dan perencanaan yang mendalam.
**catatan**
Application Discovery Service tidak lagi terbuka untuk pelanggan baru. Atau, gunakan AWS Transform yang menyediakan kemampuan serupa. Untuk informasi selengkapnya, lihat [perubahan AWS Application Discovery Service ketersediaan](https://docs.aws.amazon.com/application-discovery/latest/userguide/application-discovery-service-availability-change.html).
Misalnya, ilustrasi layar berikut menunjukkan empat alamat IP sumber yang menghubungkan ke server pada port 22 (tujuan = 172.31.1.117).
![\[Contoh menganalisis koneksi.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/migration-retiring-applications/images/best-practices-4.png)
Ini adalah host bastion yang digunakan oleh administrator sistem dan dapat diabaikan. Gambar juga menunjukkan dua server yang terhubung ke aplikasi ini pada port 80, yang berada dalam lingkup migrasi yang direncanakan. Pada tahap ini, Anda perlu menyelam lebih dalam dan memahami aplikasi penghubung. Analisis yang lebih dalam ini akan memungkinkan Anda untuk menilai apakah akan ada dampak hulu setelah pensiun.
# Jadwalkan pemberhentian yang terkontrol
Dalam rencana migrasi Anda, pastikan untuk menjadwalkan waktu untuk penghentian terkontrol selama proses migrasi. Penghentian terkontrol menghentikan proses migrasi untuk mengidentifikasi potensi gangguan jika aplikasi dihentikan. Ini mensimulasikan pensiun aplikasi, dan memungkinkan Anda untuk mengamati konsekuensinya. Ketika periode berhenti terkontrol selesai, migrasi dapat dengan mudah dilanjutkan.
Pendekatan stop terkontrol bervariasi tergantung pada jenis aplikasi dan proses terkait yang Anda kerjakan. Pola berhenti terkontrol yang umum meliputi:
+ Menerapkan firewall berbasis host untuk memblokir semua lalu lintas, yang mensimulasikan pensiun
+ Menjeda mesin virtual
+ Menghentikan layanan di host
+ Memblokir semua lalu lintas dengan menggunakan firewall eksternal
Proyek migrasi dan pemilik aplikasi perlu menentukan durasi penghentian terkontrol, tergantung pada jenis aplikasi. Misalnya, jika Anda mempensiunkan beban kerja berbasis batch yang hanya berjalan sebulan sekali atau seperempat sekali, melakukan penghentian terkontrol satu minggu mungkin tidak cukup untuk menentukan dampaknya pada sistem lain.
Melanjutkan contoh dari bagian sebelumnya, aplikasi lain terhubung ke server yang dijadwalkan untuk pensiun. Penilaian awal menyimpulkan bahwa seharusnya tidak ada dampak pada server hulu. Pemberhentian terkontrol sekarang dapat dilakukan untuk memahami dampaknya.
Pemberhentian terkontrol ini akan dilakukan dengan menerapkan firewall berbasis host untuk memblokir semua lalu lintas, mensimulasikan efek mematikan server. Jika hal ini menyebabkan masalah layanan untuk aplikasi yang dijadwalkan untuk dimigrasi ke AWS Cloud, aturan firewall ditambahkan dan semua lalu lintas dilanjutkan. Setelah penghentian terkontrol, pensiun server dipertimbangkan kembali karena degradasi atau gangguan layanan ini.
# Menilai kembali apakah aplikasi harus dimigrasikan
Dua praktik terbaik terakhir yang kami diskusikan membantu menentukan apakah tepat untuk melanjutkan tindakan pada sistem yang dijadwalkan untuk pensiun. Jika praktik terbaik tersebut menyoroti potensi dampak bisnis hulu, Anda harus mempertimbangkan untuk menilai kembali pola migrasi aplikasi. Dengan memulai proses pensiun aplikasi lebih awal, Anda sekarang memiliki cukup waktu untuk memasukkan aplikasi dalam gelombang migrasi berikutnya jika Anda mengalami masalah atau ketergantungan yang berarti tidak dapat dihentikan.
Jika, setelah mengikuti praktik terbaik tersebut, Anda tidak sepenuhnya percaya diri dalam menghentikan aplikasi, pertimbangkan apakah aplikasi tersebut harus di-host ulang ke Cloud. AWS Ini sangat penting jika migrasi Anda memiliki tanggal akhir yang ditetapkan, seperti kedaluwarsa sewa pusat data.
Layanan seperti [Layanan Migrasi AWS Aplikasi](https://aws.amazon.com/application-migration-service/) menyederhanakan pendekatan migrasi rehost. Saat memigrasikan aplikasi ke AWS, Anda dapat mengambil snapshot harian volume Amazon Elastic Block Store (Amazon EBS) Elastic Block Store (Amazon EBS) dan menghentikan instans Amazon Elastic Compute Cloud (Amazon EC2) untuk mengurangi biaya dan menguji pensiun aplikasi dalam jangka waktu yang lama. Jika dampak atau masalah muncul, Anda kemudian memiliki keyakinan untuk dapat membuat volume EBS berdasarkan snapshot untuk melanjutkan instans EC2.
**penting**
Uji proses pemulihan ini sebelum Anda menghentikan instans EC2.
# Pensiun aplikasi
Setelah mengikuti lima praktik terbaik panduan ini sebelumnya, Anda mungkin telah memutuskan bahwa aman untuk menghentikan aplikasi. Anda menerapkan pendekatan pabrik migrasi, memulai proses pensiun lebih awal, menggunakan data dan alat penemuan untuk memantau koneksi masuk, melakukan penghentian terkontrol yang berhasil, dan menilai apakah aplikasi harus dihentikan. Pensiun aplikasi sekarang dimungkinkan sebagai bagian dari strategi migrasi Anda.
Pada titik ini, Anda harus memeriksa apakah aplikasi berisi data yang mungkin berguna di masa depan. Pembelajaran mesin (ML) dan analitik telah memberikan nilai data yang lebih besar dari sebelumnya. Meskipun Anda mungkin tidak mengembangkan algoritma ML sekarang, data historis dapat terbukti bermanfaat di masa depan. Anda mungkin juga memiliki persyaratan peraturan atau kepatuhan untuk menyimpan data untuk jangka waktu tertentu, bahkan jika aplikasi telah dihentikan.
AWS menawarkan serangkaian layanan penyimpanan cloud yang komprehensif untuk retensi jangka panjang, kepatuhan, dan pelestarian digital. AWS Solusi penyimpanan untuk pengarsipan data membantu memberikan skala tak terbatas, daya tahan 99,999999999%, keandalan data, dan keamanan data.
Untuk membantu upaya kepatuhan Anda, AWS secara teratur mencapai validasi pihak ketiga untuk ribuan persyaratan kepatuhan global. Ini terus dipantau untuk membantu Anda memenuhi standar keamanan dan kepatuhan untuk keuangan, ritel, perawatan kesehatan, pemerintah, dan seterusnya.
Untuk informasi selengkapnya tentang pengarsipan data dengan AWS, lihat [Pengarsipan Data](https://aws.amazon.com//archive/) di situs web. AWS