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

Рекомендации по обработке временных сбоев

  • Статья

Применяется к следующей рекомендации контрольного списка по достижению надежности Well-Architected в Power Platform:

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

В этом руководстве описаны рекомендации по обработке временных сбоев в ваших облачных приложениях. Все приложения, которые взаимодействуют с удаленными службами и ресурсами, должны быть чувствительны к временным сбоям. Это особенно актуально для приложений, которые работают в облаке, где из-за особенностей среды и возможности подключения через интернет ошибки такого типа могут возникать чаще. Временные сбои включают мгновенную потерю сетевого подключения к компонентам и службам, временную недоступность службы и тайм-ауты, возникающие, когда служба занята. Эти сбои часто исправляются самостоятельно, поэтому, если действие повторяется после подходящей задержки, оно, скорее всего, будет успешным.

Ключевые стратегии проектирования

Временные сбои могут возникать в любой среде, на любой платформе или операционной системе и в любом приложении.

Проблемы

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

  • Приложение должно иметь возможность обнаруживать неисправности в случае их возникновения и определять, являются ли неисправности временными, длительными или критическими. Различные ресурсы, вероятно, будут возвращать разные ответы при возникновении сбоя, и эти ответы также могут различаться в зависимости от контекста операции. Например, ответ на ошибку, когда приложение получает данные из пользовательского соединителя, может отличаться от ответа, когда приложение выполняет облачный поток и ожидает ответа.

  • Приложение должно иметь возможность повторить операцию, если оно определит, что сбой, вероятно, будет временным.

  • Приложение должно использовать соответствующую стратегию повторных попыток. Стратегия определяет количество повторных попыток приложения, задержку между каждой попыткой и действия, которые необходимо предпринять после неудачной попытки. Часто бывает трудно определить подходящее количество попыток и задержку между каждой из них. Стратегия варьируется в зависимости от типа ресурса и текущих условий эксплуатации ресурса и приложения.

Общие инструкции

Следующие инструкции помогут вам разработать подходящие механизмы обработки временных сбоев для ваших приложений.

Определите, имеется ли встроенный механизм повтора

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

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

Определите, подходит ли операция для повторной попытки

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

Реализуйте повторные попытки только тогда, когда вы можете определить их полный эффект и когда условия хорошо понятны и могут быть проверены. Помните, что ошибки, возвращаемые ресурсами и службами, находящимися вне вашего контроля, могут со временем развиваться, и вам, возможно, придется пересмотреть логику обнаружения временных сбоев.

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

Определите подходящее количество повторов и интервал времени

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

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

Имейте в виду, что определение подходящих интервалов между повторными попытками — самая сложная часть разработки успешной стратегии. Типичные стратегии используют следующие типы интервалов повторов:

  • Экспоненциальный интервал. Приложение некоторое время ждет перед первой повторной попыткой, а затем экспоненциально увеличивает время между каждой последующей повторной попыткой. Например, операция может повторяться через 3 секунды, 12 секунд, 30 секунд и т. д.

  • Фиксированные интервалы. Приложение ожидает одинаковый период времени между каждой новой попыткой.

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

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

Учитывайте комбинацию всех факторов, влияющих на общее максимальное время ожидания повторной операции. К этим факторам относятся время, необходимое для получения ответа при сбое подключения, задержка между повторными попытками и максимальное количество повторных попыток. Сумма всех этих промежутков времени может привести к увеличению общего времени работы, особенно если вы используете стратегию экспоненциальной задержки, при которой интервал между повторными попытками быстро увеличивается после каждой неудачной попытки. Если процесс должен соответствовать определенному соглашению об уровнях обслуживания (SLA), общее время работы, включая все тайм-ауты и задержки, должны находиться в пределах, определенных в этом соглашении.

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

Учитывайте время ожидания операций при выборе интервалов повтора, чтобы избежать немедленного запуска последующей попытки (например, если период ожидания аналогичен интервалу повтора).

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

Избегайте анти-шаблонов

В большинстве случаев избегайте реализаций, которые включают дублированные уровни кода повторной попытки. Избегайте проектов, включающих механизмы каскадного повтора или реализующих повтор на каждом этапе операции, включающей иерархию запросов, если только нет специальных требований к этому. В этих исключительных обстоятельствах используйте политики, предотвращающие чрезмерное количество повторных попыток и периодов задержки, и убедитесь, что вы понимаете последствия. Например, предположим, что один компонент отправляет запрос другому, который затем обращается к целевой службе. Если вы реализуете повторную попытку с количеством "три" для обоих вызовов, всего будет выполнено девять повторных попыток службы. Многие службы и ресурсы реализуют встроенный механизм повтора. Вам следует изучить, как можно отключить или изменить эти механизмы, если вам необходимо реализовать повторные попытки на более высоком уровне.

Никогда не реализуйте механизм бесконечных повторов. Это может помешать восстановлению ресурса или службы после перегрузки, а также привести к тому, что регулирование и отказы в подключениях будут продолжаться в течение более длительного времени.

