Yandex Cloud Functions: как выполнять код без своего сервера

Твой первый сайт работает, платёжная система подключена — и вдруг возникает задача: когда покупатель оплачивает доступ, кто-то должен моментально отреагировать на это и открыть ему курс. Или: каждое утро в девять часов пользователям должна приходить сводка их прогресса. Поднимать ради этого отдельный сервер, который будет крутиться круглосуточно, — дорого и бессмысленно: 99% времени он будет простаивать. Ровно для таких задач и придуман подход, который называется serverless, а его российская реализация — Yandex Cloud Functions. Разберёмся, что это, как работает и когда оно действительно нужно.

Что такое serverless и Cloud Functions простыми словами

Serverless — буквально «без сервера». Название обманчиво: серверы, конечно, есть, просто они тебя не касаются. Идея такая:

1. Ты пишешь небольшой кусок кода — функцию. Например: «принять уведомление об оплате, проверить подпись, выдать пользователю доступ».
2. Загружаешь её в облако.
3. Облако запускает эту функцию только когда нужно: пришёл HTTP-запрос — запустилась, наступило девять утра по расписанию — запустилась, в очереди появилось событие — запустилась. Выполнила работу — и выключилась.

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

Yandex Cloud Functions — это именно такой сервис от Яндекса: загрузил функцию (на Python, Node.js и других языках), указал, как её вызывать, и дальше облако всё делает само. Если функцией никто не пользуется — она ничего не стоит. Если ей пользуются тысячу раз в день — облако само масштабируется под нагрузку, тебе ничего менять не нужно.

Аналогия из жизни: обычный сервер — это аренда квартиры. Платишь за месяц, даже если неделю живёшь у друзей. Cloud Functions — это такси: платишь только за конкретные поездки. Если поездок мало и они короткие — такси выгоднее аренды на порядки. Если ездишь целыми днями без остановки — дешевле арендовать.

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

Что облако берёт на себя, когда ты выбираешь функции:

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

Тебе остаётся ровно одно: код, который делает полезную работу. Всё, что вокруг него, — инфраструктурная забота Яндекса. Именно за это программисты и полюбили serverless: меньше рутины, больше времени на сам продукт.

flowchart TB
    A["HTTP-запрос или таймер"] --> B["Облако запускает функцию"]
    B --> C["Функция выполняет код"]
    C --> D["Результат возвращается"]
    D --> E["Облако останавливает функцию"]

Чем это отличается от обычного хостинга (Amvera)

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

Cloud Functions работают наоборот:

• запускают одну маленькую задачу, а не целое приложение;
• живут секунды: получили вызов — выполнили код — выключились;
• не имеют «состояния» между вызовами: каждый запуск начинается с чистого листа.

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

Типичные задачи для постоянного сервера вроде Amvera: сам сайт или приложение, которое должно отвечать пользователям в любой момент; WebSocket-соединения для чата или онлайн-игры; долгие фоновые процессы.

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

Чем это отличается от n8n

Вторая частая путаница: «а зачем писать код, если есть n8n?» Мы подробно разбирали этот инструмент в статье про автоматизацию без кода в n8n. Разница принципиальная:

• n8n — это no-code конструктор. Ты перетаскиваешь готовые блоки («получить webhook», «отправить письмо», «записать в Google-таблицу») и соединяешь их стрелками. Кода нет вообще. Быстро и просто — пока твоя логика укладывается в готовые блоки.
• Cloud Functions — это настоящий код. Ты сам пишешь логику на Python или JavaScript. Это сложнее, но даёт полную свободу: проверить криптографическую подпись платёжной системы, распарсить нестандартный формат данных, сделать расчёт, для которого готового блока просто не существует.

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

Сводная таблица трёх подходов:

Как функция выглядит изнутри

Страх «написать настоящий код» обычно проходит, когда видишь, как мало кода нужно. Функция — это не программа с интерфейсом, а один обработчик: получил входные данные, что-то сделал, вернул ответ. Вот условный пример на Python — функция, которая принимает webhook и отвечает отправителю:

