Обработка ошибок и повторные попытки в Power Automate — как не пропустить остановку потока

«Поток агрегации, который шёл каждое утро, на самом деле стоял с прошлой недели». «Поток регистрации заказов обработал те же данные дважды, и в реестре появились дубликаты». Такие обращения часто приходят от компаний, которые уже построили поток в Power Automate и начали его эксплуатировать. Собрать было легко, а то, что он остановился, никто не заметил — типичная картина.

Если ограничиться штатным сценарием, поток Power Automate можно заставить работать за несколько часов. Но подключённые службы временно падают, аутентификация истекает, а данные вне ожидаемого формата рано или поздно появятся. Поток, в котором не спроектировано «что происходит при сбое», молча копит ошибки и в худшем случае автоматически отключается через 14 дней¹. В этой статье собраны приёмы обработки ошибок, которые выдерживают продакшен: классификация сбоев, точная спецификация стандартного повтора, паттерн Try-Catch-Finally на областях, как заметить сбой, повторный запуск и идемпотентность. Общий выбор по Power Automate и обработка ошибок на стороне автоматизации UI (потока рабочего стола) разобраны в статье «Автоматизация бизнес-процессов в Power Automate — выбор между облачным потоком и потоком рабочего стола, проектирование обработки ошибок», поэтому здесь углубляемся только в облачные потоки.

1. Сначала вывод

• Сбои стоит делить на четыре типа: временный сбой, сбой из-за данных, истечение прав или аутентификации, изменение спецификации. Стандартный повтор закрывает только первый; для остальных трёх нужны обнаружение и исправление².
• Стандартная политика повтора срабатывает только если запрос завершился тайм-аутом или сбоем с ответом 408, 429 либо 5xx. По умолчанию это экспоненциальная задержка, а число попыток зависит от уровня лицензии (профиля производительности) — максимум 2 или 12³¹.
• Базовая форма обработки ошибок — Try-Catch-Finally через области (Scope) и параметр «Выполнить после». В «Выполнить после» выбирают одно из четырёх состояний: успех, сбой, пропуск, тайм-аут³⁴. В русском интерфейсе функция называется «Выполнить после», в английском интерфейсе и в документации — run after. Дальше в статье используем название «Выполнить после».
• Обработав сбой в Catch, в конце зафиксируйте выполнение как Failed действием Terminate. Если этого не сделать, в журнале выполнения будет успех, и сбой окажется скрыт⁴³.
• Штатное письмо о сбое приходит только для ошибок с известным способом исправления и после этого молчит 28 дней. На него нельзя опираться целиком. Собственное уведомление из блока Catch считайте обязательным⁵.
• Журнал выполнения по умолчанию виден только за 28 дней. Поток, который продолжает сбоить, автоматически отключается через 14 дней. Заметить остановку спустя месяц — нормальная ситуация по спецификации⁶¹.
• На повторный запуск (повторную отправку) и двойной старт сразу закладывайте идемпотентный дизайн, безопасный при повторном выполнении (флаг обработки, upsert вместо создания, условия триггера)⁷⁸.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 22, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Как отказывает поток — четыре типа сбоев

Проектировать обработку ошибок проще, если начать с классификации: «как именно происходит сбой». Рекомендации Microsoft тоже исходят из того, что автоматизация когда-нибудь откажет, и требуют заранее закладывать обслуживание подключённой службы, изменение API, смену пароля и кратковременные сетевые сбои². На практике эти четыре типа сразу подсказывают, что делать.

На практике самый неприятный тип — истечение прав или аутентификации: отказывают не только действия потока, но и сам триггер. В официальном руководстве по устранению неполадок типичный сбой триггера с ошибкой класса 4xx — смена (истечение) пароля, которым было создано подключение. Если триггер отказывает, поток вообще не запускается, в журнале выполнения нет даже строки Failed, и проблему замечают ещё позже⁹. Подключение привязано к пользователю, который его создал, поэтому увольнение или перевод сотрудника может оборвать сразу пачку подключений. Организационные меры на этот случай подробно разобраны в статье «Как снизить зависимость Power Automate от одного человека — чтобы поток не остановился, когда автор уйдёт».

