Поділитися через

Рекомендації щодо усунення перехідних несправностей

Стосується цієї Power Platform рекомендації щодо контрольного списку Well-Architected Reliability:

RE:05 Підвищте стійкість свого робочого навантаження, впровадивши обробку помилок і тимчасову обробку несправностей. Вбудуйте в рішення можливості для обробки відмов компонентів і тимчасових помилок.

У цьому посібнику описано рекомендації щодо усунення тимчасових несправностей у ваших хмарних програмах. Усі програми, які обмінюються даними з віддаленими службами та ресурсами, повинні бути чутливими до перехідних несправностей. Це особливо актуально для програм, які працюють у хмарі, де через характер середовища та підключення через Інтернет цей тип несправності, швидше за все, стикатиметься частіше. До тимчасових несправностей належать миттєва втрата підключення до мережі до компонентів і служб, тимчасова недоступність служби та тайм-аути, які виникають, коли служба зайнята. Ці несправності часто самовиправляються, тому, якщо дія повторюється після відповідної затримки, вона, швидше за все, увінчається успіхом.

Ключові стратегії дизайну

Перехідні несправності можуть виникати в будь-якому середовищі, на будь-якій платформі або операційній системі, а також у будь-якому типі програми.

Проблеми

Тимчасові несправності можуть мати значний вплив на передбачувану доступність програми, навіть якщо вона була ретельно перевірена за всіх передбачуваних обставин. Щоб ваше Power Platform робоче навантаження могло працювати надійно, вам потрібно переконатися, що воно може реагувати на такі виклики:

  • Програма повинна мати можливість виявляти несправності при їх виникненні та визначати, чи є несправності, ймовірно, тимчасовими, тривалими або є кінцевими збоями. Різні ресурси, ймовірно, повертатимуть різні відповіді в разі виникнення несправності, і ці відповіді також можуть відрізнятися залежно від контексту операції. Наприклад, відповідь на помилку, коли програма отримує дані з користувацького з’єднувача, може відрізнятися від відповіді, коли програма використовує хмарний потік і очікує відповіді.

  • Програма повинна мати можливість повторити спробу операції, якщо вона визначить, що несправність, ймовірно, є тимчасовою.

  • У програмі має використовуватися відповідна стратегія для повторних спроб. Стратегія визначає кількість спроб спроби програми, затримку між кожною спробою та дії, які потрібно виконати після невдалої спроби. Відповідну кількість спроб і затримку між кожною з них часто важко визначити. Стратегія варіюється в залежності від типу ресурсу і від поточних умов експлуатації ресурсу і сфери застосування.

Загальні рекомендації

Наведені нижче рекомендації можуть допомогти вам розробити відповідні механізми тимчасового усунення несправностей для ваших застосувань.

Визначте, чи є вбудований механізм повторних спроб

Деякі служби, до яких ви підключаєтеся, можуть уже мати механізм тимчасової обробки несправностей. Політика повторних спроб, яку він використовує, зазвичай адаптована до характеру та вимог цільової послуги. Крім того, інтерфейси REST для служб можуть повертати інформацію, яка може допомогти вам визначити, чи доцільно повторити спробу та скільки часу потрібно чекати перед наступною спробою.

Ви повинні використовувати вбудований механізм повторної спроби, коли він доступний, якщо у вас немає конкретних і добре зрозумілих вимог, які роблять іншу поведінку повторної спроби більш прийнятною.

Визначте, чи підходить операція для повторної спроби

Виконуйте операції повторної спроби лише тоді, коли несправності є тимчасовими (зазвичай це вказується характером помилки) і коли існує принаймні деяка ймовірність того, що операція буде успішною під час повторної спроби. Немає сенсу повторно намагатися виконати неправильну операцію, наприклад, оновлювати рядок Microsoft Dataverse , який не існує або на який у користувача немає дозволу, або викликати кінцеву точку API, якої не існує.

Впроваджуйте повторні спроби лише тоді, коли ви можете визначити повний ефект від цього, а також коли умови добре зрозумілі та можуть бути перевірені. Пам’ятайте, що помилки, які повертаються з незалежних від вас ресурсів і служб, можуть змінюватися з часом, і вам, можливо, доведеться переглянути логіку виявлення перехідних несправностей.

Під час розробки окремих компонентів або служб, які викликаються з ваших програм, обов’язково повертайте коди помилок і повідомлення, які допомагають клієнтам визначити, чи слід повторно виконувати невдалі операції. Розгляньте можливість вказати, чи повинен клієнт повторно спробувати операцію; наприклад, повертаючи значення isTransient . Якщо ви створюєте веб-сервіс, розгляньте можливість повернення користувацьких помилок, визначених у ваших контрактах на обслуговування.

