[ FIXED PLAN ] →
План деплоя за 48ч. Архитектура, подбор железа, этапы, бюджет — коротко и по делу. Цена и срок фиксированы.
Чтобы быстро понять объём работ и сроки до подписания месячного контракта.
> process
Как мы заходим в проект
От первого созвона до подписанного SLA: один путь, без серых зон. Discovery, план деплоя за 48ч, выбор формата работы, дежурство follow-the-sun, change management, off-boarding.
Discovery (1 созвон, 30 мин)
Один созвон, без всяких sales-воронок. Цель у него простая — понять scope, чтобы написать план деплоя за 48ч. Обычно спрашиваем вот что:
- Workload. Валидатор, RPC, LLM-инференс, prover, DePIN-парк, что-то ещё.
- Стек. Что уже выбрано, что открыто. Cosmos SDK / Geth / vLLM / SP1 / Filecoin и т.д.
- Регионы. Где нужны точки присутствия, какие юрисдикции исключены.
- Дедлайны. Дата launch'а, hard-fork, incentivized testnet, IPO раунда GPU.
- SLA-цели. Что считаем downtime, какой response time приемлем, кто платит за инцидент.
- Биллинг и ключи. Ваш cloud-аккаунт или наш, кто держит ключи валидаторов.
На созвоне всегда инженер, а не sales. И если в первом сообщении уже понятно, что вы хотите, то созвон можно пропустить и сразу пойти в план.
48-часовой план деплоя
За 48 часов после Discovery мы возвращаемся с одностраничным планом, и он fixed-price: цена и срок известны ещё до подписания месячного контракта.
Что внутри:
- Архитектура. Диаграмма топологии: регионы, типы нод, сеть, observability-стек.
- Подбор железа. Кто поставщик, какой supply window, во сколько обойдётся compute / GPU / storage.
- Roadmap. Week 1 / 2 / 4 c конкретными deliverables, milestone-датами и check-in'ами.
- Бюджет. Разбивка по статьям: hardware, инженерные часы, third-party (PagerDuty, monitoring).
- Риски и mitigation. Что может пойти не так, как откатываемся.
План отбивается, даже если дальше мы не работаем: у вас на руках остаётся архитектура и оценка бюджета на бумаге. Стоимость зависит от scope, обычно $X-$XX.
engagement models
Три формы контракта: обычно начинаем с малого, а расширяемся по мере доверия.
[ MONTHLY ] →
Месячный контракт. Полный деплой + последующая эксплуатация. Дежурство, патчи, релизы: в одном контракте.
Подходит, когда инфра уже в проде и нужна стабильная команда.
[ HOURLY ] →
Почасовая оплата. Под пиковые сценарии: incentivized testnet, hard-fork, миграция, экстренный наём.
Когда заранее не известен объём, но известна срочность.
SLA tiers
Три уровня покрытия после передачи в operate-фазу, а выбираете вы их под критичность.
| Tier | Response p95 (Sev-1) | Coverage | Incident report | Engineer hours / мес |
|---|---|---|---|---|
| Bronze | 30 мин | Business hours, 5×8 | В течение 48ч | 40 |
| Silver | 15 мин | 24/7 on-call ротация | В течение 24ч | 80 |
| Gold | 5 мин | 24/7 с выделенным инженером | В течение 12ч | 160+ |
on-call rotation
Дежурим follow-the-sun. Три таймзоны, передача смены каждые 8 часов: инцидент в 3 ночи попадает к инженеру, у которого 11 утра, а не к разбуженному.
- UTC+3 · 00:00 → 08:00 UTC. Европа / Россия / Ближний Восток.
- UTC+0 · 08:00 → 16:00 UTC. Западная Европа / UK / Африка.
- UTC-5 · 16:00 → 00:00 UTC. Северная и Южная Америка.
Передача смены фиксируется в shared runbook: что случилось за смену, что открыто, какие watch-items. Инциденты на стыке двух смен ведёт инженер, у которого утро.
change management
Заходим в ваши системы по схеме «branching first, deploy second». Все изменения через PR, ни одного `kubectl apply` вживую.
- Доступ. Read-only IAM роль на старте. Write-роль с MFA выдаётся пофайлово, под scope контракта.
- Branching. Feature branch на каждое изменение. Никаких commit'ов в main / production.
- PR-flow. CI прогоняет terraform plan / lint / unit-tests. Human-review обязательный, два аппрува на prod.
- Runbook на каждый change. Что катим, как откатываем, кто owner, что мониторим первые 24ч.
- Audit trail. Все действия в git + cloud audit log. Прозрачно для вашей security-команды.
incident severity matrix
Четыре уровня severity. Каждый имеет своё определение, response target и формат коммуникации. Не «critical/high/medium/low» из тикет-системы: конкретные пороги.
| Severity | Определение | Response target (Silver) | Коммуникация |
|---|---|---|---|
| Sev-1 | Полный outage или риск slashing'а / data loss. Деньги горят сейчас. | 15 мин p95 | Звонок + Slack war-room. Updates каждые 30 мин до восстановления. |
| Sev-2 | Деградация под SLO (p99 latency, частичный outage региона). | 1 час | Slack incident channel. Updates каждые 2 часа. |
| Sev-3 | Минорный баг, неблокирующая алерта. Можно подождать рабочий день. | 1 рабочий день | Тикет + дневной standup. |
| Sev-4 | Cosmetic / запрос на изменение без срочности. | 1 неделя | Backlog / спринт-планирование. |
Разбор инцидента мы пишем после каждого Sev-1 в течение 5 рабочих дней. Пишем без поиска виноватых, со списком исправлений и владельцами, и открываем его клиенту.
off-boarding
Контракт заканчивается — и вы забираете инфру себе или передаёте другому оператору. У нас при этом ничего не «удерживается», а vendor lock-in нулевой. Off-boarding идёт по чек-листу за 2-4 недели, в зависимости от объёма.
- Передача доступов. Снимаем наши IAM-роли, отзываем ключи, ротируем секреты. Полный audit-лог.
- Hand-off документ. Текущее состояние, открытые тикеты, watch-items, контакты вендоров.
- Runbook walkthrough. Один созвон, на котором проходим каждый runbook с принимающей командой.
- Shadow period. 1-2 недели мы доступны read-only для вопросов «как тут устроено».
- Финальный audit. Подписанный документ: что передано, что осталось у нас (обычно ничего).
Всё, что мы строили, с самого начала лежит в ваших git-репозиториях и cloud-аккаунтах, поэтому off-boarding в основном про доступы и knowledge transfer.