Rekomendasi untuk merancang strategi mitigasi kegagalan penyebaran

Berlaku untuk rekomendasi daftar periksa Keunggulan Operasional yang Dirancang dengan Baik ini Power Platform :

OE: 11	Terapkan strategi mitigasi kegagalan penyebaran yang mengatasi masalah peluncuran pertengahan yang tidak terduga dengan pemulihan cepat. Gabungkan beberapa pendekatan, seperti pengembalian, penonaktifan fitur, atau penggunaan kemampuan asli pola penerapan Anda.

Panduan ini menjelaskan rekomendasi untuk merancang strategi standar untuk menangani kegagalan penyebaran secara efektif. Seperti masalah beban kerja lainnya, kegagalan penyebaran adalah bagian yang tak terelakkan dari siklus hidup beban kerja. Dengan pola pikir ini, Anda dapat menjadi proaktif dengan memiliki strategi yang dirancang dengan baik dan disengaja untuk menangani kegagalan penerapan. Strategi semacam itu memungkinkan tim beban kerja Anda untuk mengurangi kegagalan secara efisien dengan dampak sesedikit mungkin pada pengguna Anda.

Tidak adanya rencana semacam itu dapat menyebabkan respons yang kacau dan berpotensi merugikan terhadap masalah, yang secara signifikan dapat memengaruhi kohesi tim dan organisasi, kepercayaan pelanggan, dan keuangan.

Strategi desain utama

Terkadang, terlepas dari kematangan praktik pengembangan Anda, masalah penyebaran terjadi. Menggunakan praktik penyebaran yang aman dan mengoperasikan rantai pasokan beban kerja yang kuat dapat membantu Anda meminimalkan frekuensi penyebaran yang gagal. Anda juga perlu merancang strategi standar untuk menangani penerapan yang gagal saat terjadi.

Strategi mitigasi kegagalan penyebaran terdiri dari lima fase besar:

1. Deteksi: Untuk merespons penyebaran yang gagal, Anda harus terlebih dahulu mendeteksi kegagalan. Deteksi dapat terjadi dalam beberapa bentuk, seperti tes asap yang gagal, laporan pengguna, atau peringatan yang dihasilkan platform pemantauan Anda.
2. Keputusan: Anda harus memutuskan strategi mitigasi terbaik untuk jenis kegagalan tertentu.
3. Mitigasi: Anda harus melakukan tindakan mitigasi yang diidentifikasi. Mitigasi dapat berupa penggantian, rollback, atau roll forward.
4. Komunikasi: Pemangku kepentingan dan pengguna yang terkena dampak harus mengetahui status saat Anda mendeteksi dan mengatasi masalah tersebut, seperti yang disyaratkan oleh rencana tanggap darurat Anda.
5. Postmortem: Postmortem tanpa kesalahan memberikan kesempatan bagi tim beban kerja untuk mengidentifikasi area yang perlu ditingkatkan dan membuat rencana untuk menerapkan pembelajaran.

Bagian berikut memberikan rekomendasi terperinci untuk fase ini.

Deteksi

Untuk mengidentifikasi masalah dengan penyebaran dengan cepat, Anda memerlukan praktik pengujian dan pemantauan yang kuat yang terkait dengan penyebaran. Untuk membantu mendeteksi anomali dengan cepat, Anda dapat melengkapi pemantauan dan pemberitahuan beban kerja Anda dengan menggunakan alat manajemen performa aplikasi dan pencatatan melalui instrumentasi.

Pengujian asap dan pengujian kualitas lainnya harus dilakukan di setiap fase peluncuran Anda. Pengujian yang berhasil dalam satu grup penyebaran seharusnya tidak memengaruhi keputusan untuk menguji di grup berikutnya.

Anda dapat menerapkan telemetri yang menghubungkan masalah pengguna dengan fase penyebaran. Kemudian, Anda dapat dengan cepat mengidentifikasi grup peluncuran yang terkait dengan pengguna tertentu. Pendekatan ini sangat penting untuk penyebaran eksposur progresif, karena Anda mungkin memiliki beberapa konfigurasi yang berjalan di seluruh basis pengguna Anda pada titik tertentu dalam penyebaran.

Anda harus siap untuk segera menanggapi masalah yang dilaporkan pengguna. Jika memungkinkan, terapkan fase peluncuran Anda selama jam kerja, saat Anda memiliki tim dukungan lengkap yang tersedia. Pastikan staf pendukung dilatih tentang cara meningkatkan masalah penerapan untuk perutean yang tepat. Eskalasi harus selaras dengan rencana tanggap darurat beban kerja Anda.

