Как посчитать стоимость перехода на свою инфраструктуру

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

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

Почему экспорт исходников не равен готовности к переезду

Экспорт исходников закрывает право доступа к коду, но не переносит состояние работающей системы. В репозитории обычно есть React-приложение, сервер на Go, миграции схемы и зависимости. За его пределами могут жить PostgreSQL, объектные файлы, очереди, планировщик, ключи подписи, почтовый сервис, записи DNS, сертификаты, метрики и история развертываний.

Различие между переносимостью кода и переносимостью сервиса часто стирают. Код переносим, если его можно открыть и изменить. Сервис переносим, если новая команда может воспроизвести его поведение на другой площадке, перенести текущее состояние и затем поддерживать результат в заданное время восстановления. Второе свойство заметно дороже первого.

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

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

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

Как провести инвентаризацию до оценки

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

Начните с воспроизводимого поиска, а не с совещания по памяти. В корне репозитория можно выполнить:

find . -maxdepth 3 -type f \( -name 'Dockerfile*' -o -name 'compose*.yml' -o -name 'compose*.yaml' -o -name 'go.mod' -o -name 'package.json' -o -name 'pubspec.yaml' -o -name '*.sql' -o -name '.env*' \) -print | sort
grep -RInE 'os\\.Getenv|process\\.env|DATABASE_URL|REDIS_URL|S3_|SMTP_|OAUTH|WEBHOOK|CRON' . | grep -v '/.git/' | grep -v '\\.lock:'

Первая команда показывает заявленные точки сборки и конфигурации. Вторая дает строки вида internal/mail/client.go:27: os.Getenv("SMTP_URL") или web/src/api.ts:8: process.env.VITE_API_URL. Это не список готовых секретов, а карта вопросов. Значение может поступать под другим именем или формироваться платформой во время запуска.

Дальше соберите реестр зависимостей. Для каждой строки запишите текущего поставщика, адрес, протокол, учетную запись, объем или частоту, ответственного и способ проверки. Отдельно пометьте зависимость как переносимую, заменяемую или неизвестную. «Заменяемая» означает, что код придется адаптировать, а не что работа исчезает.

Проверьте также скрытые входы: вебхуки платежей, OAuth-перенаправления, разрешенные источники CORS, мобильные deep links, почтовые DNS-записи и IP-адреса в списках доступа партнеров. Исходящий HTTP-вызов видно в коде, а партнерский запрос на старый адрес там может не оставить следа.

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

Сколько стоит перенос PostgreSQL

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

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

SELECT current_setting('server_version') AS version;
SELECT extname, extversion FROM pg_extension ORDER BY 1;
SELECT pg_size_pretty(pg_database_size(current_database())) AS database_size;
SELECT schemaname, relname, n_live_tup, n_dead_tup
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC
LIMIT 20;

Затем проверьте роли, владельцев объектов, кодировки, правила сортировки, последовательности, большие объекты и расширения. Обычный pg_dump переносит одну базу, но не все глобальные роли кластера. Если приложение зависит от ролей, отдельно получите определения через pg_dumpall -g и просмотрите их до восстановления. Не переносите пароли и сверхправа автоматически в среду с другой моделью доступа.

Документация PostgreSQL разделяет SQL-дамп, копию файловой системы и непрерывное архивирование. Для перехода между машинами и версиями чаще подходит логический дамп. Формат custom дает выборочное восстановление через pg_restore, а directory поддерживает параллельный экспорт. Документация также предупреждает, что параллельный pg_dump использует несколько соединений и согласованные снимки. Это важно: набор отдельных выгрузок таблиц без общего снимка может описывать состояние, которого никогда не существовало.

Для первой репетиции годится такая последовательность:

pg_dump -Fc -O -x -f app.dump "$SOURCE_DATABASE_URL"
createdb app_restore_test
pg_restore -e -O -x -d app_restore_test app.dump
psql "$TARGET_DATABASE_URL" -f checks.sql

