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

Автор: Владимир Ловцов (https://t.me/it_underside)

Недавно в одном из запросов мне прилетело нечто крайне сакральное:

— «Хотим сделать архитектуру как в FAANG».

И вот это всегда звучит как старт катастрофического эпизода в проекте.

Почему?

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

Да, звучит красиво. Но на практике при подходе «как в FAANG» люди делятся на четыре лагеря.

Несведущие — «Кто? Где? Что это?»Знатоки — уверены, что знают всё и готовы строить каноничные дворцы до первой боли в продакшене.Бывалые — уже строили «по книжке», обожглись и теперь проектируют с опорой на шрамы.ЯжЪ-Архитектор — прочитал пару статей на Habr, вооружился здравым смыслом и уверен, что спасает цивилизацию.

Узнали себя? Без наезда — чистое наблюдение 😏

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

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

Мы выучили «паттерны проектирования», «дизайн-доки» и священные ритуалы «code review по чек-листу». Но часто забываем задать один базовый вопрос:

- «А оно нам вообще нужно?»

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

Мы любим, когда есть готовый ответ. Канон — это про безопасность: не надо думать, не надо спорить, просто делай «как в книжке». И если всё пойдёт не так — можно сказать:

- «Ну я же сделал, как в FAANG!»

Это наш айтишный оберег. Священное «по стандарту». В мире, где задачи летят быстрее, чем коммиты, хочется верить, что где-то есть инструкция, которая избавит от боли и хаоса.

У этой любви есть три корня.

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

Второй — вера в чудо.Все тайно мечтаем о серебряной пуле: поставь Kafka, добавь Kubernetes, подключи GraphQL — и бизнес попрёт. Только потом выясняется, что Kafka у нас одна, Kubernetes никто не мониторит, а GraphQL вызывает каждая микросервисная душа.

Третий — культ совершенства.Айтишники не умеют «сделать и забыть». Мы делаем — и потом бесконечно полируем. Архитектура становится не инструментом, а самоцелью.

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

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

«Мы сделали как в FAANG, но почему-то стало хуже». Ответ прост: вы взяли не подход, а ритуал.

А ритуалы в инженерии живут ровно до первой нагрузки в продакшене.

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

Теперь — в наши реалии.

Компания на двадцать разработчиков пытается жить «как в FAANG»:вводит дизайн-доки — и тратит неделю на согласование имени таблицы;делает CI/CD — но боится выкатить релиз без ручной проверки;дробит систему — и получает семь репозиториев, где одни и те же баги чинят вручную.

И всё это — не из глупости, а из желания сделать “правильно”.

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

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

В такие моменты проявляются все архетипы:несведущие кивают, не задавая «почему»;знатоки цитируют канон и строят дворцы до первой боли;бывалые тихо предлагают «маленький рабочий путь»;а ЯжЪ-Архитектор ищет на Habr статью «Как в Google борются с техническим долгом».

Если в документации всё идеально, а в продакшене хаос — вы в архитектурном театре.Ревью — по чек-листу, инциденты — по расписанию, «переосмысление архитектуры» длится дольше, чем релизы.

Первое — не паниковать и не устраивать крестовый поход против «старой архитектуры».Паника рождает второй зоопарк — из старого и нового. Архитектуру лечат хирургически, не артиллерией.

Главное — признать, что вы не в техническом тупике, а в переизбытке решений.Это не недостаток идей, это их передозировка.Попробуйте не добавлять, а убирать.

Спросите команду: какие процессы мы делаем «потому что надо», а не потому что приносят пользу?Если половина ответов держится на фразах «так принято» и «все так делают» — у вас не архитектура, а корпоративный фольклор.

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

В одном проекте мы начали не с «переделать всё», а с инвентаризации.Убрали два дублирующих микросервиса, вернули ответственность за SLA одному владельцу, сократили онбординг с шести недель до двух.Ни одна схема не стала красивее, зато MTTR упал с 110 до 55 минут, а релизы перестали зависать по ночам (не совсем так, но было близко). Меньше паттернов — больше пользы.

Научитесь говорить “нет”: нет — моде, нет — бессрочным «рефакторингам во благо»,нет — переделкам без новых данных.

А вот чему точно стоит сказать «да»: да — прозрачности, да — конкретным метрикам, да — обратной связи.

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

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

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

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

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

Опыт без сомнения — не мастерство, а автопилот.Он удобен, пока не меняется погода.

В какой-то момент надо перестать играть в «догонялки с индустрией» и спросить:

«А какой путь — наш?»

Не тот, что в статьях, а тот, который подходит вашему продукту и людям.

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

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

Настоящая зрелость — не в знании всех схем, а в умении сказать:

«Нет, нам это пока не нужно».

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

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

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

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

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

Я видел, как команды рушили системы, потому что слишком старались сделать идеально.И видел, как другие вытаскивали бизнес, просто сказав:

«Хватит. Достаточно».

Идеальные системы живут в книгах. В реальности побеждают живые.Так что если завтра кто-то снова скажет вам:

«Сделаем, как в FAANG», — просто улыбнитесь.И спросите: «А зачем?»

Это короткое слово спасает больше проектов, чем любые паттерны.

----

Ваш ДПУПП (директор по управлению портфелем проектов, тот самый “бывалый”, который любит, когда архитектура работает, а не позирует) @it_underside