Keputusan

Memutuskan strategi mitigasi yang tepat untuk masalah penyebaran melibatkan pertimbangan faktor-faktor seperti:

• Jenis model pencahayaan progresif yang Anda gunakan. Misalnya, Anda dapat menggunakan model biru-hijau atau model kenari. Jika Anda menggunakan model biru-hijau, mundur lebih praktis daripada berguling ke belakang. Anda dapat dengan mudah mengalihkan lalu lintas kembali ke tumpukan yang menjalankan konfigurasi yang tidak diperbarui. Anda kemudian dapat memperbaiki masalah di lingkungan yang bermasalah dan mencoba penyebaran lagi pada waktu yang tepat.

• Metode yang Anda miliki untuk melewati masalah ini. Contohnya termasuk penggunaan bendera fitur, variabel lingkungan, atau jenis properti konfigurasi runtime lainnya yang dapat Anda aktifkan dan nonaktifkan. Terkadang Anda dapat dengan mudah melewati masalah dengan mematikan bendera fitur atau mengalihkan pengaturan. Dalam hal ini, Anda mungkin dapat:

  • Lanjutkan dengan peluncuran.
  • Hindari jatuh kembali.
  • Mundur saat Anda memperbaiki kode yang menyinggung.

• Tingkat upaya yang diperlukan untuk mengimplementasikan perbaikan dalam kode. Jika tingkat upaya untuk memperbaiki kode rendah, bergulir ke depan dengan menerapkan hotfix adalah pilihan yang tepat untuk skenario tertentu.

• Tingkat kekritisan untuk beban kerja yang terpengaruh. Beban kerja penting bisnis harus selalu disebarkan secara berdampingan, seperti dalam model biru-hijau, untuk mencapai penerapan tanpa waktu henti. Akibatnya, mundur adalah strategi mitigasi yang lebih disukai untuk jenis beban kerja ini.

Mitigasi

Berikut ini adalah beberapa strategi mitigasi umum:

• Rollback: Dalam skenario rollback, Anda mengembalikan sistem yang diperbarui ke status konfigurasi terakhir yang diketahui.

  Penting bagi seluruh tim beban kerja untuk menyetujui arti "kebaikan terakhir yang diketahui". Ekspresi ini mengacu pada status terakhir beban kerja yang sehat sebelum penyebaran dimulai, yang belum tentu versi aplikasi sebelumnya.

  Mengembalikan bisa jadi rumit, terutama yang berkaitan dengan perubahan data. Perubahan skema dapat membuat pengembalian berisiko. Menerapkannya dengan aman dapat membutuhkan perencanaan yang cukup besar. Sebagai rekomendasi umum, pembaruan skema harus bersifat tambahan. Catatan tidak boleh diganti dengan rekaman baru. Sebagai gantinya, rekaman lama harus tidak digunakan lagi dan harus hidup berdampingan dengan rekaman baru hingga aman untuk menghapus rekaman yang tidak digunakan lagi.

• Penggantian: Dalam skenario penggantian, sistem yang diperbarui dihapus dari perutean lalu lintas produksi. Semua lalu lintas diarahkan ke tumpukan yang tidak diperbarui. Strategi berisiko rendah ini menyediakan cara bagi Anda untuk mengatasi masalah dalam kode Anda tanpa menimbulkan gangguan lebih lanjut.

  Dengan penerapan canary, mundur mungkin tidak mudah atau bahkan memungkinkan, tergantung pada infrastruktur dan desain aplikasi Anda. Jika Anda perlu melakukan penskalaan untuk menangani beban pada sistem yang tidak diperbarui, lakukan penskalaan tersebut sebelum Anda mundur.

• Mengabaikan fungsi yang menyinggung: Jika Anda dapat mengabaikan masalah dengan menggunakan bendera fitur atau jenis properti konfigurasi runtime lainnya, Anda dapat memutuskan bahwa melanjutkan peluncuran adalah strategi yang tepat untuk suatu masalah.

  Anda harus memahami dengan jelas pengorbanan melewati fungsi, dan Anda harus dapat mengomunikasikan pengorbanan itu kepada pemangku kepentingan. Pemangku kepentingan harus menyetujui rencana ke depan. Pemangku kepentingan perlu menentukan lamanya waktu yang dapat ditoleransi untuk beroperasi dalam keadaan terdegradasi. Mereka juga perlu mempertimbangkan penentuan itu terhadap perkiraan Anda tentang waktu yang diperlukan untuk memperbaiki kode yang menyinggung dan menerapkannya.

