Как стать автором
Обновить
22
0
Евгений Скориков @EugeneSkorikov

senior бизнес-архитектор, ИТ — аналитик (BA+SA)

Отправить сообщение

Как мы делали свой поиск в Ozon: эволюция архитектуры от SQL до O2

Время на прочтение 16 мин
Количество просмотров 25K

Привет, Хабр! Меня зовут Сергей, я руководитель команды поиска в Ozon. Сегодня я расскажу об эволюции наших поисковых систем: как всё начиналось более 20 лет назад с обычных SQL-запросов, как мы осваивали Sphinx и Elasticsearch и как сейчас наш собственный поисковый движок O2 на базе Apache Lucene выдерживает нагрузку в десятки тысяч RPS в сезон распродаж. Исторические хроники восстанавливались по воспоминаниям современников и представлены для полноты картины. Новейшая история описана на основе собственного опыта, поэтому подробностей будет на порядок больше. Поехали!

Читать далее
Всего голосов 56: ↑56 и ↓0 +56
Комментарии 25

Как мы делали подсказки в продукте для корпоративного поиска на базе Elasticsearch

Время на прочтение 3 мин
Количество просмотров 2.6K

Казалось бы поисковые подсказки (автокомплит) простая и понятная вещь, реализованная во множестве проектов и работающая из коробки. 

Как бы не так. 

Под катом расскажем про существующие подходы, их ограничения, и как мы вышли из положения для реализации подсказок в продукте для корпоративного поиска Content AI Intelligent Search

Читать далее
Всего голосов 4: ↑4 и ↓0 +4
Комментарии 1

JSON API – работаем по спецификации

Время на прочтение 23 мин
Количество просмотров 158K
В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

Фронтенд с бэкендом взаимодействуют через API. И от того, какой это API, насколько хорошо или плохо бэкенд и фронтенд договорились между собой, зависит весь результат разработки. Если мы все вместе станем обсуждать, как сделать паджинацию, и потратим на её переделывание целый день, то можем и не добраться до бизнес-задач.

Чтобы не буксовать и не разводить холивары по поводу названия переменных, нужна хорошая спецификация. Давайте поговорим о том, какой она должны быть, чтобы всем жилось легче. Заодно станем экспертами по велосипедным сараям.


Всего голосов 71: ↑68 и ↓3 +65
Комментарии 110

Распределённые транзакции

Уровень сложности Средний
Время на прочтение 10 мин
Количество просмотров 29K

На собеседованиях на позицию middle/senior разработчика часто задают вопросы по распределенным транзакциям в микросервисной архитектуре.

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

Я проработал статью и подготовил конспект простыми словами, местами дополнил информацией из других источников и полезными ссылками.

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

Читать далее
Всего голосов 26: ↑23 и ↓3 +20
Комментарии 1

Архитектурный паттерн для обработки больших данных: Lambda

Уровень сложности Сложный
Время на прочтение 13 мин
Количество просмотров 8.8K

Привет, Хабр!

Мы сталкиваемся с огромными объемами информации, высокой нагрузкой, и постоянно меняющимися требованиями. Все это требует от нас не только навыков программирования, но и грамотного проектирования архитектуры, которая способна справиться с этими вызовами.

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

Читать далее
Всего голосов 12: ↑10 и ↓2 +8
Комментарии 1

Проектирование отказоустойчивости IT-систем

Время на прочтение 11 мин
Количество просмотров 18K

❓Как проектировать системы, которые будут толерантными для различного вида отказов и ошибок?

Что такое отказоустойчивость и стабильность?

Под отказоустойчивостью будем понимать свойство системы, которое позволяет максимально сохранять работоспособность при отказе отдельных конкретных компонентов системы либо связанных систем и восстанавливать работоспособность системы при восстановлении отказавших компонентов или связанных систем. Давайте рассмотрим подробнее эти 2 момента:

1. Деградация работоспособности системы должна быть прямо пропорциональна "величине" отказа. То есть, если упал сервис, отвечающий за некую некритичную функциональность — вся система не должна при этом падать. Да, небольшой кусочек не работает, но это не влияет на стабильность остальной части функционала.

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

Читать далее
Всего голосов 23: ↑22 и ↓1 +21
Комментарии 16

