Pull to refresh
34
-2
Виктор Корейша @Iktash

Пользователь

Send message

По количеству брокеров. Во-первых, у нас нагрузка на которую рассчитан кластер в rps не полтора миллиона, а на порядок больше. По трафику так же нужно смотреть — как правило пишут большими батчами, а не по одному сообщению. Это наша общая рекомендация для сервисов. Размеры батчей до 50Мб доходят. Во-вторых, у нас все рассчитано на падения одного из трех ДЦ, в которых расположена Кафка. Третий момент — нужно смотреть конфигурацию, например у нас довольно много ресурсов заложено на TLS, на работу внутренних экспортеров. Ну и последний момент, число 75 условное.

Про повторы. Вероятно, вы путаете нашу статью с аналогичной от Авито. У них похожий подход и они пишут о нем периодически, например, тут
https://habr.com/ru/companies/avito/articles/655553/

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

Потому что мы все еще хотим предоставлять шину данных с гарантиями at least once. И она все еще должна уметь хорошо горизонтально масштабироваться, для того, чтобы быть общим ресурсом для огромного количества сервисов. И, конечно, поддерживать возможность горизонтального масштабирования самих сервисов.

Я специально писал статью про DnD, как самый популярный представитель жанра. Чтобы было понятнее широкому кругу читателей. И да, как правило, я использую свою систему dnd-based.

Но статья совсем не про это. А про мой опыт использования Настольных ролевых игр для разных команд. Обратите внимания, что в статье нет абсолютно ничего Dnd-специфичного. Я пробовал адаптировать и другие системы. Или брать конкретные механики из разных систем и даже из настольных игр. С точки зрения методологии все работает так же.

В статье речь шла о разовых играх. Для того чтобы собраться один раз на 2,5 часа, на мой взгляд, не нужно бросать все свои остальные занятия и даже сильно двигать приоритеты. В конце концов, я каждый год вижу, как почти все собираются на новогодний корпоратив на 4-6 часов без зазрения совести.

Регулярные игры — другой разговор. Но это и совсем другой инструмент. Возможно, достойный отдельной статьи.

По поводу времени — это все вопрос договоренностей. Конечно, если речь о каком-то аврале или самом разгаре сезона, то рабочее время на вес золота, а в нерабочее нужно дать команде отдохнуть. Но бо́льшую часть времени такого нет. И с любым руководителем можно договориться, чтобы он выделили время на командную активность. Собственно, так ведь работает с любыми тимбилдингами/мероприятиями, разве нет?

Я говорил в статье, что метод подходит не всем. Никакой обязаловки. Да, я могу предложить. А любой член команды может отказаться. Это нормально. У нас же нет «игр в D&D» в должностной инструкции.

Отвечу по пунктам:
1) Я не могу сказать, что у меня всегда получается с первого раза. Для статьи я отобрал удачные и разнообразные кейсы. Но были и менее удачные, если честно. И да, конечно опыт помогает — с каждым разом вероятность успеха все выше.

2) Если вы хотите конкретных рекомендаций, то для sci-fi мой фаворит Starfinder, для п/а Точка отсчета(Мутанты)
Но вариантов много. В том числе, существуют соответствующие модификации D&D

Ну, или это могут быть разные люди — мастер игры и тот, кто дает обратную связь. Хотя на моей практике, обе роли всегда я играю. Поэтому тут мне трудно советовать.

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

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

Для того, чтобы не было таких конфузов, я заранее общаюсь с ребятами. Ну и, конечно, даже если я заранее этого не сделал, всегда можно поправить на ходу. Если видно, что человеку не ловко из-за чего-то, то убрать или поправить этот элемент игры.

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

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

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

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

А пока бот в разработке/отладке вы переключаете вебхук на локальную машину? Или каждый раз деплоитесь, чтобы протестировать?

Решение вашего вопроса лежит не в плоскости Кафки. Кафка не создана для того чтобы ограничивать потоки, наоборот, ее задача прогонять через себя как можно больше и как можно надежнее.

Из вашего сообщения непонятно где вы хотите избежать пика нагрузки на вторую базу или на вашу систему аналитики и преобразований? Если первое, то ковыряйте настройки debezium. Если не выйдет — придумывайте костыли с дополнительной табличкой в первой базе, куда перекладывайте из первой, например, процедурами. Мне такой подход совершенно не нравится, но это можно реализовать. На крайняк, троттлите сеть. Но лучше, конечно, свой продюсер написать, на котором вы будете контролировать скорость вычитки из базы и записи в Кафку.

Если вы хотите избежать нагрузки на вашу систему обработки. Тогда именно там это и нужно делать. Сделайте так, чтобы ваша система обработки/аналитики не забирала сразу все, а делала это постепенно.

А можете подробнее пояснить какая у вас проблема, какую задачу вы решаете? Зачем понадобилось лимитировать?

В мире Кафки принято решать все логические вопросы на стороне клиента. Соответственно, вы можете ограничить скорость вычитывания на консьюмере. Но непонятно зачем это нужно.

linger.ms и batch.size нужны для того, чтобы отправлять сообщения не по одному, а батчами. На суммарное количество/объем сообщений от продюссера не влияют.

Собственно, автор говорит об этом. Там то ли баг, то ли фича, но работает так:
1) Удаляет старые записи
2) Проходит валидацию, что все заполнено верно
3) Если валидация пройдена, то вносятся новые

Соответственно, опечатка приводит к полному удалению всего, что было.

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

А у вас есть опыт замены? Расскажете, почему приняли такое решение и как прошло?

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

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

А как насчет продуктивности? Если я пытаюсь похудеть, то все время хочу есть. А значит почти не могу думать о работе. Если в этот день мне предстоит сделать что-то физическое, то я все равно могу это делать, не зависимо от мыслей. А если нужно придумывать, анализировать, обсуждать с коллегами и доказывать свою точку зрения, то моя продуктивность падает критически. Я один такой?

Это же хабр! Хотелось бы больше технических подробностей. С какими проблемами сталкивались и как решали? Из текста следует, что самая большая сложность — договориться с безопастниками.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity