Bagikan melalui

Rekomendasi untuk menangani kesalahan sementara

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

RE:05 Perkuat ketahanan beban kerja Anda dengan menerapkan penanganan kesalahan dan penanganan kesalahan sementara. Bangun kemampuan ke dalam solusi untuk menangani kegagalan komponen dan kesalahan sementara.

Panduan ini menjelaskan rekomendasi untuk menangani kesalahan sementara dalam aplikasi cloud Anda. Semua aplikasi yang berkomunikasi dengan layanan dan sumber daya jarak jauh harus sensitif terhadap kesalahan sementara. Hal ini terutama berlaku untuk aplikasi yang berjalan di cloud, di mana, karena sifat lingkungan dan konektivitas melalui internet, jenis kesalahan ini kemungkinan akan lebih sering ditemui. Kesalahan sementara termasuk hilangnya konektivitas jaringan sesaat ke komponen dan layanan, ketidaktersediaan sementara layanan, dan batas waktu yang terjadi saat layanan sibuk. Kesalahan ini seringkali memperbaiki diri sendiri, jadi, jika tindakan diulang setelah penundaan yang sesuai, kemungkinan besar akan berhasil.

Strategi desain utama

Kesalahan sementara dapat terjadi di lingkungan apa pun, pada platform atau sistem operasi apa pun, dan di segala jenis aplikasi.

Tantangan

Kesalahan sementara dapat berdampak signifikan pada ketersediaan aplikasi yang dirasakan, bahkan jika telah diuji secara menyeluruh dalam semua keadaan yang dapat diperkirakan. Untuk memastikan bahwa beban kerja Anda dapat beroperasi dengan andal, Anda perlu memastikan bahwa beban kerja dapat Power Platform merespons tantangan berikut:

  • Aplikasi harus dapat mendeteksi kesalahan saat terjadi dan menentukan apakah kesalahan tersebut cenderung bersifat sementara, tahan lama, atau kegagalan terminal. Sumber daya yang berbeda cenderung mengembalikan respons yang berbeda ketika kesalahan terjadi, dan respons ini juga dapat bervariasi tergantung pada konteks operasi. Misalnya, respons untuk kesalahan saat aplikasi mengambil data dari konektor kustom mungkin berbeda dari respons saat aplikasi menjalankan alur cloud dan menunggu respons.

  • Aplikasi harus dapat mencoba kembali operasi jika menentukan bahwa kesalahan kemungkinan bersifat sementara.

  • Aplikasi harus menggunakan strategi yang sesuai untuk percobaan ulang. Strategi menentukan berapa kali aplikasi harus mencoba lagi, penundaan antara setiap upaya, dan tindakan yang harus diambil setelah upaya gagal. Jumlah percobaan yang tepat dan penundaan di antara masing-masing seringkali sulit untuk ditentukan. Strateginya bervariasi tergantung pada jenis sumber daya dan kondisi pengoperasian sumber daya dan aplikasi saat ini.

Pedoman umum

Pedoman berikut dapat membantu Anda merancang mekanisme penanganan kesalahan transien yang sesuai untuk aplikasi Anda.

Menentukan apakah ada mekanisme percobaan ulang bawaan

Beberapa layanan yang Anda sambungkan mungkin sudah menyediakan mekanisme penanganan kesalahan sementara. Kebijakan coba lagi yang digunakannya biasanya disesuaikan dengan sifat dan persyaratan layanan target. Atau, antarmuka REST untuk layanan mungkin mengembalikan informasi yang dapat membantu Anda menentukan apakah percobaan ulang sesuai dan berapa lama menunggu sebelum upaya coba lagi berikutnya.

Anda harus menggunakan mekanisme coba ulang bawaan saat tersedia, kecuali Anda memiliki persyaratan khusus dan dipahami dengan baik yang membuat perilaku coba lagi yang berbeda lebih tepat.

Tentukan apakah operasi cocok untuk dicoba lagi

Lakukan operasi coba lagi hanya ketika kesalahan bersifat sementara (biasanya ditunjukkan oleh sifat kesalahan) dan ketika setidaknya ada kemungkinan operasi akan berhasil saat dicoba ulang. Tidak ada gunanya mencoba kembali operasi yang mencoba operasi yang tidak valid, seperti memperbarui baris yang Microsoft Dataverse tidak ada atau yang pengguna tidak memiliki izin, atau memanggil titik akhir API yang tidak ada.

