Merencanakan modernisasi cloud Anda

Perencanaan dan tata kelola yang tepat sangat penting untuk modernisasi. Dalam tahap ini, Anda memutuskan pendekatan modernisasi mana yang akan diterapkan dan cara melakukannya. Perencanaan yang bijaksana mengurangi kemungkinan pembengkakan anggaran, perubahan cakupan proyek, atau gangguan layanan selama pelaksanaan.

Pilih strategi modernisasi

Memodernisasi beban kerja berarti memperbaruinya agar lebih selaras dengan tujuan bisnis saat ini, standar teknis, dan kemampuan cloud. Tiga strategi utama (replatform, refaktor, dan mendesain ulang arsitektur) ada pada kelanjutan kompleksitas dan nilai. Sebagian besar upaya modernisasi menggunakan kombinasi pendekatan ini.

Kuncinya adalah mencocokkan strategi dengan kebutuhan spesifik setiap komponen, mengingat tujuan, garis waktu, dan sumber daya yang tersedia. Hindari godaan untuk memodernisasi secara berlebihan. Meskipun teknologi baru menarik, setiap keputusan harus didasarkan pada nilai bisnis.

Strategi modernisasi Definition Kapan harus menggunakan Pros Cons
Replatform Pindahkan aplikasi ke platform cloud dengan perubahan kode minimal (IaaS ke PaaS). Perbaikan upaya rendah dengan gangguan minimal yang diperlukan. Kode saat ini berfungsi tetapi beban operasi tinggi. Implementasi cepat. Mengurangi upaya pemeliharaan. Meningkatkan keandalan melalui infrastruktur yang lebih baik. Peningkatan kemampuan terbatas. Aplikasi inti tetap tidak berubah.
Refactor Ubah kode yang ada untuk meningkatkan struktur, performa, dan pengoptimalan cloud sambil mempertahankan fungsionalitas. Utang teknis menyebabkan masalah atau kode tidak dioptimalkan untuk cloud. Meningkatkan ketahanan, performa, dan keamanan. Memungkinkan penyempurnaan di masa depan yang lebih mudah. Membutuhkan upaya dan pengujian pengembang yang signifikan. Tidak ada fitur baru langsung untuk pengguna.
Rearchitect Desain ulang arsitektur aplikasi menggunakan pola cloud-native (layanan mikro, tanpa server, berbasis peristiwa). Arsitektur saat ini membatasi pertumbuhan atau pengoptimalan cloud. Mengatasi masalah skalabilitas mendasar. Mengaktifkan layanan cloud tingkat lanjut. Menetapkan fondasi untuk inovasi jangka panjang. Paling kompleks dan memakan waktu. Biaya dan risiko di muka yang tinggi. Memerlukan pengujian ekstensif dan operasi paralel.

Merencanakan modernisasi dalam fase