• Penyebaran darurat (hotfix): Jika Anda dapat mengatasi masalah di tengah peluncuran, hotfix mungkin merupakan strategi mitigasi yang paling praktis.

  Seperti kode lainnya, hotfix harus melalui praktik penerapan aman Anda. Tetapi dengan hotfix, garis waktunya sangat dipercepat. Anda perlu menggunakan strategi promosi kode di seluruh lingkungan Anda. Anda juga perlu memeriksa kode hotfix di semua gerbang kualitas. Tetapi Anda mungkin perlu mempersingkat waktu pemanggangan secara dramatis, dan Anda mungkin perlu memodifikasi pengujian untuk mempercepatnya. Pastikan Anda dapat menjalankan pengujian penuh pada kode yang diperbarui sesegera mungkin setelah penerapan. Mengotomatiskan pengujian jaminan kualitas ke tingkat yang tinggi membantu membuat pengujian menjadi efisien dalam skenario ini.

Komunikasi

Penting untuk mendefinisikan tanggung jawab komunikasi dengan jelas untuk membantu meminimalkan kekacauan selama insiden. Tanggung jawab ini harus menetapkan bagaimana tim beban kerja terlibat dengan tim pendukung, pemangku kepentingan, dan personel tim tanggap darurat, seperti manajer tanggap darurat.

Standarkan irama yang diikuti tim beban kerja untuk memberikan pembaruan status. Pastikan bahwa pemangku kepentingan mengetahui standar ini sehingga mereka tahu kapan harus mengharapkan pembaruan.

Jika tim beban kerja perlu berkomunikasi langsung dengan pengguna, klarifikasi jenis informasi dan tingkat detail yang sesuai untuk dibagikan. Komunikasikan juga kepada tim beban kerja persyaratan lain yang berlaku untuk kasus ini.

Postmortem

Postmortem harus mengikuti semua penyebaran yang gagal tanpa kecuali. Setiap penerapan yang gagal adalah kesempatan untuk belajar. Postmortem dapat membantu Anda mengidentifikasi kelemahan dalam proses penerapan dan pengembangan serta kesalahan konfigurasi dalam infrastruktur Anda.

Postmortem harus selalu tidak bersalah sehingga individu yang terlibat dalam insiden merasa aman ketika mereka berbagi perspektif mereka tentang apa yang dapat ditingkatkan. Pemimpin postmortem harus menindaklanjuti dengan rencana untuk menerapkan peningkatan yang diidentifikasi dan untuk menambahkan rencana ini ke backlog beban kerja.

Pertimbangan dan rekomendasi umum

Pastikan bahwa alur penyebaran Anda dapat menerima versi yang berbeda sebagai parameter sehingga Anda dapat dengan mudah menyebarkan konfigurasi terakhir diketahui baik.

Pertahankan konsistensi dengan bidang manajemen dan data saat Anda mundur atau maju. Kunci, rahasia, data status database, dan konfigurasi yang khusus untuk sumber daya dan kebijakan semuanya harus berada dalam cakupan dan diperhitungkan. Misalnya, perhatikan desain penskalaan infrastruktur Anda dalam penyebaran terakhir yang diketahui. Tentukan apakah Anda perlu menyesuaikan konfigurasi tersebut saat menyebarkan ulang kode Anda.

Lebih suka perubahan kecil dan sering daripada perubahan besar yang jarang sehingga perbedaan antara penerapan baru dan terakhir yang diketahui baik kecil.

Lakukan analisis mode kegagalan pada alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) Anda untuk membantu mengidentifikasi masalah yang dapat mempersulit upaya mitigasi. Seperti halnya beban kerja Anda secara keseluruhan, alur Anda dapat dianalisis untuk mengidentifikasi area yang mungkin bermasalah saat Anda mencoba jenis mitigasi tertentu.

Gunakan fungsionalitas pengembalian otomatis dengan bijaksana:

• Beberapa alat CI/CD seperti memiliki Azure DevOps fungsionalitas rollback otomatis bawaan. Pertimbangkan untuk menggunakan fungsionalitas ini jika memberikan nilai nyata bagi Anda.
• Anda harus mengadopsi fungsionalitas pengembalian otomatis hanya setelah menguji alur secara menyeluruh dan teratur. Pastikan alur Anda cukup matang untuk memperkenalkan masalah tambahan jika pengembalian otomatis dipicu.
• Anda perlu percaya bahwa otomatisasi hanya menyebarkan perubahan yang diperlukan dan hanya dipicu jika diperlukan. Rancang pemicu Anda dengan hati-hati untuk memenuhi persyaratan ini.

