Нет ничего более бесполезного, чем эффективно делать то, что вообще не следует делать
Питер Фердинанд Друкер
Микросервисы часто обсуждают как цель: «нам нужно перейти на микросервисы», «нам нужно распилить монолит», «нам нужно стать современнее».
Но если смотреть глубже, настоящая цель не в количестве сервисов. Настоящая цель — Fast Flow: способность инженерной организации быстро, безопасно и устойчиво проводить ценные изменения от идеи до пользователя.
1. Что такое Fast Flow простыми словами
Fast Flow — это идея, что главная цель инженерной организации не «писать больше кода», не «делать больше микросервисов» и не «загрузить разработчиков на 100%», а быстро, безопасно и устойчиво пропускать ценные изменения от идеи до пользователя.
То есть поток выглядит так:
Идея → Понятное маленькое изменение → Разработка → Автоматическая проверка → Безопасный релиз → Обратная связь от пользователей / системы → Следующее улучшение
Chris Richardson на microservices.io формулирует Fast Flow как continuous stream of valuable changes — непрерывный поток небольших ценных изменений, который достигается сочетанием DevOps, Team Topologies и подходящей архитектуры. Он прямо пишет, что смысл не в том, чтобы заставлять людей работать дольше, а в том, чтобы работать умнее: уменьшать блокировки, очереди, зависимости и время ожидания.
Самое важное: Fast Flow — это не один конкретный инструмент и не один паттерн. Это одновременно:
- Философия: ценим поток полезных изменений, а не занятость людей.
- Подход к проектированию: архитектура должна позволять менять части системы независимо.
- Подход к организации команд: команды должны владеть понятными кусками продукта и уметь доводить изменения до production без постоянных согласований.
- Подход к платформе: CI/CD, observability, security, шаблоны сервисов, окружения и деплой должны помогать командам, а не превращаться в бюрократию.
2. Главная метафора: река
Представь реку.
У хорошей реки вода течёт свободно. Есть русло, нет завалов, нет плотин в каждом километре, нет постоянных мест, где вода стоит неделями.
В software delivery «вода» — это изменения:
- новая фича
- исправление бага
- изменение API
- обновление библиотеки
- миграция БД
- улучшение безопасности
- изменение UX
Slow Flow — это когда изменение застревает:
Идея → аналитик → backlog → архитектурный комитет → backend → frontend → DBA → security → QA → release manager → DevOps → production
На каждом шаге ожидание, согласование, очередь, ручная проверка, повторное объяснение контекста.
Fast Flow — это когда большинство изменений проходит коротким, безопасным путём:
Команда поняла проблему → сделала маленькое изменение → прогнала тесты→ задеплоила →увидела результат
Это не значит «быстро и бездумно». Скорее наоборот: система специально спроектирована так, чтобы маленькие изменения были безопасными.
3. Откуда это пошло
У Fast Flow несколько корней.
Первый корень — Lean и Toyota Production System
Идея «потока ценности» пришла не из IT. Она выросла из Lean-подхода, особенно из Toyota Production System. В Lean смотрят не на то, насколько заняты отдельные люди или станки, а на то, как ценность проходит через всю систему. Lean Enterprise Institute описывает Lean как способ создавать нужную ценность с меньшими ресурсами и меньшими потерями, через постоянные эксперименты и улучшения.
Отсюда же пришёл термин value stream — поток создания ценности. Value Stream Mapping — это практика, где рисуют все шаги от запроса клиента до поставки результата, чтобы увидеть ожидания, лишние действия и потери. LEI описывает VSM как диаграммирование всех шагов материального и информационного потока от заказа до доставки; этот инструмент был развит в Toyota и стал частью Toyota Production System.
В IT это превратилось в вопрос:
Сколько времени реально занимает путь от идеи до работающего изменения в production?
И почти всегда оказывается, что разработчик писал код 2 дня, а всё изменение «ехало» 3 недели из-за ожиданий, согласований, тестовых окружений, ревью, релизных окон и зависимостей.
Второй корень — DevOps и Continuous Delivery
DevOps добавил к Lean важную инженерную часть: часто поставлять маленькие изменения, автоматизировать проверки, быстро получать обратную связь и быстро восстанавливаться при ошибках.
DORA сейчас описывает software delivery performance через показатели потока и нестабильности: change lead time, deployment frequency, failed deployment recovery time, change fail rate и deployment rework rate. То есть современная DevOps-метрика тоже смотрит не на «сколько строк кода написал разработчик», а на то, как работает вся система доставки изменений.
Простой смысл DORA для новичка:
Lead time: Сколько времени от изменения в коде до production?
Deployment frequency: Как часто мы можем безопасно выпускаться?
Change fail rate: Какой процент релизов ломает production?
Recovery time: Как быстро мы восстанавливаемся после сбоя?
Fast Flow очень близок к DevOps, но шире. DevOps отвечает: как доставлять изменения технически и операционно. Fast Flow спрашивает: а вся организация вообще устроена так, чтобы изменения могли течь?
Третий корень — Team Topologies
Team Topologies — один из главных источников современной формулировки Fast Flow. На официальном сайте Team Topologies прямо описан как подход к проектированию «team-of-teams» организации для fast flow of value.
Team Topologies говорит: нельзя ускорить поток только CI/CD или только микросервисами. Поток ограничивают три вещи одновременно:
- Архитектура
- Процессы: Agile / DevOps
- Способы взаимодействия команд
Официальный сайт Team Topologies прямо подчёркивает, что поток ценности определяется и часто ограничивается именно сочетанием архитектуры, процессов и паттернов взаимодействия команд; если улучшать только один элемент, система всё равно будет ограничена самым медленным элементом.
Это очень важная мысль.
Можно иметь Kubernetes, CI/CD и микросервисы, но если каждое изменение требует согласования с 8 командами — Fast Flow не будет.
Можно иметь хорошие автономные команды, но если архитектура — «распределённый монолит», где любое изменение ломает 10 сервисов, — Fast Flow тоже не будет.
Можно иметь хорошую архитектуру, но если релиз возможен только раз в месяц через ручной CAB-комитет — Fast Flow снова не будет.
Четвёртый корень — микросервисы, но не так, как обычно думают
Микросервисы часто продают как «масштабируемость», «независимые сервисы», «современность». Но в контексте Fast Flow их главный смысл другой:
микросервисная архитектура полезна, если она позволяет командам независимо и часто менять части системы.
На microservices.io Richardson определяет микросервисную архитектуру как стиль, где приложение состоит из сервисов, которые loosely design-time coupled и independently deployable. То есть сервисы должны быть слабо связаны на этапе разработки и независимо деплоиться.
Это ключ. Не «у нас 150 сервисов». А:
- может ли команда изменить свой сервис;
- протестировать его;
- задеплоить его;
- и не ждать синхронного релиза всей компании;
Если да — микросервисы помогают Fast Flow.
Если нет — это не Fast Flow, а просто распределённый монолит.
4. Это философия или подход к проектированию?
Правильный ответ: и то, и другое, плюс операционная модель.
Я бы разложил так.
Fast Flow как философия
Философия здесь такая:
Оптимизируй не занятость людей, а скорость и безопасность прохождения ценности через систему.
В обычной компании часто пытаются добиться продуктивности так:
- Все должны быть заняты.
- У всех должно быть много задач.
- Разработчики должны писать больше кода.
- Надо больше митингов для синхронизации.
- Надо больше контроля.
- Надо больше отчётности.
Fast Flow говорит обратное:
- Слишком много задач = очереди.
- Слишком много зависимостей = ожидание.
- Слишком много согласований = задержка.
- Слишком большие релизы = риск.
- Слишком много ручной работы = ошибки.
- Слишком много контекста на команду = когнитивная перегрузка.
Richardson на microservices.io даже пишет, что идея «работать дольше» контрпродуктивна; вместо этого организации должны снижать трение и принимать Fast Flow.
Fast Flow как подход к архитектуре
Архитектура должна отвечать не только на вопросы:
- Система масштабируется?
- Система надёжная?
- Система безопасная?
Но и на вопрос:
- Насколько легко и безопасно её менять?
Richardson пишет, что для Fast Flow архитектура должна поддерживать DevOps и Team Topologies, а для этого нужны team-sized elements, loose design-time coupling, testability, deployability и observability.
Простым языком:
- team-sized elements → кусок системы должен помещаться в голову одной команды
- loose design-time coupling → изменение одного куска редко требует изменения другого
- testability → можно быстро и автоматически проверить изменение
- deployability → можно быстро и безопасно выкатить изменение
- observability → после релиза видно, что происходит
Это уже чисто архитектурное мышление.
Fast Flow заставляет архитектора проектировать не только runtime-свойства, но и development-time-свойства: насколько система удобна для изменения, тестирования, деплоя и сопровождения.
Fast Flow как подход к организации команд
Team Topologies говорит, что основная рабочая единица — не отдельный разработчик, а команда. Особенно важны stream-aligned teams — долгоживущие команды, выровненные по потоку ценности или части бизнес-домена. Они должны владеть своим продуктовым участком и уметь доставлять изменения end-to-end.
Например, не так:
- Команда backend
- Команда frontend
- Команда database
- Команда QA
- Команда DevOps
- Команда security
А ближе к этому:
- Команда "Оформление заказа"
- Команда "Платежи"
- Команда "Каталог"
- Команда "Личный кабинет"
- Команда "Уведомления"
Каждая такая команда владеет частью бизнес-потока. Ей не нужно каждый раз бегать по всей организации, чтобы выпустить изменение.
Это не значит, что не нужны platform/security/infra команды. Нужны. Но они должны работать как внутренняя платформа, а не как очередь заявок.
5. Какие проблемы Fast Flow решает
Проблема 1. «Мы вроде Agile, но всё равно медленно»
Многие компании используют Scrum, Jira, стендапы и спринты, но изменение всё равно идёт в production неделями или месяцами.
Почему?
Потому что Agile внутри команды не решает системные блокировки:
- зависимость от другой команды
- ручное тестирование
- нестабильные окружения
- сложный релизный процесс
- архитектурная связанность
- очередь на security review
- очередь на DevOps
- очередь на DBA
- ручные approve
Fast Flow смотрит на весь путь изменения, а не только на sprint board.
Проблема 2. Большие релизы
Slow Flow часто приводит к большим релизам:
- релиз раз в месяц
- много изменений внутри
- сложно понять, что сломалось
- страшно выкатывать
- нужны ночные релизы
- нужен rollback plan на 20 страниц
Fast Flow двигает в сторону маленьких изменений:
- маленький PR
- маленький deploy
- feature flag
- canary release
- быстрый rollback
- быстрая диагностика
Маленькое изменение легче понять, проверить, откатить и улучшить.
Проблема 3. Зависимости между командами
Team Topologies прямо называет blocking dependencies и handovers одним из главных препятствий Fast Flow. Функциональные silo-структуры создают много передач между командами, а передачи создают ожидание и задержки.
Классический пример:
- Backend делает API.
- Frontend ждёт backend.
- Backend ждёт DBA.
- DBA ждёт change request.
- QA ждёт готовый build.
- DevOps ждёт approval.
- Security ждёт документацию.
- Product ждёт релиз.
Все заняты. Но ценность не движется.
Fast Flow пытается уменьшить количество таких передач.
Проблема 4. Когнитивная перегрузка
Команда не может эффективно владеть слишком большим количеством вещей.
Если одна команда отвечает за:
- 20 микросервисов
- 5 баз данных
- 3 фронтенда
- старый монолит
- инциденты
- миграцию на Kubernetes
- security backlog
- поддержку пользователей
то она будет медленной не потому, что люди плохие, а потому что система перегрузила их мозг.
Team Topologies отдельно подчёркивает cognitive load: слишком большая система требует времени на восстановление контекста, создаёт больше багов и rework, мешает мастерству и инновациям.
Fast Flow требует проектировать границы так, чтобы команда могла реально понимать и менять свой участок.
Проблема 5. Локальная оптимизация
Типичная ошибка менеджмента:
Давайте измерять каждого разработчика:
сколько PR
сколько строк кода
сколько задач закрыл
Проблема в том, что это оптимизирует локальную активность, а не поток ценности.
Разработчик может закрыть 20 задач, но ни одна не дошла до пользователя.
Fast Flow смотрит иначе:
Сколько времени изменение идёт от идеи до production?
Где оно ждёт?
Почему ждёт?
Что ломается при релизе?
Как быстро мы получаем обратную связь?
Richardson предлагает смотреть на DORA/DevEx-подобные показатели как на измерение трения в социотехнической системе, а не как на прямую «продуктивность разработчика».
6. Как выглядит Slow Flow на практике
Допустим, нужно добавить простую бизнес-фичу: «дать скидку корпоративному клиенту».
В slow-flow организации это может выглядеть так:
- Product описывает задачу.
- Analyst уточняет требования.
- Backend-команда ждёт архитектурного решения.
- Architecture board обсуждает влияние на billing.
- Backend меняет сервис заказов.
- Оказывается, нужен billing-сервис.
- Billing-команда занята другим квартальным roadmap.
- Frontend ждёт API.
- QA ждёт test environment.
- Test environment сломан.
- DBA должен согласовать миграцию.
- Security просит threat model.
- Release manager ставит задачу в релизное окно.
- Через 6 недель фича попадает в production.
- Пользователи говорят: «это не то, что нам нужно».
Здесь разработка могла занять 3 дня, но lead time — 6 недель.
Это и есть плохой flow.
7. Как выглядит Fast Flow на практике
В fast-flow организации та же задача могла бы идти так:
1. Stream-aligned команда "Корпоративные продажи" сама владеет нужным доменом.
2. Команда режет фичу на маленький вертикальный slice.
3. Изменение проходит локальные и pipeline-тесты.
4. Контракты API проверяются автоматически.
5. Миграция БД backwards-compatible.
6. Фича скрыта за feature flag.
7. Canary release на небольшой процент клиентов.
8. Observability показывает результат.
9. Product быстро получает обратную связь.
10. Команда улучшает решение.
Важный момент: Fast Flow не обязательно означает «всё за один день». Он означает, что система не создаёт искусственных задержек, а риск снижен за счёт маленьких изменений, автоматизации и обратной связи.
8. Как Fast Flow связан с микросервисами
Микросервисы — это один из возможных способов достичь Fast Flow, но не единственный.
Fast Flow можно получить и на хорошем modular monolith, если:
- модули хорошо разделены
- есть понятные границы
- есть автоматические тесты
- есть частые релизы
- команды не блокируют друг друга
И наоборот, можно иметь микросервисы без Fast Flow:
- 100 сервисов
- общая база данных
- общие библиотеки, которые ломают всё
- синхронные релизы всех сервисов
- ручное end-to-end тестирование
- сложные зависимости между командами
Это будет не микросервисная архитектура в полезном смысле, а distributed monolith.
Richardson подчёркивает, что ключевые свойства настоящих микросервисов — loose design-time coupling и independent deployability. Именно они позволяют командам работать и деплоить независимо.
Поэтому правильная логика такая:
Не:
"Мы хотим микросервисы, потому что это современно"
А:
"Нам нужен Fast Flow.
Какая архитектура позволит командам быстро и безопасно менять систему?
Может быть, это микросервисы.
Может быть, сначала modular monolith.
Может быть, гибрид."