Сценарий повторяется из квартала в квартал: протокол объявляет incentivized testnet или горящую кампанию и просит ноды в нескольких регионах через 72 часа. Железо за такой срок не закажешь, у поставки сроки больше самого testnet'а. Мы поднимаем такие burst'ы для клиентов по отработанному runbook'у, и весь смысл в том, что 72 часа уходят не на «придумать как», а на исполнение заранее заготовленного. Дальше разбираем этот runbook.
Почему 72 часа это не про железо
За 72 часа невозможно завезти и смонтировать железо в нескольких странах, и пытаться не нужно. Burst по определению живёт в облаке, потому что только облако поднимает мощности в новом регионе за минуты. Вопрос не «где взять серверы», а «насколько быстро мы превращаем пустой аккаунт в работающий распределённый флот». А это определяется тем, что заготовлено до старта, а не тем, что мы успеем написать за три дня.
Что заготовлено заранее
72 часа выигрываются месяцами раньше. К моменту старта у нас уже есть:
- Инфраструктура как код. Terraform-модули на регионы, сети, инстансы. Поднять регион это применить модуль с другими параметрами, а не собирать его руками под стресс.
- Готовые образы нод. Конфигурация ноды, мониторинг-агенты, ключи-плейсхолдеры зашиты в образ заранее. Новая машина приходит уже почти готовой, а не настраивается после запуска.
- Шаблоны выбора региона. Какие провайдеры в каких регионах живут, где у нас уже есть аккаунты с поднятыми лимитами, где быстрый транзит. Это таблица, а не ресёрч на ходу.
- Мониторинг из коробки. Новые ноды сами регистрируются в мониторинге и начинают слать метрики, без ручного добавления каждой.
Заготовка это и есть продукт. Команда, которая в момент старта пишет Terraform с нуля, проиграет окно, как бы она ни торопилась.
Скрытые ловушки: дело в квотах, а не в ёмкости
Самый частый срыв burst'а это не нехватка серверов, а лимиты аккаунта. Новый или малоиспользуемый аккаунт у облачного провайдера приходит с низкими квотами на типы инстансов и на регионы, и заявка на их повышение обрабатывается не мгновенно, иногда часами или сутки. В горящем testnet'е сутки на одобрение квоты съедают треть окна, и об этом узнаёшь ровно в тот момент, когда уже поздно.
Поэтому в нашем runbook'е проверка и предзаказ квот идёт первым шагом, до всякого деплоя: лимиты на нужные регионы и типы карт/инстансов поднимаются заранее, на спокойную голову. Это та ловушка, которая чуть не топит первые сутки у команд, делающих burst впервые.
Раскатка без single-region риска
Когда заготовка на месте, а квоты подняты, сама раскатка это исполнение. Ноды поднимаются сразу в нескольких регионах у разных провайдеров, а не в одном: incentivized testnet часто оценивает географическое разнообразие, и складывать весь burst в один регион это и риск по оценке, и общий blast radius на один сбой. Cutover на боевую работу делаем после того, как ноды прошли первую сетевую проверку, а не по факту «инстанс поднялся».
Гашение: burst должен уметь исчезать
Половина экономики burst'а это умение выключиться. Когда кампания закончилась, флот гасится так же по коду, как поднимался: убрали инстансы, сняли с мониторинга, закрыли аккаунтные ресурсы, чтобы не капал счёт за забытую машину в дальнем регионе. Burst, который умеет аккуратно исчезнуть, стоит ровно столько, сколько длился; burst, который оставляет хвосты, утекает деньгами ещё месяцами.
Как это у клиента
На полигоне мы прогоняем этот runbook вхолостую: поднимаем multi-region флот, проверяем квоты, делаем cutover и гасим, замеряя, сколько реально занимает каждый шаг. На клиентском контракте это превращается в конкретный план под их протокол: какие регионы, какие провайдеры, где предзаказать лимиты, по какому критерию делаем cutover.
Если вам нужно развернуть multi-region мощности под горящее окно и аккуратно их погасить, это то, что мы закрываем через deploy и scale. Хотите подготовить runbook под ваш ближайший testnet заранее: напишите нам.