Mencoba memodernisasi seluruh beban kerja yang kompleks (atau beberapa) dalam sekali jalan berisiko. Pecahkan upaya menjadi fase logis. Phasing memungkinkan Anda untuk memberikan nilai secara bertahap, mengurangi risiko dengan mengatasi bagian-bagian yang lebih mudah dikelola, dan menyesuaikan arah antar tahap berdasarkan apa yang Anda pelajari.

  1. Bagi modernisasi menjadi fase logis. Tentukan cara membagi pekerjaan. Tidak ada satu pun "jalan yang benar." Pilih perincian yang masuk akal untuk arsitektur dan struktur tim Anda. Tujuannya adalah bahwa setiap fase cukup kecil untuk mengeksekusi dan menguji tanpa kompleksitas yang luar biasa, tetapi cukup bermakna untuk memberikan nilai. Cara umum untuk memecah fase:

    Metode pembagian Description Example
    Menurut komponen atau lapisan Fase terpisah berdasarkan lapisan beban kerja atau batas beban kerja Fase 1: Migrasi database, Fase 2: Pemfaktoran ulang aplikasi, Fase 3: Modernisasi UI
    Berdasarkan prioritas dan kompleksitas Mengatur pekerjaan dari perubahan berisiko rendah hingga berisiko tinggi Fase 1: Layanan tidak kritis, Fase 2: Logika bisnis inti, Fase 3: Fitur yang berhadapan dengan pelanggan
    Menurut fungsi bisnis Fase struktur di sekitar batas aplikasi atau fungsional Fase 1: Beban kerja manajemen pengguna, Fase 2: Pemrosesan pembayaran, Fase 3: Layanan pelaporan

  2. Mulailah dengan perubahan berisiko rendah dan bernilai tinggi. Untuk Fase 1 Anda, pilih sesuatu yang dapat dicapai dan memberikan manfaat yang terukur, tetapi tidak membahayakan bisnis jika masalah muncul. Misalnya, modernisasi layanan backend atau alat internal terlebih dahulu daripada situs web yang menghadap pelanggan. Bertujuan untuk menyelesaikan fase pertama dengan cepat (satu atau dua bulan) sebagai demonstrasi kelayakan. Keberhasilan awal membangun kepercayaan tim dan dukungan pemangku kepentingan untuk fase berikutnya.

  3. Urutan fase yang tersisa menurut nilai dan dependensi. Setelah fase pertama, rencanakan urutan fase berikutnya berdasarkan nilai bisnis dan dependensi teknis. Bangun peta strategi di mana setiap fase memiliki cakupan yang ditentukan dan memastikan bahwa komponen penting memiliki elemen pendukungnya yang sudah dimodernisasi atau kompatibel.

    • Mengatasi area yang rapuh. Jika beban kerja rapuh dalam keadaan saat ini, Anda bahkan mungkin memerlukan "Fase 0" awal untuk menstabilkannya di tempat (menerapkan perbaikan mendesak di lingkungan lama) sehingga aman untuk dimodernisasi pada Fase 1.
    • Prasyarat alamat terlebih dahulu: Jika modernisasi Beban Kerja B bergantung pada Beban Kerja A yang dimodernisasi (atau setidaknya stabil), lakukan Beban Kerja A terlebih dahulu.
    • Pertimbangkan nilai bisnis vs risiko: Anda mungkin memutuskan untuk bergantian, melakukan bagian bernilai tinggi tetapi lebih berisiko dalam satu fase, kemudian bagian berisiko lebih rendah di fase berikutnya, untuk menyeimbangkan beban pada tim dan risiko terhadap bisnis.

  4. Tentukan kriteria keberhasilan untuk setiap fase. Untuk setiap fase, putuskan kapan selesai dan berhasil. Memiliki kriteria keluar yang jelas mencegah perluasan lingkup yang tidak terkendali dalam suatu fase. Kriteria keberhasilan mungkin mencakup:

    Jenis kriteria keberhasilan Examples
    Tujuan teknis • Layanan X berjalan di Azure App Service dan menangani 20% lebih banyak beban
    • Database Y bermigrasi ke Azure SQL dengan kehilangan dan performa data nol dalam 10% garis besar sebelumnya
    Gerbang berkualitas • Tidak ada bug Sev-1 yang terbuka
    • Semua tes otomatis berhasil
    • Pemindaian keamanan menunjukkan kerentanan kritis nol
    Batasan waktu dan anggaran • Selesai dalam waktu tiga bulan dan dalam 5% anggaran
    • Menyebarkan selama waktu pemeliharaan terjadwal

  5. Sesuaikan rencana berdasarkan hasil. Setelah menyelesaikan fase, tinjau hasil dan pelajaran yang dipelajari. Anda mungkin menemukan bahwa beberapa asumsi meleset atau beberapa tugas ternyata lebih mudah atau lebih sulit dari perkiraan. Sesuaikan rencana untuk fase mendatang yang sesuai, seperti menambahkan, menggabungkan, atau memprioritaskan kembali fase. Pendekatan bertahap dirancang untuk fleksibel. Yang penting adalah tidak mencoba melakukan semuanya sekaligus.

