IaaS, PaaS, SaaS, FaaS: где кончается ваша ответственность

Вторник, 11:40. Миграция выкатилась не на тот стенд и снесла таблицу payments в проде. Инженер пишет в чат: «Не паникуем, у нас managed-Postgres, бэкапы делает провайдер».

Дальше выясняется следующее. Бэкапы действительно есть — восстановление на момент времени за последние семь дней. Восстановление не «откатывает» существующую базу: оно создаёт новый инстанс с новым адресом. Восстановление базы на 400 гигабайт занимает не пять минут, а десятки минут — и это время нельзя ускорить деньгами. Новый адрес нужно прописать во всех сервисах, часть из которых берёт его из переменной окружения при старте. Пользователь, от имени которого приложение ходит в базу, в новом инстансе создаётся заново, и пароль надо выдать. А ещё за эти семь дней никто ни разу не пробовал восстановиться — потому что «у нас managed».

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

Эта глава — про эту границу. Не про то, «что современнее», и не про то, «что модно»: у каждого уровня есть покупатель, поставщик и цена владения с обеих сторон. Мы разберём четыре канонических уровня — IaaS, PaaS, FaaS и SaaS — по одной и той же схеме: что уровень даёт потребителю, во что обходится поставщику, какие обязательства создаёт и как считать деньги. Про то, что вы продаёте — коробку, SaaS, self-hosted или гибрид, — предыдущая глава Модели поставки; здесь про то, на чём вы это запускаете и почему выбор уровня определяет вашу операционную нагрузку на годы вперёд.

Уровень — это не технология, а линия в стеке

Каноническое определение дал NIST в документе SP 800-145 ещё в сентябре 2011 года. Оно скучное и точное: три модели обслуживания различаются тем, чем управляет потребитель. В IaaS потребитель управляет ОС, хранилищем и приложениями. В PaaS — приложением и его настройками, но не ОС. В SaaS — только пользовательскими настройками приложения. FaaS появился позже и в NIST не попал, но встраивается в ту же шкалу.

Практическая переформулировка: уровень — это высота, на которой в стеке проходит линия ответственности.

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

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

Третья строка — та, из-за которой ломается больше всего логики. Если ваш SaaS лёг из-за сбоя провайдера, ваш клиент подаёт претензию вам, а не провайдеру. Ваша компенсационная выплата и компенсация, которую вы получите от провайдера, — два независимых, обычно очень несимметричных числа. Мы посчитаем их в разделе про SLA.

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

Уровень потребления и модель поставки — разные оси

Частая путаница: «мы делаем SaaS, значит мы на SaaS». Нет. SaaS в названии вашего продукта означает, что вы поставляете программу как услугу. На чём вы её запускаете — отдельный вопрос.

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

Один и тот же сервис на четырёх уровнях

Абстракции становятся понятны, когда видишь, что именно приходится написать. Возьмём предельно простую задачу: HTTP-эндпоинт принимает вебхук, проверяет подпись и кладёт событие в очередь.

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

# /etc/systemd/system/webhook.service — вы описываете, как процесс живёт
[Unit]
Description=Приём вебхуков
After=network-online.target

[Service]
User=webhook                      # отдельный пользователь: не запускайте от root
WorkingDirectory=/srv/webhook
EnvironmentFile=/etc/webhook.env  # секреты не в репозитории и не в юните
ExecStart=/srv/webhook/venv/bin/gunicorn -w 4 -b 127.0.0.1:8080 app:app
Restart=always                    # перезапуск после падения — тоже ваша забота
RestartSec=2
NoNewPrivileges=true              # базовое ужесточение прав процесса
ProtectSystem=strict

[Install]
WantedBy=multi-user.target

Плюс конфиг прокси, плюс автопродление сертификата, плюс правило фаервола, плюс запись в системе мониторинга. Ничего сложного по отдельности — но каждый пункт кто-то должен помнить и поддерживать годами.

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

# app.yaml — вы описываете, что запускать, а не как
runtime: python312
entrypoint: gunicorn -w 4 -b :$PORT app:app   # порт диктует платформа
env_variables:
  QUEUE_URL: "https://queue.internal/events"