JSON-RPC? Возьмите хитрый REST

Время на прочтение 6 мин
Количество просмотров 31K


Уверен, что заголовок вызвал здоровую реакцию — “ну опять началось…” Но позвольте завладеть вашим вниманием на 5-10 минут, и я постараюсь не обмануть ожидания.


Структура статьи будет такова: берется стереотипное утверждение и раскрывается “природа” возникновения этого стереотипа. Надеюсь, это позволит взглянуть на выбор парадигмы обмена данными в ваших проектах под новым углом.


Для того, чтобы была ясность в том, что такое RPC, предлагаю рассматривать стандарт JSON-RPC 2.0. C REST ясности нет. И не должно быть. Все, что нужно знать о REST — он неотличим от HTTP.

Читать дальше →
Всего голосов 52: ↑41 и ↓11 +30
Комментарии 118

GraphQL: от восторга до разочарования

Время на прочтение 14 мин
Количество просмотров 17K

Задаётесь вопросом, стоит ли использовать GraphQL в своём проекте? Ваши разработчики спорят, выдвигая аргументы типа «GraphQL — это будущее» и «REST проще»? Мы с моей командой обсуждали эту тему бесконечно. В статье я приведу краткие выводы.

Предисловие: GraphQL в моде, вы найдёте множество статей, насколько он потрясающий, однако спустя три года его использования я немного огорчён и разочарован этой технологией, поэтому не воспринимайте мои слова, как истину в последней инстанции.
Читать дальше →
Всего голосов 43: ↑39 и ↓4 +35
Комментарии 79

Платформа данных в Леруа Мерлен – 2 года, сотни источников и более 2.000 пользователей

Время на прочтение 6 мин
Количество просмотров 8.8K

Всем привет!

На сегодняшний день данные и всё связанное с ними (ML, AI, DataMining, etc) это самый хайповый тренд в IT-индустрии. Все - от ритейлеров до компаний Илона Маска - работают (или пытаются работать) с данными. Нас в Леруа Мерлен эта волна не обошла стороной - data-driven подход к принятию решений является одним из основных в компании. Следуя ему, мы создали свою платформу данных, которой на данный момент пользуется около 2 тыс.человек, а в минуту обрабатывается примерно 1800 запросов. В этой статье мы (Data-команда Леруа Мерлен Россия) расскажем, как за 2 года построили платформу данных в компании с большим количеством оффлайн-процессов, про ее архитектуру и опыт, который мы получили в процессе создания.

Читать далее
Всего голосов 9: ↑7 и ↓2 +5
Комментарии 16

О стримах и таблицах в Kafka и Stream Processing, часть 1

Время на прочтение 16 мин
Количество просмотров 59K
* Michael G. Noll — активный контрибьютор в Open Source проекты, в том числе в Apache Kafka и Apache Storm.

Статья будет полезна в первую очередь тем, кто только знакомится с Apache Kafka и/или потоковой обработкой [Stream Processing].


В этой статье, возможно, в первой из мини-серии, я хочу объяснить концепции Стримов [Streams] и Таблиц [Tables] в потоковой обработке и, в частности, в Apache Kafka. Надеюсь, у вас появится лучшее теоретическое представление и идеи, которые помогут вам решать ваши текущие и будущие задачи лучше и/или быстрее.

Содержание:

* Мотивация
* Стримы и Таблицы простым языком
* Иллюстрированные примеры
* Стримы и Таблицы в Kafka простым языком
* Пристальный взгляд на Kafka Streams, KSQL и аналоги в Scala
* Таблицы стоят на плечах гигантов (на стримах)
* Turning the Database Inside-Out
* Заключение
Читать дальше →
Всего голосов 19: ↑19 и ↓0 +19
Комментарии 4

От персон к персонажам в маркетинге или как побороть WYSIATI

Время на прочтение 10 мин
Количество просмотров 4K


Актёры репетируют роли своих персонажей.

Представляю вам лонгрид про использование персонажей, методологию, оказавшую отрезвляющее действие на разработку нашего проекта Fetchee — единого списка желаний, следящего за ценами во всех интернет-магазинах мира. Материал не является ни в коей мере пошаговой инструкцией или методичкой. Его главная задача — встряхнуть и заставить коллег-стартаперов шире посмотреть на основную составляющую любого бизнеса — своих потенциальных или уже существующих клиентов.

