Технический аудит перед инвестицией: к чему готовиться

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

Что смотрят

Глубина проверки зависит от стадии и суммы, но темы почти всегда одни и те же.

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

Код. Читается ли он, есть ли тесты на важное — деньги, права доступа, данные, — как устроены ревью и релизы. Если заметная часть кода написана с помощью ИИ, вопрос будет простым: кто в команде понимает, как это работает, и может ли это поменять.

Безопасность. Где хранятся секреты, как устроены вход и права, обновляются ли зависимости, у кого есть доступ к продакшну и базе.

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

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

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

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

Красные флаги

То, что встречается часто и выглядит плохо:

• секреты и пароли в репозитории, в том числе в старых коммитах;
• к продакшну подключаются с личных ноутбуков, учётные записи общие;
• из резервных копий ни разу не восстанавливались;
• нет отдельной среды для проверки, изменения уходят сразу к пользователям;
• нет тестов на платежи и права доступа;
• код, который никто в команде не может объяснить;
• непонятно, кому принадлежит код, написанный подрядчиком;
• расходы на инфраструктуру или внешние API растут быстрее выручки, и никто не знает почему.

Что подготовить

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

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

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

Когда начинать

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

SUBXCAT проводит такой аудит заранее и помогает закрыть найденное до того, как это найдёт кто-то другой.