automatic_scaling:
  min_instances: 1        # держим один тёплый: холодный старт виден пользователю
  max_instances: 20       # потолок, иначе всплеск превратится в счёт

FaaS. Исчезает и процесс: остаётся функция и описание того, что её вызывает.

# handler.py — обработчик обязан быть идемпотентным и не хранить состояние
import hashlib
import hmac
import json
import os

from queue_client import enqueue  # тонкая обёртка проекта над очередью

SECRET = os.environ["WEBHOOK_SECRET"].encode()  # секрет из окружения, не из кода


def verify(body: bytes, signature: str) -> bool:
    """Сравнение подписи за постоянное время: обычный `==` даёт утечку по таймингу."""
    expected = hmac.new(SECRET, body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, signature)


def handler(event, context):
    body = event["body"].encode()
    if not verify(body, event["headers"].get("x-signature", "")):
        return {"statusCode": 401, "body": "bad signature"}

    payload = json.loads(body)
    # Ключ идемпотентности: платформа вправе вызвать функцию повторно,
    # поэтому повтор обязан быть безопасным на стороне получателя.
    enqueue(payload, dedup_key=payload["event_id"])

    # Всё, что нужно сделать, делаем ДО возврата: после ответа инстанс
    # может быть заморожен, и фоновые задачи просто не выполнятся.
    return {"statusCode": 202, "body": ""}

Сведём в таблицу, что именно изменилось:

IaaS: вы арендуете железо, всё остальное — ваше

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

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

• образы машин и их обновление, иначе через год у вас зоопарк из пяти поколений;
• патчи ОС и перезагрузки, в том числе внеплановые под уязвимости;
• резервное копирование и проверка восстановления — снапшот, из которого никогда не восстанавливались, это не бэкап, а надежда;
• мониторинг, логи, алерты и дежурство (см. трек SRE);
• сетевая безопасность: группы, правила, публичные адреса, которые кто-то открыл «на пять минут» в прошлом апреле;
• управление доступом и ролями — на IaaS это самая частая причина инцидентов безопасности.

Обязательства. Модель разделённой ответственности провайдеров формулируется одинаково у всех: AWS называет это «безопасность облака против безопасности в облаке», Microsoft публикует ту же таблицу по слоям, Google добавляет к ней концепцию shared fate — «поставщик даёт защищённые по умолчанию заготовки, но исход общий». Практический вывод один: если сломалось выше гипервизора, вы можете открыть тикет, но чинить будете сами.

Живой пример прямо на этом портале. Сайт courses.digitable.life собирается в GitHub Actions и раскладывается rsync на арендованный сервер с панелью управления. Это чистый IaaS-режим: сервер наш, ОС наша, TLS-сертификаты наши, обновления панели наши. Рядом на такой же схеме живёт наш инстанс it-tools — открытый набор инженерных утилит, который мы развернули у себя. Плата за это — конкретная: кто-то должен помнить про обновления ОС и про то, что сертификат продлевается автоматически только пока работает демон, который его продлевает. Плюс — тоже конкретный: счёт за такой сервер предсказуем и не растёт от трафика.

Когда IaaS правильный ответ. Нестандартные требования к ядру, сети или железу (GPU, большие диски, специфические ядра); необходимость понимать стоимость с точностью до процента при большом объёме; регуляторные требования к размещению; наличие людей, которые всё это умеют. Про выбор между виртуалкой, выделенным сервером и своим железом есть подробная глава в треке DevOps: VPS, VDS и bare metal.

PaaS: вы приносите код, платформа диктует форму

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

Цена абстракции — контракт. PaaS работает потому, что делает жёсткие предположения о том, как устроено ваше приложение. Классическая формулировка этих предположений — Twelve-Factor App: конфигурация в переменных окружения, процессы без состояния, логи в стандартный вывод, порт из окружения, никаких локальных файлов между запросами. Механику сборки описывают Cloud Native Buildpacks — проект CNCF, выросший из подхода Heroku.

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

