Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Penilaian aplikasi terperinci
Tujuan dari penilaian aplikasi terperinci adalah pemahaman lengkap tentang aplikasi yang ditargetkan dan infrastruktur terkait (komputasi, penyimpanan, dan jaringan). Data kesetiaan tinggi diperlukan untuk menghindari jebakan. Misalnya, adalah umum bagi organisasi untuk berasumsi bahwa mereka sepenuhnya memahami aplikasi. Ini wajar, dan itu benar dalam banyak kasus. Namun, untuk meminimalkan risiko terhadap bisnis, penting untuk memvalidasi pengetahuan kelembagaan dan dokumentasi statis dengan memperoleh data terprogram sebanyak mungkin. Ini akan menangani proses penemuan yang berat. Anda dapat fokus pada elemen data yang berasal dari sumber alternatif, seperti informasi spesifik bisnis, peta jalan strategis, dan lain-lain.
Kuncinya adalah menghindari perubahan menit terakhir selama dan setelah migrasi. Misalnya, saat bermigrasi, penting untuk menghindari perubahan berdasarkan dependensi tak dikenal yang mungkin memerlukan penyertaan server ke dalam gelombang migrasi yang sedang berlangsung. Tak lama setelah migrasi, penting untuk menghindari perubahan berdasarkan persyaratan platform terkait untuk mengizinkan lalu lintas atau menyebarkan layanan tambahan. Perubahan yang tidak direncanakan ini meningkatkan risiko masalah keamanan dan operasional. Kami sangat merekomendasikan penggunaan alat penemuan terprogram untuk memvalidasi pola lalu lintas dan dependensi saat melakukan penilaian aplikasi terperinci.
Di awal penilaian, Anda harus mengidentifikasi pemangku kepentingan aplikasi. Ini biasanya sebagai berikut:
-
Unit bisnis memimpin
-
Pemilik aplikasi
-
Arsitek
-
Operasi dan dukungan
-
Tim pemberdayaan cloud
-
Tim platform tertentu seperti komputasi, penyimpanan, dan jaringan
Ada dua pendekatan untuk penemuan terperinci. Penemuan top-down dimulai dengan aplikasi, atau bahkan dengan pengguna, dan berjalan sampai ke infrastruktur. Ini adalah pendekatan yang disarankan ketika identifikasi aplikasi jelas. Sebaliknya, penemuan bottom-up dimulai dengan infrastruktur dan berjalan sampai ke aplikasi atau layanan dan penggunanya. Pendekatan ini berguna ketika program migrasi didorong oleh tim infrastruktur dan saat application-to-infrastructure pemetaan tidak jelas. Secara umum, Anda cenderung menggunakan kombinasi keduanya.
Untuk menyelam jauh ke dalam aplikasi, diagram arsitektur yang ada adalah awal yang baik. Jika ini tidak tersedia, buat satu berdasarkan pengetahuan saat ini. Jangan meremehkan pentingnya tugas ini, bahkan untuk rehost sederhana atau relokasi strategi migrasi. Merencanakan diagram arsitektur membantu Anda mengidentifikasi inefisiensi yang dapat dengan cepat diatasi dengan perubahan kecil saat berada di cloud.
Bergantung pada apakah Anda melakukan pendekatan top-down atau bottom-up, diagram awal akan memplot komponen aplikasi dan layanan atau komponen infrastruktur seperti server dan penyeimbang beban. Setelah komponen dan antarmuka utama diidentifikasi, validasi dengan data terprogram dari alat penemuan dan alat pemantauan kinerja aplikasi. Alat harus mendukung analisis ketergantungan dan memberikan informasi komunikasi antar komponen. Setiap komponen yang membentuk aplikasi ini harus diidentifikasi. Selanjutnya, dokumentasikan dependensi ke aplikasi dan layanan lain, baik internal maupun eksternal.
Dengan tidak adanya perkakas untuk memvalidasi dependensi dan pemetaan, diperlukan pendekatan manual. Misalnya, Anda dapat masuk ke komponen infrastruktur dan menjalankan skrip untuk mengumpulkan informasi komunikasi seperti port terbuka dan koneksi yang sudah mapan. Demikian juga, Anda dapat mengidentifikasi proses yang berjalan dan perangkat lunak yang diinstal. Jangan meremehkan upaya yang diperlukan untuk penemuan manual. Perkakas terprogram dapat menangkap dan melaporkan sebagian besar dependensi dalam beberapa hari, kecuali yang terjadi pada interval yang lebih besar (biasanya persentase kecil). Penemuan manual dapat memakan waktu berminggu-minggu untuk mengumpulkan dan menggabungkan semua titik data, dan masih rentan terhadap kesalahan dan data yang hilang.
Lanjutkan untuk mendapatkan informasi yang ditentukan di bagian persyaratan data untuk setiap aplikasi yang diprioritaskan dan infrastruktur yang dipetakan. Selanjutnya, gunakan kuesioner berikut untuk memandu Anda melalui proses penilaian terperinci. Bertemu dengan pemangku kepentingan yang teridentifikasi untuk mendiskusikan jawaban atas pertanyaan-pertanyaan ini.
Umum
-
Apa tingkat kekritisan aplikasi ini? Apakah itu menghasilkan pendapatan? Apakah ini aplikasi bisnis-strategis atau mendukung bisnis? Apakah ini layanan infrastruktur inti yang dimiliki oleh sistem lain?
-
Apakah ada proyek transformasi yang sedang berlangsung untuk aplikasi ini?
-
Apakah ini aplikasi yang dihadapi secara internal atau eksternal?
Arsitektur
-
Apa jenis arsitektur saat ini (misalnya, SOA, layanan mikro, monolit)? Berapa banyak tingkatan yang dimiliki arsitektur? Apakah itu digabungkan dengan erat atau digabungkan secara longgar?
-
Apa saja komponennya (misalnya, komputasi, database, penyimpanan jarak jauh, penyeimbang beban, layanan caching)?
-
Apa itu API? Jelaskan ini, termasuk nama API, operasi, URL, port, dan protokol.
-
Apa latensi maksimum yang ditoleransi antara komponen dan antara ini dan aplikasi atau layanan lainnya?
Operasi
-
Di lokasi apa aplikasi ini beroperasi?
-
Siapa yang mengoperasikan aplikasi dan infrastruktur? Apakah ini dioperasikan oleh tim internal atau AWS Mitra?
-
Apa yang terjadi jika aplikasi ini turun? Siapa yang terpengaruh? Apa dampaknya?
-
Di mana pengguna atau pelanggan berada? Bagaimana mereka mengakses aplikasi? Berapa jumlah pengguna bersamaan?
-
Kapan penyegaran teknologi terakhir? Apakah penyegaran dijadwalkan di masa depan? Jika demikian, kapan?
-
Apa risiko dan masalah yang diketahui untuk aplikasi ini? Bagaimana sejarah pemadaman dan insiden tingkat keparahan sedang dan tingkat keparahan tinggi?
-
Apa siklus penggunaan (dalam jam kerja)? Apa zona waktu operasi?
-
Apa periode pembekuan perubahan?
-
Solusi apa yang digunakan untuk memantau aplikasi ini?
Kinerja
-
Apa yang ditunjukkan oleh informasi kinerja yang dikumpulkan? Apakah penggunaan runcing atau konstan dan dapat diprediksi? Berapa kerangka waktu, interval, dan tanggal data kinerja yang tersedia?
-
Apakah ada pekerjaan batch terjadwal yang merupakan bagian dari atau berinteraksi dengan aplikasi ini?
Siklus hidup perangkat lunak
-
Berapa tingkat perubahan saat ini (mingguan, bulanan, triwulanan, atau tahunan)?
-
Apa siklus hidup pengembangan (misalnya, pengujian, pengembangan, QA, UAT, pra-produksi, produksi)?
-
Apa metode penyebaran untuk aplikasi dan infrastruktur?
-
Apa itu perkakas penyebaran?
-
Apakah aplikasi atau infrastruktur ini menggunakan continuous integration (CI) /continuous delivery (CD)? Apa tingkat otomatisasi? Apa tugas manualnya?
-
Apa persyaratan lisensi untuk aplikasi dan infrastruktur?
-
Apa itu Service Level Agreement (SLA)?
-
Apa mekanisme pengujian saat ini? Apa tahapan tesnya?
Migrasi:
-
Apa pertimbangan migrasi?
Pada titik ini, perhatikan pertimbangan apa pun saat memigrasikan aplikasi ini. Untuk penilaian yang lebih lengkap dan akurat, dapatkan jawaban atas pertanyaan ini dari berbagai pemangku kepentingan. Kemudian kontraskan pengetahuan dan pendapat mereka.
Ketahanan
-
Apa metode pencadangan saat ini? Produk apa yang digunakan untuk cadangan? Apa jadwal pencadangan? Apa kebijakan retensi cadangan?
-
Apa tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) saat ini?
-
Apakah aplikasi ini memiliki rencana pemulihan bencana (DR)? Jika demikian, apa solusi DR?
-
Kapan tes DR terakhir?
Keamanan dan kepatuhan
-
Apa saja kerangka kepatuhan dan peraturan yang berlaku untuk aplikasi ini? Apa tanggal audit terakhir dan berikutnya?
-
Apakah aplikasi ini meng-host data sensitif? Apa klasifikasi datanya?
-
Apakah data dienkripsi saat transit atau diam, atau keduanya? Apa mekanisme enkripsi?
-
Apakah aplikasi ini menggunakan sertifikat Secure Sockets Layer (SSL)? Apa otoritas penerbit?
-
Apa metode otentikasi untuk pengguna, komponen, dan aplikasi dan layanan lainnya?
Basis Data
-
Database apa yang digunakan aplikasi ini?
-
Berapa jumlah tipikal koneksi bersamaan ke database? Berapa jumlah minimum dan jumlah maksimum koneksi?
-
Apa metode koneksi (misalnya, JDBC, ODBC)?
-
Apakah string koneksi didokumentasikan? Jika demikian, di mana?
-
Apa skema database?
-
Apakah database menggunakan tipe data khusus?
Dependensi
-
Apa ketergantungan antar komponen? Perhatikan dependensi apa pun yang tidak dapat diselesaikan dan yang memerlukan migrasi komponen bersama-sama.
-
Apakah komponen dibagi di seluruh lokasi? Apa konektivitas antara lokasi-lokasi ini (misalnya, WAN, VPN)?
-
Apa dependensi aplikasi ini ke aplikasi atau layanan lain?
-
Apa dependensi operasional? Misalnya, siklus pemeliharaan dan rilis seperti menambal jendela.
