Bagikan melalui

Pertimbangan untuk memperbarui solusi multitenant

  • Artikel

Salah satu manfaat teknologi cloud adalah peningkatan dan evolusi yang berkelanjutan. Sebagai penyedia layanan, Anda perlu menerapkan pembaruan pada solusi: Anda mungkin perlu membuat perubahan pada infrastruktur Azure, kode/aplikasi, skema database, atau komponen lainnya. Sangat penting untuk merencanakan bagaimana Anda memperbarui lingkungan Anda. Dalam solusi multipenyewa, sangat penting untuk jelas tentang kebijakan pembaruan Anda karena beberapa penyewa Anda mungkin enggan mengizinkan perubahan pada lingkungan mereka, atau mereka mungkin memiliki persyaratan yang membatasi kondisi di mana Anda dapat memperbarui layanan mereka.

Saat merencanakan strategi untuk memperbarui solusi Anda, Anda perlu:

  • Identifikasi persyaratan penyewa Anda.
  • Klarifikasi persyaratan Anda sendiri untuk mengoperasikan layanan Anda.
  • Temukan saldo yang dapat diterima oleh Anda dan penyewa Anda.
  • Komunikasikan strategi Anda dengan jelas kepada penyewa dan pemangku kepentingan lainnya.

Dalam artikel ini, kami memberikan panduan untuk pembuat keputusan teknis tentang pendekatan yang dapat Anda pertimbangkan untuk memperbarui perangkat lunak penyewa Anda, dan tradeoff yang terlibat.

Kebutuhan pelanggan Anda

Pertimbangkan pertanyaan-pertanyaan berikut:

  • Harapan dan persyaratan: Apakah pelanggan Anda memiliki harapan atau persyaratan tentang kapan mereka dapat diperbarui? Ini mungkin secara resmi mereka komunikasikan kepada Anda dalam kontrak atau perjanjian tingkat layanan, atau mungkin secara informal.
  • Jendela pemeliharaan: Apakah pelanggan Anda mengharapkan jendela pemeliharaan yang ditentukan layanan atau bahkan yang ditentukan sendiri? Mereka mungkin perlu berkomunikasi dengan pelanggan mereka sendiri tentang potensi pemadaman.
  • Peraturan: Apakah pelanggan Anda memiliki masalah peraturan yang memerlukan persetujuan tambahan sebelum pembaruan dapat diterapkan? Misalnya, jika Anda memberikan solusi kesehatan yang mencakup komponen IoT, Anda mungkin perlu mendapatkan persetujuan dari Badan Pengawas Obat dan Makanan Amerika Serikat (FDA) sebelum menerapkan pembaruan.
  • Sensitivitas: Apakah salah satu pelanggan Anda sangat sensitif atau tahan terhadap penerapan pembaruan? Coba pahami alasannya. Misalnya, jika mereka menjalankan toko fisik atau situs web ritel, mereka mungkin ingin menghindari pembaruan di sekitar Black Friday, karena risikonya lebih tinggi dari potensi manfaat.
  • Riwayat: Apa rekam jejak Anda yang berhasil menyelesaikan pembaruan tanpa dampak apa pun bagi pelanggan Anda? Anda harus mengikuti praktik Azure DevOps, pengujian, penyebaran, dan pemantauan yang baik untuk mengurangi kemungkinan pemadaman, dan untuk memastikan bahwa Anda dengan cepat mengidentifikasi masalah apa pun yang dhasilkan pembaruan. Jika pelanggan Anda tahu bahwa Anda dapat memperbarui lingkungan mereka dengan lancar, mereka cenderung tidak keberatan.
  • Pembatalan: Apakah pelanggan ingin mengembalikan pembaruan jika ada perubahan yang melanggar?

Kebutuhan Anda

Anda juga perlu mempertimbangkan pertanyaan-pertanyaan berikut dari perspektif Anda sendiri:

  • Kontrol yang ingin Anda berikan: Apakah wajar bagi pelanggan Anda untuk memiliki kontrol saat pembaruan diterapkan? Jika Anda membangun solusi yang digunakan oleh pelanggan perusahaan besar, jawabannya mungkin ya. Namun, jika Anda membangun solusi yang berfokus pada konsumen, tidak mungkin Anda akan memberikan kontrol atas bagaimana Anda meningkatkan atau mengoperasikan solusi Anda.
  • Versi: Berapa banyak versi solusi yang dapat Anda pertahankan secara wajar pada satu waktu? Ingat bahwa jika Anda menemukan bug dan perlu hotfix itu, Anda mungkin perlu menerapkan hotfix untuk semua versi yang digunakan.
  • Konsekuensi dari versi lama: Apa dampak membiarkan pelanggan jatuh terlalu jauh di belakang versi saat ini? Jika Anda merilis fitur baru secara teratur, apakah versi lama akan menjadi usang dengan cepat? Juga, tergantung pada strategi pembaruan Anda dan jenis perubahan, Anda mungkin perlu mempertahankan infrastruktur terpisah untuk setiap versi solusi Anda. Jadi, mungkin ada biaya operasional dan keuangan, karena Anda mempertahankan dukungan untuk versi yang lebih lama.
  • Pembatalan: Dapatkah strategi penyebaran Anda mendukung pemutaran kembali ke versi sebelumnya? Apakah ini sesuatu yang ingin Anda aktifkan?

