Kafka-команда как сервис умывания рук

(кейс из менторской практики)

История от менти.
Крупный Enterprise. Нужно подключить сервис к Kafka.

На входе — нормальная бизнес-задача.
На выходе — аналитик, который внезапно должен:
• посчитать объёмы сообщений,
• определить количество топиков,
• выбрать число партиций,
• решить, сколько реплик и на каких брокерах,
• и аккуратно раскрасить заявку по цветам в Excel-шаблоне.
Да, буквально. Не метафора.

И вот здесь возникает простой вопрос:
а чем тогда занимается Kafka-команда?

⸻

Платформа сбрасывает ответственность — аналитик её ловит

Формально всё выглядит прилично.
Платформенная команда говорит:
«Мы не можем просто так дать доступ. Вы же можете положить кластер».

И дальше происходит ключевой трюк.

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

Если что-то пойдёт не так — виноват ты.
Не платформа. Не кластер. Не архитектурный гайд.
Аналитик, который “так указал в заявке”.

Это не про Kafka.
Это про страх ответственности, замаскированный под процесс.

⸻

Аналитик как высокооплачиваемая секретарша с навыками Excel-дизайнера

В этой модели аналитик перестаёт быть аналитиком.

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

А теперь ключевая метафора.

Аналитик подписывается под количеством партиций, хотя его экспертиза заканчивается на логике домена и бизнес-процесса.

Это как если бы официант решал, при какой температуре повару жарить стейк, чтобы ресторан не сгорел.

Не потому что он эксперт.
А потому что иначе заказ не примут.

⸻

Архитектура на костылях из аналитиков

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

И внезапно в компании начинают считать, что знание параметров Kafka важнее понимания бизнес-процесса.

Хотя должно быть ровно наоборот.

И, кстати, именно здесь становится понятно, почему в Enterprise так много системных аналитиков.

Не из-за сложности систем.
А из-за размытого ownership.

⸻

Финальный вопрос (не академический)

А вы кто в своей компании?
• архитектор смыслов,
• человек, который понимает бизнес-потоки,
• и проектирует решения

или

бесплатное приложение к Jira-шаблону платформенной команды,
которое ещё и аккуратно раскрашивает ячейки, чтобы заявка прошла дальше?

Вот здесь, кажется, и проходит настоящая граница роли аналитика.