Обязательства и риск смены правил. Чем выше уровень, тем больше решений принимает поставщик — и тем больнее их изменения. Показательная история: Heroku, платформа, которая фактически изобрела массовый PaaS, прекратила бесплатные планы 28 ноября 2022 года. Технически это было право владельца. Практически — тысячи пет-проектов, учебных стендов и внутренних утилит перестали работать в один день, и переезжать пришлось не «когда удобно», а по чужому календарю. Ещё раньше похожее пережили пользователи Parse, мобильного BaaS: сервис объявил о закрытии в январе 2016 года, а исходники сервера выложили в открытый доступ, чтобы желающие могли поднять его сами. Это, кстати, хороший пример того, как открытая лицензия работает страховкой — тему разбирает глава Открытый код как способ поставки.

Деньги. У PaaS почти всегда высокая цена за единицу вычислений и низкая цена входа. Порядок величин: небольшой постоянно работающий процесс на PaaS в 2026 году стоит в разы дороже, чем эквивалентная по мощности виртуалка у бюджетного провайдера, — но экономит часы человека в месяц. Формулу этого размена посчитаем ниже, она общая для всех уровней.

Когда PaaS правильный ответ. Маленькая команда без выделенного инженера по инфраструктуре; ранняя стадия продукта, где важнее скорость проверки гипотез, чем цена за запрос (MVP и эксперименты); внутренние инструменты, где стоимость часа разработчика заведомо выше стоимости сервера.

FaaS: единица биллинга — вызов, единица боли — состояние

FaaS (он же «функции», он же значительная часть того, что называют serverless) — это уровень, где вы поставляете не процесс, а функцию, и платите не за время работы машины, а за факт и длительность вызова.

Модель исполнения, которую надо держать в голове

Из этой диаграммы вытекают почти все практические свойства FaaS:

• Холодный старт. Первый вызов дороже по времени: нужно поднять песочницу и выполнить инициализацию. Порядок величин на 2026 год: десятки—сотни миллисекунд для лёгких сред выполнения (JavaScript, Python, Go) и до нескольких секунд для тяжёлых (JVM, .NET) без специальных мер. Изоляты V8, как в Cloudflare Workers, стартуют быстрее микровиртуалок вроде Firecracker, но и ограничений там больше.
• Состояние не переживает заморозку. Всё, что вы положили в глобальную переменную или во временный каталог, может исчезнуть между вызовами — и, наоборот, может неожиданно сохраниться и «протечь» между двумя разными запросами. Оба поведения корректны с точки зрения платформы, и код должен быть корректен при любом из них.
• Фоновая работа после ответа не выполняется. Замороженный инстанс не тикает: setTimeout, отложенная отправка метрик, дозапись буфера — всё это надо делать до возврата ответа.
• Повторы — норма. Платформа может выполнить вашу функцию дважды. Обработчики обязаны быть идемпотентными; механика — в главе Идемпотентность и доставка.
• Жёсткие потолки. У AWS Lambda, например, задокументированы максимальное время выполнения 15 минут, ограничение на размер синхронного ответа и на размер пакета развёртывания. Это не «пока так», это архитектурная граница: если задача не влезает, её нужно резать на шаги, а не искать флаг.

Деньги: где проходит точка безубыточности

Считать FaaS «дешёвым» или «дорогим» вообще бессмысленно — он дёшев при редких вызовах и дорог при постоянных. Формула стоимости за месяц:

$$C_{\text{FaaS}} = N \cdot \left( p_{\text{req}} + t \cdot m \cdot p_{\text{gbs}} \right)$$

где $N$ — число вызовов, $p_{\text{req}}$ — цена вызова, $t$ — средняя длительность в секундах, $m$ — выделенная память в гигабайтах, $p_{\text{gbs}}$ — цена гигабайт-секунды. Постоянная машина стоит фиксированные $C_{\text{VM}}$. Приравняв, получаем число вызовов, на котором счета сравняются:

$$N^{\ast} = \frac{C_{\text{VM}}}{p_{\text{req}} + t \cdot m \cdot p_{\text{gbs}}}$$

Подставим порядок величин, верный для базовой x86-функции AWS Lambda на середину 2026 года — около 0,20 USD за миллион вызовов и около 0,0000167 USD за гигабайт-секунду (актуальный прайс всегда здесь, проверяйте перед расчётом, цифры двигаются). Функция на 150 миллисекунд и 512 мебибайт памяти стоит примерно 0,00000145 USD за вызов. Небольшая постоянная машина — 30 USD в месяц. Тогда

