Cara mengukur—dan memenuhi syarat—manfaat migrasi awan

Ini adalah kesimpulan yang sudah pasti bahwa masa depan bisnis perusahaan terletak di cloud. Ini terutama benar ketika mempertimbangkan peran besar yang dimainkan migrasi cloud dalam ruang perusahaan selama beberapa tahun terakhir:

Pengeluaran untuk komputasi awan telah tumbuh 4,5 kali lipat tingkat pengeluaran TI sejak 2009, dan diperkirakan akan tumbuh lebih dari 6 kali lipat hingga tahun 2020.

Rangkuman Komputasi Awan Forbes

Hal ini didukung oleh data terbaru dari Oracle, yang prediksi nomor duanya untuk tahun 2019 adalah bahwa 80 persen dari semua beban kerja perusahaan--termasuk yang dianggap “misi kritis”--akan pindah ke cloud selama 12 bulan ke depan.

Meskipun cloud hampir ada di mana-mana di seluruh perusahaan (dan semakin familiar dengan teknologi cloud untuk pakar TI dan orang awam), memindahkan alur kerja ke cloud bukanlah hal yang mudah. Hal ini terutama berlaku dalam hal mengelola ekspektasi, dan benar-benar memberikan peningkatan--baik yang terkait dengan biaya atau kinerja--saat migrasi selesai.

Untuk memastikan tim tidak membuat janji yang tidak dapat mereka tepati, mereka membutuhkan visibilitas di setiap tahap migrasi cloud mereka. Lagi pula, “Anda tidak dapat mengelola apa yang tidak dapat Anda ukur, ” begitulah mantra lama, sehingga tim TI harus memiliki visibilitas di setiap tahap migrasi untuk menetapkan ekspektasi yang akurat dan tetap berada di depan masalah sebelum mereka menggagalkan keseluruhan usaha.

Menentukan sasaran kinerja yang dapat diterima

Sebagai permulaan, tim perlu sepenuhnya memahami aplikasi, infrastruktur jaringan, atau proses apa yang paling sering rusak. TI kemungkinan perlu melakukan wawancara lintas fungsi untuk mendapatkan informasi dan dukungan di seluruh organisasi.

Membuat kasus untuk migrasi cloud mungkin mudah ketika TI berpikir secara umum. Tentu, membongkar pemeliharaan perangkat keras jaringan akan terlihat menarik bagi para pembuat keputusan yang sadar anggaran, tetapi berapa banyak investasi di muka yang diperlukan sebelum bisnis dapat memperoleh penghematan tersebut?

Biaya saja mungkin tidak cukup untuk menarik semua pengambil keputusan. Jika migrasi cloud meningkatkan kinerja beberapa aplikasi yang dianggap penting bagi bisnis, apakah itu akan mengorbankan alat yang digunakan di tempat lain? Apakah kinerja aplikasi akan terpengaruh selama migrasi, dan untuk berapa lama? Apakah ada pelatihan baru yang diperlukan untuk pengguna?

Tim harus memahami semua pertanyaan ini sebelum mereka membawa proposal migrasi mereka ke tim eksekutif. Ini akan membutuhkan TI untuk melakukan refleksi serius pada keadaan jaringan saat ini untuk membuat dasar kinerja yang ada. Dengan cara ini, tim dapat mengonfirmasi atau menginformasikan pendapat pembuat keputusan tentang tempat yang paling membutuhkan peningkatan dan menempatkan solusi dalam konteks cloud.

Mendasarkan kinerja sebelum migrasi

Pengalaman pengguna akhir adalah tempat awal semua ini dimulai. Lagi pula, TI tidak akan berhasil jika pengalaman pengguna akhir karyawan tidak ditingkatkan -- atau bahkan lebih buruk -- setelah migrasi cloud. Bahkan pengambil keputusan yang hanya berfokus pada keuntungan akan setuju karena pengalaman pengguna yang buruk dapat memiliki efek domino pada kinerja bisnis yang lebih besar. Oleh karena itu, TI perlu membidik "keadaan saat ini" jaringan (bersama dengan kepuasan pengguna) sebelum arsitektur apa pun dicabut.

Untuk aplikasi, ini memerlukan pengujian web sintetis yang memberikan perspektif lokal TI tentang apa yang sebenarnya dialami pengguna di lokasi mereka bekerja, bersama dengan visibilitas yang jelas di seluruh jalur pengiriman. Dengan informasi ini berguna, TI dapat menetapkan "kriteria penerimaan" yang harus mereka penuhi selama dan setelah migrasi cloud untuk memastikan bahwa pengguna tetap puas. Beberapa kriteria sampel mungkin terlihat seperti:

• Waktu respons harus dalam 5 persen dari level sebelum migrasi
• Tingkat kesalahan layanan harus sama dengan, atau lebih rendah dari, tingkat sebelum migrasi
• Ketersediaan aplikasi harus sama dengan, atau lebih rendah dari, level sebelum migrasi
• Biaya infrastruktur harus dikurangi setidaknya X persen selama migrasi

Oleh karena itu, tim perlu memeriksa seberapa cepat aplikasi saat ini dikirimkan ke pengguna, latensi antar server (baik internal maupun eksternal, DNS, dll.), tingkat kesalahan, jenis kesalahan, dan masalah kinerja khusus browser. Hanya dengan semua data ini TI dapat memahami keadaan pra-migrasi jaringan.

Lanjutkan pemantauan selama migrasi

Setelah tim menetapkan baseline, penting bagi mereka untuk terus memantau kriteria penerimaan mereka selama proses migrasi. Tim harus dapat membuat dasbor dan peringatan yang dapat menandai saat jaringan tidak memenuhi kriteria, idealnya menggunakan metrik yang sama, jika bukan solusi pemantauan, yang mereka rujuk ke kinerja dasar.

• Waktu Aktif - Untuk aplikasi cloud, TI harus memperkirakan waktu henti terbatas pada menit selama minggu tertentu. Sebagian besar aplikasi publik berusaha untuk 99,9% atau lebih baik (~7 menit dalam setiap minggu kerja).
• DNS - Untuk aplikasi yang sekarang ada di cloud, TI kemungkinan akan memiliki server DNS lokal atau layanan DNS publik yang menyediakan alamat IP. Ini adalah sesuatu yang harus dipantau secara aktif karena akan mencegah koneksi untuk semua pengguna di lokasi tertentu.
• Latensi, RTT - Sekarang layanan berada di luar pusat data atau di luar kantor, mungkin ada perbedaan yang berarti dalam waktu lalu lintas yang diperlukan untuk melakukan perjalanan dari klien ke server. Lonjakan di sini mungkin terkait dengan masalah LAN, ISP, atau aplikasi.
• Kapasitas - Membayar bandwidth dari ISP adalah satu hal, tetapi kapasitas ujung-ke-ujung jaringan antara lokasi pengguna dan server aplikasi kemungkinan akan memiliki hambatan yang berbeda. Pengukuran ini memungkinkan TI untuk mengidentifikasi kapan kemacetan memengaruhi kecepatan koneksi.

Lonjakan dan lompatan adalah indikator berguna dari bug terkait migrasi yang perlu segera ditangani -- bahkan sebelum permintaan bisnis baru -- untuk menghentikan masalah sebelum berkembang biak. Dengan menyelesaikan masalah, mata TI langsung tertuju pada masalah tersebut, tim kemungkinan besar akan menerapkan solusi yang paling tepat.

Manfaatkan pemantauan untuk memenuhi syarat keberhasilan

Baselining yang dilakukan tim sebelum migrasi perlu dilakukan ulang untuk perbandingan setelah arsitektur jaringan baru diterapkan. Kuncinya di sini adalah menggunakan proses yang sama (penggunaan, pola, waktu, dll.) yang diuji melalui jaringan lama.

Dengan semua migrasi cloud, ada beberapa tingkat kontrol yang hilang. Baik itu di level bare metal, OS, atau akses, penting juga bagi tim untuk menggunakan solusi pemantauan modern yang dapat memberikan tingkat visibilitas yang sama ke jaringan baru yang didukung cloud. Jika infrastruktur tidak lagi dimiliki oleh TI maka tingkat visibilitas dengan alat pemantau lama akan terganggu. Ini sangat penting, karena banyak solusi pemantauan tidak dapat memberikan visibilitas ke lingkungan cloud atau bahkan di luar firewall TI.

Tanpa wawasan di luar firewall, sulit bagi TI untuk mengidentifikasi masalah yang berasal dari ISP atau infrastruktur pihak ketiga dan menyelesaikannya dengan cepat. Ini dapat menunda migrasi saat sedang berlangsung dan membuat pengguna di luar TI bernostalgia untuk hari-hari sebelum cloud jika kinerja terus-menerus terhambat.