Визначте відповідну кількість повторних спроб та інтервал

Оптимізуйте кількість повторних спроб та інтервал відповідно до типу випадку використання. Якщо ви не спробуєте повторити достатню кількість разів, програма не зможе завершити операцію і, ймовірно, зазнає невдачі. Якщо ви повторюєте спробу занадто багато разів або з занадто коротким інтервалом між спробами, програма може утримувати ресурси протягом тривалого часу, що негативно впливає на працездатність програми.

Адаптуйте значення інтервалу часу та кількості спроб повторних спроб до типу операції. Наприклад, якщо операція є частиною взаємодії з користувачем, інтервал має бути коротким і слід виконати лише кілька спроб. Використовуючи цей підхід, ви зможете уникнути того, щоб змушувати користувачів чекати відповіді. Якщо операція є частиною тривалого або критичного робочого процесу, коли скасування та перезапуск процесу є дорогим або трудомістким, доцільно чекати довше між спробами та повторювати кілька разів.

Майте на увазі, що визначення відповідних інтервалів між повторними спробами є найскладнішою частиною розробки успішної стратегії. У типових стратегіях використовуються такі типи інтервалу повторних спроб:

  • Експоненціальний інтервал. Програма чекає короткий час перед першою спробою, а потім експоненціально збільшує час між кожною наступною спробою. Наприклад, він може повторити спробу виконати операцію через 3 секунди, 12 секунд, 30 секунд тощо.

  • Фіксовані інтервали. Програма чекає однаковий проміжок часу між кожною спробою.

  • Негайна повторна спроба. Іноді тимчасова несправність є короткочасною, і доцільно негайно повторити операцію, оскільки вона може бути успішною, якщо несправність буде усунуто протягом часу, необхідного програмі для надсилання наступного запиту. Однак ніколи не повинно бути більше однієї негайної спроби повторного спроби. Вам слід переключитися на альтернативні стратегії, як-от експоненціальні інтервали або резервні дії, якщо негайна спроба не вдається.

Як загальну рекомендацію, використовуйте стратегію експоненціального інтервалу для фонових операцій і стратегії негайного або фіксованого інтервалу повторних спроб для інтерактивних операцій. В обох випадках вам слід вибрати затримку та кількість повторних спроб таким чином, щоб максимальна затримка для всіх спроб повторних спроб була в межах необхідної наскрізної затримки.

Розглянемо комбінацію всіх факторів, які впливають на загальний максимальний тайм-аут для повторної операції. Ці фактори включають час, необхідний для отримання відповіді на невдале з’єднання, затримку між спробами повторної спроби та максимальну кількість повторних спроб. Загальна сума всіх цих зусиль може призвести до тривалого загального часу роботи, особливо якщо ви використовуєте стратегію експоненціальної затримки, коли інтервал між повторними спробами швидко зростає після кожної невдачі. Якщо процес має відповідати певній угоді про рівень обслуговування (SLA), загальний час роботи, включно з усіма тайм-аутами та затримками, має бути в межах, визначених у SLA.

Не впроваджуйте надто агресивні стратегії повторних спроб. Це стратегії, які мають занадто короткі інтервали або занадто часті повторні спроби. Вони можуть мати несприятливий вплив на цільовий ресурс або послугу. Ці стратегії можуть перешкодити ресурсу або службі відновитися з перевантаженого стану, і вони продовжуватимуть блокувати або відхиляти запити. Такий сценарій призводить до замкнутого кола, де на ресурс або сервіс надходить все більше запитів. Отже, його здатність до відновлення ще більше знижується.

Враховуйте час очікування операцій, коли ви вибираєте інтервали повторних спроб, щоб уникнути негайного запуску наступної спроби (наприклад, якщо період очікування схожий на інтервал повторної спроби).

Використовуйте тип помилки або коди помилок і повідомлення, повернуті зі служби, щоб оптимізувати кількість повторних спроб і інтервал між ними. Наприклад, деякі винятки або коди помилок (наприклад, код HTTP 503, Служба недоступна, із заголовком Повторити спробу у відповіді) можуть вказувати на тривалість помилки або на те, що служба не виконала помилку та не відповість на будь-яку подальшу спробу.

Уникнення недієвих методів

У більшості випадків уникайте реалізацій, які включають дубльовані шари коду повторних спроб. Уникайте конструкцій, які включають каскадні механізми повторних спроб або реалізують повторні спроби на кожному етапі операції, що включає ієрархію запитів, якщо у вас немає конкретних вимог для цього. У таких виняткових обставинах дотримуйтесь правил, які запобігають надмірній кількості повторних спроб і затримок, і переконайтеся, що ви розумієте наслідки. Наприклад, скажімо, один компонент робить запит до іншого, який потім звертається до цільової служби. Якщо ви запровадите повторну спробу з рахунком три на обидва дзвінки, загалом буде дев’ять спроб повторних спроб проти сервісу. У багатьох сервісах і ресурсах реалізований вбудований механізм повторних спроб. Вам слід дослідити, як ви можете вимкнути або змінити ці механізми, якщо вам потрібно реалізувати повторні спроби на більш високому рівні.

