Ревью архитектуры: практический чек-лист для команды

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

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

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

• Зафиксируйте сценарии: обычный запрос, массовая загрузка, повтор операции, отмена и восстановление после сбоя.
• Запишите целевые показатели: время ответа, доступность, объём данных, пиковую параллельность и допустимую задержку обработки.
• Отдельно укажите ограничения: бюджет, облако или собственный ЦОД, требования к локализации данных, лицензии и доступный штат.
• Попросите схему потоков данных, список внешних зависимостей и описание границ ответственности команд.
• Проверьте версии основных компонентов: СУБД, брокера сообщений, оркестратора, языка и библиотек. Версии не выбирают «на глаз» — их фиксируют в архитектурном решении и проверяют по официальной документации.

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

Три формата ревью и их цена

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

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

Чек-лист архитектурного ревью

1. Границы системы и владение

На схеме должны быть видны не только сервисы, но и владельцы. Для каждого компонента спросите:

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

Красный флаг — «общая библиотека» или «общая база» без владельца. Формально это ускоряет разработку, но любое изменение превращается в координацию нескольких команд.

2. Данные и их жизненный цикл

Проверьте путь данных от входа до удаления. Вопросы должны быть конкретными:

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

Особенно опасна фраза «сообщение точно доставляется один раз». На практике повторная доставка или повторный запуск обработчика возможны, поэтому операция должна быть идемпотентной¹ либо иметь явный механизм защиты от дублей.

3. Отказы и деградация

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

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

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

4. Производительность и масштабирование

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

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

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

5. Безопасность и доступы

Проверяйте не наличие слова «авторизация», а конкретный путь доступа. Кто выдаёт учётные данные? Где проверяются права? Как отзывается доступ? Что попадёт в журнал?

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

Отдельно проверьте доверие между сервисами. Внутренняя сеть не делает запрос автоматически безопасным: скомпрометированный компонент может использовать слишком широкие права соседей.

6. Наблюдаемость и эксплуатация

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

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

Как формулировать замечания

Ревью ломается, когда комментарий звучит как личный вкус: «я бы взял другой брокер». Хорошее замечание связывает решение с риском, условием и проверкой.

Где чек-лист перестаёт помогать

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

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

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

Что делать дальше

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

1. Отметьте блокирующие риски, которые нужно закрыть до запуска.
2. Для каждого спорного места назначьте эксперимент: нагрузочный тест, отказ зависимости, восстановление копии или проверку миграции.
3. Зафиксируйте архитектурные решения в репозитории рядом с кодом и укажите дату следующего пересмотра.
4. После запуска сравните фактические задержки, ошибки, стоимость и объём ручной работы с исходными предположениями.

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

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