$$N^{\ast} = \frac{30}{0{,}00000145} \approx 20{,}7 \text{ млн вызовов в месяц} \approx 8 \text{ вызовов в секунду}.$$

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

$$N^{\ast}{\text{полн}} = \frac{C{\text{VM}} + h_{\text{VM}} \cdot c - h_{\text{FaaS}} \cdot c}{p_{\text{req}} + t \cdot m \cdot p_{\text{gbs}}}$$

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

Три вывода из этой картинки, которые стоят больше самих чисел:

1. Спор «serverless дороже» почти всегда идёт о разных линиях графика. Одна сторона сравнивает счета, другая — стоимость владения. Обе правы в своей системе координат.
2. Наклон важнее точки. У FaaS расход линеен по нагрузке и стремится к нулю в простое; у машины он постоянен. Если ваш трафик — рабочие часы будних дней, машина простаивает две трети времени, и реальное сравнение сдвигается в пользу функций сильнее, чем показывает средняя нагрузка.
3. Час инженера почти всегда крупнее счёта. Оптимизировать надо ту статью, которая больше, а не ту, которая заметнее в консоли биллинга.

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

"""Сравнение FaaS и постоянной машины по счёту и по стоимости владения."""

SECONDS_IN_MONTH = 30 * 24 * 3600
PER_REQUEST = 0.20 / 1_000_000   # USD за вызов, проверьте по актуальному прайсу
PER_GB_SECOND = 0.0000166667     # USD за гигабайт-секунду


def cost_per_call(duration_s: float, memory_gb: float) -> float:
    """Стоимость одного вызова: фиксированная часть плюс потреблённые ресурсы."""
    return PER_REQUEST + duration_s * memory_gb * PER_GB_SECOND


def breakeven(vm_bill: float, ops_delta_hours: float, hour_cost: float,
              call_cost: float) -> tuple[float, float]:
    """Точка безубыточности в вызовах в месяц и в вызовах в секунду.

    ops_delta_hours — насколько больше часов в месяц съедает машина по сравнению
    с функциями. Именно эта разница, а не абсолютные трудозатраты, влияет на ответ.
    """
    calls = (vm_bill + ops_delta_hours * hour_cost) / call_cost
    return calls, calls / SECONDS_IN_MONTH


call = cost_per_call(duration_s=0.15, memory_gb=0.5)
only_bills = breakeven(vm_bill=30, ops_delta_hours=0, hour_cost=78, call_cost=call)
full_cost = breakeven(vm_bill=30, ops_delta_hours=1.5, hour_cost=78, call_cost=call)

print(f"вызов стоит {call:.8f} USD")
print("по счетам провайдера:   %.1f млн в месяц (%.1f в секунду)" % (only_bills[0] / 1e6, only_bills[1]))
print("по стоимости владения:  %.1f млн в месяц (%.1f в секунду)" % (full_cost[0] / 1e6, full_cost[1]))

Сложность здесь никакая — это арифметика за O(1). Ценность в том, что расчёт занимает пять минут и заменяет получасовой спор в чате.

Когда FaaS правильный ответ. Рваная и непредсказуемая нагрузка; события и интеграции (реакция на файл в хранилище, вебхук, сообщение в очереди); задачи, где ноль в простое важнее цены пика; команды без операционных компетенций. Когда неправильный. Ровная высокая нагрузка; жёсткие требования к хвостовым задержкам, где холодный старт бьёт по p99 (про хвосты — в треке производительности); длинные задачи; тяжёлые зависимости; необходимость держать пул соединений к базе, которая не любит сотни коннектов.

SaaS как уровень потребления: вы управляете только смыслом

Когда вы потребляете SaaS — систему учёта задач, почту, аналитику, биллинг-провайдера, — вам не остаётся ни одного технического слоя. Остаются данные, доступы и настройки. И именно поэтому набор рисков здесь другой, чем на нижних уровнях.

Что даёт. Ноль операционной работы, предсказуемый счёт, обновления «сами», часто — готовая совместимость с типовыми требованиями.

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

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

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

