Зашел освежить память по конфигурации брокеров и сторон общения, спасибо за удобную выдержку по этому вопросу. Однако, если уж это методичка для вашей команды, хочу обратить внимание на ряд ошибок. Я пишу на .NET, и не исключаю, что конфигурация клиента Kafka на фреймворках Python имеет side-effects, тем не менее здесь вы рассказываете довольно общие вещи.
1. "Оффсет — это уникальный идентификатор (аналог индекса в массиве)" - offset, даже в языках с индексированными коллекциями, и есть offset. То есть смещение индекса, обычно относительно начала или конца коллекции. И offset вполне имеет место даже в непроиндексированных коллекциях - связных списках, например. 2. "Key — используется для сегментации сообщений внутри партции." Вообще говоря, скорее между партициями, ведь если ключ разный, Kafka будет запихивать сообщения в разные партиции, как раз в зависимости от ключа. Похожим образом работают buckets под капотом словаря в C# или Java. hash(key) % numPartitions 3. "enable.idempotence (true) — позволяет сделать операцию продюсера в сторону Кафка‑брокера атомарной транзакцией". Этот флаг, вообще никак не влияет на транзакционность или атомарность, ровно как не гарантирует exaclty once, но об этом позже. Он работает так, что присваивает отправляемым сообщениям специальный sequence number, по которому позже сможет понять, что в очередь попали дубликаты, и устранит их. Однако даже в таком случае имеет место падение отправляющей стороны, и тогда дубли все-таки залетят. 4. "read_commited — Консюмер считывает только те сообщения от Продюсера, по которым завершилась транзакция (enable.idempotence = true у продюсера)" - из той же серии. Это работает когда мы включаем транзакционность Kafka, и это вообще не про флаг enable.idempotence, что очевидно из названия. Поднимается Transaction Coordinator, и помечает сообщения флагами "С", "A". В ином случае использование read_commited на потребителе не имеет смысла. 5. На изображении принципа работы consumer-группы, по-моему, вообще ошибка. Да, группы делят offset на определенную партицию. Так, если pod-consumer упадет, следующий будет знать откуда читать. Но причем тут сообщения из разных партиций? Они разные, и офсеты там разные, на вашей картинке продемонстрирована потеря сообщений. 6. Про exactly once - если бы так все просто работало. enable.idempotence = true действительно сможет позаботиться об отсутствии дублей на отправке, но никак не сможет этого гарантировать - почему, упоминал выше. На стороне принятия enable.auto.commit = false тоже не будет достаточно, при определенном подходе к коду максимум что мы сможем гарантировать такими мероприятиями - at least once. Для реализации "effectively once", мы должны использовать транзакционность Kafka, или паттерн Transactional Outbox, если мы не только гоняем сообщение по очередям, но и храним.
Соглашусь про перспективы партнерства и роста. Про сеньоров жизненно, когда пришел, удивлялся, что по сути миддлов нету: только протекаемые джуны и костяк сеньоров, через год вопрос улетучился. На самом деле даже тут параллель с государством напрашивается: в каком государстве нет среднего класса? История говорит что в менее развитом и хуже организованном.
Тут у меня лично нет мнения, потому что речь об IT-компании. И вилки у меня были соответствующие (не было в компании сотрудников с зп меньше 100к). Вопрос в другом: на собесе и в доках утверждалось что по ЗП они 80 перцентиль, а на деле спектр твоих обязанностей для многих компаний вообще нонсанс. Условно, ты джун - но берешься вообще за все: фиксить логику отвечающую за деньги - не вопрос; аналитики нет - делаешь сам; тестировщиков нет - делаешь от и до сам, отвечаешь так же; частые дежурства - вообще отдельный разговор: требование за 1 смену (неделя) разобраться по идее в Data Analysis и DevOpsing - иначе вопросы. На деле в условном финтехе за такие деньги ты NPC, хорошо маппинг и эндпойнты к готовой логике подвести сумеешь. Наши же джуны без проблем собесы на миддлов с вилкой в 2-2,5 раз выше в тех же банках без проблем бы проходили.
Если говорить про мой кейс и про "нет начальника", добавьте к этому невозможность отказаться от задачи и прибавьте микроконтроль. А если отказываешься - могли притянуть "значит, ты вне культуры". Бывало, что за отказ браться за лидинг эпика, что вообще по идее не всем дано, и не прописано в ТД, могли пригрозить отложением уже запланированного повышения ЗП. А чел просто устроился сеньором и по документам "программист".
А где я не прав, выдав такую характеристику именно сочетанию "бирюзовые компании"? Хоть это отчасти и верное замечание, в статье которую вы предлагаете описывается концепция эволюции человеческой психики, она не про управление и компании. Не исключаю, что предложенное Лалу определение базировалось на этих учениях о психике, но я специально подчеркнул, что речь именно о словосочетании "бирюзовые компании", чтобы не смещать фокус и не раздувать статью.
Действительно хорошее замечание, так как сейчас вполне нормально казаться лучше на собесах - как компании, так и сотруднику. Что касается моих вопросов: панацеи, как не странно, не существует. Но задать их нужно, либо для того чтобы засомневаться в самом начале, либо, в случае описанного вами случая, как можно раньше понять и смыться. Думая над вопросами, я проецировал на себя. Поэтому, полагаю, если бы я проговаривал эти вопросы при трудоустройстве, я бы либо вообще не устроился, либо ушел бы гораздо раньше, экономя свои нервы.
Также надо понимать, что компания вкладывает в сотрудника ресурсы. А если говорить про эту компанию, речь о серьезных затратах. Это дорогущее оборудование, командировки, в том числе и за границу, длительный онбординг. Есть немалая вероятность, что в таком случае, если виден серьезный мисматч по культуре, который, в том числе мог бы быть выявлен вопросами из статьи, компания сама не будет готова брать риски.
Меня уже 2 раза притянули за скрытый PR, так что, пожалуй, просьбу отклоню. Можете продублировать первую часть названия статьи "Бирюзовые компании в РФ", с чего я сам начинал, когда садился за статью. Получите вполне удовлетворительный результат. Уверен, о многих услышите не впервые, а возможно чьими-то услугами уже пользуетесь.
Это не упоминалось в статье чтоб не уводить акцент, но есть в подкасте, на который я ссылался, говоря про "клиентократию". Спикер говорит, что конкретно у них люди которые напрямую не связаны с донесением пользы клиента - если угодно, инфраструктурные сотрудники, типа финансового директора, работают по более классической модели.
Отвечу просто: так получилось. Эта статья - желание поделиться + самому отрефлексировать/систематизировать полезный жизненный опыт. Также, о чем не говорилось в самом тексте, она является итоговой работой на зачет в универе. Мое направление - разработка ПО, и никак с PR и прочим не связана. В пользу этого, я, сознательно или нет, избегал хвалебной или враждебной риторики. Даже приводя в пример организацию из статьи, назвал её устройство "адаптацией бирюзовых подходов", избегая лишних ассоциаций с маркой или эталоном. А привел я её для лучшего понимания обывателя, просто взяв за пример организацию "на слуху".
У нас это решалось через микроконтроль. Был "особо инициативный", как правило "старший" в команде, который не стесняясь в формулировках распрашивал команду о прогрессе. Имел место случай, когда "проактивность" этого человека совпала с уходом одного из сотрудников, в сторону которого такая риторика накануне применилась, совпадение? Вообще "протекаемость" работников была довольно высокая. Обосновывалась теми же ребятками сложностью модуля, над которым работала команда, а я бы расширил список причин. Правильно, если бы был, как выразился yellowmew в своем комментарии, "красный" лид с правом решающего голоса. То же высказывает Кривенко, в подкасте, упомянутом в статье. То же, как вариант, затрагиваю здесь я: если явной иерархии вообще нет, часто все приходит к соревнованию по размеру тестикул.
Зашел освежить память по конфигурации брокеров и сторон общения, спасибо за удобную выдержку по этому вопросу. Однако, если уж это методичка для вашей команды, хочу обратить внимание на ряд ошибок. Я пишу на .NET, и не исключаю, что конфигурация клиента Kafka на фреймворках Python имеет side-effects, тем не менее здесь вы рассказываете довольно общие вещи.
1. "Оффсет — это уникальный идентификатор (аналог индекса в массиве)" - offset, даже в языках с индексированными коллекциями, и есть offset. То есть смещение индекса, обычно относительно начала или конца коллекции. И offset вполне имеет место даже в непроиндексированных коллекциях - связных списках, например.
2. "Key — используется для сегментации сообщений внутри партции." Вообще говоря, скорее между партициями, ведь если ключ разный, Kafka будет запихивать сообщения в разные партиции, как раз в зависимости от ключа. Похожим образом работают buckets под капотом словаря в C# или Java.
hash(key) % numPartitions3. "enable.idempotence (true) — позволяет сделать операцию продюсера в сторону Кафка‑брокера атомарной транзакцией". Этот флаг, вообще никак не влияет на транзакционность или атомарность, ровно как не гарантирует exaclty once, но об этом позже. Он работает так, что присваивает отправляемым сообщениям специальный sequence number, по которому позже сможет понять, что в очередь попали дубликаты, и устранит их. Однако даже в таком случае имеет место падение отправляющей стороны, и тогда дубли все-таки залетят.
4. "read_commited — Консюмер считывает только те сообщения от Продюсера, по которым завершилась транзакция (enable.idempotence = true у продюсера)" - из той же серии. Это работает когда мы включаем транзакционность Kafka, и это вообще не про флаг enable.idempotence, что очевидно из названия. Поднимается Transaction Coordinator, и помечает сообщения флагами "С", "A". В ином случае использование read_commited на потребителе не имеет смысла.
5. На изображении принципа работы consumer-группы, по-моему, вообще ошибка. Да, группы делят offset на определенную партицию. Так, если pod-consumer упадет, следующий будет знать откуда читать. Но причем тут сообщения из разных партиций? Они разные, и офсеты там разные, на вашей картинке продемонстрирована потеря сообщений.
6. Про exactly once - если бы так все просто работало. enable.idempotence = true действительно сможет позаботиться об отсутствии дублей на отправке, но никак не сможет этого гарантировать - почему, упоминал выше. На стороне принятия enable.auto.commit = false тоже не будет достаточно, при определенном подходе к коду максимум что мы сможем гарантировать такими мероприятиями - at least once. Для реализации "effectively once", мы должны использовать транзакционность Kafka, или паттерн Transactional Outbox, если мы не только гоняем сообщение по очередям, но и храним.
Соглашусь про перспективы партнерства и роста. Про сеньоров жизненно, когда пришел, удивлялся, что по сути миддлов нету: только протекаемые джуны и костяк сеньоров, через год вопрос улетучился. На самом деле даже тут параллель с государством напрашивается: в каком государстве нет среднего класса? История говорит что в менее развитом и хуже организованном.
Тут у меня лично нет мнения, потому что речь об IT-компании. И вилки у меня были соответствующие (не было в компании сотрудников с зп меньше 100к). Вопрос в другом: на собесе и в доках утверждалось что по ЗП они 80 перцентиль, а на деле спектр твоих обязанностей для многих компаний вообще нонсанс. Условно, ты джун - но берешься вообще за все: фиксить логику отвечающую за деньги - не вопрос; аналитики нет - делаешь сам; тестировщиков нет - делаешь от и до сам, отвечаешь так же; частые дежурства - вообще отдельный разговор: требование за 1 смену (неделя) разобраться по идее в Data Analysis и DevOpsing - иначе вопросы. На деле в условном финтехе за такие деньги ты NPC, хорошо маппинг и эндпойнты к готовой логике подвести сумеешь. Наши же джуны без проблем собесы на миддлов с вилкой в 2-2,5 раз выше в тех же банках без проблем бы проходили.
Если говорить про мой кейс и про "нет начальника", добавьте к этому невозможность отказаться от задачи и прибавьте микроконтроль. А если отказываешься - могли притянуть "значит, ты вне культуры". Бывало, что за отказ браться за лидинг эпика, что вообще по идее не всем дано, и не прописано в ТД, могли пригрозить отложением уже запланированного повышения ЗП. А чел просто устроился сеньором и по документам "программист".
А где я не прав, выдав такую характеристику именно сочетанию "бирюзовые компании"? Хоть это отчасти и верное замечание, в статье которую вы предлагаете описывается концепция эволюции человеческой психики, она не про управление и компании. Не исключаю, что предложенное Лалу определение базировалось на этих учениях о психике, но я специально подчеркнул, что речь именно о словосочетании "бирюзовые компании", чтобы не смещать фокус и не раздувать статью.
Действительно хорошее замечание, так как сейчас вполне нормально казаться лучше на собесах - как компании, так и сотруднику. Что касается моих вопросов: панацеи, как не странно, не существует. Но задать их нужно, либо для того чтобы засомневаться в самом начале, либо, в случае описанного вами случая, как можно раньше понять и смыться. Думая над вопросами, я проецировал на себя. Поэтому, полагаю, если бы я проговаривал эти вопросы при трудоустройстве, я бы либо вообще не устроился, либо ушел бы гораздо раньше, экономя свои нервы.
Также надо понимать, что компания вкладывает в сотрудника ресурсы. А если говорить про эту компанию, речь о серьезных затратах. Это дорогущее оборудование, командировки, в том числе и за границу, длительный онбординг. Есть немалая вероятность, что в таком случае, если виден серьезный мисматч по культуре, который, в том числе мог бы быть выявлен вопросами из статьи, компания сама не будет готова брать риски.
Меня уже 2 раза притянули за скрытый PR, так что, пожалуй, просьбу отклоню. Можете продублировать первую часть названия статьи "Бирюзовые компании в РФ", с чего я сам начинал, когда садился за статью. Получите вполне удовлетворительный результат. Уверен, о многих услышите не впервые, а возможно чьими-то услугами уже пользуетесь.
Это не упоминалось в статье чтоб не уводить акцент, но есть в подкасте, на который я ссылался, говоря про "клиентократию". Спикер говорит, что конкретно у них люди которые напрямую не связаны с донесением пользы клиента - если угодно, инфраструктурные сотрудники, типа финансового директора, работают по более классической модели.
Отвечу просто: так получилось. Эта статья - желание поделиться + самому отрефлексировать/систематизировать полезный жизненный опыт. Также, о чем не говорилось в самом тексте, она является итоговой работой на зачет в универе. Мое направление - разработка ПО, и никак с PR и прочим не связана. В пользу этого, я, сознательно или нет, избегал хвалебной или враждебной риторики. Даже приводя в пример организацию из статьи, назвал её устройство "адаптацией бирюзовых подходов", избегая лишних ассоциаций с маркой или эталоном. А привел я её для лучшего понимания обывателя, просто взяв за пример организацию "на слуху".
У нас это решалось через микроконтроль. Был "особо инициативный", как правило "старший" в команде, который не стесняясь в формулировках распрашивал команду о прогрессе. Имел место случай, когда "проактивность" этого человека совпала с уходом одного из сотрудников, в сторону которого такая риторика накануне применилась, совпадение? Вообще "протекаемость" работников была довольно высокая. Обосновывалась теми же ребятками сложностью модуля, над которым работала команда, а я бы расширил список причин. Правильно, если бы был, как выразился yellowmew в своем комментарии, "красный" лид с правом решающего голоса. То же высказывает Кривенко, в подкасте, упомянутом в статье. То же, как вариант, затрагиваю здесь я: если явной иерархии вообще нет, часто все приходит к соревнованию по размеру тестикул.