Ожидаемый результат последней команды должен быть формализован. Например, checks.sql возвращает по одной строке на проверку: имя проверки, фактическое значение и ok. Сравните число учетных записей, активных заказов, связей без родителя, максимальные идентификаторы и контрольные суммы по выбранным неизменяемым наборам. Факт успешного завершения pg_restore не доказывает целостность бизнес-данных.

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

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

Пользовательские файлы живут не в репозитории

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

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

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

Целевое хранилище должно сохранить ожидаемый контракт приложения. Проверьте тип содержимого, заголовки кеша, загрузку по частям, максимальный размер, приватные ссылки, срок их действия и правила удаления. Если приложение выдает временный подписанный адрес, старый секрет подписи и старый домен влияют на доступ к уже отправленным ссылкам. Бизнес должен решить, обязаны ли такие ссылки пережить переключение.

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

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

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

Авторизация требует отдельного плана

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

Если приложение хранит парольные хеши в PostgreSQL, перенос таблицы обычно сохраняет возможность входа. Но проверьте алгоритм, параметры хеширования, наличие отдельного pepper-секрета и код, который повышает стоимость хеша после успешной проверки. Потерянный pepper нельзя восстановить из базы. Его отсутствие превращает тихий перенос в принудительный сброс паролей, уведомления и нагрузку на поддержку.

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

OWASP Session Management Cheat Sheet требует обновлять идентификатор сессии после изменения уровня привилегий и задавать абсолютный срок действия. Я бы не переносил исторические сессии вслепую только ради незаметного переключения. Сначала нужно доказать, что новая система одинаково обрабатывает срок действия, флаги cookie, домен, HTTPS, выход, блокировку пользователя и отзыв полномочий.

Внешний OAuth добавляет настройки, которых нет в исходниках: redirect URI, client ID, секрет клиента и иногда подтверждение домена. Смена домена без заранее добавленного обратного адреса ломает вход даже при безупречной сборке. Для каждого провайдера включите в оценку доступ к кабинету, изменение конфигурации, тест существующей связки и сценарий, когда один внешний аккаунт ошибочно создает второго локального пользователя.

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

Сборка должна работать без прежней платформы

Стоимость сборки равна работе по превращению репозитория в повторяемый артефакт, а не одному успешному запуску на ноутбуке разработчика. Зафиксируйте версии Go, Node.js, менеджера пакетов, Flutter, системных библиотек и команд сборки. Затем запустите процесс в чистом окружении без кешей и личных учетных данных.

Для Go проверьте go.mod, go.sum, build tags, CGO и приватные модули. Справочник Go Modules объясняет, что GOPRIVATE управляет обращением к закрытым путям и не дает отправлять сведения о них публичному прокси и базе контрольных сумм. Если сборка зависит от приватного репозитория, в смете нужны сервисная учетная запись, сетевой доступ, закрепленные права и способ обновления токена.

Для React отдельно учитывайте конфигурацию времени сборки. Переменная, встроенная в клиентский bundle, уже не секрет, даже если называлась API_SECRET. Проверьте базовый URL API, source maps, правила кеширования статических файлов и поведение старой вкладки браузера после выпуска новой версии. Хешированные имена файлов помогают, но сервер должен достаточно долго отдавать старые ресурсы при поэтапном обновлении.

Flutter-приложение расширяет границу проекта. Собрать файл недостаточно: нужны ключи подписи, доступ к кабинетам распространения, идентификаторы приложения, push-уведомления, universal links или app links и совместимость старой версии клиента с новым API. Если публикация мобильной версии не входит в конкретный переход, это надо явно записать. Иначе она появится в конце как «небольшое дополнение» с отдельным циклом проверки.

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

Не советую начинать с оркестратора контейнеров только потому, что он считается стандартом. Для одного сервера Docker Compose с явной конфигурацией, политикой перезапуска и внешними резервными копиями иногда дешевле и понятнее. Сложный кластер оправдан требованиями к отказоустойчивости и масштабу, а не самим фактом переезда.

Секреты нельзя просто скопировать