• «Вот перечень наших внешних сервисов, вот какие данные в каждый уходят и в какой стране они хранятся. Какие из этих передач требуют отдельного основания или уведомления?»
• «Договор с провайдером ограничивает его ответственность суммой платежей за три месяца. Наш договор с клиентом ограничивает нашу ответственность как? Есть ли между ними разрыв и насколько он велик?»
• «Что происходит с нашими данными, если провайдер прекращает обслуживание или расторгает договор в одностороннем порядке? В какой срок и в каком формате мы получим выгрузку?»
• «Мы работаем с клиентами в такой-то юрисдикции. Что из нашей текущей схемы размещения данных это запрещает?»

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

Что не переходит поставщику никогда

Соберём в одном месте то, что на картинке было выделено полосой. Ни один уровень не снимает с вас:

Последняя строка — про то, что показывает следующая диаграмма.

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

SLA: что вы на самом деле купили

SLA — единственный формальный документ, описывающий, на что вы вправе рассчитывать. Читать его нужно как инженерную спецификацию, а не как маркетинговое обещание.

Проценты в минуты. Месяц в 30 суток — это 43 200 минут. Отсюда:

Составная доступность. Если ваш путь запроса проходит через $n$ независимых компонентов, доступность цепочки — произведение:

$$A_{\text{цепочки}} = \prod_{i=1}^{n} A_i$$

Четыре сервиса по 99,9 % дают $0{,}999^4 \approx 0{,}9960$ — это около 173 минут простоя в месяц, почти три часа. Отсюда два практических правила: сокращайте число обязательных звеньев на критическом пути и не обещайте клиенту больше, чем произведение доступностей того, на чём вы стоите. Методика построения собственных обещаний — в главах SLI и SLO и бюджет ошибок.

Компенсация не равна убытку. Типовой механизм у крупных провайдеров: при нарушении порога вы получаете кредит на будущие платежи — обычно 10 % месячного счёта за услугу, 25 % при более серьёзном нарушении, до 100 % в крайних случаях. Считаем: счёт за услугу 4 000 USD в месяц, авария на четыре часа, кредит 25 % — 1 000 USD на будущие счета, не деньгами. Ваш собственный убыток за эти четыре часа — упущенная выручка плюс компенсации клиентам плюс отток — почти наверняка выше на порядок. Вывод не «SLA бесполезен», а «SLA — это стимул для провайдера и индикатор для вас, но не страховка».

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

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

Как выбирать уровень

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

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

Стоимость выхода: измеряется в человеко-неделях

Привязка к поставщику (lock-in) — не идеологический вопрос, а число. Его надо оценить до входа, а не тогда, когда захотелось выйти.

Из чего складывается счёт за выход:

1. Переписывание кода, завязанного на конкретные API. Самое очевидное и не самое дорогое.
2. Перенос данных. Здесь два разных расхода: время (терабайты по сети едут долго) и трафик на выход. Порядок величин у гиперскейлеров исторически 0,05–0,12 USD за гигабайт исходящего трафика; у VPS-провайдеров трафик часто включён в тариф. Регуляторное давление это меняет: европейский Data Act (Регламент (ЕС) 2023/2854) прямо направлен на устранение платы за смену провайдера, и крупные облака ещё в 2024 году объявили о бесплатном выводе данных при уходе. Проверяйте текущие условия конкретного провайдера — это как раз то место, где цифры устаревают за квартал.
3. Параллельная работа. Во время миграции вы платите двум провайдерам сразу, часто месяцами.
4. Переучивание команды и перенос всей операционной обвязки — мониторинг, алерты, роли, пайплайны.

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

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

