Rekomendasi untuk merancang strategi mitigasi kegagalan penyebaran
Berlaku untuk rekomendasi daftar periksa Azure Well-Architected Framework Operational Excellence ini:
| OE:12 | Terapkan strategi mitigasi kegagalan penyebaran yang mengatasi masalah pertengahan peluncuran yang tidak terduga dengan pemulihan yang cepat. Gabungkan beberapa pendekatan, seperti pemutaran kembali, penonaktifan fitur, atau menggunakan kemampuan asli pola penyebaran 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 tidak dapat dihindari dari siklus hidup beban kerja. Dengan pola pikir ini, Anda dapat proaktif dengan memiliki strategi yang dirancang dengan baik dan disengaja untuk menangani kegagalan penyebaran. Strategi seperti itu memungkinkan tim beban kerja Anda untuk secara efisien mengurangi kegagalan dengan dampak sesedikitan mungkin pada pengguna akhir Anda.
Tidak adanya rencana tersebut dapat menyebabkan respons yang kacau dan berpotensi merugikan terhadap masalah, yang dapat secara signifikan 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. Tetapi Anda juga perlu merancang strategi standar untuk menangani penyebaran yang gagal ketika itu terjadi.
Saat Anda menggunakan model penyebaran eksposur progresif sebagai praktik standar Anda:
- Anda memiliki fondasi yang tepat untuk meminimalkan efek pada pelanggan atau pengguna internal Anda saat penyebaran gagal.
- Anda dapat mengurangi masalah secara efisien.
Strategi mitigasi kegagalan penyebaran terdiri dari lima fase luas:
Deteksi: Untuk merespons penyebaran yang gagal, Anda harus terlebih dahulu mendeteksi kegagalan. Deteksi dapat mengambil beberapa formulir, seperti pengujian asap yang gagal, masalah yang dilaporkan pengguna, atau pemberitahuan yang dihasilkan platform pemantauan Anda.
Keputusan: Anda harus memutuskan strategi mitigasi terbaik untuk jenis kegagalan tertentu.
Mitigasi: Anda melakukan tindakan mitigasi yang diidentifikasi. Mitigasi dapat berbentuk fallback, rollback, roll forward, atau penggunaan konfigurasi runtime untuk melewati fungsi yang menyinggung.
Komunikasi: Pemangku kepentingan dan pengguna akhir yang terpengaruh harus mengetahui status saat Anda mendeteksi dan mengatasi masalah sebagaimana diperlukan oleh rencana respons darurat Anda.
Postmortem: Postmortem tanpa kesalahan memberikan peluang bagi tim beban kerja untuk mengidentifikasi area untuk perbaikan dan membuat rencana untuk menerapkan pembelajaran.
Bagian berikut memberikan rekomendasi terperinci untuk fase ini. Bagian ini mengasumsikan bahwa Anda mendeteksi masalah setelah menyebarkan perubahan ke satu atau beberapa grup pengguna atau sistem tetapi sebelum Anda memperbarui semua grup dalam paket peluncuran Anda.
Merancang mekanisme deteksi kegagalan
Untuk mengidentifikasi masalah penyebaran dengan cepat, Anda memerlukan praktik pengujian dan pengamatan yang kuat karena berkaitan dengan penyebaran. Untuk membantu mendeteksi anomali dengan cepat, Anda dapat melengkapi pemantauan dan pemberitahuan beban kerja Anda dengan mengambil langkah-langkah berikut:
- Gunakan alat manajemen performa aplikasi.
- Aktifkan pengelogan melalui instrumentasi.
Pengujian asap dan pengujian kualitas lainnya harus terjadi di setiap fase peluncuran Anda. Pengujian yang berhasil dalam satu grup penyebaran tidak boleh memengaruhi keputusan untuk diuji dalam grup berikutnya.
Anda dapat menerapkan telemetri yang menghubungkan masalah pengguna dengan fase penyebaran. Kemudian Anda dapat dengan cepat mengidentifikasi grup peluncuran mana yang terkait dengan pengguna tertentu. Pendekatan ini sangat penting untuk penyebaran paparan 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. Setiap kali praktis, sebarkan fase peluncuran Anda selama jam kerja, ketika Anda memiliki tim dukungan penuh yang tersedia. Pastikan staf dukungan dilatih tentang cara meningkatkan masalah penyebaran untuk perutean yang tepat. Eskalasi harus selaras dengan rencana respons darurat beban kerja Anda.
Memutuskan strategi mitigasi
Memutuskan strategi mitigasi yang sesuai untuk masalah penyebaran tertentu melibatkan mempertimbangkan banyak faktor, termasuk:
Jenis model eksposur progresif yang Anda gunakan. Misalnya, Anda dapat menggunakan model biru-hijau atau model kenari.
Jika Anda menggunakan model biru-hijau, mundur lebih praktis daripada menggulung balik. 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 Anda lagi pada waktu yang tepat.
Metode yang Anda miliki untuk melewati masalah. 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 menonaktifkan bendera fitur atau beralih ke pengaturan. Dalam hal ini, Anda mungkin dapat:
- Lanjutkan dengan peluncuran.
- Hindari mundur.
- Gulung balik saat Anda memperbaiki kode yang menyinggung.
Tingkat upaya yang diperlukan untuk menerapkan perbaikan dalam kode.
Jika tingkat upaya untuk memperbaiki kode rendah, bergulir ke depan dengan menerapkan perbaikan panas adalah pilihan yang tepat untuk skenario tertentu.
Tingkat kekritisan untuk beban kerja yang terpengaruh.
Beban kerja yang penting bagi bisnis harus selalu disebarkan secara berdampingan, seperti dalam model biru-hijau, untuk mencapai penyebaran nol waktu henti. Akibatnya, mundur adalah strategi mitigasi yang lebih disukai untuk jenis beban kerja ini.
Jenis infrastruktur yang digunakan beban kerja—dapat diubah atau tidak dapat diubah.
Jika beban kerja Anda dirancang untuk menggunakan infrastruktur yang dapat diubah, rolling forward dapat masuk akal, karena melibatkan pembaruan infrastruktur di tempat. Sebaliknya, menggulung balik atau mundur dapat masuk akal ketika Anda menggunakan infrastruktur yang tidak dapat diubah.
Apa pun pilihan yang Anda buat, Anda harus menyertakan persetujuan yang sesuai dalam proses pengambilan keputusan Anda dan mengkodifikasinya di pohon keputusan Anda.
Menerapkan strategi mitigasi
Pembatalan: Dalam skenario putar kembali, Anda mengembalikan sistem yang diperbarui ke status konfigurasi terakhir yang diketahui baik.
Penting bagi seluruh tim beban kerja untuk menyetujui arti dari kebaikan terakhir yang diketahui. Ekspresi ini mengacu pada status terakhir beban kerja yang sehat sebelum penyebaran dimulai, yang belum tentu merupakan versi aplikasi sebelumnya.
Menggulung balik bisa menjadi kompleks, terutama karena berkaitan dengan perubahan data. Perubahan skema dapat membuat rolling back riskan. Menerapkannya dengan aman dapat memerlukan perencanaan yang cukup besar. Sebagai rekomendasi umum, pembaruan skema harus aditif. Tidak boleh berupa perubahan penggantian—rekaman tidak boleh diganti dengan rekaman baru. Sebagai gantinya, rekaman lama harus tidak digunakan lagi dan harus hidup berdampingan dengan rekaman baru sampai aman untuk menghapus rekaman yang tidak digunakan lagi.
Fallback: Dalam skenario fallback, 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 penyebaran kenari, mundur mungkin tidak mudah atau bahkan mungkin, tergantung pada infrastruktur dan desain aplikasi Anda. Jika Anda perlu melakukan penskalakan untuk menangani beban pada sistem yang tidak diperbarui, lakukan penskalan tersebut sebelum Anda mundur.
Melewati fungsi yang menyinggung: Jika Anda dapat melewati masalah dengan menggunakan bendera fitur atau jenis properti konfigurasi runtime lainnya, Anda dapat memutuskan bahwa melanjutkan peluncuran adalah strategi yang tepat untuk masalah tertentu.
Anda harus memahami dengan jelas tradeoff melewati fungsi, dan Anda harus dapat mengomunikasikan tradeoff itu kepada pemangku kepentingan. Pemangku kepentingan harus menyetujui rencana maju. Pemangku kepentingan perlu menentukan lamanya waktu yang dapat ditoleransi untuk beroperasi dalam keadaan terdegradasi. Mereka juga perlu menimbang tekad itu terhadap perkiraan waktu yang diperlukan untuk memperbaiki kode yang menyinggung dan menyebarkannya.
Penyebaran darurat (perbaikan panas): Jika Anda dapat mengatasi masalah pertengahan peluncuran, perbaikan panas mungkin merupakan strategi mitigasi yang paling praktis.
Seperti kode lainnya, perbaikan panas harus melalui praktik penyebaran Anda yang aman. Tetapi dengan perbaikan panas, garis waktu jauh dipercepat. Anda perlu menggunakan strategi promosi kode di seluruh lingkungan Anda. Anda juga perlu memeriksa kode perbaikan panas di semua gerbang kualitas. Tetapi Anda mungkin perlu secara dramatis mempersingkat waktu kue, dan Anda mungkin perlu memodifikasi tes untuk mempercepatnya. Pastikan Anda dapat menjalankan pengujian penuh pada kode yang diperbarui sesegera mungkin setelah penyebaran. Mengotomatiskan pengujian jaminan kualitas ke tingkat tinggi membantu membuat pengujian efisien dalam skenario ini.
Tradeoffs:
- Mampu mundur biasanya berarti Anda memerlukan kapasitas infrastruktur yang memadai untuk menangani dua versi konfigurasi beban kerja Anda secara bersamaan. Tim beban kerja Anda juga harus dapat mendukung dua versi dalam produksi secara bersamaan.
- Mampu menggulung balik secara efektif mungkin melibatkan elemen refaktor beban kerja Anda. Misalnya, Anda mungkin perlu memisahkan fungsi atau mengubah model data Anda.
Menstandarkan pembaruan status selama insiden
Penting untuk memiliki tanggung jawab komunikasi yang jelas untuk membantu meminimalkan kekacauan selama insiden. Tanggung jawab ini harus menetapkan bagaimana tim beban kerja terlibat dengan tim dukungan, pemangku kepentingan, dan personel tim respons darurat, seperti manajer respons 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 akhir, klarifikasi jenis informasi dan tingkat detail yang sesuai untuk dibagikan dengan pengguna. Juga berkomunikasi dengan tim beban kerja persyaratan lain yang berlaku untuk kasus-kasus ini.
Melakukan pascamortem insiden
Postmortem harus mengikuti semua penyebaran yang gagal, tanpa pengecualian. Setiap penyebaran yang gagal adalah kesempatan untuk belajar. Postmortem dapat membantu Anda mengidentifikasi kelemahan dalam proses penyebaran dan pengembangan Anda. Anda juga dapat mengidentifikasi kesalahan konfigurasi dalam infrastruktur Anda, di antara banyak kemungkinan lainnya.
Postmortem harus selalu tidak disalahkan sehingga individu yang terlibat dalam insiden merasa aman ketika mereka berbagi perspektif mereka tentang apa yang dapat ditingkatkan. Pemimpin pascamortem harus menindaklanjuti dengan rencana untuk menerapkan perbaikan yang telah diidentifikasi dan menambahkan rencana ini ke backlog beban kerja.
Mengoprasialisasi proses mitigasi
Pastikan bahwa alur penyebaran Anda dapat menerima versi yang berbeda sebagai parameter sehingga Anda dapat dengan mudah menyebarkan konfigurasi terakhir yang diketahui baik.
Pertahankan konsistensi dengan manajemen dan bidang data saat Anda menggulung balik atau melakukan roll forward. Kunci, rahasia, data status database, dan konfigurasi yang khusus untuk sumber daya dan kebijakan semuanya perlu berada dalam cakupan dan diperhitungkan. Misalnya, perhatikan desain penskalaan infrastruktur Anda dalam penyebaran terakhir anda yang dikenal baik. Tentukan apakah Anda perlu menyesuaikan konfigurasi tersebut saat menyebarkan ulang kode Anda.
Lebih suka perubahan kecil dan sering dibandingkan perubahan besar yang jarang terjadi sehingga delta antara penyebaran baru dan terakhir yang diketahui-baik kecil.
Lakukan analisis mode kegagalan (FMA) pada alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) Anda untuk membantu mengidentifikasi masalah yang dapat mempersulit mitigasi. Seperti beban kerja Anda secara keseluruhan, alur Anda dapat dianalisis untuk mengidentifikasi area yang mungkin bermasalah saat Anda mencoba jenis mitigasi tertentu.
Gunakan fungsionalitas putar kembali otomatis secara yudisius:
- Beberapa alat CI/CD seperti Azure DevOps memiliki fungsionalitas putar kembali otomatis yang bawaan. Pertimbangkan untuk menggunakan fungsionalitas ini jika memberikan nilai nyata kepada Anda.
- Anda harus mengadopsi fungsionalitas pemutaran kembali otomatis hanya setelah menguji alur Anda secara menyeluruh dan teratur. Pastikan alur Anda cukup matang untuk memperkenalkan masalah tambahan jika pemutaran kembali otomatis dipicu.
- Anda perlu mempercayai 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 pemutaran kembali. Misalnya, pencadangan dan pemulihan point-in-time dapat membantu penyimpanan dan pembatalan data. Atau jika Anda menggunakan komputer virtual (VM) untuk menghosting aplikasi Anda, akan sangat membantu untuk memulihkan lingkungan Anda ke titik pemeriksaan yang segera sebelum insiden.
Uji seluruh strategi mitigasi kegagalan penyebaran Anda secara sering. Seperti rencana respons darurat dan rencana pemulihan bencana, rencana kegagalan penyebaran Anda hanya berhasil jika tim Anda dilatih dan mempraktikkannya secara teratur. Rekayasa chaos dan pengujian injeksi kesalahan dapat menjadi teknik yang efektif untuk menguji strategi mitigasi penyebaran Anda.
Fasilitasi Azure
Azure Pipelines menyediakan layanan build dan rilis untuk mendukung CI/CD aplikasi Anda.
Azure Test Plans adalah solusi manajemen pengujian berbasis browser yang mudah digunakan. Solusi ini menawarkan kemampuan yang diperlukan untuk pengujian manual terencana, pengujian penerimaan pengguna, dan pengujian eksplorasi. Azure Test Plans juga menyediakan cara bagi Anda untuk mengumpulkan umpan balik dari pemangku kepentingan.
Azure Monitor adalah solusi pemantauan komprehensif untuk mengumpulkan, menganalisis, dan merespons data pemantauan dari lingkungan cloud dan lokal Anda. Monitor menyertakan platform pemberitahuan yang kuat. Anda dapat mengonfigurasi sistem tersebut untuk pemberitahuan otomatis dan tindakan lainnya, seperti penskalaan otomatis dan mekanisme penyembuhan diri lainnya.
Application Insights adalah ekstensi Monitor yang menyediakan fitur pemantauan performa aplikasi (APM).
Azure Logic Apps adalah platform berbasis cloud untuk menjalankan alur kerja otomatis yang mengintegrasikan aplikasi, data, layanan, dan sistem. Anda dapat menggunakan Logic Apps untuk membuat versi baru aplikasi Anda setiap kali pembaruan dibuat untuk aplikasi tersebut. Azure mempertahankan riwayat versi dan dapat mengembalikan atau mempromosikan versi sebelumnya.
Banyak layanan database Azure menyediakan fungsionalitas pemulihan point-in-time yang dapat membantu Anda saat Anda perlu mengembalikan:
Pratinjau Azure Chaos Studio adalah layanan terkelola yang menggunakan rekayasa chaos untuk membantu Anda mengukur, memahami, dan meningkatkan ketahanan aplikasi dan layanan cloud Anda.
Tautan terkait
- Eksperimen progresif dengan bendera fitur
- Rekomendasi untuk merancang dan membuat kerangka kerja pengamatan
- Rekomendasi untuk merancang strategi respons darurat
- Rekomendasi untuk merancang strategi pengujian keandalan
- Rekomendasi untuk merancang rantai pasokan pengembangan beban kerja
- Rekomendasi untuk melakukan analisis mode kegagalan
- Rekomendasi untuk praktik penyebaran yang aman
Daftar periksa Keunggulan Operasional
Lihat kumpulan rekomendasi lengkap.