А какие критерии удовлетворенности работы Кафкой вы бы взяли? Уже вторую итерацию сомневаюсь, что хорошие выбрал.
Хороший вопрос. Но давайте сразу разберёмся — а мы про что именно?
Есть два совершенно разных уровня:
👉 1. Технические SLA 👈
Это твоя зона ответственности. Здесь всё предельно скучно и конкретно:
- гарантия сохранности и доставки сообщений (с кучей сносок и оговорок)
- работоспособность коннекторов и интеграций (Debezium и прочие)
- живые алерты и мониторинг (если упало — узнали)
- что интерфейсы мониторинга реально что-то показывают
- что есть возможность внести изменения в конфиги без плясок с бубном
Тут надо оговориться, что сохранность сообщений это сложная тема. Ты не можешь отвечать за приёмку чужих данных полностью — максимум за то, что, получив, запишешь их надёжно и сколько-то подержишь. Почему-то не очевидно, что “пуля вылетела со стороны моего приложения” — ещё не значит, что она долетела до хранилища. И обязательно надо формализовть: срок хранения, объём, всяческие оговорки вроде что происходит если клиент нарушает соглашение.
👉 2. "Удовлетворённость клиентов" / “Что всё хорошо работает” 👈
Это вообще другой пласт. И тут люди хотят магии:
- ничего не падает
- данные всегда тянутся
- любую свою поделку можно интегрировать за вечер
- саппорт отвечает быстро и по делу
Но это не про технику. Это про сервис.
Если хочешь метрику уровня "довольны — не довольны", проведи регулярный опрос вида «Кафка — заебись?». Никаких цифр в прометее не будет, но будет политический актив: аргумент на встречи с руководством и способ строить отношения с командами.
А если хочешь, чтобы эта метрика улетела в небеса — начни раздавать всем денег, вот радости-то будет!
А теперь о том, что реально можно померить.
Если хочешь именно технические метрики:
- latency контрольного приложения, которое пишет и читает тестовое сообщение — покажет по сути погоду на марсе, но прикольную
- доступность маршрута от контрольного клиента до брокеров — зависит от кучи других людей типа сетевиков, но тоже ничего так погода на марсе
- процент зелёных health-check’ов — не говорит ни о чём само по себе, но пускай будет
- размеры очередей — важно, но на практике всё сильно зависит от клиента
- падения коннекторов — 99% не зависящих от тебя, но пускай будет
Зачем? Чтобы показать “как хорошо мы работаем”? Нет, ни в коем случае!
Эти метрики могут дать ВНУТРЕННЮЮ пищу для размышлений: чтобы понять, где пора разгребать SRE-долг, как повлияли принятые решения, где искать рут коз стрельнувшей проблемы.
У продуктовых команд своя сказка, с этими метриками ВООБЩЕ не связанная. Они могут страдать даже при зелёной панели в графане.
⚠️ Важная мысль ⚠️
"Чтобы все были довольны" — это не инженерная задача. Это политическая. Игра про ожидания и договорённости.
Если хочешь работать над "удовлетворённостью" всерьёз — начинай с вопросов:
- Что именно пользователь ждал?
- Чем ты реально можешь управлять?
- Где заканчивается твоя ответственность?
- Кто будет эти ожидания формулировать и транслировать?
Это уже не про Kafka, а про продуктовое управление и лидерство.
Потому что да, если Кафка падает и теряет данные — пользователи точно будут недовольны. Но если она не падает и не теряет — довольными их это не сделает автоматически. 😳
Всё остальное — коммуникация. И договорённости.
Если непонятно, как это построить — велкам на обучение руководству и тимлидству. Потому что никакие красивые метрики тебя от этих разговоров не спасут.