Merencanakan tata kelola modernisasi

Modernisasi sering memperkenalkan perubahan signifikan pada beban kerja penting, sehingga tata kelola yang kuat diperlukan untuk mengelola risiko. Tata kelola modernisasi melibatkan proses manajemen perubahan, pembekuan, dan cakupan pengendalian:

  • Menetapkan alur kerja persetujuan perubahan formal. Tentukan proses persetujuan terstruktur untuk semua perubahan terkait modernisasi. Integrasikan dengan Dewan Penasihat Perubahan (CAB) yang ada atau buat dewan tinjauan khusus untuk modernisasi. Tetapkan otoritas persetujuan berdasarkan kategori perubahan dan dokumentasikan alur kerja lengkap dalam rencana proyek Anda. Untuk informasi selengkapnya, lihat Mengelola perubahan.

  • Bekukan perubahan jika perlu. Tepat sebelum dan selama peristiwa penyebaran besar, bekukan perubahan lain pada beban kerja tersebut. Penghentian perubahan sementara berarti tidak ada perubahan lain yang tidak terkait yang dilakukan pada beban kerja tersebut sebelum dan selama penyebaran. Ini menstabilkan lingkungan sehingga Anda tidak menyebarkan ke lingkungan yang tidak stabil. Komunikasikan periode pembekuan ke semua tim yang relevan.

  • Hindari perluasan cakupan proyek yang tidak terkendali. Lingkup ekspansi adalah tantangan utama dalam modernisasi. Memerlukan perubahan yang diusulkan ke cakupan modernisasi yang disepakati untuk melalui langkah evaluasi dan persetujuan. Sebagian besar permintaan harus ditangguhkan kecuali sangat penting. Formalise "tidak, tidak sekarang" menjadi pekerjaan ekstra dengan sebuah proses. Pertahankan backlog ide yang diinginkan yang muncul, yang dapat berkontribusi pada proyek inovasi di masa depan setelah modernisasi saat ini selesai dilakukan. Pemangku kepentingan harus tahu ide mereka tidak hilang.

Tentukan strategi penyebaran Anda

Keputusan eksekusi penting adalah cara meluncurkan komponen yang dimodernisasi ke dalam produksi. Ada dua strategi utama. Dalam penyebaran di tempat, Anda meningkatkan konfigurasi yang ada (memperbarui lingkungan yang ada secara langsung). Dalam penyebaran paralel, Anda membangun konfigurasi baru secara bersamaan (membangun lingkungan baru, lalu beralih). Pilih strategi yang sesuai dengan tingkat perubahan dan toleransi risiko untuk setiap fase atau beban kerja. Seringkali, setiap fase modernisasi mungkin menggunakan strategi yang berbeda. Misalnya, Anda dapat memilih langsung untuk Fase 1 (jika perubahannya kecil) dan paralel untuk Fase 2 (jika melibatkan perombakan database besar).

  • Gunakan penyebaran di tempat untuk perubahan yang berisiko rendah dan dapat dibalik. Penyebaran di tempat memperkenalkan perubahan langsung ke lingkungan produksi saat ini, mungkin selama jendela pemeliharaan. Strategi ini meminimalkan overhead infrastruktur tetapi meningkatkan risiko waktu henti. Gunakan penyebaran di tempat hanya ketika perubahan kecil, terisolasi, dan mudah dikembalikan. Contohnya termasuk pembaruan kode kecil atau perubahan skema yang dapat digulung balik dengan cepat menggunakan kontrol sumber atau cadangan.

  • Gunakan penyebaran paralel untuk perubahan yang kompleks atau berisiko tinggi. Dalam model ini, Anda menyiapkan lingkungan baru untuk beban kerja yang dimodernisasi saat beban kerja lama masih berjalan. Data tetap sinkron (melalui proses replikasi atau migrasi) sehingga ketika siap, Anda dapat memotong dari lingkungan lama ke baru. Gunakan model ini untuk perubahan kompleks atau berisiko tinggi di mana waktu henti harus minimal. Jika Anda melakukan migrasi database utama atau pembuatan ulang yang melibatkan infrastruktur baru, penyebaran paralel biasanya merupakan pilihan yang lebih baik. Selain itu, jika beban kerja sangat penting dan tidak dapat memiliki lebih dari beberapa menit waktu henti, paralel (dengan replikasi dan cutover cepat) diperlukan.

    Strategy Description Kapan harus menggunakan Pros Cons
    Penyebaran di tempat Menyebarkan perubahan langsung ke lingkungan produksi saat ini Perubahan kecil dan dapat dibalik dengan periode pemeliharaan yang sesuai Tidak ada infrastruktur duplikat, penyebaran yang lebih cepat Risiko lebih tinggi, memerlukan downtime, pengembalian yang lebih lambat
    Penyebaran paralel Jalankan lingkungan baru bersama beban kerja yang ada selama transisi Perubahan kompleks, beban kerja misi penting yang membutuhkan waktu henti minimal Penyebaran yang lebih aman, waktu henti hampir nol, pemulihan segera Biaya infrastruktur duplikat, sinkronisasi data yang kompleks, upaya penonaktifan

