Чек-лист ревью архитектуры
Это чек-лист, по которому я иду, когда клиент просит посмотреть его архитектуру: 48 пунктов в восьми категориях, в том порядке, в котором я реально работаю. Он целиком на этой странице. Ничего не нужно запрашивать, оставлять почту или регистрироваться.
Чек-лист ревью архитектуры — это структурированный набор вопросов, по которым прогоняют уже работающую систему: контекст, масштабируемость, надёжность, безопасность, стоимость, модульность, готовность к AI и документация. Так находят то, что сломается первым, и то, что построили на годы раньше срока. Это рабочий чек-лист Олега Сотникова, CTO по подписке с 25+ годами в IT и 1000+ проектами за плечами: 48 пунктов в восьми категориях, и всё опубликовано целиком, без сбора почты. Правило одно на всё: архитектуру оценивают относительно вашей стадии, а не относительно общепринятых практик, потому что избыточная инженерия убивает стартапы так же надёжно, как недостаточная.
Как им пользоваться
Сначала зафиксируйте контекст
Заполните первую категорию до того, как оценивать что-либо ещё: стадия, размер команды, реальная нагрузка, ограничения, которые в этом году не сдвинуть. Все выводы ниже отсчитываются от этих цифр. Без них вы меряете свою систему чужой меркой.
Идите по категориям с доказательствами
Отвечайте планом запроса, дашбордом, строкой лога или путём к файлу, а не воспоминанием о том, как система задумывалась. Если доказательство никто не может достать, это тоже находка — запишите её отдельно.
Соберите находки в план, а не в переписывание
Отсортируйте найденное по тому, во что оно вам обходится, и выстройте работы так, чтобы каждая следующая стоила дешевле предыдущей. Сорок красных отметок — не повод переписывать всё заново. Это бэклог с проблемой приоритетов, а её решить куда дешевле.
Чек-лист
Архитектура бывает правильной только относительно чего-то. Один и тот же дизайн при 500 000 пользователей — халатность, а при 500 — избыточность, и вторая ошибка убивает стартапы тише: месяцы работы над инфраструктурой под нагрузку, которая так и не пришла, пока продуктовый вопрос оставался без ответа.
Поэтому каждый пункт ниже — сравнение с вашей стадией, вашей командой и трафиком, который вы реально держите. Идите сверху вниз. Первая категория стоит первой, потому что задаёт точку отсчёта для всего остального.
Контекст и ограничения
- Выпишите сегодняшние цифры до того, как откроете первую схему: активные пользователи в день, пик запросов в секунду, самая большая таблица, объём данных.
- Одной строкой зафиксируйте стадию — до product-market fit, рост или ровное плато, — потому что все выводы ниже отсчитываются от неё.
- Опишите команду как есть: сколько инженеров, кто дежурит, кто единственный разбирается в платежах.
- Отделите реальную нагрузку от желаемой и проектируйте под трафик, который есть, плюс год правдоподобного роста.
- Перечислите ограничения, которые в этом году не изменить: требования регулятора, установка on-prem для корпоративного клиента, база данных, от которой не уйти по договору.
- Сформулируйте бизнес-цель на ближайшие двенадцать месяцев, которую архитектура обязана обслужить — раунд, новый рынок, маржинальность, — и держите её перед глазами до конца разбора.
Масштабируемость и производительность
- Проследите три самых частых запроса по всем переходам и запишите, где на самом деле уходит время.
- Найдите самый медленный запрос к самой нагруженной таблице, прочитайте его план и проверьте, объясняет ли всё пропущенный индекс или выборка без лимита.
- Спросите, что не выдержит при десятикратной нагрузке, а не при стократной. Спорить сейчас стоит только о том компоненте, который сломается первым.
- Перечислите все синхронные вызовы внутри обработки запроса, которые могли бы стать фоновой задачей.
- Посчитайте потребителей у каждой очереди и проверьте, за сколько разбирается накопившееся, когда один из них падает.
- Поищите N+1 и веерные вызовы на эндпоинтах, куда чаще всего приходят пользователи, — до того как оптимизировать что-то глубже.
Надёжность и сценарии отказа
- Назовите вслух точки единичного отказа: одна база, один регион, один хост с кронами, один человек.
- Для каждой внешней зависимости напишите, что произойдёт, если она недоступна час: таймаут, ретрай, запасной путь или простой.
- Разверните продовый бэкап в отдельном окружении и засеките время. Непроверенный бэкап — не бэкап.
- Убедитесь, что у ретраев есть лимит и backoff и что ни один из них не продублирует запись, которая никогда не была идемпотентной.
- Проверьте, что у каждого критичного пути есть алерт, который доходит до живого человека, и удалите те, на которые за год никто не отреагировал.
- Перечитайте три последних инцидента и решите, починили структурную причину или только симптом.
Безопасность и потоки данных
- Нарисуйте, где персональные и регулируемые данные появляются, лежат и уходят, — включая логи, аналитику, бэкапы и промпты к моделям.
- Найдите, где лежат секреты и как они ротируются, а потом поищите в истории репозитория те, что утекли.
- Составьте карту, какой сервис до какого дотягивается, и отметьте каждую пару, которая доверяет друг другу только потому, что оба внутри периметра.
- Убедитесь, что авторизация проверяется на сервере на каждом эндпоинте, включая внутренние админки.
- Проверьте, что выгрузки подрядчикам и аналитические пайплайны защищены так же, как продакшен: обычно регулируемые данные утекают именно там.
- Проверьте, что зависимости и образы сканируются, и назовите человека, который разбирает результаты.
Стоимость, заложенная в дизайн
- Разложите счёт за прошлый месяц по составляющим: вычисления, хранение, трафик, managed-сервисы, вызовы моделей.
- Доведите каждую крупную строку до решения в дизайне, которое её порождает: болтовня между зонами, веер запросов, хранилище без тиров, вызов модели на каждое нажатие клавиши.
- Поделите расходы на инфраструктуру на активных пользователей и посмотрите, куда это число двигалось последние полгода.
- Сложите, во сколько обходятся непродовые окружения, пока ими никто не пользуется, и решите, стоит ли это тех денег.
- Оцените вызовы к топовым моделям, которые с тем же результатом обслужила бы модель поменьше, кэш или ночной батч.
- Назначьте счёту еженедельного владельца — того, кому при этом позволено менять архитектуру, которая этот счёт формирует.
Модульность и скорость поставки
- Проверьте, могут ли два инженера выкатить две фичи в один день, не редактируя одни и те же файлы.
- Замерьте путь от коммита до продакшена и посчитайте, сколько человек должны по дороге что-то сделать руками.
- Найдите модули без владельца и модули, которые безопасно менять умеет только один человек.
- Поищите таблицы, в которые пишет больше одного сервиса, — самая частая фальшивая граница в системе, которая называет себя модульной.
- Посчитайте окружения, в очередь за которыми встают команды. Один стенд на всех выстраивает в цепочку всю компанию.
- Убедитесь, что откат — рутинная операция, а не аврал, и что кто-то недавно его делал.
Готовность к AI
- Опишите ответственность каждого модуля одним предложением. Агенты хорошо работают внутри границ, которые формулируются так просто, и буксуют там, где их нет.
- Прогоните тесты и честно ответьте, означает ли зелёный прогон, что изменение можно вливать.
- Замерьте цикл от правки до сигнала, что она сработала. Всё, что дольше перерыва на кофе, тормозит и людей, и агентов.
- Отметьте, какие части кода сгенерированы AI, примерно когда и кто вычитывал их построчно.
- Проверьте, что в репозитории лежит контекст, нужный агенту: соглашения, заметки об архитектуре и как поднять всё локально.
- Запишите, куда агентам ходить нельзя — платежи, авторизация, миграции, изменения схемы, — там, где это читает тулинг, а не только в чьей-то голове.
Документация и записи решений
- Дайте README новому человеку и посмотрите, как он поднимает систему локально. Почините то, на чём он споткнётся.
- Найдите решения, которые обсуждали неделями и нигде не записали, и оформите их задним числом.
- Сверьте схему архитектуры с тем, что реально работает в продакшене, и поставьте на ней дату.
- Зафиксируйте два-три ограничения, которые объясняют форму системы: именно их будущие читатели понимают неправильно первым делом.
- Ведите список проблем, с которыми вы сознательно решили жить, — тогда они читаются как решения, а не как недосмотр.
- Проверьте, что на три самых вероятных инцидента есть раннбуки, написанные так, чтобы по ним справился человек, который прошлый такой инцидент не застал.
Частые вопросы
Что такое ревью архитектуры?
Ревью архитектуры — это структурированный разбор уже работающей системы: как она разделена на части, как между ними движутся данные, где она проседает под нагрузкой и во что обходится сам дизайн. Оценка идёт относительно стадии и планов конкретной компании, а не относительно универсальных рекомендаций: правильная архитектура для 500 и для 500 000 пользователей — это разные системы. На выходе письменные находки, отсортированные по последствиям, и порядок, в котором их чинить.
Как часто нужно пересматривать архитектуру?
Не по календарю, а на смене стадии. Перед рывком в масштабирование, перед раундом или сделкой, где технику будут разбирать подробно, после разворота, который поменял задачи системы, и тогда, когда поставка замедлилась, а причину никто не может назвать. У большинства компаний выходит раз или два в год. В промежутках обычно хватает прохода по одной категории.
Можно ли применить этот чек-лист к коду, написанному AI?
Да, седьмая категория существует ровно для этого. Код от агентов обычно разумен локально и несогласован в целом: дублирующаяся логика, поплывшие границы модулей, тесты, которые ничего не проверяют, зависимости, которые никто не выбирал осознанно. Проходите те же восемь категорий и отдельно смотрите, какие части кода человек действительно читал: непрочитанный код под продовой нагрузкой опаснее, чем качество этого кода само по себе.
А если по итогам ревью нужно всё переписать?
Так почти никогда не бывает. Полное переписывание меняет систему с известными проблемами на систему с неизвестными и стабильно занимает больше времени, чем оценка, которой его обосновали. Почти всё, что находит ревью, чинится постепенно — вынести одну границу, разобрать горячий путь, разделить общую таблицу, — и продукт при этом продолжает выходить. Честных исключений мало: платформа, для которой больше не выпускают обновления безопасности, или лицензия, с которой дальше не жить.
Пройдите сами или отдайте мне
Чек-лист тот же, которым пользуюсь я. Разница в том, что я его действительно прохожу: сам читаю критичные пути в коде, который вы не писали, и раскладываю находки по тому, во что они вам обходятся.
Объём считаю под задачу. Получаса на звонке хватает, чтобы его оценить. NDA по запросу.
По теме
Архитектурные решения, масштабирование и компромиссы за тем и другим.
