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

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

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

Почему временные сбои происходят в облачных системах?

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

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

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

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

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

• Сетевые условия между клиентом и сервером часто различаются, особенно если обмен данными пересекает Интернет. Даже в локальных расположениях нагрузки с интенсивным трафиком могут замедлить обмен данными и вызвать периодические сбои подключения.

Проблемы

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

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

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

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

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

Общие рекомендации

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

Проверьте, существует ли встроенный механизм повторных попыток

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

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

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

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

Повторные задачи выполняются только в том случае, если ошибки являются временными, что характер ошибки обычно указывает, и когда операция может завершиться успешно при повторном выполнении. Для HTTP-служб код состояния 429 («Too Many Requests») и серверные ошибки 5xx являются типичными кандидатами для повторных попыток. Большинство ошибок клиента 4xx, таких как 400, 401, 403 и 404, указывают на проблемы, которые повторные попытки не устраняются. Не повторяйте задачи, которые пытаются выполнить операцию, которая не может завершиться успешно, например обновление базы данных для элемента, который не существует, или запрос к службе или ресурсу, который столкнулся с фатальной ошибкой.

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

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

Определение соответствующего количества повторных попыток и интервала

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

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

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

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

• Добавочные интервалы: Приложение ожидает некоторое время до первого повтора, а затем добавочно увеличивает время между каждой последующей повторным попыткой. Например, она может повторить операцию через 3 секунды, 7 секунд и 11 секунд.

• Регулярные интервалы: Приложение ожидает одного и того же периода времени между каждой попыткой. Например, она может повторить операцию каждые три секунды.

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

• Рандомизация: Любая из стратегий повторных попыток, перечисленных ранее, может включать рандомизацию, чтобы предотвратить ситуацию, когда несколько экземпляров клиента отправляют последующие повторные попытки одновременно. Например, один экземпляр может повторить операцию через 3 секунды, 11 секунд или 28 секунд, а другой экземпляр может повторить операцию через 4 секунды, 12 секунд или 26 секунд. Случайное использование — это полезный метод, который можно объединить с другими стратегиями.

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

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

• Время, которое требуется при неудачном подключении для получения ответа. Значение тайм-аута в настройках клиента обычно задаёт этот период.

• Задержка между повторными попытками.

• Максимальное количество повторных попыток.

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

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

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

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

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

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

Избегайте антипаттернов

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

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

Многие службы и ресурсы реализуют встроенный механизм повтора. Отключите или измените эти механизмы, если необходимо реализовать повторные попытки на более высоком уровне. Дополнительные сведения о рисках несогласованных повторных попыток см. в статье Retry Storm antipattern.

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

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

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

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

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

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

Тестирование стратегии повторений и её реализации

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

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

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

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

• Рассмотрите возможность использования службы внедрения ошибок для выполнения контролируемых экспериментов с ресурсами Azure. Например, Azure Chaos Studio поддерживает непосредственные сбои в службе, такие как добавление задержки сети или перезагрузка кластера кэша, а также сбои, зависящие от агента, например подача нагрузки на память или завершение процесса на виртуальной машине (VM). Вы можете интегрировать эксперименты по внедрению ошибок в конвейеры непрерывной интеграции и непрерывной доставки (CI/CD) для непрерывной проверки устойчивости в процессе развертывания.

• Для API на основе HTTP следует рассмотреть возможность использования библиотеки в автоматических тестах для изменения результата HTTP-запросов, либо добавлением дополнительных задержек, либо изменением ответа, например, кода состояния HTTP, заголовков, содержимого или других факторов. Этот подход позволяет детерминированно протестировать подмножество условий сбоя для временных сбоев и других типов сбоев.

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

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

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

• Может ли ошибка быть временной
• Тип интервала, используемый, например регулярный, экспоненциальный откат или случайность
• Фактические значения интервала
• Количество повторных попыток

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

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

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

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

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

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

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

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

Реализуйте систему телеметрии и мониторинга, которая вызывает оповещения при увеличении следующих метрик:

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

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

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

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

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

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

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

Другие рекомендации

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

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

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

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

Учет того, как стратегия повторных попыток влияет на соседей и других клиентов в общем приложении и при использовании общих ресурсов и служб. Агрессивные политики повторных попыток могут увеличить количество временных сбоев, возникающих для других пользователей и для приложений, использующих ресурсы и службы. Кроме того, политики повторных попыток, которые реализуют другие пользователи, могут повлиять на приложение. Для критически важных для бизнеса приложений используйте службы класса Premium, которые не являются общими. Такой подход позволяет управлять нагрузкой и следовательно регулированием ресурсов и служб, которые могут оправдать дополнительные затраты.

Следующий шаг