Gunakan kemampuan yang disediakan platform selama pengembalian. Misalnya, pencadangan dan pemulihan titik waktu dapat membantu penyimpanan dan pengembalian data. Atau jika Anda menggunakan komputer virtual untuk menghosting aplikasi, akan sangat membantu untuk memulihkan lingkungan Anda ke pos pemeriksaan dari segera sebelum insiden.

Sering-seringlah menguji seluruh strategi mitigasi kegagalan penyebaran Anda. Seperti rencana tanggap darurat dan rencana pemulihan bencana, rencana kegagalan penerapan Anda hanya berhasil jika tim Anda dilatih dan mempraktikkannya secara teratur. Rekayasa kekacauan dan pengujian injeksi kesalahan dapat menjadi teknik yang efektif untuk menguji strategi mitigasi penerapan Anda.

Power Platform Fasilitasi

Pipeline Power Platform bertujuan untuk mendemokratisasi manajemen siklus hidup aplikasi (ALM) untuk Power Platform pelanggan dan Dynamics 365 dengan menghadirkan otomatisasi ALM dan kemampuan integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) ke dalam layanan.

Microsoft Power Platform Build Tools for Azure DevOps dapat digunakan untuk mengotomatiskan tugas build dan penyebaran umum yang terkait dengan aplikasi yang dibuat Power Platform.

GitHub Actions untuk Power Platform memungkinkan pengembang membangun alur kerja siklus hidup pengembangan perangkat lunak otomatis. Dengan Tindakan GitHub untuk Microsoft Power Platform, Anda dapat membuat alur kerja dalam repositori Anda untuk membuat, menguji, mengemas, merilis, dan menerapkan aplikasi; melakukan otomatisasi; serta mengelola bot dan komponen lainnya yang dibangun di Microsoft Power Platform.

ALM Accelerator adalah alat sumber terbuka yang terdiri dari serangkaian aplikasi, skrip, dan alur yang dirancang untuk mengotomatiskan proses integrasi/pengiriman berkelanjutan.

Mengotomatiskan pengujian dengan Azure Pipelines.

Gunakan Power CAT Copilot Studio Kit untuk mengonfigurasi agen dan pengujian. Dengan menjalankan pengujian individual terhadap Copilot Studio API (Direct Line), respons agen dievaluasi terhadap hasil yang diharapkan.

Variabel lingkungan dalam solusi menyimpan kunci dan nilai parameter, yang kemudian berfungsi sebagai input ke objek aplikasi lainnya. Memisahkan parameter dari objek yang mengonsumsi memungkinkan Anda mengubah nilai dalam lingkungan yang sama atau ketika Anda memigrasi solusi ke lingkungan lain.

Power Platform Lingkungan menyediakan fungsionalitas pemulihan titik waktu yang dapat membantu Anda memutar kembali.

Power Platform terintegrasi dengan Application Insights, yang merupakan bagian dari ekosistem Azure Monitor . Gunakan integrasi ini untuk:

• Terima telemetri pada diagnostik dan kinerja yang ditangkap oleh Dataverse platform di Application Insights. Anda dapat berlangganan untuk menerima telemetri tentang operasi yang dilakukan aplikasi di database Dataverse Anda dan dalam aplikasi berdasarkan model. Telemetri ini memberikan informasi yang dapat Anda gunakan untuk mendiagnosis dan memecahkan masalah yang terkait dengan kesalahan dan performa.

• Hubungkan aplikasi kanvas Anda ke. Application Insights Anda dapat menggunakan analitik ini untuk mendiagnosis masalah dan memahami apa yang dilakukan pengguna dengan aplikasi Anda. Anda dapat mengumpulkan informasi untuk membantu mendorong keputusan bisnis yang lebih baik dan meningkatkan kualitas aplikasi.

• Konfigurasikan Power Automate telemetri untuk mengalir Application Insights; misalnya, untuk memantau eksekusi alur cloud dan membuat pemberitahuan untuk kegagalan eksekusi alur cloud.

• Tangkap data telemetri dari agen Microsoft Copilot Studio Anda untuk digunakan di Azure Application Insights. Anda dapat menggunakan telemetri ini untuk memantau pesan dan peristiwa yang dicatat yang dikirim ke dan dari agen Anda, topik yang akan dipicu selama percakapan pengguna, dan peristiwa telemetri kustom yang dapat dikirim dari topik Anda.

Daftar periksa Keunggulan Operasional

Lihat rangkaian lengkap rekomendasi.

Daftar periksa Keunggulan Operasional