[ 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.