Catatan

Pertimbangkan apakah Anda perlu melakukan offline solusi untuk pembaruan atau pemeliharaan. Umumnya, jendela pemadaman dipandang sebagai praktik yang sudah usang, dan praktik Azure DevOps modern dan teknologi cloud memungkinkan Anda menghindari waktu henti selama pembaruan dan pemeliharaan. Namun, Anda perlu merancang untuk penyebaran waktu henti nol, jadi penting untuk mempertimbangkan proses pembaruan Anda saat Merencanakan arsitektur solusi Anda.

Bahkan jika Anda tidak merencanakan pemadaman selama proses pembaruan, Anda mungkin masih mempertimbangkan untuk menentukan jendela pemeliharaan reguler. Jendela dapat membantu berkomunikasi dengan pelanggan Anda bahwa perubahan terjadi selama waktu tertentu.

Untuk informasi selengkapnya tentang mencapai penyebaran waktu henti nol, lihat Menghilangkan waktu henti melalui pembaruan layanan versi.

Menemukan keseimbangan

Jika Anda meninggalkan irama pembaruan layanan sepenuhnya sesuai dengan kebijaksanaan penyewa Anda, mereka mungkin memilih untuk tidak pernah memperbarui. Sangat penting untuk memungkinkan diri Anda untuk memperbarui solusi, sambil mempertimbangkan masalah atau kendala yang wajar yang mungkin dimiliki pelanggan Anda. Misalnya, jika pelanggan sangat sensitif terhadap pembaruan pada hari Jumat karena itu adalah hari tersibuk mereka dalam seminggu, maka dapatkah Anda dengan mudah menukar pembaruan ke hari Senin, tanpa memengaruhi solusi Anda?

Salah satu pendekatan yang dapat bekerja dengan baik adalah dengan meluncurkan pembaruan berdasarkan penyewa per penyewa, menggunakan salah satu pendekatan yang dijelaskan di bawah ini. Berikan pemberitahuan kepada pelanggan Anda tentang pembaruan yang direncanakan. Memungkinkan pelanggan untuk sementara memilih keluar, tetapi tidak selamanya; menempatkan batas yang wajar pada saat kapan memerlukan pembaruan untuk diterapkan.

Juga, pertimbangkan untuk membiarkan kemampuan diri Anda untuk menyebarkan patch keamanan, atau hotfix kritis lainnya, dengan pemberitahuan minimal atau tanpa pemberitahuan sebelumnya.

Pendekatan lain adalah memungkinkan penyewa untuk memulai pembaruan mereka sendiri, pada saat yang mereka pilih. Sekali lagi, Anda harus memberikan tenggat waktu, pada titik mana Anda menerapkan pembaruan atas nama mereka.

Peringatan

Berhati-hatilah dalam mengaktifkan penyewa untuk memulai pembaruan mereka sendiri. Ini rumit untuk diterapkan, dan akan membutuhkan upaya pengembangan dan pengujian yang signifikan untuk menghasilkan dan memelihara.

Apa pun yang Anda lakukan, pastikan Anda memiliki proses untuk memantau kesehatan penyewa Anda, terutama sebelum dan sesudah pembaruan diterapkan. Seringkali, insiden produksi kritis (juga disebut insiden situs langsung) terjadi setelah pembaruan kode atau konfigurasi. Oleh karena itu, penting bagi Anda untuk secara proaktif memantau dan menanggapi masalah apa pun untuk mempertahankan keyakinan pelanggan. Untuk informasi selengkapnya tentang pemantauan, lihat Pemantauan untuk DevOps.

Berkomunikasi dengan pelanggan Anda

Komunikasi yang jelas adalah kunci untuk membangun keyakinan pelanggan Anda. Penting untuk menjelaskan manfaat pembaruan rutin, termasuk fitur baru, perbaikan bug, menyelesaikan kerentanan keamanan, dan peningkatan kinerja. Salah satu manfaat dari solusi cloud-hosted modern adalah pengiriman fitur dan pembaruan yang sedang berlangsung.

Pertimbangkan pertanyaan-pertanyaan berikut:

  • Apakah Anda akan memberi tahu pelanggan tentang pembaruan yang akan datang?
  • Jika Anda melakukannya, apakah Anda akan secara implisit meminta izin dengan memberikan proses penolakan, dan apa batasan untuk menolak?
  • Apakah Anda memiliki ruang pemeliharaan terjadwal yang Anda gunakan saat menerapkan pembaruan?
  • Bagaimana jika Anda memiliki pembaruan darurat, seperti patch keamanan kritis? Bisakah Anda memaksa pembaruan dalam situasi tersebut?
  • Jika Anda tidak dapat secara proaktif memberi tahu pelanggan tentang pembaruan yang akan datang, dapatkah Anda memberikan pemberitahuan retrospektif? Misalnya, dapatkah Anda memperbarui halaman di situs web Anda dengan daftar pembaruan yang telah Anda terapkan?
  • Berapa banyak versi terpisah dari sistem Anda yang akan Anda pertahankan dalam produksi?