Rencanakan untuk mengurangi risiko modernisasi

Bahkan dengan perencanaan dan pengujian terbaik, tidak setiap perubahan berjalan dengan sempurna. Modernisasi sering melibatkan perubahan yang kompleks, dan selalu ada risiko bahwa penyebaran dapat menimbulkan masalah, atau sesuatu berperilaku tak terduga dalam produksi. Tim yang disiapkan dengan baik memiliki rencana pembatalan menyeluruh untuk setiap perubahan atau fase.

  1. Gunakan teknik penyebaran progresif. Jika platform memungkinkan, lakukan rilis canary atau alihkan lalu lintas secara bertahap ke bagian aplikasi yang telah dimodernisasi. Misalnya, sebarkan versi baru bersama yang lama dan awalnya hanya mengirim 5% pengguna ke dalamnya saat memantau. Pendekatan ini dapat menangkap masalah sementara sebagian besar pengguna tidak terpengaruh. Jika metrik terlihat bagus, tingkatkan hingga 50%, maka 100%. Jika sesuatu mulai gagal, rutekan kembali ke 0% baru (putar kembali) dengan cepat.

  2. Buat prosedur pemulihan untuk setiap perubahan besar. Untuk setiap perubahan besar atau deliverable fase, tulis prosedur pembatalan langkah demi langkah. Cantumkan dengan jelas setiap tindakan untuk membatalkan perubahan, siapa yang bertanggung jawab atas setiap langkah, dan berapa lama waktu yang diperlukan. Setelah putar kembali, sertakan pemeriksaan apa yang mengonfirmasi bahwa semuanya kembali normal.

  3. Mengotomatiskan pemutaran kembali jika memungkinkan. Skrip putar kembali otomatis atau infrastruktur sebagai kode dapat membuat pemulihan cepat dan dapat diandalkan. Gunakan alat untuk menjadikan infrastruktur sebagai kode (Terraform, templat ARM, dan Bicep) untuk menerapkan kembali status yang telah diverifikasi baik. Penyebaran biru-hijau atau kenari secara inheren memungkinkan "beralih kembali" ke versi sebelumnya jika diperlukan. Uji mekanisme ini di lingkungan staging. Tujuannya adalah untuk mengurangi upaya manual (selama insiden) ke tindakan berskrip. Tulis langkah-langkah pemulihan bersama dengan langkah-langkah penyebaran agar mudah untuk melakukan rollback.

  4. Memiliki dukungan yang siap sedia selama dan setelah penyebaran. Rencanakan penyebaran selama periode lalu lintas rendah (akhir pekan atau semalam) jika memungkinkan, tetapi pastikan para ahli yang relevan tersedia. Hindari penjadwalan penyebaran saat anggota tim kunci tidak tersedia. Memiliki periode dukungan yang diperpanjang (hypercare) tepat setelah penyebaran dengan pengembang dan tim operasi berjaga untuk menangani masalah apa pun lebih dini. Untuk peluncuran besar, beberapa organisasi memiliki pemantauan intensif ala ruang perang selama 24-48 jam setelahnya.