• «Managed — значит не наша забота». Managed снимает эксплуатацию слоя, но не снимает ответственность за данные, доступы и восстановление. История из начала главы — ровно про это.
• Бэкап, из которого никогда не восстанавливались. Единственная проверка бэкапа — восстановление на чистый инстанс с замером времени. Всё остальное — вера.
• Выбор уровня по презентации, а не по нагрузке. «Перейдём на serverless и сэкономим» без подсчёта числа вызовов — это лотерея. Посчитайте по формуле выше, займёт двадцать минут.
• Сравнение счетов вместо стоимости владения. И наоборот: оправдание любой цены «зато не надо администрировать», когда администрировать там было полчаса в месяц.
• Обещание клиенту доступности выше произведения доступностей поставщиков. Арифметика не прощает.
• Отсутствие своего мониторинга поверх чужого сервиса. Без своих данных вы не докажете простой и не получите даже символический кредит.
• Смешение уровней в одной системе без явного решения. Часть на PaaS, часть на функциях, часть на своих машинах — не проблема сама по себе; проблема, когда никто не может сказать, почему именно так, и каждая часть требует своей компетенции дежурного.
• Игнорирование квот. На верхних уровнях лимит на конкурентность, на размер запроса или на число подключений — это ваш потолок производительности, и упираются в него внезапно, обычно в пике (режимы отказов).
• Перенос требования о размещении данных в конец проекта. Юрисдикционное требование меняет выбор провайдера, а не настройку — узнавать о нём за неделю до запуска дорого.

Мини-практика: карта уровней вашей системы

Упражнение на полтора часа, дающее непропорционально много.

1. Выпишите все компоненты, из которых состоит ваш продакшн, включая внешние сервисы (почта, платежи, аналитика, ошибки, CI).
2. Для каждого проставьте уровень: своё железо, IaaS, PaaS, FaaS, SaaS.
3. Для каждого ответьте на четыре вопроса из начала главы: кто платит, кого будят, кто отвечает перед клиентом, кто может починить.
4. Проставьте обещанную доступность и перемножьте те, что лежат на критическом пути. Сравните с тем, что вы обещаете клиенту.
5. Оцените стоимость выхода в человеко-неделях по каждому. Отметьте те, где она больше квартала.
6. Отметьте компоненты, где восстановление ни разу не проверялось. Это ваш список задач на ближайший месяц.

Результат — одна таблица на страницу. В большинстве команд она обнаруживает как минимум одно обещание, не подкреплённое арифметикой, и как минимум один непроверенный бэкап.

Мини-итог

• Уровень облака — это высота линии ответственности в стеке, а не поколение технологии. Выше линия — меньше операционной работы и меньше контроля, и это всегда размен, а не улучшение.
• Данные, доступы и настройки не переходят поставщику ни на одном уровне. Обязательство перед вашим клиентом — тоже.
• IaaS даёт контроль и требует людей. PaaS даёт скорость и требует жить внутри его предположений. FaaS даёт ноль в простое и требует идемпотентности и жизни без состояния. Покупной SaaS даёт отсутствие работы и требует управлять тем, что в него уходит.
• Считайте деньги формулой, а не ощущением: точка безубыточности FaaS против машины сдвигается в пять раз, стоит добавить в расчёт час инженера.
• SLA — спецификация, а не страховка: переводите проценты в минуты, перемножайте доступности цепочки и помните, что кредит на порядок меньше вашего убытка.
• Стоимость выхода измеряется в человеко-неделях и оценивается до входа. Дешёвую дверь наружу стоит держать там, где она почти бесплатна; в остальных местах — осознанно соглашаться на привязку.
• Правовые вопросы — к юристу, но формулировать их обязан инженер: перечень внешних сервисов, состав данных, страна хранения, условия расторжения.

Источники

• NIST SP 800-145, «The NIST Definition of Cloud Computing» — https://csrc.nist.gov/pubs/sp/800/145/final
• AWS Shared Responsibility Model — https://aws.amazon.com/compliance/shared-responsibility-model/
• Microsoft, «Shared responsibility in the cloud» — https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
• The Twelve-Factor App — https://12factor.net/
• Cloud Native Buildpacks (CNCF) — https://buildpacks.io/
• AWS Lambda: квоты и ограничения — https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
• Cloudflare Workers: лимиты платформы — https://developers.cloudflare.com/workers/platform/limits/
• Firecracker — https://firecracker-microvm.github.io/
• Регламент (ЕС) 2023/2854 (Data Act) — https://eur-lex.europa.eu/eli/reg/2023/2854/oj
• Heroku, «Next Chapter» (о прекращении бесплатных планов) — https://blog.heroku.com/next-chapter

Что дальше

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

Многотенантность: изоляция, данные и стоимость обслуживания