«Как в FAANG» без культа: переносим практики вместе с контекстом

Фраза «хотим архитектуру как в FAANG» звучит как высокая планка. Но сама по себе она не задаёт ни требований, ни критериев успеха. Более того, FAANG — удобное собирательное название крупных технологических компаний, а не единый архитектурный стандарт.

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

Практика работает внутри контекста

Дизайн-док, платформа разработки, микросервисы или Kubernetes могут быть оправданы. Но их ценность зависит от исходных условий:

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

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

Копировать артефакт без причины его появления — всё равно что перенести лекарство без диагноза.

Где хорошие намерения превращаются в лишнюю сложность

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

Несколько характерных сигналов:

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

Отдельный репозиторий ещё не даёт независимость. Брокер сообщений сам по себе не обеспечивает устойчивость. Оркестратор не заменяет эксплуатационную дисциплину. Любой из этих инструментов начинает приносить пользу только вместе с ответственностью, наблюдаемостью и понятным процессом изменений.

Собирательный мини-кейс

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

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

Исправление началось не с очередной перестройки. Команда:

1. сопоставила сервисы с бизнес-возможностями и владельцами;
2. нашла компоненты, которые не имели самостоятельного жизненного цикла;
3. объединила там, где разделение не давало измеримой пользы;
4. закрепила SLO, дежурство и сценарии восстановления за конкретными владельцами;
5. оставила только те контрольные точки, для которых был понятен риск.

Результатом стала не «идеальная архитектура», а более короткая цепочка ответственности и понятный путь изменения системы. Именно это и было исходной целью.

Пять вопросов перед переносом практики

Перед тем как внедрять решение «как у больших», я предлагаю короткую проверку.

1. Какое ограничение мы устраняем?

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

2. Как поймём, что стало лучше?

Выберите одну-две метрики, связанные с целью: lead time изменения, частота отказов при релизе, время восстановления, доля независимых поставок или стоимость инфраструктуры на полезную нагрузку.

3. Какова полная цена решения?

Считать нужно не только разработку. В цену входят платформа, наблюдаемость, тестовые среды, безопасность, обучение, дежурства, обновления и координация между владельцами.

4. Какие условия сделали практику успешной у источника?

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

5. Как проверить гипотезу обратимым шагом?

Выделить один контур, автоматизировать один поток поставки, ввести короткий ADR, проверить один сервис с независимым масштабированием. Небольшой эксперимент даёт данные и сохраняет возможность отступить.

Что действительно стоит перенимать

У сильных инженерных организаций полезно перенимать не внешний вид системы, а качество принятия решений:

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

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

Решение, которое подходит нашей команде

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

Поэтому на предложение «сделаем как в FAANG» я бы не отвечал ни согласием, ни отказом. Я бы спросил:

«Какую нашу проблему это решит — и как мы это проверим?»

Этот вопрос не отменяет амбицию. Он превращает её в инженерное решение.

---

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

Ваш ДПУПП