Ніколи не впроваджуйте нескінченний механізм повторних спроб. Це, швидше за все, завадить ресурсу або службі відновитися після ситуацій перевантаження та спричинить тривалішу роботу дроселювання та відмову в з’єднанні.

Ніколи не виконуйте негайну спробу повторення більше одного разу.

Уникайте використання фіксованого інтервалу повторних спроб під час доступу до служб і ресурсів Azure, особливо якщо у вас велика кількість спроб повторних спроб. Найкращим підходом у цьому сценарії є стратегія експоненціального інтервалу.

Перевірте свою стратегію та реалізацію повторних спроб

Повністю перевірте свою стратегію повторних спроб за якомога ширшого збігу обставин, особливо коли як програма, так і цільові ресурси або сервіси, які вона використовує, зазнають екстремального навантаження. Щоб перевірити поведінку під час тестування, ви можете:

  • Внесіть перехідні та неперехідні несправності в сервіс. Наприклад, надсилати невірні запити або додавати код, який виявляє тестові запити та відповідає різними типами помилок.

  • Створіть макет ресурсу або служби, який повертає діапазон помилок, які може повернути реальний сервіс. Охопіть усі типи помилок, на виявлення яких спрямована ваша стратегія повторних спроб.

  • Для користувацьких служб, які ви створюєте та розгортаєте, примусово виникайте тимчасові помилки, тимчасово вимкнувши або перевантаживши службу. (Не намагайтеся перевантажити будь-які спільні ресурси або спільні служби в Azure.)

  • Під час тестування стійкості клієнтського веб-додатку до тимчасових збоїв використовуйте інструменти розробника браузера або здатність вашого тестового фреймворку імітувати абоблокувати мережеві запити.

  • Проведіть тести з високим коефіцієнтом навантаження та паралельними тестами, щоб переконатися, що механізм повторних спроб і стратегія працюють правильно в цих умовах. Ці тести також допомагають переконатися, що повторна спроба не матиме негативного впливу на роботу клієнта та не спричинить перехресного забруднення між запитами.

Керування конфігураціями політик повторних спроб

Політика повторних спроб – це комбінація всіх елементів вашої стратегії повторного спроби. Він визначає механізм виявлення, який визначає, чи є несправність ймовірною тимчасовою, тип інтервалу, який потрібно використовувати (наприклад, фіксований або експоненціальний), фактичні значення інтервалу та кількість повторних спроб.

Скористайтеся перевагами вбудованих стратегій або стратегій повторних спроб за замовчуванням, але лише тоді, коли вони підходять для вашого сценарію. Ці стратегії, як правило, є загальними. У деяких сценаріях вони можуть бути все, що вам потрібно, але в інших сценаріях вони не пропонують повного спектру варіантів, які відповідають вашим конкретним вимогам. Щоб визначити найбільш підходящі значення, потрібно провести тестування, щоб зрозуміти, як налаштування впливають на ваш додаток.

Реєструйте та відстежуйте перехідні та неперехідні несправності

У рамках стратегії повторних спроб включіть обробку винятків та інші інструменти, які реєструють спроби повторних спроб. Випадковий перехідний збій і повторна спроба є очікуваними та не вказують на проблему. Однак регулярна та зростаюча кількість повторень часто є показником проблеми, яка може спричинити збій або погіршити продуктивність та доступність програми.

Реєструйте тимчасові несправності як попереджувальні записи, а не як записи помилок, щоб системи моніторингу не виявили їх як помилки програми, які можуть викликати помилкові сповіщення.

Розгляньте можливість збереження в записах журналу значення, яке вказує, чи викликані повторні спроби регулюванням у службі або іншими типами несправностей, наприклад помилками з’єднання, щоб ви могли розрізняти їх під час аналізу даних. Збільшення кількості помилок троттлінгу часто є показником конструктивного недоліку в додатку або необхідності додати в оточення преміальну потужність.

Розгляньте можливість впровадження системи телеметрії та моніторингу, яка може надсилати сповіщення, коли кількість і частота відмов, середня кількість спроб або загальний час, що минув до успішної операції, зростає.

Керуйте операціями, які постійно зазнають невдачі

Розглянемо, як виконувати операції, які продовжують зазнавати невдачі при кожній спробі. Такі ситуації неминучі.