Для понимая материала, вам желательно уже знать, что такое персоны (англ. persona), попробовать составить хотя бы одну для своего проекта, и только тогда продолжать чтение.
Читать дальше →
Всего голосов 7: ↑6 и ↓1 +5
Комментарии 2

Пример написания функциональных требований к Enterprise-системе

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

Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.

Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.

Вся документация на наш программный продукт состояла из следующих разделов:
  • Общая часть
    • Список терминов и определений
    • Описание бизнес-ролей
  • Требования
    • Бизнес-требования
    • Общие сценарии
    • Сценарии использования
    • Алгоритмы и проверки
    • Системные требования
    • Нефункциональные требования
    • Требования к интеграции
    • Требования к пользовательскому интерфейсу
  • Реализация
  • Тестирование
  • Руководства
  • Управление

Читать дальше →
Всего голосов 15: ↑13 и ↓2 +11
Комментарии 36

От моделирования процессов к проектированию автоматизированной системы (Часть 1)

Время на прочтение 8 мин
Количество просмотров 21K

«Один день из жизни белки» или от моделирования процессов к проектированию автоматизированной системы учёта материальных ценностей «Белка-1.0» (Часть 1)



Использована иллюстрация к "Сказке о царе Салтане" А.С.Пушкина, изд."Детская литература", Москва, 1949 год, Ленинград, рисунки К.Кузнецова


При чем тут «белка»?


Сразу поясню, при чем тут «белка». Наткнувшись в Сети на забавные проекты для изучения UML с опорой на предметную область, заимствованную из сюжетов сказок (например, здесь [1]), я для своих студентов тоже решила подготовить подобный пример, чтобы можно было изучить для начала всего три вида диаграмм: Activity Diagram, Use-case Diagram и Class Diagram. Умышленно не перевожу на русский язык названия диаграмм, чтобы избежать споров о «трудностях перевода». Что для чего – поясню немного позже. В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [2] – хороший инструмент за разумные деньги. А в рамках учебных занятий применяю Modelio [3], неплохое бесплатное средство объектно-ориентированного проектирования, поддерживающее стандарты UML2.0 и BPMN, без излишних наворотов в части изобразительных возможностей, но вполне достаточное для изучения основ языка.

Читать дальше →
Всего голосов 19: ↑18 и ↓1 +17
Комментарии 8

Как я чуть не выкинул 150к на ветер или история установки приточной вентиляции в квартире

Время на прочтение 19 мин
Количество просмотров 616K

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


Читать дальше →
Всего голосов 375: ↑370 и ↓5 +365
Комментарии 595

Интеграция программного обеспечения. Описание процесса от бизнес консультанта

Время на прочтение 11 мин
Количество просмотров 99K
Синерги́я (греч. συνεργία — сотрудничество, содействие, помощь, соучастие, сообщничество; от греч. σύν — вместе, греч. ἔργον — дело, труд, работа, (воз)действие) — суммирующий эффект взаимодействия двух или более факторов, характеризующийся тем, что их действие существенно превосходит эффект каждого отдельного компонента в виде их простой суммы[1], эмерджентность.

Википедия.

В процессе работы бизнес консультантом, для увеличения эффективности работы систем предприятия, я почти всегда предлагаю провести интеграцию между различным ПО заказчика. Потому что интегрировав различные системы возможно добиться эффекта синергии.

Мне постоянно приходится сталкиваться с одними и теми же проблемами и решениями многие из которых приходится пояснять в каждом новом проекте заказчикам, некоторые – программистам. А потому я считаю, что о процессе интеграции стоит поговорить подробно. В большинстве примеров я выбрал различные случаи интеграции 1С и CRM, так как сегодня именно этот вопрос, как показывает моя практика, наиболее актуален. Хотя данная статья подойдет при интеграции практически любого программного обеспечения. Итак начнем.
Читать дальше →
Всего голосов 2: ↑2 и ↓0 +2
Комментарии 2

Когда нужны тесты и автотесты, взгляд из надсистемы