Ещё одно, что стоит знать: если сбои игнорировать, отключат сам поток. Поток, у которого триггер или действия продолжают отказывать, автоматически выключается через 14 дней; поток, который постоянно регулируют, тоже выключается через 14 дней. Поток, который 90 дней не срабатывал, тоже могут отключить (если владелец не на премиум-лицензии или лицензии на ёмкость)¹. Кроме того, из-за нарушения политики DLP (Data Loss Prevention — предотвращение потери данных. Администратор ограничивает, какие соединители можно использовать и в каких сочетаниях, чтобы данные организации не ушли наружу. Текущее официальное название — «политики данных»)¹⁰ или из-за повторяющихся сбоев поток может оказаться в состоянии «приостановлен» (suspended)¹¹. Изменение политики DLP применяется сразу и без предупреждения останавливает потоки, поэтому если сломалось сразу несколько потоков, первым делом стоит проверить, не меняли ли политику¹¹. Часть случаев «работавший поток вдруг остановился» — не авария, а именно эта спецификация.

3. Как устроен стандартный повтор

В каждое действие Power Automate (в основе — Azure Logic Apps) политика повтора уже встроена. Если знать спецификацию точно, можно решить, добавлять ли свои настройки повтора и поможет ли повтор вообще.

Что и когда повторяется

Политика повтора срабатывает, когда запрос действия (или триггера) завершился тайм-аутом либо сбоем с ответом 408 (тайм-аут запроса), 429 (слишком много запросов = регулирование) или 5xx (ошибка сервера)³. Политика по умолчанию — экспоненциальная задержка (повтор с растущим интервалом). Число попыток и интервал по умолчанию в Power Automate зависят от профиля производительности потока (по сути — от уровня лицензии)¹.

То есть при одном и том же определении потока «устойчивость к временным сбоям» зависит от лицензии владельца. Профиль влияет не только на число повторов, но и на суточный лимит запросов, поэтому уровень лицензии — полноценный фактор проектирования; подробнее — в статье «Лицензии Power Automate и граница между стандартными и премиум-соединителями».

Политику повтора можно сменить в параметрах действия. Типов четыре: по умолчанию, нет, фиксированный интервал, экспоненциальный интервал — число попыток и интервал задаются явно. Верхние границы: 90 попыток, минимальный интервал 5 секунд, максимальная задержка 1 день³¹. В рекомендациях Microsoft по коду для восстановления после временного сбоя советуют экспоненциальный интервал, а не фиксированный: так вы не долбите получателя коротким интервалом и не мешаете ему восстановиться⁴.

Что повтор устраняет, а что нет

Отдельно: повтор тоже расходует лимит запросов (Power Platform requests). Каждое выполнение действия считается в лимит независимо от успеха или неудачи; то же верно для запросов повтора и разбиения на страницы¹. Наращивать число попыток в ответ на 429 иногда только усиливает регулирование, поэтому прежде чем увеличивать число повторов, проверьте, нельзя ли сократить сами вызовы.

4. Паттерн Try-Catch-Finally — области и «Выполнить после»

Сбой, который повтор не чинит, перехватывают внутри потока. Синтаксиса try-catch в Power Automate нет, но ту же структуру собирают из области (Scope) и «Выполнить после» (в английском интерфейсе — run after). Это стандартный приём и в рекомендациях Microsoft по коду⁴.

Основа механизма — «Выполнить после». По завершении каждое действие получает одно из состояний: успех (Succeeded), сбой (Failed), пропуск (Skipped) или тайм-аут (TimedOut); следующее действие по умолчанию выполняется только «если предыдущее завершилось успехом». Условие можно сменить для каждого действия и получить ветку, которая выполняется «при сбое» или «при тайм-ауте»³.

Где это искать, с первого раза обычно не видно. В конструкторе откройте меню «…» (три точки) у нужного действия или области и выберите «Выполнить после» — появится панель с флажками четырёх состояний для каждого предыдущего действия¹¹. Отметьте нужные состояния. Один нюанс: должен быть выбран хотя бы один флажок, поэтому снимать установленный по умолчанию «при успехе» можно только после того, как отметили другое состояние³. «Выполнить после» не ограничено «одним предыдущим действием»: можно указать несколько предшествующих действий и назначить каждому своё состояние³.