Секреты нужно обнаружить, классифицировать и по возможности заменить, потому что экспорт мог пройти через рабочие станции, архивы и временные каналы. К секретам относятся пароль базы, ключи подписи сессий, OAuth-данные, SMTP-пароль, токены вебхуков, ключи push-уведомлений, закрытые ключи TLS и доступ к резервным копиям.

OWASP Secrets Management Cheat Sheet советует ограничивать права на каждый секрет, автоматизировать ротацию и фиксировать зависимости, которые она может сломать. Это полезнее общего требования «хранить безопасно». Для сметы нужен жизненный цикл каждого значения: кто создает, кто читает, как меняет, как отзывает и как приложение ведет себя во время смены.

Сделайте манифест без значений:

secrets:
  DATABASE_PASSWORD:
    owner: platform
    consumers: [api, worker]
    rotate: before_cutover
  SESSION_SIGNING_KEY:
    owner: security
    consumers: [api]
    rotate: dual_key_window
  SMTP_PASSWORD:
    owner: operations
    consumers: [worker]
    rotate: after_mail_test

Такой файл не раскрывает данные, но показывает объем работы. Он предотвращает знакомый сбой: API запустили с новым паролем базы, а фоновый обработчик остался со старым и молча перестал отправлять письма.

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

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

Домен переключают после репетиции трафика

Цена переноса домена складывается из DNS, сертификата, внешних обратных адресов, кешей и плана возврата. Изменить A-запись легко. Сложнее добиться того, чтобы старые и новые клиенты получали совместимые ответы во время распространения записи.

За несколько дней до окна проверьте владельца домена и доступ к DNS, затем уменьшите TTL до разумного для переключения значения. Старый высокий TTL продолжит действовать, пока не истечет, поэтому изменение за минуту до работ ничего не ускорит. Не обещайте точное время распространения: рекурсивные резолверы и локальные кеши подчиняются разным условиям.

Поднимите новый адрес заранее и проверьте его без изменения публичной записи. Можно направить тестовый поддомен или локальную запись hosts на новый IP, пройти HTTPS, API, загрузку файлов, WebSocket-соединения и вход через внешнего провайдера. Сертификат должен выпускаться и обновляться автоматически, а команда должна знать, где увидеть ошибку продления.

Составьте реестр всего, что привязано к имени или IP: CORS, cookie domain, callback URL, вебхуки, SPF и DKIM для почты, разрешенные адреса партнеров, мобильные links и политики межсетевого экрана. DNS переносит имя, но не меняет эти доверительные связи.

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

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

Фоновые задачи часто определяют реальный простой

Фоновые задачи нужно переносить как самостоятельные сервисы с состоянием, расписанием и правилом повторов. К ним относятся рассылки, обработка файлов, очистка данных, синхронизация с партнерами, формирование отчетов и отложенные действия. Они редко видны при ручной проверке интерфейса.

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

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

Вторая ошибка возникает при потере очереди между снимком базы и запуском нового worker. Если очередь хранится в PostgreSQL, ее захватит согласованный дамп, но часть задач может находиться в состоянии running. Новый обработчик должен уметь вернуть зависшие задания после истечения аренды. Если очередь внешняя, нужен отдельный экспорт, дренирование или период параллельной доставки.

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

Наблюдаемость для worker должна отвечать на четыре вопроса: запускается ли он, растет ли очередь, сколько задач завершилось ошибкой и когда последний раз успешно отработало расписание. Журнал без сигнала об отсутствии событий не поймает умерший планировщик.

Эксплуатация начинается в день переключения

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

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

Журналы приложения должны попадать за пределы процесса, иначе перезапуск удалит причину аварии. Согласуйте срок хранения, маскирование персональных данных и секретов, поиск по идентификатору запроса и ограничение доступа. Полный debug-журнал в рабочей среде быстро создает счет за диск и риск утечки. Слишком короткий журнал оставляет команду без следов после поздней жалобы пользователя.

