Миф: что работает у Google, сработает и у вас

MAATRIX

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

Откуда берётся уверенность, что чужое решение подойдёт и вам

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

Добавьте к этому обычный страх отстать: если про технологию X пишут все конференции и все крупные блоги, кажется, что не использовать её — значит быть отсталым. Это ровно тот же механизм, что заставляет небольшие проекты тащить к себе Kubernetes без единого признака реальной потребности в оркестрации — про это подробно разобрано в статье про миф о том, что Kubernetes нужен любому проекту. Здесь та же логика, только шире: не про один инструмент, а про сам способ принимать архитектурные решения — «раз у них сработало, сработает и у нас», без промежуточного шага «а у нас вообще та же проблема?».

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

Что скрыто за финальной архитектурной схемой

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

Что типично не попадает в публикацию:

• Альтернативы, которые пробовали и отбросили. Если команда перешла на очередь сообщений вместо синхронных вызовов, за кадром обычно остаётся, что до этого они пробовали два-три других подхода, и каждый упирался в конкретное ограничение их системы — ограничение, которого у вас может не быть вообще.
• Промежуточные версии решения. То, что выглядит как одна архитектура, на практике часто третья или четвёртая итерация за несколько лет, с постепенным усложнением по мере роста нагрузки. Взять сразу финальную версию — значит взять сложность, которая нарастала годами, в первый же день, без причины, которая её породила.
• Цена, которую решение стоило внутри. Сколько человеко-месяцев ушло на миграцию, сколько инцидентов было в процессе, какая команда теперь это поддерживает на постоянной основе — это редко указывается в блоге, потому что не является предметом статьи.
• Условия, специфичные для конкретной компании. Исторический выбор языка программирования, унаследованная от старой системы схема данных, требования конкретного регулятора, договорённости между командами — всё то, что определяло выбор не меньше, чем сама техническая задача, но выглядит слишком специфично, чтобы попасть в обобщающую статью.

В результате читатель видит красиво нарисованную диаграмму «было → стало» и додумывает всё, что было между стрелками, по своему усмотрению. Обычно додумывается версия проще и чище, чем происходило на самом деле — а значит и ваши ожидания от копирования будут завышены с самого начала.

Масштаб решает: чужая проблема может быть не вашей проблемой

Главная переменная, которую чаще всего игнорируют при переносе чужого решения, — это масштаб, на котором проблема вообще возникает. Многие архитектурные усложнения существуют не потому что они «правильные» сами по себе, а потому что при определённом объёме трафика, данных или количества сервисов старое простое решение физически перестаёт справляться.

Условный ориентир, чтобы почувствовать разницу (это не измеренные цифры конкретных систем, а иллюстрация порядка величин):

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

Ресурсы для поддержки сложности: то, что не видно в статье

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

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

Показательный пример последствий — каскадный отказ, когда падение одного компонента архитектуры, скопированной без полного понимания её протоколов отказоустойчивости (таймауты, ретраи, circuit breaker), утягивает за собой несколько формально не связанных сервисов. Механика такого отказа и то, как от него защищаться, разобраны в статье про то, как один упавший микросервис утянул за собой ещё пять. Ирония в том, что у компании-источника решения защитные механизмы против такого сценария почти наверняка есть и хорошо отлажены — просто про них реже пишут статьи, чем про сам факт перехода на распределённую архитектуру. Копируется видимая часть, а невидимая — обвязка, которая делает решение безопасным, — остаётся за скобками и переносится в лучшем случае частично.

Конкретные ограничения, которые формировали решение

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

Что обычно остаётся за кадром публичной статьи:

• Организационная структура. Известная закономерность (иногда называемая законом Конвея) в том, что архитектура системы повторяет структуру команд, которые её строят. Если в компании десятки автономных команд, микросервисная архитектура частично следует из организационной структуры, а не только из технических требований. У вас может быть одна команда — и тогда следовать той же архитектуре значит имитировать организационную структуру, которой у вас нет.
• Унаследованные системы. Многие решения — это не выбор с чистого листа, а компромисс вокруг того, что уже было построено пять или десять лет назад и стоит слишком дорого, чтобы переписывать целиком. То, что выглядит как осознанная архитектура, часто наполовину — способ ужиться со старой системой.
• Регуляторные и договорные требования. Требования конкретных юрисдикций, отраслевых регуляторов или крупных клиентов по контракту формируют часть решений (например, про репликацию данных между регионами или про изоляцию окружений), которые со стороны выглядят как общая инженерная практика, а на деле — обязательный пункт договора, которого у вас может не быть.
• История инцидентов конкретной компании. Часть защитных механизмов появляется не проактивно, а как реакция на конкретный инцидент, который у вас, возможно, структурно не может произойти — потому что у вас другая архитектура данных, другой профиль пользователей или другой набор внешних зависимостей.

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

Как учиться на чужом опыте, не копируя решения буквально

Чужой опыт остаётся ценным источником — вопрос в том, что именно из него извлекать. Разница между полезным чтением и карго-культом не в том, читать статью или нет, а в том, на каком уровне абстракции забирать из неё информацию.

Работающий подход — три вопроса к любой чужой статье, прежде чем переносить из неё хоть строчку в свою архитектуру:

Какую конкретно проблему это решает, и есть ли она у меня прямо сейчас? Не «может пригодиться», а измеримая проблема, которую вы уже наблюдаете в своей системе — конкретный тип инцидента, конкретная метрика, которая упирается в потолок. Если проблемы нет — решения тоже пока не нужно, вне зависимости от того, насколько элегантно оно описано.

Какой trade-off спрятан за преимуществом, о котором пишут? У любого архитектурного решения есть цена — в сложности, в деньгах, в скорости разработки, в количестве точек отказа. Публичные статьи обычно фокусируются на выигранном свойстве (масштабируемость, независимость команд, устойчивость к пиковой нагрузке) и меньше — на том, что было отдано взамен. Задача читателя — реконструировать этот trade-off самостоятельно и явно решить, готовы ли вы платить ту же цену за то же преимущество.

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

На практике это выглядит как привычка переформулировать любую заинтересовавшую вас статью в одно предложение вида: «Они решили проблему X ценой Y при масштабе Z, используя принцип W» — и только после этого спрашивать себя, есть ли у вас X, готовы ли вы платить Y, и совпадает ли ваш масштаб с Z хотя бы по порядку величины. Если совпадает — можно смотреть, как перенести принцип W в свою реализацию, обычно сильно более простую, чем в оригинале. Если нет — статья остаётся интересным чтением про чужой опыт, а не техническим заданием для вашего проекта.

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

Частые вопросы