Terapkan percobaan ulang hanya ketika Anda dapat menentukan efek penuh dari melakukannya dan ketika kondisinya dipahami dengan baik dan dapat divalidasi. Ingatlah bahwa kesalahan yang dikembalikan dari sumber daya dan layanan di luar kendali Anda mungkin berkembang seiring waktu, dan Anda mungkin perlu meninjau kembali logika deteksi kesalahan sementara Anda.

Saat Anda mengembangkan komponen atau layanan individual yang dipanggil dari aplikasi Anda, pastikan untuk mengembalikan kode kesalahan dan pesan yang membantu klien menentukan apakah mereka harus mencoba kembali operasi yang gagal. Pertimbangkan untuk menunjukkan apakah klien harus mencoba kembali operasi; misalnya, dengan mengembalikan nilai isTransient . Jika Anda membuat layanan web, pertimbangkan untuk mengembalikan kesalahan kustom yang ditentukan dalam kontrak layanan Anda.

Menentukan jumlah dan interval percobaan ulang yang sesuai

Optimalkan jumlah percobaan ulang dan interval ke jenis kasus penggunaan. Jika Anda tidak mencoba lagi cukup kali, aplikasi tidak dapat menyelesaikan operasi dan mungkin akan gagal. Jika Anda mencoba lagi terlalu sering, atau dengan interval yang terlalu singkat di antara percobaan, aplikasi mungkin menyimpan sumber daya untuk waktu yang lama, yang berdampak buruk pada kesehatan aplikasi.

Sesuaikan nilai untuk interval waktu dan jumlah upaya coba lagi dengan jenis operasi. Misalnya, jika operasi adalah bagian dari interaksi pengguna, interval harus pendek dan hanya beberapa percobaan ulang yang harus dicoba. Dengan menggunakan pendekatan ini, Anda dapat menghindari membuat pengguna menunggu tanggapan. Jika operasi adalah bagian dari alur kerja yang berjalan lama atau kritis, di mana membatalkan dan memulai ulang proses mahal atau memakan waktu, sebaiknya tunggu lebih lama di antara upaya dan coba lagi lebih banyak kali.

Perlu diingat bahwa menentukan interval yang tepat di antara percobaan ulang adalah bagian tersulit dalam merancang strategi yang sukses. Strategi umum menggunakan jenis interval coba lagi berikut:

  • Interval eksponensial. Aplikasi menunggu sebentar sebelum percobaan ulang pertama dan kemudian meningkatkan waktu secara eksponensial di antara setiap percobaan ulang berikutnya. Misalnya, mungkin mencoba kembali operasi setelah 3 detik, 12 detik, 30 detik, dan seterusnya.

  • Interval tetap. Aplikasi menunggu periode waktu yang sama di antara setiap upaya.

  • Coba lagi segera. Terkadang kesalahan sementara bersifat singkat, dan mencoba kembali operasi segera sesuai karena mungkin berhasil jika kesalahan diselesaikan dalam waktu yang dibutuhkan aplikasi untuk mengirim permintaan berikutnya. Namun, tidak boleh ada lebih dari satu upaya coba ulang segera. Anda harus beralih ke strategi alternatif, seperti interval eksponensial atau tindakan penggantian, jika percobaan ulang segera gagal.

Sebagai pedoman umum, gunakan strategi interval eksponensial untuk operasi latar belakang, dan gunakan strategi percobaan ulang interval langsung atau tetap untuk operasi interaktif. Dalam kedua kasus tersebut, Anda harus memilih penundaan dan jumlah percobaan ulang sehingga latensi maksimum untuk semua upaya percobaan ulang berada dalam persyaratan latensi end-to-end yang diperlukan.

Pertimbangkan kombinasi semua faktor yang berkontribusi pada batas waktu maksimum keseluruhan untuk operasi yang dicoba ulang. Faktor-faktor ini termasuk waktu yang dibutuhkan koneksi yang gagal untuk menghasilkan respons, penundaan antara upaya coba ulang, dan jumlah percobaan ulang maksimum. Total dari semua waktu ini dapat menghasilkan waktu operasi keseluruhan yang lama, terutama ketika Anda menggunakan strategi penundaan eksponensial di mana interval antara percobaan ulang tumbuh dengan cepat setelah setiap kegagalan. Jika suatu proses harus memenuhi perjanjian tingkat layanan (SLA) tertentu, waktu operasi keseluruhan, termasuk semua batas waktu dan penundaan, harus berada dalam batas yang ditentukan dalam SLA.

