Советы по архитектуре от агентства: что проверить перед подписанием

Почему диаграммы недостаточно

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

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

Этот контекст важен. Если в предложении пять сервисов, для каждого должна быть понятная причина. «Лучшие практики» — это не причина. «Будущий рост» тоже недостаточно. Ваша команда будет платить за такие решения временем, деньгами, работой поддержки и давлением при найме.

Пара прямых вопросов быстро пробивает слабое мышление:

• Какую проблему решает этот компонент сегодня?
• Что произойдёт, если мы уберём его?
• Когда он действительно понадобится?
• Кто будет его поддерживать после запуска?

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

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

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

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

Что должно объяснять предложение

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

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

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

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

Вы должны получать простые ответы на вопросы вроде:

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

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

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

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

Прямо спрашивайте про компромиссы

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

Ставьте прямые вопросы и ждите прямых ответов:

• Что мы приобретаем с этим выбором и что теряем?
• Если трафик удвоится, что ухудшится первым: скорость, надёжность или нагрузка на команду?
• Где со временем будет скапливаться кастомный код?
• Какие части привяжут нас к одному вендору?
• Какой самый простой вариант и какую проблему он оставит не решённой?

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

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

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

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

Попросите один более простой дизайн специально. Вдумчивое агентство может сказать: «Мы можем оставить это одним приложением сейчас, убрать event‑систему и согласиться на медленную отчётность до роста продукта.» Такой ответ даёт реальную точку сравнения. Он также показывает, знают ли они, как решить вашу проблему, а не только как добавить частей.

Проверьте путь выхода до подписания

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

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

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

Подтвердите письменно следующие элементы:

• репозитории кода и админ‑доступ
• облачные, DNS, почтовые и аналитические аккаунты
• конфигурации деплоя, процесс бэкапов и обработка секретов
• метод экспорта данных из каждого внешнего сервиса
• runbooks для релизов, инцидентов и восстановления

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

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

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

Пути выхода кажутся скучными в продажах, но они становятся срочными, когда меняются отношения.

Оцените операционные расходы по шагам

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

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

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

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

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

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

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

Человеческое время тоже должно быть в смете. Если «дешёвое» решение экономит $300 на хостинге, но съедает 15 инженерных часов в месяц на ручные деплои, патчи и ночные инциденты, оно не дешёвое.

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

Простой пример на растущей SaaS‑команде

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

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

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

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

Пара вопросов обычно выявляет компромиссы:

• Какой уровень трафика действительно выведет приложение за рамки модульного дизайна?
• Какую часть стоит выделить первой и почему именно её?
• Какие управляемые сервисы добавят месячные платежи после запуска?
• Насколько сложно будет заменить эти сервисы позже?

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

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

Частые ошибки покупателей при ревью агентских предложений

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

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

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

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

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

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

Перед утверждением проверьте несколько простых вещей:

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

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

Короткий чек‑лист перед одобрением

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

Короткий чек‑лист помогает держать обсуждение практичным и не дать аккуратной диаграмме скрыть будущую боль.

• Попросите версию простыми словами. Агентство должно объяснить, что делает каждая основная часть, зачем она нужна и что сломается при её удалении.
• Ищите компромиссы, а не рекламную речь. У каждого выбора есть цена.
• Проверьте, кто сможет управлять системой после передачи. Ваша команда должна знать, что требует ежедневного внимания, что требует узких специалистов и что агентство продолжит делать, если вы перестанете с ним работать.
• Получите диапазон ежемесячных расходов. Нужны грубые минимальная, ожидаемая и максимальная суммы по хостингу, внешним инструментам, поддержке и работе по инцидентам.
• Спросите, как упростить систему позже. Должен быть понятный путь убрать сервисы, объединить компоненты или перейти на более дешёвые варианты, если продукт изменится.

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

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

Когда стоит взять второе мнение

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

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

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

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

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

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

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