Архитектурное ревью: один стол вместо пинбола

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

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

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

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

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

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

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

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

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

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

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

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

Обычно хватает C4 на уровнях L1 и L2 — как система живёт в ландшафте и что будет, если модуль недоступен. В изученных Антоном инструментах модель строится по документации. Он видит два риска: описание отстаёт от кода и может содержать ошибки уже при написании. Александр добавляет, что честнее называть это не архитектурой как кодом, а архитектурной документацией как кодом, и вспоминает касту архитекторов-старейшин, хранящих знание о системе.

Гипотеза Антона: L1 и L2 можно собирать из внутренних систем — платформы разработки с планируемым артефактом развёртывания и внешними зависимостями, учёта инфраструктуры и платформы логов, метрик и трейсов; Александр добавляет, что её написали на замену ушедшему из России Splunk. Такая модель местами будет вероятностной; это направление разработки, а не готовая полная картина.

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

Отдельная линия — RFC и ADR. Несколько лет назад стало непонятно, почему построена та или иная система, и похожие изменения шли в разных управлениях независимо; так появилось пространство, куда приносят значимые изменения и просят комментарии. Сопротивлялись долго, зато сейчас RFC есть примерно в 90% подразделений, с которыми Антон работает. Но команды иногда убирают из шаблона требования и альтернативы: именно эти пропуски приходится возвращать на ревью.

ADR добавился следом: принятое решение с обоснованием и ожидаемым результатом, запись, к которой через год можно вернуться, — иначе, замечают оба, остаётся только «так исторически сложилось». Пересмотр оформляют новой записью, сохраняя прежний контекст; описывать нужно требования, из-за которых возникла необходимость изменения.

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