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

Введение

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

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

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

Почему?

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

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

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

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

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

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

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

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

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

1. Почему мы так любим каноны

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

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

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

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

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

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

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

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

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

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

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

2. FAANG — это не про схемы, это про культуру

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

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

Компания на двадцать разработчиков пытается жить «как в FAANG»:

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

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

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

3. Как понять, что вы уже в ловушке

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

В такие моменты проявляются все архетипы:

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

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

4. Что делать, если вы всё-таки туда попали

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

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

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

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

💡 Мини-кейс из практики

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

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

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

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

5. Почему лучшие ошибаются чаще

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

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

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

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

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

6. Как выбрать свой путь

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

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

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

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

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

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

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

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

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

Финал

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

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

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

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

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

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

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

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

Из моего Telegram-канала @it_underside.

Ваш ДПУПП