Если применить это к области, получается Try-Catch-Finally. Область сводит результаты всех вложенных действий в одно общее состояние, поэтому конструкция «если что-то внутри области Try отказало, выполнить область Catch» гораздо проще в поддержке, чем настраивать условие вокруг каждого действия³⁴.

flowchart TD
    accTitle: Паттерн Try-Catch-Finally в облачном потоке Power Automate
    accDescr: Схема показывает, как область Try передаёт управление в Catch при сбое или тайм-ауте, затем Finally выполняет завершающие действия, после чего при сбое срабатывает Terminate.
    Trigger[Триггер] --> Try[[Область Try<br/>сюда собираем основную обработку]]
    Try -- Успех --> Fin
    Try -- Сбой / тайм-аут --> Catch[[Область Catch<br/>«Выполнить после»: сбой и тайм-аут]]
    Catch --> Extract[Функция result + Фильтр массива:<br/>извлечь сбойные действия и причину]
    Extract --> Notify[Уведомить ответственного в Teams / по почте<br/>имя потока, сбойный шаг, детали ошибки, URL выполнения]
    Notify --> Fin[[Область Finally<br/>«Выполнить после»: успех, сбой, пропуск, тайм-аут — все]]
    Fin --> Cleanup[Завершающие действия: обновить столбец статуса в реестре]
    Cleanup --> Judge{Прошли через Catch?}
    Judge -- Да --> Term[Terminate<br/>состояние: Failed, завершить выполнение]
    Judge -- Нет --> Done([Нормальное завершение])

Четыре практических правила сборки.

• В «Выполнить после» у области Catch отметьте и «при сбое», и «при тайм-ауте». Флажок по умолчанию «при успехе» снимите. Если оставить только сбой, тайм-аут ожидания согласования или отложенного действия проскочит незамеченным³.
• В Catch достаньте содержимое сбоя. Функция result('ИмяОбластиTry') возвращает массив результатов действий непосредственно внутри области (состояние, входы и выходы, текст ошибки). Действием Фильтр массива (Filter array) оставьте только элементы со статусом Failed или TimedOut — и в уведомление можно положить имя сбойного действия и текст ошибки³⁴. Если фильтровать только по Failed, при входе в Catch через тайм-аут выборка будет пустой, и из уведомления выпадет как раз тот шаг, который нужен. Заодно возьмите идентификатор выполнения из функции workflow() и соберите прямую ссылку на журнал выполнения — расследование сразу проще (выражения — в следующем подразделе)⁴.
• В «Выполнить после» у области Finally отметьте все четыре состояния. Сюда кладут завершающие действия, которые должны выполниться и при успехе, и при сбое: удаление временных файлов, обновление столбца статуса в реестре и т. п.
• Неудачное выполнение в конце завершайте действием Terminate со статусом Failed. Это чаще всего забывают. Если Catch отработал штатно, выполнение потока в целом заканчивается успехом последнего действия, и в журнале это записывается как Succeeded. То есть одно только уведомление прячет сбой от мониторинга и последующей статистики. Если завершить выполнение через Terminate, задав статус Failed и сообщение об ошибке, в журнале останется сбой⁴³. Но не ставьте Terminate прямо в конец области Catch. Terminate немедленно останавливает всё выполнение, поэтому следующая область Finally не запустится, и завершающие действия, особенно нужные при ошибке, будут пропущены. Как на схеме: в Catch только выставьте флаг сбоя (переменную) и отправьте уведомление, после завершающих действий в Finally проверьте флаг и вызывайте Terminate только при сбое.

«Выполнить после» — ещё и центральная деталь ветвления по тайм-ауту в потоке согласования (напоминания, эскалация). Как это собирать, разобрано в статье «Как собрать поток согласования в Power Automate — перевод бумажных и почтовых заявок в электронный вид».

Содержимое Catch — как выражением достать сбойное действие и URL выполнения

Это ключевой момент реализации, поэтому ниже сами выражения. Если область Try называется Try, действие Фильтр массива настраивается так. Условие пишите напрямую, переключившись в «изменить в расширенном режиме»³⁴.

From:  @result('Try')
Условие (расширенный режим): @or(equals(item()['status'], 'Failed'), equals(item()['status'], 'TimedOut'))