def handler(event, context):
    # event — это данные запроса: заголовки, тело, параметры
    body = event.get("body", "")

    # здесь твоя логика: проверить подпись, записать в базу,
    # открыть доступ пользователю

    return {
        "statusCode": 200,
        "body": "OK",
    }

Всё. Десяток строк — и это уже рабочая функция. Структура у любой функции одинаковая:

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

Такой обработчик под силу написать даже новичку — а с ИИ-ассистентом вроде Claude задача сводится к тому, чтобы чётко описать желаемое поведение: «прими POST-запрос, достань из тела email и сумму, проверь подпись вот по такому алгоритму, верни 200, если всё сошлось». Это ровно тот навык постановки задач, который тренируется на курсе.

Чем можно запустить функцию: триггеры

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

HTTP-запрос. Самый частый вариант: у функции появляется публичный адрес, и любой сервис может её дёрнуть. Именно так работают webhook платёжных систем: в настройках кассы указываешь адрес функции, и она получает уведомление о каждой оплате.

Таймер. Запуск по расписанию: «каждый день в 9:00», «каждый понедельник», «раз в час». Расписание задаётся в привычном для серверных задач cron-формате. Утренние сводки, еженедельные отчёты, регулярная чистка старых данных — всё это таймеры.

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

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

Как создать первую функцию: общий порядок

Точные названия кнопок в консоли Яндекс Облака меняются со временем, поэтому здесь — общая логика, а не пошаговая инструкция по интерфейсу. Свежие детали всегда смотри в официальной документации: cloud.yandex.ru/docs/functions

Порядок действий такой:

1. Зарегистрируйся в Яндекс Облаке и привяжи карту. Для старта обычно дают стартовый грант, а мелкие нагрузки и вовсе укладываются в бесплатную квоту.
2. Создай функцию: выбери имя и язык — для новичка проще всего Python или Node.js.
3. Напиши код прямо во встроенном редакторе или загрузи архивом. Код обязан содержать функцию-обработчик вроде той, что в примере выше.
4. Сохрани версию. В Cloud Functions работают именно версии кода: можно вернуться к предыдущей, если новая сломалась.
5. Настрой вызов: сделай функцию публичной по HTTP или добавь триггер — таймер, очередь, событие.
6. Протестируй: в консоли есть тестовый вызов — скорми функции пример входных данных и посмотри, что она вернула и что написала в лог.

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

Почему именно Яндекс для российского пользователя

Serverless-подход придумали не в Яндексе: самый известный такой сервис — AWS Lambda от Amazon, есть и Google Cloud Functions. Но для новичка из России у Яндекса есть практические преимущества:

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

Для сравнения: чтобы пользоваться AWS Lambda или Google Cloud Functions из России, придётся решать и вопрос оплаты (российские карты там не принимают), и вопрос доступа. Для учебных и рабочих проектов российской аудитории это лишнее трение, которое Яндекс просто убирает.

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

Практический пример: функция для приёма оплаты

Самая живая задача для аудитории курса: ты подключил платёжную систему — например, по нашим статьям про Prodamus или ЮKassa — и теперь нужно, чтобы после успешной оплаты пользователь автоматически получал доступ к курсу.

Платёжные системы умеют слать webhook — HTTP-запрос на указанный тобой адрес в момент оплаты. Вопрос: кто этот запрос примет? Ради одного webhook держать целый сервер — расточительно. А вот функция подходит идеально:

1. Платёжная система отправляет POST-запрос с данными платежа.
2. Облако запускает твою функцию.
3. Функция проверяет подпись запроса (чтобы это действительно платёжная система, а не мошенник), находит пользователя по email, открывает ему доступ в базе и отвечает платёжной системе «принято».
4. Функция завершается. Если в следующие полчаса оплат нет — она ничего не стоит.

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

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

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

Если слово webhook и сама идея «один сервис дёргает другой по HTTP» пока звучит абстрактно — сначала прочитай статью что такое API, там эта механика разобрана на пальцах.

Безопасность: почему webhook нельзя принимать вслепую

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

