Операционная проверка небольшого SaaS перед покупкой

Почему грязь прячется за пределами кода

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

Именно поэтому операционный аудит важен не меньше, чем чтение кода. Большинство простоев не начинаются с драматичного бага. Они начинаются с чего‑то скучного. Карта карты истекла. Не удалось обновить домен. Почтовый провайдер заблокировал аккаунт. Задача резервного копирования не работала месяцами, и никто этого не заметил.

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

Доступ создаёт ещё больше проблем. Многие маленькие SaaS строятся вокруг привычек основателей, а не ясного владения. Приложение может работать под одним облачным аккаунтом, DNS — под другим, аналитика — в личном входе, а платёжные письма — в почтовом ящике, к которому имеет доступ только продавец. Вы можете купить продукт и при этом не получить нужных аккаунтов, чтобы держать его онлайн.

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

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

Попросите полную карту операций

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

Начните с каждого сервиса, от которого зависит бизнес, даже самых скучных, о которых обычно забывают. Обычно это хостинг, доставка почты, DNS, регистратор домена, аналитика, почтовые ящики поддержки, трекинг ошибок, платёжные инструменты, облачное хранилище, SMS, магазины приложений и любые сторонние API, которые могут остановить продукт при сбое.

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

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

Спросите, где команда хранит креденшалы сегодня. Вам нужен честный ответ, а не отшлифованный. Менеджер паролей — нормально. Общая таблица, сообщение в Slack или ноутбук одного инженера — уже другая история.

Затем разделите работу по двум корзинам: что работает само по себе и что требует человека. Ночная задача резервного копирования, еженедельный экспорт счетов, ручная проверка мошенничества, ручной деплой или cron‑задача на старом сервере — всё это должно быть на карте.

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

Проверьте резервные копии, доказав, что можно восстановить

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

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

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

Быстрый обзор должен ответить на пять вопросов:

• Какие данные сохраняются в бэкапах?
• Как часто выполняется каждое резервное копирование?
• Где хранятся копии?
• Кто может выполнить восстановление?
• Как долго хранятся старые копии?

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

Важно и хранение истории. Если сохраняются только одна‑две последние копии, медленная порча данных может лишить вас вариантов восстановления. Я предпочту простую настройку с 30 днями истории, чем навороченную систему, которую никто не тестировал.

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

Проверьте планировщики и другие «тихие» автоматизации

Запланированные задачи поддерживают маленький SaaS в рабочем состоянии долгое время даже после того, как код перестаёт меняться. Они отправляют счета, синхронизируют данные, ротируют логи, очищают очереди, собирают отчёты и повторяют неудачные задания. Часто именно там скрываются самые неприятные сюрпризы.

Попросите продавца показать каждое расписание вживую. Проверьте crontab на серверах, systemd timers, расписания контейнеров, облачные функции, CI‑пайплайны, задачи в базе данных и любые хостингованные инструменты автоматизации. Одна таблица недостаточна. Вы хотите увидеть реальную задачу, где она выполняется и кто получает оповещение при сбое.

Затем сопоставьте каждую задачу с бизнес‑функцией. Если задача запускается в 2:00, что она делает? Если никто не может ответить одним предложением — это сигнал тревоги. Выставление счетов, письма о завершении пробного периода, экспорты аналитики, бэкапы, проверки мошенничества и ежедневные отчёты часто завязаны на скриптах, о которых никто не вспоминает до их остановки.

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

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

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

Часовые пояса делают тихую работу ещё более коварной. Задача, которая должна запускаться в полночь по времени клиента, может реально запускаться по серверному времени, после перехода на летнее время или дважды за ночь. Это приводит к дублированным счетам, сломанным отчётам или пропущенным письмам о продлении.

Проверьте доступы, владение и восстановление аккаунтов

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

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

Админ‑доступ — не то же самое, что право владельца. Попросите продавца показать текущую роль владельца в каждом сервисе и пройти шаги передачи вживую. Приглашение с правами администратора помогает, но не решает проблему блокировки при передаче позже.

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

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

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

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

