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

MAATRIX

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

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

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

Технический сооснователь регистрирует домен вечером, когда нужно было проверить гипотезу к утру. Регистрирует на свою личную почту и свою карту — юрлица нет, а ждать было некогда. Через неделю поднимает первый сервер у облачного провайдера — снова личная карта, потому что корпоративного счёта тоже пока нет. Код с самого начала лежит в его личном аккаунте на GitHub — там уже настроен SSH-ключ, знакомый интерфейс, не нужно ничего заводить с нуля. Пароли от панели хостинга, от DNS, от аккаунта email-рассылки, от аналитики он хранит в своём личном менеджере паролей, потому что это тот, которым он и так пользуется каждый день.

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

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

Домен: зарегистрирован «чтобы было быстрее»

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

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

Сервер: платится с личной карты, «разберёмся потом»

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

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

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

Репозиторий: код живёт в личном аккаунте

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

Дальше в этом репозитории накапливается вся история проекта: коммиты, issues, pull request'ы, настройки CI/CD, секреты в переменных окружения. Формально всё это принадлежит владельцу личного аккаунта, а не компании — даже если по факту это единственный код продукта. При смене технического руководителя, при конфликте между сооснователями или просто при попытке нанять второго разработчика, которому нужен доступ, выясняется, что доступ к коду проходит через личное разрешение одного конкретного человека, а не через организационную структуру компании. Перенос репозитория в организацию технически прост — но требует добровольного участия того, кто им сейчас владеет, и это именно тот момент, когда добровольность может внезапно закончиться.

Пароли и доступы: у каждого свой менеджер

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

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

Как эти пункты складываются в одну картину контроля

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

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

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

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