Демо для клиента живёт третий год: как превратить его в нормальный сервис

MAATRIX

Два года назад вы за неделю собрали демо, чтобы показать клиенту, как будет выглядеть решение. Демо понравилось, сделку закрыли — а ссылка так и осталась работать, потому что клиент начал ей пользоваться. Сначала иногда, потом каждую неделю, а сейчас его сотрудники открывают её каждое утро наравне с почтой. Формально это по-прежнему демо-стенд без SLA и без обязательств. Фактически — если он ляжет в среду в 11 утра, для клиента это будет такой же сбой, как падение настоящего продакшена, только вы к этому уровню ответственности не готовились.

Как демо для показа тихо становится рабочим инструментом

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

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

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

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

Что на самом деле стоит за словом «демо» технически

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

Типичный набор проблем демо-инфраструктуры, дожившей до третьего года без апгрейда:

• Один сервер без резервирования. Изначально это была нормальная экономия — зачем резервировать то, что должно жить неделю. Сейчас это единственная точка отказа для того, чем клиент пользуется каждый день.
• Бэкапов нет или они настроены «на всякий случай», без проверки восстановления. Демо-данные казались невосстановимо неважными на старте, а сейчас в базе — реальные рабочие записи клиента.
• Учётные данные и доступы размазаны. Пароль от базы, возможно, тот же, что ставился при первом деплое, известен паре человек в команде, часть из которых уже не работает в компании.
• Версии зависимостей и рантайма не обновлялись — потому что «зачем трогать то, что не ломается», а плановых окон на обновление у демо-стенда никогда не было.
• Мониторинга нет — узнать о падении раньше клиента возможности не было заложено изначально, и с тех пор это не поменялось.

Проверить реальное состояние можно за полчаса, не дожидаясь инцидента:

# Когда сервер поднимался и сколько он не перезагружался
uptime
cat /proc/uptime

# Последнее обновление пакетов
grep " upgrade " /var/log/dpkg.log 2>/dev/null | tail -5
# или для rpm-систем
rpm -qa --last | head -10

# Есть ли вообще бэкап и когда он делался последний раз
ls -lh /var/backups/ 2>/dev/null
find / -iname "*backup*" -newer /etc/hostname -mtime -7 2>/dev/null | head -20

# Кто и как заходит на сервер
last -a | head -20
cat /etc/ssh/sshd_config | grep -i passwordauth

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

Риск первый: клиент считает демо частью обещанного

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

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

Разрыв между этими двумя картинами мира не проявляется, пока всё работает. Он проявляется ровно в момент первого серьёзного сбоя — и именно тогда становится понятно, что стороны все эти два года по-разному понимали, на что клиент вправе рассчитывать.

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

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

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

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

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

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

Что стоит сделать до этого разговора, а не во время него:

• Собрать конкретику, а не общие ощущения. Как часто клиент реально заходит в систему, есть ли данные о частоте использования (логи запросов, количество активных пользователей за последний месяц) — это превращает разговор из «нам кажется, вы часто пользуетесь» в «мы видим 40+ обращений в день от вашей команды».
• Подготовить хотя бы черновой план исправления, чтобы разговор сразу переходил от проблемы к решению, а не заканчивался неопределённостью «мы подумаем».
• Выбрать формат — письмо или звонок. Для такого разговора звонок или видеовстреча обычно работают лучше письма: тон и уверенность считываются напрямую, а не додумываются читателем письма в худшую сторону.

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

Технический аудит: что проверить перед любым решением

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

Минимальный чек-лист аудита демо-инфраструктуры перед принятием решения:

Практическая настройка бэкапов и мониторинга для такого перехода не отличается от любого другого случая, когда временное стало постоянным — подробно разобрана дедупликация, шифрование и расписание в статье про установку BorgBackup на VPS, а базовый внешний мониторинг доступности поднимается за 10-15 минут через Uptime Kuma, что описано в статье про мониторинг сайта и сервера. Для демо, которое уже фактически стало рабочим инструментом клиента, оба пункта — не «было бы неплохо», а минимально необходимое условие, независимо от того, какое решение будет принято дальше.

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

Два пути дальше: официальный продакшен или плановая замена

По итогам разговора с клиентом и аудита есть, по сути, два разумных направления — и оба лучше, чем оставить всё как есть.

Путь первый: официально перевести демо на продакшен-уровень поддержки. Это значит не только закрыть найденные технические дыры (резервирование, бэкапы, мониторинг, актуальные доступы), но и формализовать отношения — зафиксировать в договоре или дополнительном соглашении, что именно теперь гарантируется и что происходит при сбое. Если объём ответственности вырос настолько, что требует дополнительных ресурсов — резервного сервера, оплаченного мониторинга, времени на обслуживание, — разумно обсудить с клиентом пересмотр коммерческих условий. Это не попытка нажиться на ситуации, а честное приведение цены в соответствие с реальным уровнем сервиса. Многие клиенты реагируют на такое предложение спокойнее, чем ожидается, — оно означает, что система, которой они и так пользуются каждый день, наконец получит должный уровень внимания.

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

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

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