Из каждого элемента, который возвращает result(), можно взять следующие значения. Если в текст уведомления положить эти четыре поля, ещё до открытия журнала выполнения уже понятно, куда смотреть³.

Прямую ссылку на журнал выполнения собирают из функции workflow(). Функция возвращает объект с идентификатором потока (name), именем среды (tags.environmentName), логическим именем потока (tags.logicAppName), идентификатором выполнения (run.name) и другими полями; URL получается такого вида⁴.

concat('https://make.powerautomate.com/environments/', workflow()?['tags']?['environmentName'],
       '/flows/', workflow()?['tags']?['logicAppName'],
       '/runs/', workflow()?['run']?['name'])

В официальной документации URL собирают иначе: сначала разбирают вывод workflow() действием Анализ JSON (Parse JSON), затем собирают строку действием Создание (Compose)⁴. Результат тот же, но URL портала может измениться, поэтому сразу после сборки один раз откройте получившуюся ссылку и убедитесь, что открывается нужная запись журнала. Та же документация предупреждает: слишком много собственной журнализации раздувает число действий и время выполнения и даёт обратный эффект⁴. На практике в уведомление достаточно четырёх пунктов: имя потока, сбойное действие, ошибка, URL выполнения.

5. Как заметить сбой — уведомления и наблюдаемость

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

Что на самом деле делает штатное письмо о сбое

В Power Automate есть отправка письма при сбое, но если опираться на неё, не зная спецификации, дыр окажется много. Уведомлений два вида⁵.

• Оповещение о сбое на уровне выполнения: уходит сразу после сбоя выполнения, но только если сбой признан «известным и имеющим способ исправления» — разрыв подключения, регулирование, известная ошибка соединителя и т. п. При обычном сбое действия письмо не отправляется. Получатели — владелец и совладельцы (пользователи только с правом запуска не входят), администраторам оно не приходит. После одного такого письма для того же потока действует пауза 28 дней: за новые сбои в этот период дополнительные оповещения не приходят. Оповещения на уровне выполнения к тому же включены по умолчанию не во всех потоках — это нужно проверить в параметрах потока⁵.
• Еженедельный дайджест сбоев: раз в неделю приходит сводка сбоев по средам. В неё попадают и обычные сбои, за которые оповещение на уровне выполнения не уходило⁵.

Кроме того, по отдельным ошибкам владельцу приходит письмо с «подсказками по исправлению» и шагами восстановления (его можно отключить для каждого потока)⁷. Итого: штатное уведомление позволяет заметить первый разрыв подключения, но легко пропускает сбои из-за бизнес-данных и повторные сбои. Для важных потоков считайте собственное уведомление из блока Catch (глава 4) обязательным.

Уведомление из Catch — когда отказывает сам путь уведомления

У собственного уведомления тоже есть свои правила.

• Не адресуйте его конкретному человеку. Письмо лично ответственному перестаёт доходить в отпуск и после увольнения. Официальная документация рекомендует общий почтовый ящик или канал Teams¹¹.
• Отделите путь уведомления от основной обработки. Типичная авария: «подключение Outlook оборвалось, поток отказал, а уведомление о сбое тоже не уходит, потому что использует то же подключение Outlook». Если причина сбоя — истечение аутентификации, действие уведомления на том же подключении падает вместе с основной обработкой. Для уведомления возьмите другой соединитель и другое подключение (например, сообщение в Teams) или вынесите его в отдельный маленький поток уведомлений — риск совместного отказа снизится. «Уведомление об уведомлении» до бесконечности не построить, поэтому последним рубежом остаётся регулярная проверка ниже.
• Кладите в уведомление всё, что нужно для разбора. Имя потока, имя сбойного действия, текст ошибки, прямую ссылку на журнал выполнения. Без этого приходит только «что-то сломалось», и письмо легко игнорируют⁴.

Наблюдаемость и регулярная проверка