Jangan menerapkan strategi percobaan ulang yang terlalu agresif. Ini adalah strategi yang memiliki interval yang terlalu pendek atau percobaan ulang yang terlalu sering. Mereka dapat berdampak buruk pada sumber daya atau layanan target. Strategi ini mungkin mencegah sumber daya atau layanan pulih dari status kelebihan beban, dan akan terus memblokir atau menolak permintaan. Skenario ini menghasilkan lingkaran sétan, di mana semakin banyak permintaan dikirim ke sumber daya atau layanan. Akibatnya, kemampuannya untuk pulih semakin berkurang.

Pertimbangkan batas waktu operasi saat Anda memilih interval coba lagi untuk menghindari segera meluncurkan upaya berikutnya (misalnya, jika periode batas waktu mirip dengan interval coba lagi).

Gunakan jenis kesalahan atau kode kesalahan dan pesan yang dikembalikan dari layanan untuk mengoptimalkan jumlah percobaan ulang dan interval di antara keduanya. Misalnya, beberapa pengecualian atau kode kesalahan (seperti kode HTTP 503, Layanan tidak tersedia, dengan header Retry-After dalam respons) mungkin menunjukkan berapa lama kesalahan mungkin berlangsung, atau bahwa layanan gagal dan tidak akan merespons upaya berikutnya.

Menghindari anti-pola

Dalam kebanyakan kasus, hindari implementasi yang menyertakan lapisan kode coba lagi yang diduplikasi. Hindari desain yang menyertakan mekanisme percobaan ulang berjenjang atau yang mengimplementasikan percobaan ulang di setiap tahap operasi yang melibatkan hierarki permintaan, kecuali Anda memiliki persyaratan khusus untuk melakukannya. Dalam keadaan luar biasa ini, gunakan kebijakan yang mencegah jumlah percobaan ulang dan periode penundaan yang berlebihan, dan pastikan Anda memahami konsekuensinya. Misalnya, katakanlah satu komponen membuat permintaan ke komponen lain, yang kemudian mengakses layanan target. Jika Anda menerapkan percobaan ulang dengan hitungan tiga pada kedua panggilan, total ada sembilan upaya coba ulang terhadap layanan. Banyak layanan dan sumber daya menerapkan mekanisme coba ulang bawaan. Anda harus menyelidiki bagaimana Anda dapat menonaktifkan atau memodifikasi mekanisme ini jika Anda perlu menerapkan percobaan ulang di tingkat yang lebih tinggi.

Jangan pernah menerapkan mekanisme coba lagi tanpa akhir. Melakukannya kemungkinan akan mencegah sumber daya atau layanan pulih dari situasi kelebihan beban dan menyebabkan pembatasan dan koneksi yang ditolak berlanjut untuk waktu yang lebih lama.

Jangan pernah melakukan percobaan ulang segera lebih dari sekali.

Hindari menggunakan interval coba ulang tetap saat Anda mengakses layanan dan sumber daya di Azure, terutama ketika Anda memiliki jumlah upaya coba lagi yang tinggi. Pendekatan terbaik dalam skenario ini adalah strategi interval eksponensial.

Menguji strategi dan implementasi coba lagi

Uji sepenuhnya strategi percobaan ulang Anda dalam serangkaian keadaan seluas mungkin, terutama ketika aplikasi dan sumber daya atau layanan target yang digunakannya berada di bawah beban ekstrem. Untuk memeriksa perilaku selama pengujian, Anda dapat:

  • Menyuntikkan kesalahan sementara dan non-sementara ke dalam layanan. Misalnya, kirim permintaan yang tidak valid atau tambahkan kode yang mendeteksi permintaan pengujian dan merespons dengan berbagai jenis error.

  • Buat mockup sumber daya atau layanan yang mengembalikan berbagai kesalahan yang mungkin dikembalikan oleh layanan sebenarnya. Mencakup semua jenis error yang dirancang untuk dideteksi oleh strategi percobaan ulang Anda.

  • Untuk layanan kustom yang Anda buat dan sebarkan, paksa kesalahan sementara terjadi dengan menonaktifkan atau membebani layanan untuk sementara. (Jangan mencoba membebani sumber daya bersama atau layanan bersama apa pun di Azure.)

  • Saat menguji ketahanan aplikasi web klien terhadap kesalahan sementara, gunakan alat pengembang browser atau kemampuan kerangka kerja pengujian Anda untuk menipu atau memblokir permintaan jaringan.

  • Lakukan faktor beban tinggi dan pengujian bersamaan untuk memastikan bahwa mekanisme dan strategi coba lagi berfungsi dengan benar dalam kondisi ini. Pengujian ini juga membantu memastikan bahwa percobaan ulang tidak berdampak buruk pada pengoperasian klien atau menyebabkan kontaminasi silang antar permintaan.

