Технический дью‑дилидженс: что взять с собой перед масштабированием

Почему этот звонок кажется сложнее до масштабирования

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

Большинство ревьюеров видят разницу между ранним стартапом и зрелой инженерной командой. Они не ожидают одинакового уровня процессов или покрытий. Они ожидают ясного суждения.

Именно на это они обращают внимание, когда доказательств мало. Почему вы выбрали эту архитектуру? Что было отложено намеренно? Что сломается первым, если нагрузка вырастет в 10 раз? Молодому продукту не нужны идеальные ответы, подтверждённые месяцами данных, но команда должна показать, что продумала компромиссы.

Основная ошибка основателей — слишком переживать из‑за пробелов и недооценивать расплывчатость. Прямой ответ вроде «Мы ещё не тестировали больше 5 000 DAU» воспринимается лучше, чем «Это должно масштабироваться нормально». Первый ответ даёт людям реальную точку для оценки. Второй звучит как догадка.

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

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

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

Как звучит сильный ответ

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

Простые числа вызывают доверие быстрее отшлифованной речи. Полезный ответ может выглядеть так: 2 500 активных пользователей в месяц, пик около 40 запросов в секунду, команда из трёх инженеров и облачные расходы примерно $3 200 в месяц. Это даёт инвестору или покупателю реальную картину бизнеса и системы.

Каждый выбор в проектировании должен быть связан с реальной потребностью или реальным ограничением. Если вы выбрали монолит, объясните, что маленькая команда хотела быстро выпускать фичи и держать операционку простой. Если вы остались на одной базе Postgres, скажите, что модель данных пока управляемая и расходы на разделение сервисов пока не оправданы. Ясные причины важнее красивой архитектуры.

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

Держите текущие факты отдельно от планов на будущее. Скажите: «Сегодня у нас одна primary‑база, фоновые задачи на shared‑воркерах и ежедневные бэкапы». Затем: «В следующем квартале мы уже заложили бюджет на read‑replicas и отдельные воркеры, если нагрузка продолжит расти». Такое разделение важно. Люди теряют доверие, когда основатели говорят о будущих исправлениях как о уже существующих.

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

Упакуйте архитектуру на одной странице

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

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

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

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

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

Отметьте первые части, которые вы ожидаете изменить. Частые примеры: вынести фоновые задачи из основного приложения, добавить read‑replicas, снизить нагрузку на общую базу или уменьшить зависимость от одной внешней службы. Это показывает, что вы не делаете догадки — вы уже смотрели на следующую версию системы.

Назовите лимиты заранее

Инвесторы не ожидают, что предмасштабный продукт выдержит огромную нагрузку. Они ожидают, что вы знаете, где у системы края. Маленький ясно озвученный предел звучит лучше, чем расплывчатое «всё должно быть нормально».

Начните с протестированной нагрузки, а не с догадок. Скажите, что вы запускали в staging или продакшне, как долго и что произошло. «Мы тестировали 200 одновременных пользователей и ~25 запросов в секунду в течение 40 минут. Мы ещё не тестировали 10x эту нагрузку» — сильный ответ, потому что он точен.

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

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

Одиночные точки отказа важны даже если продукт сегодня работает. Может быть, один основатель единственный, кто умеет применять изменения в базе данных. Может быть, у очереди нет fallback. Может быть, всё размещено в одном облачном регионе. Само по себе это не фатально. Проблема возникает, если команда удивляется этим фактам на звонке.

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

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

Возьмите один‑два инцидента

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

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

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

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

Держите обвинения вне рассказа. Не говорите, что инженер что‑то пропустил или подрядчик виноват. Говорите, что сломалось, что команда сделала и что изменилось после. Обвинения звучат защищённо, а ясная ответственность — спокойно.

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

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

Соберите короткий пакет для дью‑дилидженса

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

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

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

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

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

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

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

Простой пример для предмасштабного продукта

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

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

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

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

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

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

Лучший финал — профинансированный следующий шаг, а не расплывчатое обещание. В этом случае следующий шаг — мониторинг очередей и read‑replica для тяжёлых чтений. Это показывает, что команда уже знает, где появится нагрузка, и имеет разумный план для её решения.

Ошибки, которые подрывают доверие

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

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

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

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

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

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

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

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

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

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

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

Сильный ответ может звучать так: «Поиск тормозит после ~2 млн записей. Нина отвечает за этот сервис. Три недели назад был таймаут из‑за неиндексированного запроса, мы починили в тот же день. Мы уже запланировали спринт по настройке базы и read‑replicas на следующий месяц.» Если вы можете сказать это без подсказки — вы готовы.

Что делать после встречи

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

Отправьте короткое резюме в тот же день или на следующее утро. Используйте те же факты, числа и лимиты, которые называли вживую. Не превращайте рассказ в нечто большее после звонка. Если вы сказали, что система держит определённую нагрузку с запасом на квартал — повторите это точно в письме.

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

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

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

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

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