Никогда не выполняйте немедленную повторную попытку более одного раза.

Избегайте использования фиксированного интервала повторных попыток при доступе к службам и ресурсам в Azure, особенно если у вас большое количество повторных попыток. Лучшим подходом в этом сценарии является стратегия экспоненциального интервала.

Проверка стратегии повторных попыток и ее реализация

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

  • Внедряйте в службу временные и устойчивые сбои. Например, отправьте недействительные запросы или добавьте код, который обнаруживает тестовые запросы и отвечает с различными типами ошибок.

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

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

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

  • Выполните тесты с высоким коэффициентом нагрузки и параллельные тесты, чтобы убедиться, что механизм и стратегия повторных попыток работают правильно в этих условиях. Эти тесты также помогают гарантировать, что повторная попытка не окажет отрицательного воздействия на работу клиента и не приведет к перекрестному загрязнению между запросами.

Управление конфигурациями политики повторов

Политика повторов — это комбинация всех элементов вашей стратегии повторных попыток. Она определяет механизм обнаружения, который определяет, будет ли сбой временным, тип используемого интервала (например, фиксированный или экспоненциальный), фактические значения интервала и количество повторных попыток.

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

Регистрируйте и отслеживайте временные и устойчивые сбои

В свою стратегию повторных попыток включите обработку исключений и другие инструменты, которые регистрируют повторные попытки. Случайные временные сбои и повторные попытки является ожидаемыми и не указывают на проблему. Однако регулярное и увеличивающееся количество повторных попыток часто является индикатором проблемы, которая может вызвать неисправность или снизить производительность и доступность приложения.

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

Рассмотрите возможность сохранения в записях журнала значения, указывающего, вызваны ли повторные попытки регулированием в службе или другими типами сбоев, например сбоями подключения, чтобы можно было различать их во время анализа данных. Увеличение количества ошибок регулирования часто является индикатором конструктивного дефекта приложения или необходимости добавить в среду емкость Premium.

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

Управляйте операциями, которые постоянно завершаются сбоем

Подумайте, как обрабатывать операции, которые продолжают завершаться сбоем при каждой попытке. Подобные ситуации неизбежны.

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

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

Тем временем вы, возможно, сможете выполнить некоторые альтернативные операции в надежде, что служба скоро станет доступна. Например, может оказаться целесообразным хранить запросы к службе в очереди или хранилище данных и повторять их позже. Или вам может потребоваться вернуть пользователю сообщение о том, что приложение недоступно.

Прочие рекомендации

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

Подумайте, может ли повторная попытка той же операции привести к несогласованности данных. Если некоторые части многоэтапного процесса повторяются и операции не являются идемпотентными, могут возникнуть несогласованности. Например, если операция вставки записи в Microsoft Dataverse повторяется, это может привести к неверным значениям в таблице. Или, если вы повторяете операцию, которая отправляет пользователю уведомление, он может получить повторяющиеся сообщения.

Учитывайте объем операций, которые повторяются. Например, может быть проще реализовать код повтора на уровне, охватывающем несколько операций, и повторять их все, если одна из них окажется завершается сбоем. Однако это может привести к проблемам идемпотентности или ненужным операциям отката.

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

Возможности в Power Platform

В следующих разделах описаны механизмы, которые можно использовать для управления временными сбоями.

Power Automate

Power Automate включает функцию повтора действия в случае сбоя. Настройте эту функцию на уровне каждого действия. Подробнее о снижении риска и планировании обработки ошибок в проекте Power Automate. Power Automate также предлагает действия для возврата пользовательских ошибок и данных в вызывающее приложение или поток.

Некоторые временные потоки могут быть вызваны ограничениями пропускной способности и запросов. Узнайте об ограничениях автоматических, запланированных и мгновенных потоков и ограничениях и распределениях запросов.

Настройте обработку ошибок и исключений в облачных потоках с помощью областей и параметров "выполнения после".

Power Apps

Приложения на основе холста в Power Apps предоставляют возможность проверять состояние подключения, что позволяет им изменять свое поведение, если приложение находится в автономном режиме. Подробнее о разработке автономных приложений на основе холста.

Вы также можете использовать функции Error, IfError, IsError и IsBlankOrError в приложениях на основе холста, чтобы определить дальнейшие шаги в случае возникновения ошибки.

Дополнительную информацию об обработке временных сбоев см. в Power Apps:

Соединители Azure и пользовательские соединители

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

Чтобы управлять ответами на ошибки пользовательского соединителя, соблюдайте стандарты кодирования.

Application Insights

Используйте интеграцию Application Insights для регистрации ошибок в Power Automate и Power Apps:

См. также

Непрерывность бизнес-процессов и аварийное восстановление для приложений Dynamics 365 SaaS

Контрольный список надежности

Обратитесь к полному набору рекомендаций.

Контрольный список надежности