Mengelola konfigurasi kebijakan coba lagi

Kebijakan percobaan ulang adalah kombinasi dari semua elemen strategi percobaan ulang Anda. Ini mendefinisikan mekanisme deteksi yang menentukan apakah kesalahan cenderung bersifat sementara, jenis interval yang akan digunakan (seperti tetap atau eksponensial), nilai interval aktual, dan berapa kali untuk mencoba lagi.

Manfaatkan strategi coba ulang bawaan atau default, tetapi hanya jika strategi tersebut sesuai dengan skenario Anda. Strategi ini biasanya umum. Dalam beberapa skenario, mereka mungkin semua yang Anda butuhkan, tetapi dalam skenario lain, mereka tidak menawarkan berbagai opsi yang sesuai dengan kebutuhan spesifik Anda. Untuk menentukan nilai yang paling sesuai, Anda perlu melakukan pengujian untuk memahami bagaimana pengaturan memengaruhi aplikasi Anda.

Mencatat dan melacak kesalahan sementara dan non-sementara

Sebagai bagian dari strategi percobaan ulang Anda, sertakan penanganan pengecualian dan instrumentasi lain yang mencatat upaya percobaan ulang. Kegagalan sementara dan percobaan ulang sesekali diharapkan dan tidak menunjukkan masalah. Namun, jumlah percobaan ulang yang teratur dan meningkat sering kali merupakan indikator masalah yang dapat menyebabkan kegagalan atau yang menurunkan kinerja dan ketersediaan aplikasi.

Catat kesalahan sementara sebagai entri peringatan daripada sebagai entri kesalahan sehingga sistem pemantauan tidak mendeteksinya sebagai kesalahan aplikasi yang dapat memicu pemberitahuan palsu.

Pertimbangkan untuk menyimpan nilai dalam entri log Anda yang menunjukkan apakah percobaan ulang disebabkan oleh pembatasan dalam layanan atau oleh jenis kesalahan lainnya, seperti kegagalan koneksi, sehingga Anda dapat membedakannya selama analisis data. Peningkatan jumlah kesalahan pelambatan seringkali merupakan indikator cacat desain dalam aplikasi atau kebutuhan untuk menambahkan kapasitas premium ke lingkungan.

Pertimbangkan untuk menerapkan sistem telemetri dan pemantauan yang dapat menimbulkan peringatan ketika jumlah dan tingkat kegagalan, jumlah rata-rata percobaan ulang, atau waktu keseluruhan yang berlalu sebelum operasi berhasil meningkat.

Kelola operasi yang terus gagal

Pertimbangkan cara menangani operasi yang terus gagal di setiap upaya. Situasi seperti ini tidak bisa dihindari.

Meskipun strategi coba lagi menentukan frekuensi maksimum operasi harus dicoba ulang, strategi ini tidak mencegah aplikasi mengulangi operasi dengan jumlah percobaan yang sama. Misalnya, mengirimkan formulir di aplikasi Anda dapat memicu alur. Strategi coba lagi mungkin mendeteksi batas waktu koneksi dan menganggapnya sebagai kesalahan sementara. Alur akan mencoba kembali operasi beberapa kali tertentu dan kemudian menyerah. Namun, ketika pengguna yang sama atau pengguna baru mencoba mengirimkan formulir lagi, operasi dicoba lagi, meskipun mungkin terus gagal.

Aplikasi dapat menguji layanan secara berkala, secara terputus-putus dan dengan interval yang lama di antara permintaan, untuk mendeteksi kapan tersedia. Interval yang tepat tergantung pada faktor-faktor seperti kekritisan operasi dan sifat layanan. Mungkin antara beberapa menit dan beberapa jam. Ketika pengujian berhasil, aplikasi dapat melanjutkan operasi normal dan meneruskan permintaan ke layanan yang baru dipulihkan.

