Serverless Scheduled Tasks на AWS: EventBridge, Lambda, мониторинг

Serverless scheduled tasks: где ломаются регулярные задания

Serverless scheduled tasks выглядят надёжными ровно до первого инцидента: расписание срабатывает, а результат не приходит. Классический сценарий — задание запускается по таймеру, обработчик падает на середине, платформа считает попытку завершённой, и следующего запуска ждать сутки. Никто не звонит, метрика «успешных вызовов» зелёная, а данные за день потеряны.

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

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

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

Что даёт управляемый запуск заданий по расписанию

Предсказуемость запусков вместо «плавающего» времени

Расписание в EventBridge срабатывает по cron-выражению с точностью до минуты, а не «когда проснётся сервер». Для регулярных задач — выгрузок, сверок, рассылок, пересчёта агрегатов — это снимает целый класс проблем: запуск не съезжает из-за перезагрузки машины, переполнения очереди или зависшего предыдущего процесса. Если задача идёт дольше окна, следующий запуск не наслаивается: параллельные экземпляры гасятся на уровне правила. Время старта перестаёт быть предметом догадок — оно одинаково и в будни, и в пик нагрузки.

Ручные проверки уходят в мониторинг

Раньше дежурный открывал логи и глазами сверял, прошла ли ночная выгрузка. Теперь об этом сообщает система: успешный запуск пишет метрику, ошибка — алерт в канал команды с телом исключения и идентификатором запроса. Число ручных проверок падает с ежедневных обходов до нуля, а инженер занимается разбором, а не наблюдением. Отдельно настраиваем «мёртвую» тишину: если задача не стартовала в ожидаемое окно, приходит уведомление — молчание тоже сигнал.

Время реакции на сбой — минуты, а не сутки

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

Что это даёт в сумме

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

Способы запуска: планировщик, очередь, ручной триггер

Регулярные задачи в serverless-контуре запускаются тремя способами, и выбор между ними определяется не удобством, а характером нагрузки и требованиями к повторяемости. Планировщик (в AWS это EventBridge Scheduler) вызывает функцию по cron- или rate-выражению: он хорош для задач с фиксированным временем — ночные отчёты, синхронизация справочников, прогрев кэша. Очередь заданий (SQS + Lambda) запускает обработку по событию: сообщение появляется — функция стартует, и так до опустошения очереди. Ручной триггер — вызов через API или консоль для разовых операций: переиндексация, миграция, пересчёт.

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

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

Как мы внедряем регулярные задания: этапы работ

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

1. Аудит заданий. Собираем всё, что сейчас запускается по расписанию: системные планировщики, скрипты на серверах, ручные запуски «по звонку». Для каждого фиксируем периодичность, длительность, зависимости от других процессов и последствия сбоя — какие задания критичны, а какие можно повторить без вреда.
2. Схема запусков. Раскладываем задания по типам: частые короткие, длительные, зависящие от внешних систем. Определяем, где нужен запуск по календарю, где — по событию, а где — цепочка с передачей результата. На этой схеме сразу видно пересечения, из-за которых задания конкурируют за одни данные.
3. Настройка расписания. Переносим правила в управляемый сервис расписаний: часовые пояса, окна запуска, повторные попытки при сбое, ограничение параллельных копий одного задания. Расписание хранится как конфигурация, а не как знание одного инженера.
4. Логика и права. Каждое задание получает собственную роль с минимальными правами — только те данные и операции, которые ему нужны. Секреты и доступы выносятся в защищённое хранилище, а не в код.
5. Проверка отказоустойчивости. Прогоняем сценарии: недоступность внешней системы, повторный запуск, превышение времени работы, сбой в середине цепочки. Смотрим, что задание не теряется, не дублирует операции и корректно сообщает об ошибке.
6. Мониторинг и оповещения. Настраиваем контроль факта запуска, длительности и результата. Оповещения приходят на пропуск запуска и на повторяющиеся ошибки, а не на каждую мелочь — иначе сигнал теряется в шуме.
7. Передача в эксплуатацию. Отдаём документацию: карту заданий, расписание, порядок ручного перезапуска и отката. Проводим разбор с вашей командой, чтобы поддержка не зависела от нас.

Опишите, какие задания у вас есть сейчас, — вернёмся с оценкой и планом перевода их на управляемое расписание.

Что заказчик получает на руки после внедрения

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