Найдите продления, риски по оплате и тихие зависимости

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

Попросите продавца один экспорт со всеми подписками, лицензиями и продлениями. В нём должны быть вендор, сумма, цикл выставления, следующая дата продления, владелец аккаунта, e‑mail для уведомлений и способ оплаты. Если это собирается днями — у операций, вероятно, беспорядок.

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

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

Модель оплаты по использованию требует внимания больше, чем кажется по сумме в счёте. Некоторые сервисы остаются дешёвыми, пока вы не перескочите порог по письмам, API‑вызовам, хранилищу, логам или местам для пользователей. Растущий SaaS может быстро пересечь этот порог, и ваши расходы изменятся за ночь.

Тихие зависимости важны так же. Команды часто забывают упомянуть провайдера DNS, трекинг ошибок, SMS, captcha, реестр пакетов, хост для cron‑задач или платный плагин, который поддерживает административные процессы. Приложение может работать сегодня, потому что эти сервисы уже оплачены.

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

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

Проведите тест передачи шаг за шагом

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

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

Практический тест передачи обычно состоит из четырёх шагов:

1. Начните с доступа. Зайдите вместе, подтвердите владельца аккаунта и проверьте адрес восстановления и 2FA. Поменяйте один пароль с низким риском, сохраните его в менеджере паролей покупателя и зафиксируйте, кто теперь владеет аккаунтом.
2. Выберите один фоновой воркер или обработчик очереди, безопасный для вмешательства. Перезапустите его во время созвона и посмотрите, что произойдёт. Приложение должно восстановиться чисто, а оповещения должны сработать при ошибке.
3. Возьмите небольшую копию резервной базы и восстановите её в тестовой системе. Вы проверяете не сами файлы бэкапа, а то, может ли команда превратить эти файлы в рабочую базу или приложение без догадок.
4. Приостановите одну плановую задачу, останов которой не навредит клиентам в кратком сроке. Подождите немного, затем возобновите её. Если не появилось оповещений, ничего не изменилось в дашбордах и никто не заметил — у бизнеса, вероятно, есть тихие точки отказа.

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

Если один простой тест превращается в 30‑минутный поиск по следам, воспринимайте это как реальный риск. Малые сделки SaaS чаще ломаются не в коде, а в этих деталях.

Простой пример из передачи малого SaaS

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

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

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

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

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

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

Код был в порядке. Операции вокруг него — нет. В этом разрыве многие передачи SaaS идут не так.

Ошибки, которые делают покупатели при обзоре

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

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

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

Другой пробел — область охвата. Покупатели проверяют серверы и БД, но пропускают регистратора домена, записи DNS, почту поддержки, вебхуки платежей и настройки входа через сторонние сервисы. SaaS может работать на своём облачном инстансе, в то время как домен истечёт в следующем месяце или почтовый ящик поддержки всё ещё перенаправляет письма подрядчику.

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

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

Один знакомый покупатель проверил продакшн‑сервер, не нашёл cron‑записей и успокоился. Через неделю письма со счетами перестали отправляться, потому что реальное расписание жило в забытом CI‑раннере. Это именно тот промах, который превращает спокойную передачу в починку в первый же день.

Быстрая проверка перед закрытием

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

Убедитесь, что вы можете ясно ответить на эти вопросы:

• Можете ли вы назвать владельца каждого важного аккаунта?
• Можете ли вы восстановить недавние данные в тестовой среде?
• Видите ли вы каждую запланированную задачу и её последний запуск?
• Можете ли вы перечислить продления на следующие 12 месяцев?
• Можете ли вы взять на себя оповещения, счета и главный админ‑ящик?

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

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

Следующие шаги после обзора

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

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

Сократите список задач на закрытие до главного:

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

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

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

Если передача всё ещё кажется грязной — возьмите второе техническое ревью перед закрытием. Oleg Sotnikov at oleg.is работает со стартапами и малыми бизнесами как fractional CTO и советник; такой обзор инфраструктуры, владения и автоматизации часто окупает себя.

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