• Средство проверки потока (Flow checker): до сохранения находит ошибки и предупреждения в определении потока. После того как поток собран, прогоните проверку хотя бы один раз¹².
• Регулярная проверка журнала выполнения: журнал выполнения потока по умолчанию показывают только за 28 дней⁶. У потока в составе решения (solution) метаданные журнала можно хранить в Dataverse, но и там срок хранения по умолчанию — 28 дней, а продление — настройка администратора¹³. Для боевых потоков примерно раз в неделю стоит смотреть не только сбои, но и «выполнения в состоянии отмены» (иногда из-за контроля параллелизма) и «резкое падение числа выполнений» (признак, что триггер перестал срабатывать)¹¹.
• Централизованный мониторинг администратора: чтобы видеть все сбои, включая те, за которые нет оповещения на уровне выполнения, самый полный вариант — Monitor (мониторинг) в центре администрирования Power Platform. Можно смотреть число сбоев и детали ошибок по потоку или по среде⁵.

У регулярного потока нужен ещё и контроль «вообще ли он стартовал». Проектирование регулярного запуска с учётом рабочих дней и обработки конца месяца разобрано в статье «Регулярные потоки Power Automate и расчёт рабочих дней».

6. Повторный запуск и идемпотентность — «не ломается даже при двойном выполнении»

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

Спецификация повторной отправки (Resubmit)

Неудачное выполнение можно запустить заново из журнала выполнения через повторную отправку (Resubmit). Это повтор с теми же данными триггера: при временном сбое (500/502 и т. п.) достаточно просто повторить отправку; если причина — ошибка в определении потока, сначала исправьте и сохраните поток, и повторная отправка пойдёт уже по исправленному определению⁷. Из списка журнала выполнения можно повторно отправить сразу до 20 запусков — это помогает при массовом сбое. Для потока с ручным запуском (мгновенный триггер) свои собственные выполнения можно повторять всегда, а повтор выполнений, которые запустили другие пользователи, администратор должен разрешить в параметрах клиента (tenant)¹⁴.

Главное: повторная отправка запускает поток с самого начала. Если повторить выполнение, которое отказало на 8-м шаге из 10, шаги 1–7, уже прошедшие успешно, выполнятся снова. Отсюда аварии вроде «письмо уже ушло, а его отправили ещё раз» или «в реестре появилась та же строка дважды».

Идемпотентность — дизайн, безопасный при двойном выполнении

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

• Ведите флаг обработки. Дайте реестру (например, списку SharePoint) столбец «Статус» (Не обработано / В обработке / Обработано). В начале потока проверяйте статус: если уже обработано — завершайте выполнение; по окончании обработки обновляйте статус. Тогда повторная отправка не даст двойной обработки. Но флаг работает, только если задана и очерёдность обновления. Для внешних побочных эффектов вроде отправки письма или регистрации в учётной системе сначала переведите статус в «В обработке», затем выполните действие и только после успеха — в «Обработано». Выполнение, которое отказало после побочного эффекта, но до обновления флага, останется в «В обработке» — состояние, в котором неизвестно, прошёл ли побочный эффект на самом деле. Механическая повторная отправка такой строки может дать двойную отправку, поэтому строки «В обработке» исключайте из автоматического повтора и переводите в «Обработано» или «Не обработано» вручную, сверив с фактическим результатом отправки или регистрации. Без раздумий безопасно повторять только строки, застрявшие на «Не обработано».
• Не «создавать» безусловно, а «обновить, если есть, создать, если нет» (upsert). Ищите существующую строку по уникальному ключу (номер заказа, ID заявки и т. п.) и ветвитесь: при совпадении — обновление, при отсутствии — создание. Безусловное «Создание элемента» при каждом повторе копит дубликаты. Иначе говоря, данные без уникального ключа сделать идемпотентными нельзя, поэтому ключевой столбец нужно определить уже на этапе проектирования реестра.
• Ненужные запуски останавливайте условиями триггера. Многократные запуски вроде «поток с триггером „при создании или изменении элемента“ перезапускает сам себя из-за собственной обратной записи» нужно останавливать не последующим условием, а условиями триггера (trigger conditions). Для события, которое условию не удовлетворяет, выполнение вообще не создаётся, поэтому не расходуются ни счётчик выполнений, ни лимит запросов⁸.