Sementara itu, Anda mungkin dapat melakukan beberapa operasi alternatif berdasarkan harapan bahwa layanan tersebut akan segera tersedia. Misalnya, mungkin tepat untuk menyimpan permintaan untuk layanan dalam antrean atau penyimpanan data dan mencobanya lagi nanti. Atau Anda mungkin harus mengembalikan pesan ke pengguna untuk menunjukkan bahwa aplikasi tidak tersedia.

Pertimbangan lain

Saat Anda memutuskan nilai untuk jumlah percobaan ulang dan interval coba lagi untuk kebijakan, pertimbangkan apakah operasi pada layanan atau sumber daya adalah bagian dari operasi yang berjalan lama atau multilangkah. Mungkin sulit atau mahal untuk mengkompensasi semua langkah operasional lain yang telah berhasil ketika salah satu gagal. Dalam hal ini, interval yang panjang dan sejumlah besar percobaan ulang mungkin dapat diterima, selama strategi tersebut tidak memblokir operasi lain dengan menahan atau mengunci sumber daya yang langka.

Pertimbangkan apakah mencoba kembali operasi yang sama dapat menyebabkan inkonsistensi dalam data. Jika beberapa bagian dari proses multilangkah diulang dan operasinya tidak idempoten, inkonsistensi mungkin terjadi. Misalnya, jika operasi yang menyisipkan rekaman diulang Microsoft Dataverse , itu mungkin menyebabkan nilai yang salah dalam tabel. Atau, jika Anda mengulangi operasi yang mengirimkan pemberitahuan ke pengguna, mereka mungkin menerima pesan duplikat.

Pertimbangkan ruang lingkup operasi yang dicoba ulang. Misalnya, mungkin lebih mudah untuk menerapkan kode coba lagi pada tingkat yang mencakup beberapa operasi dan mencoba kembali semuanya jika salah satu gagal. Namun, hal ini dapat mengakibatkan masalah idempotensi atau operasi pengembalian yang tidak perlu.

Jika Anda memilih cakupan coba lagi yang mencakup beberapa operasi, pertimbangkan latensi total dari semuanya saat Anda menentukan interval coba ulang, saat Anda memantau waktu operasi yang telah berlalu, dan sebelum Anda memunculkan pemberitahuan untuk kegagalan.

Power Platform Fasilitasi

Bagian berikut menjelaskan mekanisme yang dapat Anda gunakan untuk mengelola kesalahan sementara.

Power Automate

Power Automate menyertakan fitur untuk mencoba kembali tindakan jika gagal. Konfigurasikan ini pada tingkat per tindakan. Pelajari cara mengurangi risiko dan merencanakan penanganan kesalahan dalam Power Automate proyek. Power Automate juga menawarkan tindakan untuk mengembalikan error dan data kustom ke aplikasi atau alur panggilan.

Beberapa alur sementara dapat disebabkan oleh batas throughput dan permintaan. Pelajari tentang batas alur otomatis, terjadwal, dan instan serta batas dan alokasi permintaan.

Konfigurasikan penanganan kesalahan dan pengecualian dalam alur cloud dengan menggunakan cakupan dan pengaturan run-after.

Power Apps

Power Apps Aplikasi kanvas menyediakan kemampuan untuk memeriksa status koneksi, memungkinkannya berperilaku berbeda jika aplikasi offline. Pelajari cara mengembangkan aplikasi kanvas berkemampuan offline.

Anda juga dapat menggunakan fungsi Error, IfError, IsError, dan IsBlankOrError di aplikasi kanvas untuk memutuskan apa yang harus dilakukan selanjutnya jika terjadi kesalahan.

Pelajari lebih lanjut penanganan kesalahan sementara di: Power Apps

Azure dan konektor kustom

Jika beban kerja Anda tersambung ke layanan Azure, pelajari cara menangani kesalahan sementara menggunakan Azure Well-Architected Framework.

Untuk mengelola respons konektor kustom terhadap error, ikuti standar pengkodean.

Application Insights

Gunakan Application Insights integrasi untuk mencatat error Power Automate dan Power Apps:

Kelangsungan bisnis dan pemulihan bencana untuk aplikasi Dynamics 365 SaaS

Daftar periksa keandalan

Lihat rangkaian lengkap rekomendasi.

Daftar periksa keandalan