Это разные бизнес-модели. Amazon Go дорог в масштабировании, хотя хорош как концепт. А «Пятёрочка #налету» возможно масштабировать — технологии унифицированы и не столь дороги.
Наверное, стоило уточнить в прошлом комментарии, что это значения, которые мы используем по умолчанию для команд, которые не просят каких-то специфичных настроек. Мы используем эти в том числе, чтобы перестраховаться от возможной потери данных, а не потому, что это единственно верный вариант настройки кластера.
Как упомянуто в статье, если команда понимает, что для их нужд лучше подходят другие значения, то мы готовы настроить их иначе, в том числе и значение min ISR.
Для справедливости стоит отметить, что IBM Hyperledger также рекомендуют использовать минимум 4 брокера Kafka, именно из этого расчёта они исходят:
Let K and Z be the number of nodes in the Kafka cluster and the ZooKeeper ensemble respectively:
Не совсем – replication factor = количество нод в кластере. Таким образом, на каждой ноде будет реплика данных из топика.
Что касается рекомендации про количество нод — 1 – это относится к min insync replicas. Это значение мы используем для трёхнодовых кластеров, которые мы предоставляем командам.
Как можно видеть в статье, мы используем значение kafka_cfg_min_insync_replicas: "{{ kafka_cfg_min_insync_replicas | default([kafka_cfg_default_replication_factor|int — 1, 1] | max) }}".
Это значит, что количество минимально синхронизированных реплик будет равно replication factor — 1 (в нашем случае, как раз количество нод — 1), но не менее 1.
Этот параметр отвечает за то, сколько минимально нам нужно нод для того, чтобы обрабатывать запросы, которые для которых установлено значение acks=all.
Подскажите, почему было недостаточно beats агентов на конечных серверах и вы добавили ещё один слой в виде Kafka? Агенты же тоже шлют данные по TCP и перешлют их, если не смогут достучатся до логстэша?
Добрый день! Спасибо за хорошее замечание.
Мы хотели, помимо пересылки, ещё и хранить данные некоторое время, в случае, если что-то пойдёт не так. Например, был кейс, когда нам нужно было удалить некоторые индексы из Elasticsearch, когда у нас сломалась ротация, чтобы стабилизировать работу кластера.
Мы сделали это не моргнув глазом, потому что знали, что данные мы сможем просто перечитать из топика Kafka, сбросив значение offset. Да, мы получили данные, которые было не очень удобно анализировать с точки зрения timestamp самого Elasticsearch, но тем не менее, это оставляло возможность использовать их для поисков исторических данных.
В данный момент наш сервис поставки логов переживает большой рефакторинг, возможно, что от текущей схемы мы перейдём к чему-то более удобному и простому. Может быть, мы расскажем об этом в будущих статьях
средний объем данных[1] в топиках – 555.1 ГБ
[1] значение за последние 90 дней
это что? Т.е. мы посчитали каждое мгновенное значение количества данных в каждом топике с неким разрешением в интервале 90 дней, а потом взяли и усреднили по всем измерениям и по всем топикам? Или это общий объем данных с ретеншеном 90 дней? Или общее количество «прокачанных» за 90 дней данных, среднее по топикам? Не совсем понимаю.
Это средние значения объема данных в каждом топике за промежуток времени (в данном случае за 90 дней), которые мы просуммировали
p.s. и еще вопрос — какой минимальный, средний и максимальный лаги по доставке логов от источника до эластика? Потому что есть гипотеза, что в определенных конфигурациях такой лаг может достигать 30 минут, что ставит полный крест на использовании эластика как средства оперативного мониторинга (но при этом это ок для расследования исторических инцидентов)
Спасибо за хорошую идею! Временные значения лагов мы не замеряем, пока не было необходимости в этих цифрах, но теперь, думаю, начнем. Пока же нам хватает данных по лагу в количестве сообщений.
В целом картина такая, что топик лаг возникает только в случае, когда проблема возникает на принимающей стороне, например, упал logstash. В остальном – топик лаг у нас либо нулевой, либо не превышает несколько тысяч сообщений, которые разгребаются быстро и задержка не становится критичной. Опять же, как только мы понимаем, что нагрузка растёт и очередь не успевает разгребаться, а только растёт, мы увеличиваем количество партиций и накидываем потоки на чтение. Особых жалоб на то, что данные поступают с большой задержкой мы не получаем.
В конце 2020 года была проблема с нестабильной работой кластера Elasticsearch, тогда системы, которые генерировали большое количество сообщений получили очень большой топик лаг и почти сутки разгребали очереди.
Это было неприятно, но подсветило нам проблемные места, которые мы успешно поправили.
Эти вопросы не относятся напрямую к теме статьи, поэтому не раскрывались. Автотесты встроены в пайплайн и в зависимости от тестового набора запускаются либо автоматически по принятию MR, либо вручную. У всей команды есть доступ к подробной отчетности в AllureEE, уровни детализации отчетов позволяют понять, что именно поломалось.
Хорошее замечание, пока у нас нет возможности маппить тесты с затрагиваемой функциональностью (есть маппинг по экранам, но нет по компонентам), но в перспективе мы планируем с этим вопросом разобраться.
Мы придерживаемся мнения, что unit-тесты – зона ответственности разработчиков. Snapshot-тесты полезны, хотя их поддержка не менее трудоемка, чем поддержка других тестов. Перевернуть мороженку в правильную пирамиду – как раз то, что нам нужно в перспективе, но для начала нужно подружить теорию с реальностью.
Конечно, мы запускаем тесты параллельно, количество потоков подбирается с учетом минимизации времени на запуск (увеличение количества потоков не всегда дает экономию на запуске).
Конечно, мы учитываем поддержку – тонуть под поддержкой автотестов не лучше, чем тонуть под ручным регрессом. В остальном вы спешите с выводами. Возможно, в одной из следующих статей мы рассмотрим именно ROI.
При принятии решения об автоматизации UI мы руководствовались спецификой продуктов и анализом дефектов по продукту. Пользы от автоматизации API никто не умаляет, однако гарантировать работоспособность продуктов API-тесты могут только в комплексе с unit-тестами на фронт. Практика автоматизации фронта со стороны разработки на наших продуктах в процессе внедрения. Поэтому с целью максимизации полезности автотестов было принято решение часть регресса и e2e автоматизировать на UI. По поводу ножа – у нас не настолько большая команда автоматизаторов, чтобы так легкомысленно пускать сотрудников в расход)
Расчетная окупаемость первых тестов – 40-45-й запуск, для нас это 2-3 месяца в зависимости от количества поставок. Но нужно учитывать, что в старт автоматизации вошла и трудоемкая часть – разработка фреймворка.
Все верно, исторические колебания есть. Но есть и гипотеза, что как раз усреднение оценок коллег позволяет немного убрать этот шум. Один пришел не в духе, зато другой — как раз в хорошем настроении. И так далее. Сюда же оценка от руководителя — предполагается, что он подходит ответственно, и убирает свой bias. То есть аргументы За имеются тоже. Опять же, с авторами оценок нужно работать, но это уже хорошо описано в процитированном тексте от коллег.
Тут ведь дело даже не в менеджерской лени, а в наличии инструмента, который может как-то помочь даже трудолюбивому менеджеру, который чего-то просто забыл или не учел.
В целом мы согласны, что любая работа с людьми — дело тонкое, инструменты ненадежны, и несколько раз в тексте на это указали, тут спорить действительно не о чем.
Для каждого продукта этот вопрос решается по разному. В продуктах монетизации в связи с активным развитием разрабатываются довольно крупные функциональные задачи, поэтому работает такой подход: процессы разработки/анализа/тестирования асинхронны. К этапу планирования задачи для спринта уже разобраны. В начале спринта разрабочики начинают работу над задачами, тестировщик преобразует чек-листы в тест -кейсы, начиная с тех, что будут разработаны быстрее, аналитик работает над новыми задачами для спринта. К середине процесса разработки тестировщик заканчивает работу над тесткейсами, и переходит к формированию чекиста по новым задачам, уже разобранным аналитиком. Итогом, к этапу интеграционного тестирования задачи для нового спринта уже прошли этап создания чек-листов.
Особенностью этого процесса является то, что работая над кейсами/чеклистами, тестировщик прерывается на тест готовых задач. А формализация вопросов и доработка постановки задач на новый спринт по комментариям тестировщика ложится на плечи аналитика.
На текущий момент у нас небольшая команда и такой подход работает. Для больших команд тестировщиков несколько и формализацией и тестированием новых задач занимаются разные тестировщики.
Речь идет возможности разработки одного и того же объема нового функционала в более короткий срок. Выкладка проходит недельными циклами не из-за ожидания, а потому что продукт активно развивается и на каждом релизе добавляется крупный кусок нового функционала. Мелкие правки могут выкатываться ежедневно. Более сложные бизнес — задачи — раз в неделю.
Действительно не показывает) вторая диаграмма с ветками и организацией процесса разработки так, чтобы минимизировать необходимость ретеста. К каждой ветке прикреплён свой стейдж. С аналогичным названием) На каждом стейдже происходит свой вариант тестирования.
Действительно, сегодня у представителей ритейл свои требования, процессы и регламенты. Они были сформированы годами и менять их сложно, т. к. значимость изменений процессов мастер-данных не всегда очевидна в конкуренции с другими инновациями.
X5 делает этот шаг, понимая что во многом является первопроходцем.
В вопросе обеспечения соответствия кодов ТН ВЭД, ставок НДС и прочего важно соблюдать баланс. В противном случае есть риск просто перевести бюрократию в цифровое измерение и сделать требования невыполнимыми.
Использование портала дает поставщику дополнительные возможности. Поставщик может самостоятельно загрузить мастер данные своего товара как путем ручного заполнения формы, так и через загрузку Excel файла заданного формата. Услуги КСП провайдера являются дополнительной опцией, а не обязанностью. Каждый поставщик самостоятельно принимает решение, каким путем пойти.
В дальнейшем функционал портала будет развиваться. Но об этом позднее.
Как упомянуто в статье, если команда понимает, что для их нужд лучше подходят другие значения, то мы готовы настроить их иначе, в том числе и значение min ISR.
Для справедливости стоит отметить, что IBM Hyperledger также рекомендуют использовать минимум 4 брокера Kafka, именно из этого расчёта они исходят:
Let K and Z be the number of nodes in the Kafka cluster and the ZooKeeper ensemble respectively:
1. At a minimum, K should be set to 4.
Что касается рекомендации про количество нод — 1 – это относится к min insync replicas. Это значение мы используем для трёхнодовых кластеров, которые мы предоставляем командам.
Как можно видеть в статье, мы используем значение kafka_cfg_min_insync_replicas: "{{ kafka_cfg_min_insync_replicas | default([kafka_cfg_default_replication_factor|int — 1, 1] | max) }}".
Это значит, что количество минимально синхронизированных реплик будет равно replication factor — 1 (в нашем случае, как раз количество нод — 1), но не менее 1.
Этот параметр отвечает за то, сколько минимально нам нужно нод для того, чтобы обрабатывать запросы, которые для которых установлено значение acks=all.
Добрый день! Спасибо за хорошее замечание.
Мы хотели, помимо пересылки, ещё и хранить данные некоторое время, в случае, если что-то пойдёт не так. Например, был кейс, когда нам нужно было удалить некоторые индексы из Elasticsearch, когда у нас сломалась ротация, чтобы стабилизировать работу кластера.
Мы сделали это не моргнув глазом, потому что знали, что данные мы сможем просто перечитать из топика Kafka, сбросив значение offset. Да, мы получили данные, которые было не очень удобно анализировать с точки зрения timestamp самого Elasticsearch, но тем не менее, это оставляло возможность использовать их для поисков исторических данных.
В данный момент наш сервис поставки логов переживает большой рефакторинг, возможно, что от текущей схемы мы перейдём к чему-то более удобному и простому. Может быть, мы расскажем об этом в будущих статьях
Это средние значения объема данных в каждом топике за промежуток времени (в данном случае за 90 дней), которые мы просуммировали
Спасибо за хорошую идею! Временные значения лагов мы не замеряем, пока не было необходимости в этих цифрах, но теперь, думаю, начнем. Пока же нам хватает данных по лагу в количестве сообщений.
В целом картина такая, что топик лаг возникает только в случае, когда проблема возникает на принимающей стороне, например, упал logstash. В остальном – топик лаг у нас либо нулевой, либо не превышает несколько тысяч сообщений, которые разгребаются быстро и задержка не становится критичной. Опять же, как только мы понимаем, что нагрузка растёт и очередь не успевает разгребаться, а только растёт, мы увеличиваем количество партиций и накидываем потоки на чтение. Особых жалоб на то, что данные поступают с большой задержкой мы не получаем.
В конце 2020 года была проблема с нестабильной работой кластера Elasticsearch, тогда системы, которые генерировали большое количество сообщений получили очень большой топик лаг и почти сутки разгребали очереди.
Это было неприятно, но подсветило нам проблемные места, которые мы успешно поправили.
Хорошее замечание, пока у нас нет возможности маппить тесты с затрагиваемой функциональностью (есть маппинг по экранам, но нет по компонентам), но в перспективе мы планируем с этим вопросом разобраться.
Мы придерживаемся мнения, что unit-тесты – зона ответственности разработчиков. Snapshot-тесты полезны, хотя их поддержка не менее трудоемка, чем поддержка других тестов. Перевернуть мороженку в правильную пирамиду – как раз то, что нам нужно в перспективе, но для начала нужно подружить теорию с реальностью.
Конечно, мы запускаем тесты параллельно, количество потоков подбирается с учетом минимизации времени на запуск (увеличение количества потоков не всегда дает экономию на запуске).
Тут ведь дело даже не в менеджерской лени, а в наличии инструмента, который может как-то помочь даже трудолюбивому менеджеру, который чего-то просто забыл или не учел.
В целом мы согласны, что любая работа с людьми — дело тонкое, инструменты ненадежны, и несколько раз в тексте на это указали, тут спорить действительно не о чем.
Особенностью этого процесса является то, что работая над кейсами/чеклистами, тестировщик прерывается на тест готовых задач. А формализация вопросов и доработка постановки задач на новый спринт по комментариям тестировщика ложится на плечи аналитика.
На текущий момент у нас небольшая команда и такой подход работает. Для больших команд тестировщиков несколько и формализацией и тестированием новых задач занимаются разные тестировщики.
X5 делает этот шаг, понимая что во многом является первопроходцем.
В вопросе обеспечения соответствия кодов ТН ВЭД, ставок НДС и прочего важно соблюдать баланс. В противном случае есть риск просто перевести бюрократию в цифровое измерение и сделать требования невыполнимыми.
Использование портала дает поставщику дополнительные возможности. Поставщик может самостоятельно загрузить мастер данные своего товара как путем ручного заполнения формы, так и через загрузку Excel файла заданного формата. Услуги КСП провайдера являются дополнительной опцией, а не обязанностью. Каждый поставщик самостоятельно принимает решение, каким путем пойти.
В дальнейшем функционал портала будет развиваться. Но об этом позднее.