Метрики нужно выбирать по отказам, которые бизнес хочет заметить. Загрузка CPU редко объясняет, почему перестали создаваться заказы. Полезнее видеть долю ошибок API, задержку основных операций, число успешных входов, подключения к базе, свободное место, возраст последней копии и состояние очередей. У каждой тревоги должен быть порог, канал доставки и действие получателя.

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

Обновления операционной системы, PostgreSQL, контейнеров и библиотек образуют постоянный поток работы. В смету входят тестовый контур, окно обслуживания, проверка совместимости и возврат. Если никто не назначен владельцем обновления, версия останется старой до первой уязвимости или несовместимости, а затем работа станет аварийной и дорогой.

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

Завершает контур инструкция дежурному: где увидеть проблему, как оценить влияние, как остановить выпуск, как вернуть предыдущий артефакт и кому сообщить. Ее надо выполнить в учебной аварии. Документ, который не открывали под ограничением времени, остается предположением, а не средством восстановления.

Как собрать полную смету

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

Для каждого компонента заведите строку со следующими полями:

Компонент | Разовая работа | Внешние расходы | Простой | Ежемесячно | Доказательство
PostgreSQL | анализ, дамп, восстановление, сверка | временный диск и стенд | окно записи | база, копии, трафик | протокол восстановления
Авторизация | перенос ключей, сессий и OAuth | уведомления при повторном входе | возможный выход пользователей | аудит доступа | матрица тестов
Сборка | чистая сборка и конвейер | хранилище артефактов | нет | минуты сборки | версия артефакта
Домен | DNS, TLS, callbacks | сертификат или сервис DNS | распространение записи | DNS и трафик | журнал переключения
Фоновые задачи | перенос расписаний и очередей | брокер при наличии | остановка обработки | вычисления и мониторинг | тест повтора

Разовую трудоемкость считайте по ролям, а не одной усредненной ставке:

разовая стоимость =
  часы backend * ставка backend
+ часы frontend/mobile * ставка команды
+ часы DevOps * ставка DevOps
+ часы QA * ставка QA
+ часы управления * ставка владельца работ
+ внешние разовые расходы
+ резерв на подтвержденные неизвестные

«Подтвержденные неизвестные» не означают произвольные 30 процентов сверху. Это конкретные пункты инвентаризации без ответа: неизвестен объем файлов, нет доступа к OAuth, не проверена версия расширения, отсутствует ключ подписи. Для каждого задайте дешевое исследование и развилку стоимости. После исследования резерв должен уменьшаться.

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

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

Сравнивайте минимум три сценария: остаться на текущем размещении, перенести на управляемые сервисы и обслуживать все самостоятельно. Своя инфраструктура не обязана означать собственный PostgreSQL на том же сервере. Управляемая база часто дороже по счету, но дешевле с учетом дежурства, обновлений и восстановления.

Репетиция превращает оценку в обязательство

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

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

Репетиция считается успешной, когда команда выполнила такие условия:

1. Новый контур разворачивается по сохраненной инструкции из чистого состояния.
2. Проверки данных возвращают ожидаемые значения, а основные сценарии проходят.
3. Секреты выданы по утвержденным правам и хотя бы один из них заменен без аварии.
4. Фоновые задачи не потерялись и не выполнились дважды.
5. Резервная копия нового контура восстановлена в отдельную базу.

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

Если приложение экспортировано из TakProsto, в оценке все равно нужно проверить собственную сборку, PostgreSQL, домен, секреты, snapshots и rollback по фактическому проекту, поскольку наличие этих возможностей не заменяет приемку нового контура. Экспорт дает хорошую исходную позицию, а самостоятельность появляется после того, как другая команда повторила развертывание и восстановление без доступа к прежней площадке.

Не подписывайте фиксированную цену до инвентаризации и первой репетиции. Честный ранний результат состоит из диапазона, списка допущений и стоимости уточнения каждого неизвестного. После тестового переноса диапазон сужается, окно простоя опирается на замер, а ежемесячный счет включает человеческую эксплуатацию. Именно такую оценку можно сравнивать с ценой дальнейшего использования платформы.