Хоча стратегія повторних спроб визначає максимальну кількість спроб, яку слід повторити операцію, це не заважає програмі повторювати операцію з тією ж кількістю повторень. Наприклад, якщо ви надішлете форму в заявку, це може запустити ланцюжок. Стратегія повторної спроби може виявити тайм-аут з’єднання та вважати його тимчасовою помилкою. Потік повторить операцію вказану кількість разів, а потім здасться. Однак, коли той самий або новий користувач намагається надіслати форму знову, операція повторюється, навіть якщо вона може продовжувати завершуватися невдачею.

Додаток може періодично тестувати послугу, на періодичній основі та з великими інтервалами між запитами, щоб виявити, коли вона стає доступною. Відповідний інтервал залежить від таких факторів, як критичність роботи та характер послуги. Це може бути від кількох хвилин до кількох годин. Коли тест пройде успішно, програма може відновити нормальну роботу та передати запити до щойно відновленого сервісу.

Тим часом, можливо, вам вдасться виконати деякі альтернативні операції, сподіваючись, що служба стане доступною найближчим часом. Наприклад, може бути доцільно зберігати запити на послугу в черзі або сховищі даних і повторювати їх пізніше. Або, можливо, вам доведеться надіслати користувачу повідомлення про те, що програма недоступна.

Інші фактори, які необхідно враховувати

Визначаючи значення кількості повторних спроб і інтервалів повторних спроб для політики, враховуйте, чи є операція в службі або ресурсі частиною довготривалої або багатоетапної операції. Може бути важко або дорого компенсувати всі інші вже успішні операційні кроки, коли один з них виходить з ладу. У цьому випадку довгий інтервал і велика кількість повторних спроб можуть бути прийнятними, якщо ця стратегія не блокує інші операції, утримуючи або блокуючи обмежені ресурси.

Подумайте, чи може повторна спроба виконати ту саму операцію до невідповідності даних. Якщо деякі частини багатоетапного процесу повторюються, а операції не є ідемпотентними, можуть виникнути невідповідності. Наприклад, якщо операція з вставкою запису Microsoft Dataverse повторюється, це може призвести до неправильних значень у таблиці. Або, якщо ви повторите операцію, яка надсилає сповіщення користувачу, він може отримати дублікати повідомлень.

Розглянемо обсяг операцій, які повторюються. Наприклад, може бути простіше реалізувати код повторної спроби на рівні, який охоплює кілька операцій, і спробувати їх усі, якщо одна з них не вдається. Однак це може призвести до проблем з ідемпотентією або непотрібних операцій відкату.

Якщо ви вибрали область повторних спроб, яка охоплює кілька операцій, враховуйте загальну затримку всіх із них під час визначення інтервалів повторних спроб, під час моніторингу часу, що минув операції, і перед тим, як надсилати сповіщення про збої.

Power Platform Сприяння

У наступних розділах описано механізми, які можна використовувати для керування перехідними несправностями.

Power Automate

Power Automate Містить функцію для повторної спроби виконання дії, якщо вона не вдається. Налаштуйте це на рівні кожної дії. Дізнайтеся про зниження ризиків і планування роботи з помилками в Power Automate проекті. Power Automate Також пропонує дії для повернення користувацьких помилок і даних у додаток для дзвінків або Flow.

Деякі перехідні потоки можуть бути викликані обмеженнями пропускної здатності та запитів. Дізнайтеся про обмеження автоматизованих, запланованих та миттєвих потоків, а також про обмеження та розподіл запитів ....

Налаштуйте обробку помилок та винятків у хмарних потоках за допомогою областей дії та параметрів виконання після виконання.

Power Apps

Power Apps Програми Canvas надають можливість перевіряти стан з’єднання, що дозволяє їм поводитися по-іншому, якщо програма перебуває в автономному режимі. Дізнайтеся, як розробляти офлайн-додатки на основі полотна.

Ви також можете використовувати функції Error, IfError, IsError та IsBlankOrError у програмах на основі полотна, щоб вирішити, що робити далі, якщо виникне помилка. ...

Дізнайтеся більше про обробку тимчасових несправностей у Power Apps:

Azure та настроювані з’єднувачі

Якщо ваше робоче навантаження підключається до служб Azure, дізнайтеся, як обробляти тимчасові збої за допомогою Azure Well-Architected Framework.

Щоб керувати відповідями користувацьких конекторів на помилки, дотримуйтесь стандартів кодування.

Application Insights

Використовуйте інтеграції Application Insights для реєстрації помилок у Power Automate та Power Apps:

Безперервність бізнесу та аварійне відновлення для SaaS-програм Dynamics 365

Контрольний список надійності

Зверніться до повного зведення рекомендацій.

Контрольний список надійності