Persetujuan pemangku kepentingan yang aman

Hingga saat ini, kami berfokus pada perencanaan teknis. Yang sama pentingnya adalah mendapatkan persetujuan dari pemangku kepentingan, baik kepemimpinan bisnis maupun teknis. Modernisasi sering membutuhkan investasi yang signifikan, jadi Anda perlu menyajikan kasus yang menarik dan menjaga pemangku kepentingan tetap terlibat di seluruh.

  • Sesuaikan proposisi nilai untuk setiap audiens. Pemangku kepentingan yang berbeda peduli dengan hasil yang berbeda. Kustomisasi pesan Anda:

    • Tim teknis memprioritaskan efisiensi operasional: mengurangi pemeliharaan, meningkatkan waktu aktif, dan lebih sedikit eskalasi.
    • Pemimpin bisnis berfokus pada hasil: waktu-ke-pasar yang lebih cepat, peningkatan pengalaman pelanggan, dan penghematan biaya.

  • Dokumentasikan rencana terstruktur dengan tonggak pencapaian. Pemangku kepentingan lebih nyaman jika melihat peta jalan yang jelas. Sajikan fase yang Anda rencanakan, seperti yang diputuskan sebelumnya, dan apa yang harus dicapai masing-masing, dengan garis waktu yang kasar. Tekankan kemenangan awal, seperti "Dalam waktu 6 minggu, kami bertujuan untuk memodernisasi komponen X dan meningkatkan performanya sebesar 20%."

  • Kuantifikasi nilai modernisasi. Siapkan beberapa metrik sebelum dan sesudah serta targetkan peningkatannya. Contoh metrik dan rentang peningkatan umum (berdasarkan tolok ukur industri) adalah:

    Category Contoh metrik Rentang nilai umum
    Pengurangan biaya Infrastruktur, pemeliharaan, lisensi 20-40% penghematan tahunan
    Keuntungan produktivitas Frekuensi penyebaran, waktu resolusi Peningkatan 50-80%
    Mitigasi risiko Menghindari terjadinya waktu henti, insiden-insiden keamanan $100K-$1 Juta+ penghematan biaya
    Revenue Waktu ke pasar yang lebih cepat, retensi pelanggan 10-25% akselerasi pendapatan

  • Mengatasi risiko proyek. Identifikasi potensi tantangan dan tunjukkan kesiapsiagaan melalui strategi mitigasi tertentu. Risiko umum termasuk replikasi data, penurunan performa, dan masalah integrasi. Sajikan solusi seperti prosedur putar kembali otomatis, protokol pengujian komprehensif, dan ketersediaan konsultasi ahli. Diskusi risiko transparan membangun kepercayaan pemangku kepentingan dalam kepemimpinan proyek dan perencanaan ketelitian.

  • Pertahankan irama komunikasi rutin. Laporkan kemajuan terhadap kriteria keberhasilan yang ditentukan, sorot hasil yang diselesaikan, dan komunikasikan tonggak pencapaian mendatang. Minta umpan balik secara aktif dan atasi masalah untuk mempertahankan dukungan sepanjang proses modernisasi.

Langkah selanjutnya

Jalankan modernisasi cloud Anda

  • Last updated on