Управление архитектурой

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

Когда Павел пришёл, Авито был большим толстым монолитом; он успел сделать объём фич рядом с ядром и немного потрогать авторизацию. Примерно через год компания решила идти в микросервисы. Внутри ходила байка про самую большую нешардированную базу — правда, пару лет спустя её опровергли, а цифр Павел не помнит. Логики в хранимых процедурах было много, но в основном это была логика доступа к данным. Была и точка невозврата: называли конкретную дату, после которой база просто не поднимется, а по мере приближения к ней она периодически падала, и дба спасали её микротюнингом конфигов. Отдельный «испанский стыд» — сервис, который получал данные из трёх сервисов и красиво отдавал цену: рисовать её умел только PHP-код, а команды, которым это внезапно потребовалось, PHP-экспертизу уже утратили. Александр переворачивает картину: это не плохие решения предшественников, а проблема роста — проблема счастливой компании.

Вторая линия разговора — как менялись процессы. Релиз в монолите собирали примерно раз в день: отдельная ветка со всеми свежими изменениями, долгие прогоны — полчаса по хорошей погоде и часов по пять-шесть по плохой, — и компания «гуру», которая в конце решала, что вроде работает. Само по себе это давало неплохой quality gate: крупных провалов было мало, а дежурства сводились к тому, что всех поднимали по звонку. С микросервисами релизы стали частыми, появился инцидент-менеджмент, а за ним вопрос: инциденты чинятся, но становится ли лучше? Так возникла отдельная команда, и Павел зашёл в архитектуру через надёжность. Похоже ли это на SRE в Google, спрашивает Александр. Концептуально — подмножество, отвечает Павел: у них получилась скорее центральная команда, которая много знает про всё, потому что участвовала в распиле, но частью продуктовой разработки не была. Ловили и базовые ошибки вроде открытой транзакции с походом в соседний сервис.

Как измерять внутреннюю надёжность сложного продукта, готового ответа не нашлось: наружу Amazon транслирует SLA для S3, а как оценивать надёжность магазина целиком и протаскивать её вниз по системам — приходилось выдумывать самим. Сейчас в Авито развели техническую и продуктовую надёжность: за продуктовую платформенной команде следить тяжело, поэтому начали с наборов пользовательских сценариев — открыл, положил в корзину, купил, заказал доставку. Продукты описывают сценарии и раскладывают их по зонам критичности, а тулинг превращает описания в граф связей сервисов, на который нанизаны технические метрики. Бонусом критичность компонентов назначается не экспертно: попал твой сервис в сценарий без слабых связей — поздравляю, теперь ты критичный и держишь три девятки. Заодно снялась часть споров о приоритетах. У Александра есть похожий каталог услуг с зафиксированными SLA и критичностью, но трассировка протянута не по всем системам, поэтому в динамике цепочка может оборваться посередине.

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

С метриками сложнее. Классические цикломатическая сложность и изолированность модулей описывают одно приложение, а не микросервисный ландшафт, поэтому команда Павла сейчас тестирует межсервисные coupling и cohesion, взятые из статей и проверенные мысленными экспериментами: добавили связь — метрика не изменилась, убрали — стало лучше. Александр возражает примером: зная формулу, сервис-паук можно распилить на входной и выходной с одной тонкой связью между ними — на картинке связанность падает, толщина передачи данных не меняется. Буквально на днях, после похожего обсуждения в чате, Павлу описали ровно эту схему в жизни. Похожая ловушка с их инструментом нефункциональных требований: команда, пробившая собственные гейты, просто расширяет себе допуски, и governance приходится разбирать, чем это вызвано. На прощание Павел говорит, что готового рецепта не существует в природе, и советует вовлекаться в создание решений — именно это, по его словам, растило его экспертизу.