Раскрою немного наши мысли, почему мы начали смотреть другое решение: - RedHat дает по сути другой продукт на базе keycloak с другой инфраструктурной начинкой - у нас итак Java решение размывало стек технологий, а тут стало бы еще больше - Хороший такой vendor-lock в части технологий, поддержки, инфраструктуры. Авторизация для нас ключевой цифровой сервис, от которого нам нужна гибкость и возможность изменения быстрее того, что предлагает поставщик - Все же RH-SSO и Keycloak больше относятся к системам класса Workforce IAM со всеми вытекающими особенностями. Для авторизации клиентов подходит больше Customer IAM, который по функциональности во многом схож, но имеет свои доп плюшки в виде интеграций с CRM, сервисом само регистрации, расширенными правилами политики безопасности, cloud ready архитектурой
Искали ресурсы, где есть располагающая для общения аудитория. Заметил, что в русскоязычный канал иногда захаживают иностранцы и никто им не отказывает в ответе.
Тут зависит от того, как у вас выглядит фронтенд. Если это админка со своей дизайн системой, то для одинаковых компонент селекторы проще вынести отдельно. Например, для того же хедера или элементов попапа.
А вообще в прошлом мой тимлид на подобный вопрос отвечал: "люблю, когда везде все упорядочено по папкам и классам" :)
Выше я говорил про команду разработки, которая отвечает за выпуск и работоспособность своих систем или продукта. Конечно, на уровне орг структуры можно собрать команду из разных департаментов, но тут о себе постоянно будет напоминать закон Конвея с числом Данбара и ставить палки в колеса.
Для поддержки и развития сотрудника можно выделить функционального руководителя. Т.е. нет серебряной пули.
В статье как раз описано отделение аналитика от команды. Да, его могут привлекать к задачам и к решению проблем команды, но он никогда не будет являться частью команды, так как тут разные линейные руководители. Команда на то и команда, что она объединена в одной иерархии под одним линейным руководителем, который имеет прямой доступ и контроль над своей командой.
Либо команда сама несет определенную функцию, либо привлекает ее на стороне, в том числе и других командах, в вашем случае в команде аналитики. В то, что разделения нигде нет не поверю, обычно в компаниях, начиная со средней, в дирекции\направлении\департаменте ERP есть отдельные люди с функциями системного анализа, часто называются консультантами.
В самом начале статьи правильно подмечено, что от компании к компании есть отличия как в распределении функций системного\бизнес анализа, так и названия конкретных должностей. С учетом диаграммы активности по этапам, расположением отдела в проектном офисе и описания рабочего процесса должности системный аналитик, то действительно этой должности в Lamoda в большей мере присущи функции бизнес анализа, чем системного. Тут я солидарен с мнением.
Это также заметно по контексту, в котором озвучена работа аналитиков: когда это проект с его стандартным жизненным циклом инициация-анализ-разработка-запуск, то аналитик фокусируется на целях проекта и его бизнес заказчиках (т.е. бизнес анализе), а за кадром участия в проекте остаются прочие аспекты уже системного анализа. Аспекты вовлечения в не проектные задачи, реального устройства "черного ящика" и деталей его работы, документирование "черного ящика", привлечение в L3 уровень поддержки, тесное взаимодействие с продактом в случае продуктовых команд. В эти аспекты просто невозможно погружаться в проектном подходе, вот и получается что это закрывает команда и техлид, кто на самом деле и будут выполнять большинство функций системного анализа.
Статья полезная, раскрывает чем придется заниматься и что делать в компании.
В спокойном режиме необходимо было бы пройтись по всем операциям (ценообразование, работа с остатками, акциями), результаты их работ максимально централизовать в одном внутреннем хранилище и минимизировать время отставания данных между магазинами и этим внутренним хранилищем. Оно будет предназначаться под операционные процессы под операционный профиль нагрузки.
Далее через механизм CDC (Change Data Capture) настроить передачу данных уже в горячее хранилище, на которое уже будет падать пользовательский профиль нагрузки. Т.е. все равно иметь два места хранения данных, но под разные профили нагрузки.
420к изменений в минуту рассчитывал эмпирически с учетом всех магазинов, расчет делал для примера и определения потенциального минимального трешхолда запросов, которое надо закладывать при проектировании. И то это только те изменения, которые генерируют покупатели. Помимо покупателей еще всегда есть операционные процессы, например, приемки товаров, обновления цен, которые тоже ощутимо увеличивают профиль нагрузки.
Сейчас же подключено уже 20% магазинов от всей сети, что уже с учетом операций магазина дает 150к RPS в пике, когда накопленные данные отправляются в DIH. Классический случай "ожидание - реальность".
Я обычно удивляюсь, когда кто-то ArchiMate нотацию узнает, так как ее применение не так популярно, как тот же UML. Что касается железа, то все инстансы кластера именно с Tarantool размещены на 4 виртуальных машинах в конфигурации 16 CPU & 64 RAM. И по выдерживаемой нагрузке я чуть ошибся, там все же 150к изменений в секунду.
Именно так, это паттерны поведения, которые могут быть присущи каждому. И от каждого зависит, как много места они занимают в его жизни, как они отражаются на его жизни.
Приятно попасть в топ рейтинга, но надо смотреть правде в глаза, что размер компаний в расчетах исчисляется всеми сотрудниками (курьеры, продавцы, сотрудники операций), а не штатом IT специалистов. Если взглянуть на xbig и big компании, то по IT штату многие не дотягивают даже до размера средних честно подсчитанных medium IT компаний. И в своей честной "весовой категории" позиции были бы значительно ниже.
Как минимум поэтому в рейтинге не видны компании с большим штатом IT специалистов, которые на слуху у многих.
Платформа предоставляется исключительно как сервис, пока других моделей нет и не планируется. Я могу это обосновать тем, что основа платформы это операционные процессы, вокруг которых и строится программная автоматизация. Т.е. при выносе, скажем, той же доставки недостаточно передать просто исходные коды, надо еще передать процессы найма людей, брендирования, управления мотивацией сотрудников, обслуживание автопарка, управление географией и логистикой. Это дорого и позволительно только малому количеству бизнесов.
Мое мнение, что будущее как раз за рынком маркетплейсов, сервисных провайдеров и небольших компаний агрегаторов к этой инфраструктуре. У больших компаний будут деньги и ресурсы на поддержку сложной инфраструктуры, у небольших — фокус на построение частных B2B интеграций вокруг инфраструктуры под заказ.
Мне нравится ваш ответ, он кратко и ясно описывает всю проблематику данной задачи. Я работаю с Лешей, но в подразделении, как раз занимающимся добавлением колоночек в таблички хранения номенклатур.
Если Леше достаточно расширить индекс эластика и нарисовать пару UI элементов в интерфейсе desktop\mobile приложений, то другим людям потребуется подготовить данные для фильтрации. И тут уже надо понимать всю глубину проблематики унификации этих данных.
Вот взять тот же размер. Каждый бренд хоть и шьет свои вещи примерно в одинаковых азиатских странах, но крепит на вещи размеры в соответствии с размерными сетками (например, обувь 40, 41, 42 размер), где эта вещь будет продаваться. Если вещь шилась для Америки, а носить хочется где-то в России (например, найки), то при закупке надо обязательно не забыть переклеить этикетку и сконвертировать размер с американской размерной сетки на российскую. Проблема множится тем, что размерных сеток тьма, плюс каждый из брендов может иметь свое чувство прекрасного и рассчитывать размер относительно своих показателей, страны продажи. Дополнительно, у тех же рубашек есть еще такая характеристика, как силуэт (classic fit, slim fit, super slim fit), которая зависит от размера талии. А у футболок нет, для каждой категории одежды дьявол кроется в мелочах.
В идеале размер должен регламентировать пропорции продаваемого продукта, но по факту мы имеем кучу разных особенностей, которые надо сводить к одному понятному для всех покупателей стандарту, и вести контроль: размерных сеток брендов, договоренностей, плана и факта поставляемых продуктов.
Можно, конечно, по размеру, шкале и некоторым характеристикам автоматически выводить привязанные пропорции тела, но это бы работало, если бы мир состоял только из атлетично собранных людей и честных брендов. И выходит пока так, что с размерами бы хорошо управляться, а потом уже можно всем миром придти к одному знаменателю.
Забавно. Я, как сотрудник компании, на каждой такой вставке бросал ностальгическую скупую слезу и в голове прокручивал фразы вида: «О! Это ж Артемка, помню, как звали его к нам из Питера, а теперь он вон рядом сидит». Могу для себя сделать вывод, что на внутреннем ревью данный подход воспринимается иначе: все же все лица знакомые (авторитетные), факты для внутреннего круга людей подтвержденные, и не формируется заведомо фальшивое мнение о подходе.
И предполагаю, что даже разместив свое фото с нейтральным мнением, мои слова для окружающих бы воспринимались как очередной недостоверный отзыв в очередной рекламной статье\лендинге. Заставили задуматься, спасибо.
Да, тоже находил подобную дискуссию, где Фабьен сказал, что .env файл полностью не заменяют параметры.
А я всего лишь хотел уйти от поддержки parameters.yml.dist -> parameters.yml и остаться только на .env.dist -> .env файле. Но пока приходится поддерживать оба механизма конфигурации.
С .env файлами не все так просто ввиду того, что ENV переменные это всегда строки. Часто параметры должны быть четко типизированы, например, тот же параметр disable_delivery (swift mailer) ожидает строго тип bool, и передать в него ENV переменную напрямую не удается. Поэтому полный переход на .env файлы весьма затруднителен.
Спасибо, работает.
Интересно, слоупоки в числе достаточно редких покемонов, а рядом с местом по-умолчанию их аж три штуки в данный момент. Неужели рандом такой беспощадный, что выбрал именно это место для базового спавна?
Раскрою немного наши мысли, почему мы начали смотреть другое решение:
- RedHat дает по сути другой продукт на базе keycloak с другой инфраструктурной начинкой - у нас итак Java решение размывало стек технологий, а тут стало бы еще больше
- Хороший такой vendor-lock в части технологий, поддержки, инфраструктуры. Авторизация для нас ключевой цифровой сервис, от которого нам нужна гибкость и возможность изменения быстрее того, что предлагает поставщик
- Все же RH-SSO и Keycloak больше относятся к системам класса Workforce IAM со всеми вытекающими особенностями. Для авторизации клиентов подходит больше Customer IAM, который по функциональности во многом схож, но имеет свои доп плюшки в виде интеграций с CRM, сервисом само регистрации, расширенными правилами политики безопасности, cloud ready архитектурой
Искали ресурсы, где есть располагающая для общения аудитория. Заметил, что в русскоязычный канал иногда захаживают иностранцы и никто им не отказывает в ответе.
Тут зависит от того, как у вас выглядит фронтенд. Если это админка со своей дизайн системой, то для одинаковых компонент селекторы проще вынести отдельно. Например, для того же хедера или элементов попапа.
А вообще в прошлом мой тимлид на подобный вопрос отвечал: "люблю, когда везде все упорядочено по папкам и классам" :)
Выше я говорил про команду разработки, которая отвечает за выпуск и работоспособность своих систем или продукта. Конечно, на уровне орг структуры можно собрать команду из разных департаментов, но тут о себе постоянно будет напоминать закон Конвея с числом Данбара и ставить палки в колеса.
Для поддержки и развития сотрудника можно выделить функционального руководителя. Т.е. нет серебряной пули.
В статье как раз описано отделение аналитика от команды. Да, его могут привлекать к задачам и к решению проблем команды, но он никогда не будет являться частью команды, так как тут разные линейные руководители. Команда на то и команда, что она объединена в одной иерархии под одним линейным руководителем, который имеет прямой доступ и контроль над своей командой.
Либо команда сама несет определенную функцию, либо привлекает ее на стороне, в том числе и других командах, в вашем случае в команде аналитики. В то, что разделения нигде нет не поверю, обычно в компаниях, начиная со средней, в дирекции\направлении\департаменте ERP есть отдельные люди с функциями системного анализа, часто называются консультантами.
В самом начале статьи правильно подмечено, что от компании к компании есть отличия как в распределении функций системного\бизнес анализа, так и названия конкретных должностей. С учетом диаграммы активности по этапам, расположением отдела в проектном офисе и описания рабочего процесса должности системный аналитик, то действительно этой должности в Lamoda в большей мере присущи функции бизнес анализа, чем системного. Тут я солидарен с мнением.
Это также заметно по контексту, в котором озвучена работа аналитиков: когда это проект с его стандартным жизненным циклом инициация-анализ-разработка-запуск, то аналитик фокусируется на целях проекта и его бизнес заказчиках (т.е. бизнес анализе), а за кадром участия в проекте остаются прочие аспекты уже системного анализа. Аспекты вовлечения в не проектные задачи, реального устройства "черного ящика" и деталей его работы, документирование "черного ящика", привлечение в L3 уровень поддержки, тесное взаимодействие с продактом в случае продуктовых команд. В эти аспекты просто невозможно погружаться в проектном подходе, вот и получается что это закрывает команда и техлид, кто на самом деле и будут выполнять большинство функций системного анализа.
Статья полезная, раскрывает чем придется заниматься и что делать в компании.
В спокойном режиме необходимо было бы пройтись по всем операциям (ценообразование, работа с остатками, акциями), результаты их работ максимально централизовать в одном внутреннем хранилище и минимизировать время отставания данных между магазинами и этим внутренним хранилищем. Оно будет предназначаться под операционные процессы под операционный профиль нагрузки.
Далее через механизм CDC (Change Data Capture) настроить передачу данных уже в горячее хранилище, на которое уже будет падать пользовательский профиль нагрузки. Т.е. все равно иметь два места хранения данных, но под разные профили нагрузки.
420к изменений в минуту рассчитывал эмпирически с учетом всех магазинов, расчет делал для примера и определения потенциального минимального трешхолда запросов, которое надо закладывать при проектировании. И то это только те изменения, которые генерируют покупатели. Помимо покупателей еще всегда есть операционные процессы, например, приемки товаров, обновления цен, которые тоже ощутимо увеличивают профиль нагрузки.
Сейчас же подключено уже 20% магазинов от всей сети, что уже с учетом операций магазина дает 150к RPS в пике, когда накопленные данные отправляются в DIH. Классический случай "ожидание - реальность".
Я обычно удивляюсь, когда кто-то ArchiMate нотацию узнает, так как ее применение не так популярно, как тот же UML.
Что касается железа, то все инстансы кластера именно с Tarantool размещены на 4 виртуальных машинах в конфигурации 16 CPU & 64 RAM. И по выдерживаемой нагрузке я чуть ошибся, там все же 150к изменений в секунду.
А что именно интересно? Стек технологий, куда идем, из чего пришли, с чем боролись (нужное подчеркнуть)?
Именно так, это паттерны поведения, которые могут быть присущи каждому. И от каждого зависит, как много места они занимают в его жизни, как они отражаются на его жизни.
Приятно попасть в топ рейтинга, но надо смотреть правде в глаза, что размер компаний в расчетах исчисляется всеми сотрудниками (курьеры, продавцы, сотрудники операций), а не штатом IT специалистов. Если взглянуть на xbig и big компании, то по IT штату многие не дотягивают даже до размера средних честно подсчитанных medium IT компаний. И в своей честной "весовой категории" позиции были бы значительно ниже.
Как минимум поэтому в рейтинге не видны компании с большим штатом IT специалистов, которые на слуху у многих.
Мое мнение, что будущее как раз за рынком маркетплейсов, сервисных провайдеров и небольших компаний агрегаторов к этой инфраструктуре. У больших компаний будут деньги и ресурсы на поддержку сложной инфраструктуры, у небольших — фокус на построение частных B2B интеграций вокруг инфраструктуры под заказ.
Мне нравится ваш ответ, он кратко и ясно описывает всю проблематику данной задачи. Я работаю с Лешей, но в подразделении, как раз занимающимся добавлением колоночек в таблички хранения номенклатур.
Если Леше достаточно расширить индекс эластика и нарисовать пару UI элементов в интерфейсе desktop\mobile приложений, то другим людям потребуется подготовить данные для фильтрации. И тут уже надо понимать всю глубину проблематики унификации этих данных.
Вот взять тот же размер. Каждый бренд хоть и шьет свои вещи примерно в одинаковых азиатских странах, но крепит на вещи размеры в соответствии с размерными сетками (например, обувь 40, 41, 42 размер), где эта вещь будет продаваться. Если вещь шилась для Америки, а носить хочется где-то в России (например, найки), то при закупке надо обязательно не забыть переклеить этикетку и сконвертировать размер с американской размерной сетки на российскую. Проблема множится тем, что размерных сеток тьма, плюс каждый из брендов может иметь свое чувство прекрасного и рассчитывать размер относительно своих показателей, страны продажи. Дополнительно, у тех же рубашек есть еще такая характеристика, как силуэт (classic fit, slim fit, super slim fit), которая зависит от размера талии. А у футболок нет, для каждой категории одежды дьявол кроется в мелочах.
В идеале размер должен регламентировать пропорции продаваемого продукта, но по факту мы имеем кучу разных особенностей, которые надо сводить к одному понятному для всех покупателей стандарту, и вести контроль: размерных сеток брендов, договоренностей, плана и факта поставляемых продуктов.
Можно, конечно, по размеру, шкале и некоторым характеристикам автоматически выводить привязанные пропорции тела, но это бы работало, если бы мир состоял только из атлетично собранных людей и честных брендов. И выходит пока так, что с размерами бы хорошо управляться, а потом уже можно всем миром придти к одному знаменателю.
И предполагаю, что даже разместив свое фото с нейтральным мнением, мои слова для окружающих бы воспринимались как очередной недостоверный отзыв в очередной рекламной статье\лендинге. Заставили задуматься, спасибо.
Вот данное сообщение после создания приватного сервера рецептов меня очень удивило. Где-то я упустил момент со стоимостью.
А я всего лишь хотел уйти от поддержки parameters.yml.dist -> parameters.yml и остаться только на .env.dist -> .env файле. Но пока приходится поддерживать оба механизма конфигурации.
Интересно, слоупоки в числе достаточно редких покемонов, а рядом с местом по-умолчанию их аж три штуки в данный момент. Неужели рандом такой беспощадный, что выбрал именно это место для базового спавна?