• Конфигурации заданий как код — определения расписаний, обработчиков и их параметров лежат в репозитории, а не собираются руками в веб-консоли. Изменение проходит через ревью, откат — обычным возвратом предыдущей версии.
• Схемы запусков — таблица «задание → периодичность → часовой пояс → что происходит при пересечении запусков → куда уходит результат». Видно, какие задачи зависят друг от друга и где окно обслуживания.
• Политики доступа — роли с минимально необходимыми правами: что разрешено конкретному заданию, кто из инженеров может менять расписание, как выдаётся и отзывается доступ. Отдельно фиксируем, что задание не может выйти за пределы своих полномочий.
• Обработка сбоев — повторы с нарастающей паузой, «мертвая очередь» для безнадёжных запусков, поведение при недоступности внешнего сервиса. Описано, сколько раз пробуем и когда сдаёмся.
• Мониторинг и оповещения — метрики успешных и упавших запусков, задержка старта, алерты в ваш канал. Настроено так, чтобы о проблеме узнавали до того, как её заметит бизнес.
• Регламент эксплуатации — что делать при сбое, как временно отключить задание, как добавить новое, кому звонить. Сценарии расписаны по шагам, без расчёта на конкретного человека.
• Инструкции для команды — короткие руководства по типовым операциям и передача знаний: разбор на созвоне с записью, чтобы новый инженер вошёл в контур без нас.

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

Кейс: как регулярные отчёты перестали срываться

Заказчик — сервисная компания с ежемесячной отчётностью для внутренних команд и партнёров. Отчёты собирались cron-скриптом на одном сервере: он опрашивал биллинг, склад и CRM, сводил данные и рассылал файлы. Пока объёмы были небольшими, схема работала, но с ростом числа источников запуск стал падать — то по таймауту на выгрузке, то из-за перезапуска сервера ровно в момент формирования. Доля успешных запусков держалась около 70%, а сбой обычно замечали уже получатели: отчёт не приходил или приходил частичным.

Мы перенесли расписание и обработку на управляемые сервисы: планировщик Amazon EventBridge запускает задачу по календарю, сама обработка идёт в изолированных функциях, а промежуточные результаты складываются в объектное хранилище. Каждый шаг — отдельная задача со своим повтором: если выгрузка из одного источника не удалась, повторяется только она, а не весь конвейер. Ошибки больше не «висят» в логах сервера — они попадают в очередь недоставленных сообщений, и по ней сразу видно, какой источник и на каком шаге отвалился.

Что изменилось в цифрах

Доля успешных запусков выросла с ~70% до 99,6%: повтор и развязка шагов убрали основную причину срывов — падение на одном источнике при живых остальных. Время восстановления после сбоя сократилось с нескольких часов ручного разбора до минут: задача перезапускается автоматически, инженеру остаётся проверить очередь недоставленных сообщений.

Отдельно закрылся целый класс отказов — «тихие» пропуски, когда расписание не срабатывало из-за недоступности сервера. Теперь планировщик живёт отдельно от обработки, и его недоступность не блокирует выпуск отчёта. Мониторинг отслеживает не факт «сервер жив», а результат: пришёл ли отчёт, уложился ли в окно, сколько повторов потребовалось.

Чем отличается запуск по расписанию от запуска по событию?

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

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

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

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

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

Частые технические сомнения по serverless scheduled tasks

Планировщик в облаке почти всегда работает в UTC, и это первое, обо что спотыкаются при переносе задач из cron на сервере. Если бизнес-логика завязана на местное время — отчёт к открытию смены, рассылка по рабочему дню региона, — расписание задаётся не «на 9 утра», а со смещением, либо через именованную зону. Отдельная ловушка — переход на летнее время: фиксированное смещение даёт сдвиг на час дважды в год, а зона с правилами переходов его отрабатывает.

Что будет, если задача выполняется дольше отведённого времени?

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

Как понять, что задание не выполнилось?

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

Можно ли перенести существующий cron без переписывания логики?

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

Разбор этих сомнений до старта экономит недели отладки в проде. Опишите свои задания и текущее расписание — вернёмся с оценкой и планом переноса.

Обсудим вашу задачу и вернёмся с планом

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

На первом разговоре уточняем:

• какие процессы нужно запускать по расписанию и с какой частотой — раз в минуту, ежедневно или по календарю с часовыми поясами;
• что именно делает каждая задача: обращается к базе, вызывает внешние сервисы, формирует отчёты, чистит устаревшие данные;
• допустимое время выполнения и объём данных на один запуск — от этого зависит, укладывается ли задача в один вызов или её нужно разбивать на шаги;
• поведение при сбое: повторять запуск, уведомлять ответственного, писать в очередь необработанных или останавливать цепочку;
• как сейчас запускаются эти операции — вручную, по cron на сервере, через сторонний сервис — и что мешает;
• требования к наблюдаемости: куда должны приходить уведомления об ошибках, нужна ли история запусков и метрики;
• ограничения по доступам и среде: в каком облаке работаете, какие сервисы уже задействованы, есть ли требования по хранению данных.

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

Опишите задачу в удобном виде — вернёмся с оценкой и планом.