Один нюанс. Подход «сначала проверить, потом записать» — и флаг обработки, и upsert — работает против последовательного повтора вроде повторной отправки, но сам по себе не даёт атомарной защиты. Если два дублирующих события триггера приходят почти одновременно, оба выполнения могут прочитать «Не обработано» и оба пойти в обработку. Чтобы надёжно исключить дубли в потоке, где возможны параллельные запуски, либо сериализуйте выполнение контролем параллелизма, поставив степень параллелизма в 1 (следующий подраздел), либо дополнительно используйте механизм на стороне хранилища, который умеет принудительно применять ограничение уникальности (например, уникальное ограничение базы данных), чтобы дублирующее создание падало уже на записи.

Компромисс между контролем параллелизма (concurrency control) и порядком

Рядом с двойным выполнением стоит пара «параллелизм» и «порядок». По умолчанию, если одновременно приходит много событий, удовлетворяющих условию триггера, поток запускается параллельно в любом числе экземпляров¹. Когда несколько выполнений одновременно читают и пишут одну и ту же строку реестра, возможна рассинхронизация: прочитали устаревшее значение и перезаписали его (грязное чтение, dirty read)¹⁵.

Если в параметрах триггера включить контроль параллелизма (Concurrency Control), число параллельных выполнений (степень параллелизма) задаётся от 1 до 100. При степени 1 выполняется только один экземпляр за раз, и обработка ближе к строгому порядку¹¹⁵. У этого переключателя есть тяжёлые оговорки.

• После включения выключить нельзя. Вернуться к «выключено» можно только удалив триггер и создав его заново¹. Контроль параллелизма необратим, поэтому его рекомендуют только для потоков с небольшим числом действий (при необходимости вынесите логику в дочерний поток)¹⁵.
• Появляется риск потерять события. При включённом контроле параллелизма число выполнений, которые могут ждать в очереди, ограничено значением «10 + степень параллелизма». Триггер, пришедший, пока этот лимит исчерпан, будет повторён на стороне соединителя, но при долгом превышении лимита он может так и не дойти до выполнения. Официальная документация прямо пишет: если каждый триггер обязан привести к выполнению, контроль параллелизма оставляйте выключенным¹. Если журнал выполнения забит состояниями отмены, причиной может быть именно эта настройка¹¹.

Иначе говоря, «соблюсти порядок» и «ничего не потерять» — это компромисс. Сериализация со степенью параллелизма 1 полезна для процессов с небольшим потоком событий, где важен порядок (например, выдача порядковых номеров в реестре), но её не стоит бездумно ставить на обработку, куда в пике приходит много событий. Если строго нужны и порядок, и полнота одновременно, вы уже в области, которую, как сказано в главе 8, стоит проектировать вне Power Automate.

7. Контрольный список перед выводом в продакшен

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

Двенадцать пунктов могут показаться избыточными, но в первый продакшен-день нужны только шесть «обязательных», и больше половины из них продумываются один раз. Шесть «желательных» — не «можно забить», а «можно спокойно закрыть, когда поток уже крутится». Наоборот, «доделать потом» у потока, который этот список пропустил и сразу поехал в продакшен, обычно так и не происходит: страшно трогать то, что уже работает, — и дело доходит до аварии.

8. Где граница Power Automate

Если довести обработку ошибок до конца, становятся видны требования, которые Power Automate уже не закрывает. Ориентиры для границы.

На ощущение граница примерно такая: пока процедуру восстановления после сбоя можно объяснить словами — это территория Power Automate; как только без схемы уже не получается — это область разработки. Особенно работа с компенсационной транзакцией (в системе компании A запись уже прошла, в системе компании B — сбой, отменять ли A?) сложнее, чем кажется по внешнему виду потока, и Terminate с уведомлением её не закрывают. Выбор с учётом Планировщика заданий и PowerShell разобран в статье «Когда брать Power Automate, а когда PowerShell и Планировщик заданий».

9. Итоги

«Работавший поток вдруг остановился» — почти никогда не невезение, а проблема проектирования. Поток рано или поздно откажет. Из четырёх типов сбоев повтор закрывает только временные; сбои из-за данных, истечения аутентификации и изменения спецификации ловят только многослойно: перехват Try-Catch, фиксация Terminate, собственное уведомление и еженедельный просмотр журнала выполнения. Штатное письмо о сбое — ограниченный механизм с условиями и паузой 28 дней, и эксплуатация, которая опирается только на него, обязательно что-то пропустит.