Berkomunikasi dengan tim dukungan pelanggan Anda

Sangat penting bahwa tim dukungan Anda sendiri memiliki visibilitas penuh ke dalam pembaruan yang telah diterapkan pada setiap penyewa. Perwakilan dukungan pelanggan harus dapat dengan mudah menjawab pertanyaan-pertanyaan berikut:

  • Apakah pembaruan baru-baru ini diterapkan pada infrastruktur penyewa?
  • Apa sifat dari pembaruan tersebut?
  • Apa versi sebelumnya?
  • Seberapa sering pembaruan diterapkan pada penyewa ini?

Jika salah satu pelanggan Anda memiliki masalah karena pembaruan, Anda perlu memastikan tim dukungan pelanggan memiliki informasi yang diperlukan untuk memahami apa yang telah berubah.

Strategi penyebaran untuk mendukung pembaruan

Pertimbangkan bagaimana Anda akan menerapkan pembaruan ke infrastruktur. Hal ini sangat dipengaruhi oleh model sewa yang Anda gunakan. Tiga pendekatan umum untuk menyebarkan pembaruan adalah stempel penyebaran, bendera fitur, dan lingkaran penyebaran. Anda dapat menggunakan pendekatan ini secara independen, atau Anda dapat menggabungkannya bersama-sama untuk memenuhi persyaratan yang lebih kompleks.

Dalam semua kasus, pastikan Anda memiliki pelaporan dan visibilitas yang memadai, sehingga Anda tahu versi infrastruktur, perangkat lunak, atau fitur apa yang diaktifkan setiap penyewa, apa yang memenuhi syarat untuk dimigrasikan, dan data terkait waktu apa pun yang terkait dengan status tersebut.

Pola Stempel Penyebaran

Banyak aplikasi multipenyewa cocok untuk pola Stempel Penyebaran, di mana Anda menyebarkan beberapa salinan aplikasi Anda dan komponen lainnya. Bergantung pada persyaratan isolasi, Anda dapat menerapkan prangko untuk setiap penyewa, atau prangko bersama yang menjalankan beberapa beban kerja penyewa.

Perangko adalah cara yang bagus untuk memberikan isolasi antara penyewa. Mereka juga memberi Anda fleksibilitas untuk proses pembaruan Anda, karena Anda dapat meluncurkan pembaruan secara progresif di seluruh stempel, tanpa memengaruhi orang lain.

Gunakan bendera fitur

Bendera fitur memungkinkan Anda menambahkan fungsionalitas ke solusi Anda, sekaligus hanya mengekspos fungsionalitas tersebut ke subset pelanggan atau penyewa Anda.

Pertimbangkan untuk menggunakan bendera fitur jika salah satu situasi ini berlaku untuk Anda:

  • Anda menyebarkan pembaruan secara teratur tetapi ingin menghindari menampilkan fungsionalitas baru hingga diimplementasikan sepenuhnya.
  • Anda ingin menghindari penerapan perubahan perilaku hingga pelanggan ikut serta.

Anda dapat menyematkan dukungan bendera fitur ke dalam aplikasi dengan menulis kode Anda sendiri, atau dengan menggunakan layanan seperti Azure App Configuration.

Jaringan penyebaran

Jaringan penyebaran memungkinkan Anda untuk secara progresif meluncurkan pembaruan di satu set penyewa atau prangko penyebaran. Anda dapat menetapkan subset penyewa ke setiap jaringan.

Anda dapat menentukan berapa banyak cincin yang akan dibuat dan apa arti setiap cincin untuk solusi Anda sendiri. Biasanya, organisasi menggunakan cincin berikut:

  • Kenari: Cincin kenari mencakup penyewa pengujian Anda sendiri dan pelanggan yang ingin memiliki pembaruan segera setelah tersedia, dengan pemahaman bahwa mereka mungkin menerima pembaruan yang lebih sering, dan pembaruan tersebut mungkin belum melalui proses validasi yang komprehensif seperti di hal-hal lain.
  • Pengadopsi awal: Cincin adopsi awal berisi penyewa yang sedikit lebih averse risiko, tetapi yang masih siap untuk menerima pembaruan rutin.
  • Pengguna: Sebagian besar penyewa Anda akan menjadi milik cincin pengguna , yang menerima pembaruan yang lebih jarang dan lebih banyak diuji.

Versi API

Jika layanan Anda mengekspos API eksternal, pertimbangkan bahwa pembaruan apa pun yang Anda terapkan dapat memengaruhi cara pelanggan atau mitra berintegrasi dengan platform Anda. Secara khusus, Anda harus sadar melanggar perubahan pada API Anda. Pertimbangkan untuk menggunakan strategi pembuatan versi API untuk mengurangi risiko pembaruan api Anda.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

  • John Downs | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lain:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah selanjutnya

Pertimbangkan kapan Anda akan memetakan permintaan ke penyewa, dalam solusi multitenant.