Механика стандартная для всех платёжных систем:

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

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

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

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

Бесплатный лимит и стоимость

У Yandex Cloud Functions есть бесплатная месячная квота: определённое количество вызовов и вычислительного времени не оплачивается вообще. Точные цифры Яндекс периодически меняет, поэтому актуальные значения смотри на официальном сайте сервиса в разделе тарификации — не верь никаким статьям (включая эту) насчёт конкретных чисел.

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

Из формулы тарификации следуют три практических вывода:

• Быстрый код — дешёвый код. Функция, которая работает сто миллисекунд, стоит заметно меньше той, что думает пять секунд. Оптимизация здесь напрямую конвертируется в деньги.
• Не выделяй память «с запасом». При создании функции указывается объём оперативной памяти, и он влияет на цену каждой секунды. Для обработчика webhook обычно хватает минимальных значений.
• Простаивающая функция бесплатна. Пока функцию никто не вызывает, счётчик стоит. Это принципиальное отличие от сервера, который «съедает» арендную плату и ночью.

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

Ограничения, о которых стоит знать честно

Serverless — не волшебство, и у подхода есть реальные минусы.

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

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

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

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

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

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

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

Когда брать Cloud Functions, а когда — нет

Сводим всё в простое правило.

Cloud Functions подходят, если задача:

• короткая (секунды, редко минуты);
• запускается по событию — запрос, таймер, сообщение в очереди;
• вызывается редко или неравномерно;
• требует настоящего кода, а не готовых блоков n8n.

Cloud Functions НЕ подходят, если:

• нужно приложение, работающее непрерывно (сайт, бэкенд с WebSocket);
• задача длится долго — десятки минут и больше;
• нагрузка постоянная и плотная: тогда «аренда квартиры» обычного сервера выйдет дешевле, чем вечное «такси».

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

Типичные ошибки новичков

Напоследок — грабли, на которые наступает почти каждый, кто впервые работает с функциями.

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

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

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

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

Ошибка 5. Не смотреть в логи. Функция «не работает» — а в логах обычный синтаксический промах или таймаут при обращении к базе. Логи в serverless — единственное «окно внутрь», привыкай открывать их первым делом.

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

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

Это правда «без сервера»?

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

Нужно ли уметь программировать, чтобы пользоваться Cloud Functions?

Да, функцию нужно написать кодом — в отличие от n8n, где всё собирается мышкой. Хорошая новость: с ИИ-ассистентом вроде Claude написать функцию из двадцати строк под конкретную задачу («прими webhook от ЮKassa и проверь подпись») под силу даже новичку.

Сколько это стоит на практике?

Есть бесплатная месячная квота вызовов и вычислительного времени — для учебного проекта и редких задач её обычно хватает с запасом. Сверх квоты оплата идёт за фактические вызовы и время работы. Точные цифры меняются, актуальные тарифы смотри на официальном сайте Yandex Cloud.

Что будет, если функцию вызовут тысячу раз одновременно?

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

Чем Cloud Functions лучше просто отдельного скрипта на моём сервере?

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

Можно ли вызывать функцию по расписанию, например каждое утро?

Да. Помимо HTTP-вызова функции запускаются триггерами: таймер по расписанию (cron-подобный формат), сообщения в очередях, события в других сервисах Яндекс Облака. Ежедневная сводка или еженедельная чистка данных — классический сценарий.

Заключение

Yandex Cloud Functions — это способ выполнять свой код в облаке, не арендуя и не обслуживая сервер: платить только за реальные секунды работы, масштабироваться автоматически и не думать об инфраструктуре. Для российского новичка это ещё и самый доступный вход в serverless: рубли, русская документация, никаких VPN.

Главное — правильно понимать нишу инструмента. Короткие задачи по событию (webhook оплаты, обработка файла, утренняя рассылка) — сюда. Постоянно работающее приложение — на обычный хостинг. Быстрые автоматизации без кода — в n8n. Выбери инструмент под задачу, а не наоборот — и архитектура твоего проекта будет простой, дешёвой и надёжной.

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