Главная опора подготовки к сбою — не уведомление, а идемпотентность. Если флаг обработки и upsert дают форму «не ломается даже при двойном выполнении», перестают быть страшными и повторная отправка, и дублирование триггера, а восстановление сводится к «выбрать неудачное и повторить отправку». Наоборот, работу, которой нужна компенсационная транзакция или строгая гарантия порядка, не стоит насильно втискивать в Power Automate: вынести её в область разработки в долгосрочной перспективе дешевле. Именно в день, когда поток впервые заработал, стоит один раз пройти этот список.

Похожие статьи

• Автоматизация бизнес-процессов в Power Automate — выбор между облачным потоком и потоком рабочего стола, проектирование обработки ошибок
• Регулярные потоки Power Automate и расчёт рабочих дней
• Как собрать поток согласования в Power Automate — перевод бумажных и почтовых заявок в электронный вид
• Как снизить зависимость Power Automate от одного человека — чтобы поток не остановился, когда автор уйдёт
• Когда брать Power Automate, а когда PowerShell и Планировщик заданий

Смежные области консультирования

合同会社小村ソフト (KomuraSoft LLC) делает ревью обработки ошибок и эксплуатационного проектирования потоков Power Automate и системную реализацию требований к порядку и транзакциям, которые в поток уже не укладываются.

• Техническая консультация и ревью проекта
• Разработка приложений для Windows
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Если поток Power Automate завершился сбоем, придёт ли письмо с уведомлением автоматически?

Только в ограниченном числе случаев. Оповещение о сбое на уровне выполнения отправляется владельцу и совладельцам, если сбой признан «известным и имеющим способ исправления» — например, разрыв подключения или регулирование (throttling). При обычном сбое действия письмо не уходит. После одного такого оповещения для того же потока действует пауза 28 дней: дополнительные оповещения в этот период не приходят. Оповещения на уровне выполнения к тому же включены по умолчанию не во всех потоках. Чтобы сбой гарантированно заметили, лучше слать собственное уведомление в Teams или по почте из блока Catch.

Сколько раз и с каким интервалом срабатывает стандартный повтор в Power Automate?

Если запрос действия завершается тайм-аутом или сбоем с ответом 408, 429 или 5xx, по умолчанию выполняется автоматический повтор с экспоненциально растущим интервалом. Число попыток зависит от профиля производительности потока (по сути — от уровня лицензии): для низкого профиля, например лицензии Microsoft 365, — максимум 2 повтора; для среднего и высокого, например Power Automate Premium или лицензии Process, — максимум 12. В параметрах действия политику можно сменить на «нет / фиксированный интервал / экспоненциальный интервал» и задать до 90 попыток. Ошибки из-за данных или настроек, такие как 400 и 404, повторным попыткам не подлежат.

Как заново запустить (повторно отправить) неудачное выполнение потока?

Откройте неудачное выполнение в журнале выполнения и выберите «Повторная отправка» (Resubmit) — поток выполнится снова с теми же данными триггера. Если причина была в определении потока, сначала исправьте поток, сохраните его и только потом повторите отправку: выполнение пойдёт уже по исправленному определению. Из списка журнала выполнения можно повторно отправить сразу до 20 запусков. Важно: повторная отправка запускает поток с самого начала, поэтому в выполнении, которое частично уже прошло успешно, успешные шаги выполнятся ещё раз. Нужен идемпотентный дизайн (флаг обработки, запись с приоритетом обновления, а не создания), при котором двойной запуск не портит результат.

Может ли поток отключиться, пока я об этом не знаю?

Да. Поток, у которого триггер или действия продолжают завершаться ошибкой, автоматически отключается через 14 дней. Поток, который постоянно попадает под регулирование (превышение лимитов), тоже отключается через 14 дней. Кроме того, поток, ни разу не сработавший за 90 дней, может быть отключён, если у владельца нет премиум-лицензии или лицензии на ёмкость. Игнорирование сбоев напрямую ведёт к отключению потока, поэтому в эксплуатацию нужно заложить обнаружение сбоев и регулярную проверку журнала выполнения (по умолчанию 28 дней).

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

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