Пилот случайно стал продакшеном: как легализовать инфраструктуру задним числом

MAATRIX

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

Как пилот тихо превращается в продакшен

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

Ситуация похожа на историю с MVP, собранным за выходные хакатон-спринта — там тоже инфраструктура сначала оптимизируется под скорость, а не под надёжность. Но сценарий пилота отличается тонким нюансом: у MVP обычно есть чёткий момент запуска, после которого команда осознанно решает продолжать или нет (разбор того, что чинить в первую очередь после такого спринта — в статье про чек-лист первого рабочего понедельника). У пилота момента «мы вкладываемся всерьёз» может не быть вообще — есть только постепенное расширение зоны ответственности при инфраструктуре, которая всё это время не менялась.

Есть три типичных признака, что пилот незаметно пересёк черту:

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

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

Шаг 1: честно признать текущий статус

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

Вопросы, на которые нужны честные ответы, а не удобные:

• Сколько реальных пользователей или клиентов сейчас зависят от системы — не «сколько подключено формально», а сколько реально её используют каждую неделю?
• Есть ли среди них те, для кого простой на несколько часов означает финансовые потери, нарушение договорных обязательств или репутационный удар?
• Проходят ли через систему деньги, персональные данные, договорные обязательства или что-то ещё, что подпадает под регуляторные требования?
• Ссылаются ли на данные этой системы в отчётах, которые видит руководство или внешние стороны (инвесторы, аудиторы, партнёры)?
• Если систему выключить прямо сейчас без предупреждения — кто узнает об этом в первые 10 минут, а не через день?

Соберите ответы в таблицу — это заодно станет черновиком документа для шага 4:

Последние две строки — не абстракция. RTO (recovery time objective) и RPO (recovery point objective) — это не технические метрики ради метрик, а способ перевести ощущение «ну, это важно» в конкретное число, с которым можно работать: «простой до 4 часов — приемлем, потеря данных больше суток — недопустима», например. Если на эти вопросы никто в команде не может ответить уверенно — это само по себе диагноз: система уже критична, просто это не формализовано.

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

Шаг 2: аудит надёжности — что реально есть, а что кажется

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

Базовый чек-лист на один день:

Бэкапы.

• Существуют ли актуальные копии данных, снятые не позднее чем сутки-двое назад?
• Хранятся ли они физически отдельно от продакшен-сервера (не в том же датацентре, не на том же диске)?
• Была ли хотя бы раз проведена пробная процедура восстановления — не «файл скопировался», а полноценный тестовый запуск из копии?

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

Мониторинг и алерты.

• Узнаёт ли кто-то из команды о падении сервиса раньше, чем об этом напишет клиент?
• Настроены ли алерты хотя бы на базовые вещи: доступность сайта/API, свободное место на диске, нагрузка на CPU и память?
• Приходят ли эти алерты туда, где их реально увидят (мессенджер, а не почта, которую проверяют раз в день)?

Точка единого отказа.

• Что произойдёт, если сервер физически недоступен (авария у хостера, DDoS, человеческая ошибка при обновлении)? Есть ли план восстановления, или ответ «будем разбираться на месте»?
• Кто, кроме одного человека, знает, как устроена система и как её перезапустить? Если ответ «только один разработчик, и он сейчас в отпуске» — это критичный риск.

Секреты и доступы.

• Пароли и ключи API всё ещё лежат в коде или конфигах в открытом виде, потому что «так было проще на старте»?
• Кто имеет доступ к серверу, и остался ли там доступ у людей, которые уже не должны его иметь?

По итогам аудита у вас получится список конкретных дыр — не абстрактное «всё плохо», а перечень: «бэкап не проверялся 4 месяца», «алерт на диск не настроен», «пароль от базы в открытом виде в docker-compose.yml». Это ровно то, что нужно на следующем шаге.

Шаг 3: закрыть критичные дыры по приоритету

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

Логика приоритизации похожа на подход из статьи про аудит сервера своими силами за выходные: сначала — то, что нельзя исправить постфактум (потерянные данные), затем — то, что можно исправить, но дорого (длительный простой), и только потом — удобства и техдолг, которые не угрожают бизнесу напрямую.

Практический порядок для первых одной-двух недель:

1. Настроить рабочий бэкап с проверкой восстановления. Если данные вообще не защищены — это приоритет номер один без исключений. Даже простой скрипт с pg_dump по cron, копирующий архив на отдельное хранилище (не на тот же диск), закрывает 80% риска до появления более зрелого решения.

# минимальный рабочий вариант на старте — не идеал, но лучше, чем ничего
0 3 * * * pg_dump -Fc mydb | gzip > /backup/mydb_$(date +\%Y\%m\%d).sql.gz
# и обязательно — копия за пределы сервера, например через rclone на S3-совместимое хранилище
0 4 * * * rclone copy /backup remote:project-backups --min-age 1h

1. Поставить базовый мониторинг доступности. Не сложную систему метрик, а простую проверку «сервис отвечает / не отвечает» с алертом в мессенджер. Uptime Kuma или healthchecks.io разворачиваются за час и закрывают риск «узнали о падении от клиента».

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

1. Зафиксировать, кто имеет доступ к серверу, и отозвать лишнее. Часто на этапе пилота доступ раздавали свободно «на всякий случай» — теперь, когда система критична, это нужно сузить до необходимого минимума.

1. Только после первых четырёх пунктов — переходить к более капитальным вещам: вынос базы на отдельный инстанс, полноценный стек метрик (Prometheus/Grafana или аналог), документация архитектуры, тестовый контур для проверки изменений перед выкладкой на прод.

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

Шаг 4: сделать капитализацию пилота официальной задачей команды

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

Что нужно сделать, чтобы это не повторилось:

• Назначить явного ответственного. Не «кто-нибудь из бэкенда», а конкретный человек, у которого это в списке задач, а не в списке благих намерений.
• Выделить время как на обычный проект, а не как на побочную активность между тикетами. Если для остальных задач команда планирует спринты, у капитализации пилота должен быть свой спринт или хотя бы фиксированная доля времени, а не «в свободные часы».
• Оценить объём работы отдельно от аудита рисков. Аудит из шага 2 даёт список того, что критично закрыть немедленно; капитализация — это более широкая задача довести систему до состояния, в котором она без опасений выдерживает свою реальную нагрузку и роль. Это может занять от одной до нескольких недель в зависимости от масштаба — конкретный срок сильно зависит от вашей системы, и универсальной цифры здесь нет.
• Договориться о критериях готовности заранее. Что именно должно быть верно, чтобы сказать «система легализована»: рабочие бэкапы с проверкой, мониторинг с алертами, документация, понятная процедура доступа, план восстановления после сбоя. Список из шага 2 — хорошая основа для этих критериев.

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

Задокументировать новый статус для всей команды

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

Минимальный набор для документации, который стоит вести и обновлять — подробнее в статье про то, что стоит фиксировать про сервер:

• Статус системы одной фразой в самом начале документа: «production, критично для процессов X и Y, SLA не формализован, но простой более N часов недопустим».
• RTO/RPO из шага 1 — зафиксированные, а не подразумеваемые значения.
• Кто зависит от системы — список клиентов/процессов, а не абстрактное «пользователи».
• Что уже закрыто из рисков, а что ещё в работе — прозрачный статус, а не молчаливое предположение, что всё уже в порядке.
• Кто отвечает за систему — на случай инцидента, отпуска ответственного, увольнения.
• Процедура на случай сбоя — хотя бы в три-четыре пункта: куда смотреть, кого звать, откуда восстанавливать.

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

Частые вопросы