Что будет, если больше 200 бэкенд‑разработчиков запускают по 2–3 новых проекта в неделю в более чем 400 микросервисов, написанных на пяти разных языках — C++, Go, Python, Java и PHP? Ответ хорошо знаком любому, кто сталкивался с быстрорастущей распределённой системой: хаос появляется быстрее, чем успеваешь его отлавливать. И в какой‑то момент становится очевидно, что нужна надёжная точка контроля, чтобы поддерживать архитектуру в рабочем состоянии.
В Яндекс Еде этой точкой стало архитектурное ревью — процесс, который постеп��нно вырос из локальной инициативы в полноценный инструмент управления сложной системой. В этой статье я расскажу, как эволюционировало архревью, какие инсайты появились по пути и как этот процесс выглядит сегодня.
В этой статье разберём:
что такое архревью в контексте Яндекс Еды;
какие реальные кейсы встречались в процессе;
какую практическую пользу этот процесс приносит;
в каких ситуациях команда считает архревью обязательным;
как именно устроен рабочий поток;
кто участвует в ревью и чем занимаются архревьюеры;
какую аналитику собирают и зачем.
Что такое архревью
Архитектурное ревью — это обязательный этап перед началом разработки, на котором команда системно проверяет архитектурное решение на корректность, риски и жизнеспособность. На этом этапе важно понять, как данные будут проходить через систему, как сервисы — взаимодействовать друг с другом, какие механизмы обеспечат масштабируемость, отказоустойчивость и безопасность, а также насколько решения окажутся поддерживаемыми..
Главная задача архревью — выявить слабые места заранее и убедиться, что выбранная архитектура выдержит рост нагрузки и будущие изменения продукта.
Несколько примеров архревью
Пуш-уведомления, или Как сработал принцип DRY
Задача казалась прямой: научиться отправлять пуш‑уведомления в приложение для партнёров ресторанного направления. Для этого я готовлю детальный RFC: подробно описываю API публичных контактов, структуру хранения, механику доставки. На этапе проектирования уже видно, что работа растягивается минимум на три месяца.
Но на архревью выясняется, что всё нужное уже существует: решения готовы, остаётся только правильно интегрироваться. Проект, рассчитанный минимум на квартал разработки, превращается в задачу, которая займёт меньше месяца.
PS: DRY — Don«t Repeat Yourself, принцип, который здесь сработал буквально.»
Новый гейтвей
Следующая история — про новый формат авторизации между двумя контурами. Решение прорабатывается, выходит на архревью и, по моей оценке, кажется вполне подъёмным: «Пара недель — и готово».
Однако руководитель направления не согласен с уже утверждённым вариантом и блокирует включение задач в спринт. Приходится идти на второй круг согласований, повторно «продавать» архитектуру и объяснять её обоснование. После этого блокировка снимается, проект стартует — но к этому моменту потеряно две недели.
Отчёты партнёрам при 0 RPS
У команды была задача добавить в отчёт по заказам на сервисе Яндекс Еды для партнёров новые данные по ресторанам, а именно адрес и название. На архревью команда стала разбираться, что представляет собой отчёт по заказам на сервисе, и выяснилось, что ответ может содержать несколько тыся�� заказов, а один партнёр может быть привязан более чем к тысяче ресторанов. В худшем сценарии сервису, который хранит данные о ресторанах, может прилететь запрос сразу на тысячу ресторанов — а payload ответа будет содержать все соответствующие объекты, каждый из которых сам по себе не самый лёгкий. Такое решение явно не выглядит масштабируемым, и формирование отчётов заметно замедлилось бы.
Разработчик предлагает смягчить проблему батч‑запросами по 100 ресторанов в каждом. Это лучше, но фактически превращается уже в 100 RPS к сервису ресторанов.
На этом этапе в разговор вступают мейнтейнеры сервиса ресторанов. Они подтверждают, что такой подход тоже не масштабируется, и подсказывают очевидное: данные об адресах и названиях ресторанов почти статичны, меняются редко, а все события об изменениях они уже публикуют в message broker — и на них можно подписаться.
Итоговое решение оказывается простым и эффективным: на стороне отчётов появляется небольшой локальный кеш данных по ресторанам, который обновляется за счёт периодического чтения событий из message broker. Нулевые RPS к сервису ресторанов, формирование отчётов не замедляется, довольны все — и заказчик, и мейнтейнеры.
Отклонили RFC — и получили no-code-решение
В этом кейсе мне нужно было научиться оперативно сравнивать присутствие сервиса по географии и времени, чтобы команда мониторинга могла быстро реагировать на скачки и инициировать оперативный ресёрч проблем в регионе. Для этого я нашёл три потенциальных источника данных. Первый проверяется вручную: немного кода, замер объёмов — и выясняется, что там около 800 TPS (tasks per second). Собранный драфт дашборда показывает: при такой частоте ничего не прокрасится, выводы сделать будет невозможно.
Исследования фиксируются в RFC. Прорабатываются оставшиеся два варианта, и автор аргументированно предлагает второй. С этим он приходит на архревью.
Руководитель направления хорошо знает домен и сразу озвучивает порядок входящего потока — примерно 15 000 TPS. На созвоне команда прикидывает риски: на таких объёмах данные снова могут не успевать обрабатываться, и дашборд окажется бесполезным.
Остаётся третий вариант — он тоже заранее приготовлен. Но там поток около 100 000 TPS, и, чтобы просто обработать такие данные, потребуются дополнительные ресурсы: например, пара ядер на каждый под с кешем. Для небольшой фичи решение выглядит чрезмерно тяжёлым.
В итоге RFC не согласуют — и это оказывается лучшим исходом. Уже через два дня поиска находится источник данных, где всё заранее подготовлено и идеально подходит под задачу. На нём получается почти no‑code‑решение за несколько дней.
Если бы не архревью, с высокой вероятностью команда выбрала бы второй вариант, потратила бы 2–3 недели и всё равно получила бы риски, что фича не взлетит.
Зачем проходить архревью
За время существования процесса в Яндекс Еде мы выделили семь причин, почему архитектурное ревью действительно полезно.
Более осознанное проектирование фич. Ошибку в классе или отдельной функции можно исправить точечным рефакторингом. Но неверное архитектурное решение способно затронуть десятки сервисов и несколько команд сразу. Архревью помогает заранее проверить корректность выбранного подхода и избежать системных проблем, которые невозможно решить быстрыми правками.
Меньше дублирующей функциональности. В больших системах легко не заметить момент появления очередного «велосипеда» — сервиса, библиотеки или фрагмента логики, которые уже существуют в другом месте. Архревью помогает вовремя останавливать такие инициативы. Избавиться от дублирования на 100% нельзя, но сократить его — вполне.
Технологическая стратегия. Отсутствие общей технологической стратегии неизбежно приводит к «зоопарку» хранилищ, брокеров и инструментов. Например, для работы с векторами команда не внедряет Qdrant, а использует расширение pgvector в PostgreSQL. Если игнорировать стратегию, эксплуатация становится дороже и сложнее. На архитектурном ревью решения сверяются с техрадаром и принятыми технологическими правилами.
Выбор релевантной технологии под задачу. Архревью помогает избежать ситуаций, когда для справочника стран проектируются шардированные базы, а в простых REST‑сценариях внезапно появляется GraphQL. Внимательная сверка задачи и технологии позволяет не утяжелять архитектуру.
Передача знаний и опыта. Разработчики, однажды прошедшие через этот процесс, уносят с собой новые подходы и начинают применять их локально, делясь знаниями внутри команды. Так выравнивается инженерная культура. Команда архревьюеров — это тоже инструмент распространения единых подходов. Выполняя роль ревьюеров, они естественным образом несут практики и технологии в свои команды.
Снижение числа инцидентов. На ревью подробно разбираются риски, механизмы деградации, стратегии обхода ошибок. Планируется запуск через релиз или фича‑флаг, заранее определяются метрики и логи, по которым можно контролировать состояние системы после включения фичи. Это снижает вероятность инцидентов и ускоряет реакцию на проблемы.
Сокращение Time‑to‑Market. Архревью уменьшает количество переделок и помогает избежать дорогостоящих ошибок. Команды тратят меньше времени на исправление последствий неверных решений: не создают лишние сервисы, не строят сложных систем там, где можно обойтись простым решением, не внедряют новые технологии без реальной необходимости. TTM сокращается не на старте, а на всём пути разработки и поддержки системы.
Следуя здравому смыслу, важно понимать: архревью — это не бесплатный и не моментальный проце��с. В среднем, по нашей статистике, весь цикл занимает до четырёх дней. Поэтому прежде чем идти в архревью, стоит чётко определить, когда оно действительно необходимо.
Мы выделили несколько ситуаций, при которых архревью обязательно:
Создание нового сервиса.
Добавление нового домена, модели или события.
Изменения, влияющие на критическую функциональность сервиса.
Появление нового хранилища данных.
Интеграция с внешними системами.
Внедрение новых технологий или архитектурных подходов.
Существенные изменения в потоках данных или нагрузке.
Сомнения в корректности или эффективности выбранного решения.
Если хотя бы один пункт совпадает с вашей ситуацией, значит, самое время залетать в процесс.
Теперь, когда мы определили точки входа, можно переходить к тому, как именно устроено архревью и что вас ждёт внутри.
Процесс архревью
Процесс архревью состоит из восьми основных этапов:
Подготовить RFC. Коротко и структурированно описать задачу, контекст и предлагаемое решение.
Создать PR. Приложить черновую реализацию или прототип, чтобы команда могла увидеть детали.
Заполнить форму. Ответить на уточняющие вопросы, необходимые для корректного анализа архитектуры.
Обсудить решение. Провести встречу или асинхронное обсуждение — разобрать ключевые точки и риски.
Получить резолюцию. Итоговое решение: проект принимается, отправляется на доработку или отклоняется.
Дать обратную связь по процессу. Это помогает нам повышать качество и скорость архревью.
Реализовать решение. Внести доработки или приступить к полноценной разработке.
Провести ретро по завершении проекта. Зафиксировать инсайты, сложности и то, что можно улучшить в будущем.
Далее рассмотрим детальнее каждый из пунктов.
Подготовить RFС
Первый шаг для разработчика — подготовить RFC (Request for Comments). Чтобы избежать «проблемы белого листа» и связанной с ней прокрастинации, в Яндекс Еде используется подробный шаблон — набор вопросов, которые помогают структурировать мышление и последовательно пройти все этапы проектирования.
В шаблоне около 30 вопросов, охватывающих весь проектный цикл. Отвечать нужно только на те, которые реально относятся к вашим изменениям. Каждый вопрос снабжён пояснением: какие детали важно раскрыть, на что обратить внимание, какие риски оценить. Для удобства к ним добавлены примеры возможных ответов и — когда это уместно — ссылки на документацию и внутренние гайды.
Например, один из вопросов шаблона выглядит так:
Периодические процессы Необходимо перечислить периодические процессы (cron, periodic и др.). Подробно раскрыть логику работы. Если полезно, добавить диаграммы последовательности. Указать периодичность запуска и/или условия для запуска. Ссылка на документацию про периодики и кроны в userver. Пример 1: В фоне крутится периодик, вычитывает блокировки в статусе launch_at больше чем now и ставить задачу в STQ на включение запланированной блокировки. Вычитывание базы данных идет батчами по 100 шт (настраивается в конфиге).
Шаблон и схему процесса можно забрать на GitHub.
Даже с подробным шаблоном RFC некоторые вопросы всё равно вызывают у разработчиков затруднения. Часть таких ситуаций закрывают внутренние гайды. Например, когда команда планирует писать новый сервис и не уверена, что выбрать — C++ или Go, можно открыть гайд по выбору языка программирования. Он работает как упрощённое «дерево решений». Там встречаются вполне прямые формулировки вроде «Команда не знает ни C++, ни Go — учимся писать на Go».
Для выравнивания технологий и облегчения выбора мы используем мощный инструмент — техрадар. Это прозрачный способ зафиксировать, какие технологии и подходы считаются применимыми в компании и на каких условиях.
Техрадар включает четыре категории:
Adopt — используем по умолчанию;
Trial — применяем там, где безопасно, и накапливаем опыт эксплуатации;
Assess — изучаем;
Hold — не используем.
Кроме того, есть категория Hold | Ban, где настоятельно рекомендуется съезжать с технологии.
Текущий техрадар Яндекс Еды отражает накопленный опыт команды. Например, компания перестала использовать MySQL. А Go сравнительно недавно перешёл из зоны Trial в Adopt: накопили достаточный опыт, развили собственный фреймворк Goliath — теперь на Go можно писать критическую функциональность сервиса.
Техрадар
В дополнение ко всему существует технологическая стратегия компании. Она задаёт общий вектор для разработки и формирует рамки, в которых должна развиваться архитектура.
Например, сейчас в компании активно драйвится переход на gRPC во взаимодействии между сервисами. Там, где это оправданно и приносит пользу, начинают использовать Temporal и YDB, постепенно снижая долю наследия. При этом в стратегии отдельно подчёркивается важный принцип — не допускать появления новых монолитов, которые в перспективе замедляют развитие и усл��жняют эксплуатацию.
Создать PR
Следующий шаг знаком каждому разработчику: отвести ветку, закоммитить изменения и создать PR. Всё происходит в привычном для команды рабочем процессе — ровно так же, как при обычной разработке.
Заполнить форму
В описании задачи указывают, каких сервисов касаются изменения, что именно планируется сделать и влияет ли это на цикл заказа, — на этом этапе определяется критичность. Туда же добавляется ссылка на PR, в котором лежит полный текст RFC.
На этом этапе подключается основная часть автоматизации. После отправки формы система выполняет несколько действий:
создаёт тикет в Трекере для архитектурного ревью (а при необходимости — ещё и для ИБ‑ или фрод‑ревью);
вызывает дежурного архревьюера;
выставляет дедлайн запуска проекта;
отправляет уведомление в телеграм‑канал;
выполняет ряд других служебных операций, упрощающих дальнейший процесс.
Обсудить решение
Дальше начинается обсуждение. В привычном интерфейсе код‑ревью все заинтересованные участники — разработчики, архитекторы, мейнтейнеры сервисов — последовательно проходят по RFC и обсуждают планируемые изменения. Формат остаётся максимально комфортным и привычным: комментарии, эмодзи, треды, уточнения, альтернативные варианты.
Перевод архитектурного ревью в асинхронный формат заметно повышает эффективность процесса. Очные встречи нужны только в двух случаях: если обсуждение зашло в deadlock посреди холивара или если ревьюерам проще прогреть контекст, когда автор решения раскрывает голосом детали доменной области, объясняет причины, почему пришли к необходимости внесения изменений, и рассказывает об особенностях продуктовой реализации, иногда даже с демонстрацией дизайна и CJM (Customer Journey Map).
В остальных ситуациях асинхронный формат работает быстрее и оказывается удобнее для всех участников.
Ниже — небольшой фрагмент реального обсуждения в интерфейсе нашего монорепозитория.
После завершения всех обсуждений PR мержится в trunk и остаётся в системе как полезный артефакт.
Поскольку все RFC и их обсуждения хранятся в Version Control System, со временем формируется большой датасет. Он уже сегодня позволяет обучать модели, которые смогут помогать в проектировании архитектурных изменений или даже частично ревьюить их.
Получить резолюцию
Этап согласования — это фактически «подпись» под документом. Если поставил её, значит, решение поддержано и назад пути уже нет. Такой формат помогает всем участникам подходить к вопросам максимально ответственно — и архревьюерам, и владельцам направлений, в которых происходят изменения.
Дать обратную связь по процессу
После завершения этапа согласования в тикете автоматически появляется форма для обратной связи, и автор изменений получает приглашение её заполнить. Форма проста и состоит из трёх полей:
оценка от 1 до 5 баллов, где 5 означает полное удовлетворение процессом;
кто из ревьюеров оказал полезное влияние своим участием;
комментарии в свободной форме, чтобы поделиться любыми дополнительными наблюдениями или предложениями.
Это позволяет не только собирать впечатления о процессе, но и выявлять лучших архревьюеров и области для улучшения.
Реализовать решение
Наконец‑то можно пописать код:D
Провести ретро по завершении проекта
В тикете на архревью всегда настроен дедлайн запуска. Когда он наступает, система автоматически призывает архревьюера для организации аудита проделанной работы. Звучит угрожающе, но на деле это комфортная встреча, на которой разработчик и архревьюер обсуждают:
разошлись ли ожидания и реальность;
что пошло не так и почему;
есть ли технический долг и запланирован ли его возврат.
Команда считает этот шаг крайне полезным: он помогает выявлять проблемы как в самом процессе архревью, так и в архитектуре системы, а также не забывать про технический долг.
А кто такие архревьюеры?
Мы сформировали для себя следующий портрет идеального архревьюера:
Individual Contributor высокого грейда или руководитель;
значительный опыт в бэкенде;
отличные знания инфраструктуры и технологий Яндекса;
хорошее знание архитектуры Яндекс Еды.
Под toxic‑free environment понимается, что весь процесс архревью должен быть комфортным с точки зрения коммуникаций: разработчики уходят не с психологической травмой, а с более эффективным решением своей задачи.
А что же может мотивировать стать частью процесса? Мы видим несколько вариантов:
Перформанс‑ревью. Возможно, для кого‑то это спорно, но роль архревьюера учитывается при оценке перформанса. Ревью занимает значительное время и не должно игнорироваться.
Самореализация. Для многих это возможность делиться знаниями, улучшать процессы и архитектуру вокруг себя.
Сообщество. Некоторые ценят возможность быть частью команды архревьюеров — интересного и уважаемого сообщества внутри компании.
Кроме того, мы выдаём ачивки архревьюерам в зависимости от их вклада, что дополнительно мотивирует на участие.
Не всё так гладко с командой архревьюеров — процесс нельзя оставлять без внимания. Кто‑то может быть перегружен проектами и начать формально подходить к ревью, кто‑то — продвигать спорные решения.
Здесь помогает то, что вокруг архревью сформировалось сообщество — «гильдия архитектуры». Благодаря регулярным встречам многие перекосы удаётся быстро замечать и устранять. Например, на одной из встреч мы обнаружили, что значительная часть задач магическим образом уходит к одному архревьюеру. Разобрались в причинах и перераспределили поток.
Чтобы держать процесс под контролем, мы собрали дашборд, который позволяет в любой момент увидеть состояние архревью. На нём мы отслеживаем:
Какие архревью сейчас в работе: авторы и ревьюеры.
Попадание процесса в SLA.
Нагрузку на архревьюеров.
Архревью, ожидающие обратной связи (это ещё и повод ревьюеру напомнить автору о фидбэке).
Статистику по обратной связи.
Архревью, ожидающие аудита.
Статистику по завершённым архревью — в разрезе ревьюеров и авторов.
Такой дашборд помогает держать руку на пульсе и, например, упрощает архревьюерам подготовку self‑review к перформанс‑ревью.
Саботёр!
Процесс архревью полезен, но что делать, если разработчики не участвуют? Самый простой вариант — сделать его обязательным. Но здесь есть риски: процесс может вызвать недовольство, ведь пользу от него команда почувствует позже, а затраты времени возникают сразу. Это классическая история, когда short‑term profit побеждает long‑term profit. Многие разработчики наверняка помнят случаи, когда откладывали написание тестов, а через месяц тратили часы на дебаг при каждом мелком изменении.
Система архревью должна строиться вокруг разработчика, чтобы ему было максимально эффективно существовать внутри процесса. Что это значит на практике:
Процесс должен быть лёгким и простым, с минимумом ручных действий.
Он должен приносить реальную и понятную пользу уже сегодня. Вследствие этого команде архревьюеров важно давать обратную связь быстро и эффективно.
Исторически в Яндекс Еде сложилась высокая инженерная культура в разработке, и это сильно помогает в реализации такого подхода.
Заключение
Так выглядит архревью Яндекс Еды в цифрах:
С 2020 года проведено более 800 архревью.
В пиковый месяц — 30 архревью.
SLA — четыре дня. За последний год 80% задач проходят согласование быстрее этого срока.
95% разработчиков довольны процессом архревью.
Архитектурное ревью выполняет команда из 10 человек.
Сегодня трудно представить разработку большой микросервисной архитектуры без архитектурного ревью. Даже простой процесс с этапом проектирования, написанием RFC и обсуждением его с коллегами уже даёт ощутимую пользу.
Большей эффективности можно добиться, отстроив комплексное и продуманное решение, но нельзя останавливаться на достигнутом: процесс архревью нужно постоянно улучшать и актуализировать.
И самое главное — в центре процесса должен быть разработчик, автор изменений в архитектуре. Только если ему комфортно участвовать в архитектурном ревью, весь механизм работает эффективно и приносит реальную ценность проектам и команде. Расскажите в комментариях, есть ли в вашей команде архревью, и, если есть, поделитесь чем‑то максимально нестандартным или очень полезным!