Время на прочтение 6 мин
Количество просмотров 15K
Нужно ли автотестирование? Когда оно нужно? Какую ценность оно приносит?

В статье разобраны когда и зачем нужно тестирование как таковое и в каких случаях нужна его автоматизация.
Читать дальше →
Всего голосов 5: ↑4 и ↓1 +3
Комментарии 6

11 шагов к хорошему интернет-магазину. Сопутствующие товары

Время на прочтение 5 мин
Количество просмотров 16K
Сегодня у нас — шестой шаг из одиннадцати. Обсуждаем сопутствующие товары в интернет-магазинах — зачем предлагать, когда и как.

Краткое содержание предыдущих серий



Соответствуйте ожиданиям.
Делайте сайт простым.
Показывайте актуальный склад.
Позволяйте клиентам платить картой.
Сегментируйте предложение.

Предлагайте нужное!


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

В современной России странные сопутствующие товары в интернет-магазине чаще обусловлены не суровым умыслом освободить склад от бесполезного, а недостатком аналитики и бедностью фантазии маркетологов. Возьмем, например, люстру во вполне симпатичном магазине всякой электрики 220-volt.ru:

Читать дальше →
Всего голосов 13: ↑13 и ↓0 +13
Комментарии 7

Зачем нам в «Леруа Мерлен» нужен собственный российский отдел разработки на 200 человек

Время на прочтение 8 мин
Количество просмотров 28K
Привет! Я Валерий Лаптев, руководитель разработки LM в России. За два года мне нужно было поднять огромный отдел, и это был довольно интересный опыт.

Дело в том, что «Леруа Мерлен» есть во многих странах. Головная компания — во Франции, называется ADEO. Там пишут код под Францию, Италию, Испанию и Россию. Бизнес-модели у нас разные: если на российском рынке мы держим минимальные цены (ниже всех конкурентов в мониторинге), то в Европе всё иначе. На самом деле отличий море — начиная от особенностей локали и заканчивая другим законодательством. Есть особенности инфраструктуры России (те же очень большие задержки до Хабаровска) и другой жизненный цикл оформления заказа. Всё это порождает вот такой адский код, состоящий из огромных блоков IF:



Два года назад у нас было 60 магазинов и много-много хотелок по фичам. Накатывались они примерно за полгода и не всегда правильно. Последней каплей после кучи отклонённых по низкому приоритету фич была просьба завести в заказ поле-строку, чтобы мы его уже потом сами парсили. Это нужно было для особенностей доставки в России, поскольку страна больше других стран присутствия LM. Нам отказали и в этом, точнее, сказали, что будет где-то через семь-восемь месяцев.

Полугодовой цикл неспешной головной компании нам не подходил. Естественно, мы предложили написать свой код, отдать на ревью и подождать внедрения… Правда, из этого ничего хорошего не вышло.
Читать дальше →
Всего голосов 57: ↑52 и ↓5 +47
Комментарии 49

Как мы делали клубную программу Спортмастера

Время на прочтение 9 мин
Количество просмотров 20K
Если вы чаще раза в год ходите в наши магазины за спорттоварами или одеждой, скорее всего, у вас есть наша клубная карта (синяя, серебряная или золотая). Меня зовут Максим, я заместитель директора департамента разработки, внедрения и сопровождения ПО, и в этом посте мы с коллегами расскажем про становление клубной программы Спортмастера, про коллекцию собранных нами в процессе граблей и про то, чем наша клубная программа отличается от привычных скидочных карт других торговых сетей.



Тогда


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

В те годы мы сами написали систему лояльности, которая могла нормально вести учёт бонусных баллов каждого пользователя. Но так как магазинов у нас уже тогда было много, в отличие от мощностей для обработки данных, вся наша база данных бонусов умещалась в одном файле, который просто рассылался по магазинам и обслуживался локально, а изменения за день возвращались обратно. Кстати, именно это стало первопричиной того, что бонусы можно тратить только на следующий день после покупки, а не требования бизнеса и обеспечение возврата клиентов — в течение суток всё это просто не успевало обновиться и пересчитаться как следует.
Читать дальше →
Всего голосов 49: ↑44 и ↓5 +39
Комментарии 60

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность