Привет! Меня зовут Влад, и я разрабатываю сердце витрины Ozon — сервис product-facade. Пару лет назад мы уже делились нашим опытом в этой статье, но с тех пор многое изменилось: выросли нагрузки, появились новые фичи и оптимизации, система стала сложнее и надёжнее.

Прежде чем перейти непосредственно к актуальности кешей, давайте разберёмся, почему это так важно. Представьте: вы добавляете товар в корзину, но что-то пошло не так, и покупку совершить не удаётся — склад больше не возит в ваш ПВЗ. Даже 0.1% таких ошибок — это тысячи недовольных пользователей каждую секунду. А когда что-то массово меняется, разработчики вынуждены расследовать инцидент, чтобы понять, что проблема была всего лишь в устаревших кешах.

Когда слышишь слово «API», первое, что приходит в голову — это технический набор функций для программистов. Но в нашей работе с Ozon Seller API я убедился, что API — это целый продукт, в котором нужно думать не только о коде, но и о двух разных аудиториях, метриках, бизнес-логике и даже внутренней политике большой компании.

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

Меня зовут Лев Савельев, я старший менеджер по продукту Ozon Seller API. В этой статье расскажу, как мы развиваем Seller API как продукт, с какими вызовами столкнулись, какие ошибки сделали и чему научились, и как вся работа связана с экосистемой Ozon — порталом dev.ozon.ru и существующим Магазином приложений для селлеров.

Всем привет! Меня зовут Андрей Иблеминов, я инженер группы управления уязвимостями в Ozon, в сфере информационной безопасности работаю более 5 лет. В данной статье я поделюсь своим личным опытом (и опытом моей команды) решения задач, связанных со своевременным обнаружением и устранением уязвимостей в ИТ-инфраструктуре Ozon.

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

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

Когда речь заходит о стажёрах, многие представляют себе беспомощных новичков, которым требуется постоянная опека. В этой статье я хотел бы развенчать это заблуждение. Хочу показать, что среди начинающих специалистов много талантливых людей, которые не требуют чрезмерного контроля и способны удивить своими навыками. Для этого я постараюсь показать, что грейд (стажёр, джуниор, мидл или сеньор) — это не одномерный показатель, а среднее из нескольких аспектов, некоторые из которых более важны, а потому заслуживают особого внимания. Но обо всём по порядку.

Прежде чем углубиться в детали, позвольте представиться. Меня зовут Анзар, я работаю фронтенд-разработчиком уже 9 лет, последние 3 из которых — в Ozon Tech, где я занимаю позицию тимлида. За это время я побывал на десятках, а может, и сотнях собеседований — и как кандидат, и как интервьюер. Кроме того, у меня за плечами многолетний опыт менторства и мне приходилось наблюдать, как различные факторы влияют на скорость роста. Все это заставило меня глубоко задуматься о системных проблемах найма разработчиков. Думаю, эта статья будет особенно полезна нанимающим менеджерам, рекрутерам и, возможно, HR-специалистам — она поможет пересмотреть подход к найму.

Привет, Хабр! Меня зовут Настя, я работаю методологом в команде проекта Route 256 — онлайн-курсов продвинутой разработки от экспертов Ozon Tech. В год мы запускаем несколько потоков обучения. И на каждый запуск мы набираем не только студентов, но и экспертов из направления IT в качестве преподавателей. В этой статье хочу поделиться тем, как начать путь спикера и преподавателя на примере внутренних курсов компании. Здесь я не касаюсь темы научного преподавания и работы с вузами, а скорее даю универсальные рекомендации для тех, кто хочет делиться своими знаниями и опытом с другими, но пока не знает, как это сделать. 

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

Всем привет!
Меня зовут Александр Исай, я тимлид в Ozon Tech. Сегодня я расскажу историю о том, как мы спасали нашу систему резервации товаров от краха в самый горячий момент года.

Привет! Меня зовут Кирилл, я руковожу ИБ в Ozon. Уже 15 лет занимаюсь ИБ, успел поработать в телекоме, в медиабизнесах, участвовал в построении SOC, AppSec, строил ИБ с нуля. В общем, успел много повидать, а сегодня расскажу, как, будучи CISO, снова оказался на позиции специалиста первой линии SOC.

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

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

Всем привет! Меня зовут Мурад Арфанян, я разработчик информационных систем в Ozon Tech. Наша команда работает с данными жизненного цикла товаров в логистике. Объём продаж растет стремительными темпами и нешардированный ClickHouse уже не справляется с постоянно увеличивающимися потоками данных. Чтобы решить эту задачу, мы построили шардированный кластер, преодолев на пути несколько интересных технических вызовов. В этой статье я расскажу о нашем опыте и решениях, которые помогли масштабировать систему и обеспечить стабильную работу при росте нагрузки.

Привет! Меня зовут Никита, я старший фронтенд-инженер в Ozon Tech и я разрабатываю кабинет рекламодателя. Однажды мы попытались обновить версию Node.js и нашли баг, который затянулся на два года и вовлёк в себя команды Jest, Node.js и V8.

Всем привет! Меня зовут Артём Подвальный, я Data Engineer в Ozon Tech. Мои основные задачи это  сбор и объединение данных из разных источников для обучения моделей, которые определяют порядок выдачи в поиске. До этого я занимался дата-инженерными задачами в SMlab (команда персональных рекомендаций).

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

По моим наблюдениям, дата-инженеры — это те, кто строит фундамент всей работы с данными: они собирают, обрабатывают, хранят и передают данные в аналитические системы. В этом Roadmap я поделюсь, как самому стать таким специалистом, какие навыки реально важны на разных этапах, и чего обычно ждут на собеседованиях. Всё — из моего опыта, историй коллег и реальных требований с рынка.

Привет, друзья!

Меня зовут Дмитрий, и я инженер отдела Compliance и безопасности данных в Ozon. Моя работа сфокусирована на разработке, введении и при необходимости модернизации требований ИБ к контрагентам, выстраивании процессов взаимодействия с партнерами.

Привет! Меня зовут Роман Чечёткин, я разработчик в команде «Платформа коммуникаций» в Ozon Tech. Наша платформа предоставляет возможность другим командам отправлять различные сообщения в личные кабинеты пользователей.

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

Обрыв каналов связи, багованный релиз, мискоммуникация… Серия загадочных событий, авантюрный детектив из цикла «Следствие вели…» — нет, не с Леонидом Каневским, и даже не Колобки, а команда разбора инцидентов, или просто Post. 

Хей-хей! Я Юля, и я специалист по сопровождению инцидентов в команде Post департамента SRE (Site Reliability Engineering). Когда я рассказываю своим друзьям, чем я занимаюсь на работе, мне часто говорят, что я работаю в детективном агентстве. 

Поэтому сегодня поговорим о том, как устроено управление инцидентами и проблемами в Ozon и чем оно схоже с работой детективов. Статья-расследование будет интересна всем, кто хоть раз задумывался о том, как большие компании не только справляются с форс-мажорами, но и учатся на своих ошибках. Расскажу о внутренней кухне и почему инцидент- и проблем-менеджмент — не «бюрократия», а палочка-выручалочка на пути к стабильности.

Статья Галины Шайдуровой

Психология тестировщика: почему критическое мышление – это суперсила

Привет, Хабр! Меня зовут Галина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы — не просто охотники за дефектами (хотя баги ловить умеем). Мы те, кто ежедневно выходит на поле боя против самого изощренного противника — нашего собственного мозга.

Вы обращали внимание на то, как легко не заметить очевидное? Например, когда вы ищете очки, а они у вас на голове. Теперь представьте, что тестировщик делает это на уровне сложных систем и интерфейсов, где каждая «потерянная пара очков» может обернуться тысячами разъяренных пользователей.

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

Привет! Меня зовут Игорь, я старший инженер по тестированию в Ozon Tech. Тестированием занимаюсь около 20 лет. До Ozon занимался проверкой качества ПО таких компаний как Smartbear, Evernote.  За это время в результате проб и ошибок, анализа обратной связи от пользователей, удалось найти решения, которые смогли уменьшить негатив от сообщений об ошибках. В этой статье я хочу привести несколько примеров, вызывающих наибольший негатив и как этого можно избежать. Это может быть полезно, если вы встретите подобные случаи в своих продуктах и позволит избежать их в новых разработках. 

Всем привет, меня зовут Денис, и я старший инженер инфраструктурной безопасности в Ozon. Эта статья — продолжение цикла про osquery и Fleet.
Предыдущие статьи вы можете почитать здесь и здесь.

В статье хочу поделиться радостью и «болью» опыта эксплуатации связки Fleet и osquery в масштабе e-commerce/highload.
Этот опыт будет полезен тем, кто ещё только думает об этой связке и планирует её внедрять, а также тем, кто уже внедрил и эксплуатирует.
Osquery мы эксплуатируем на рабочих станциях и серверах под управлением операционных систем MacOS, Windows и Linux.
Для начала стоит напомнить, что такое osquery и Fleet и почему они так классно друг друга дополняют.

Osquery — opensource, написанный на С++, представляет собой агента, запущенного на хостовой (и не только) ОС, который может предоставить большое количество информации о вашей системе и событиях в виде СУБД.

Также osquery имеет два вида запросов:

У нас были две сотни брокеров, шесть тысяч топиков, клиенты на четырех языках программирования, миллионы сообщений в секунду и целое море различных паттернов использования Kafka. А также жесткие требования по latency, тонна SLA и желание сделать гибкую систему аутентификации и авторизации для сервисов. Не то, чтобы все это было категорически необходимо для начала этой истории, но если уж начал рассказывать про асинхронные взаимодействия, то иди в этом до конца.

Единственное, что меня беспокоило — это авторизация. В мире нет ничего более желанного для ИБ и ненавистного разработчиками, чем контроль доступа. И я знал, что довольно скоро мы доберёмся и до этого вопроса.

Если вам интересно распутать клубок асинхронного взаимодействия тысяч продюссеров и консьюмеров, узнать, где документация Kafka нас обманывает, а librdkafka и Confluent.Kafka не могут договориться, и как один потерянный пакет может привести к Permission denied, добро пожаловать под хабракат. Эта история для тех, кто догадался, что недостаточно было «просто включить флажок в конфиге».

Привет, Хабр! Меня зовут Виктор Корейша и я — руководитель направления Managed Services в Ozon. Я и моя команда, в том числе, отвечаем за всю инфраструктуру асинхронного взаимодействия между сервисами, которую строим на базе Kafka. А ещё я ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».

Эта статья написана по мотивам моего доклада для DevOps Conf 2025. Расскажу нашу историю про внедрение авторизации и аутентификации в Kafka. Инженеры по эксплуатации найдут в ней обзор решений реализации SASL-сервера, разработчики — историю о конфликтах в production-ready клиентах, архитекторы — любопытные кейсы взаимодействия высоконагруженных систем, ну а менеджеры — эпос о внедрении технически сложных изменений в больших компаниях.

Снова привет! Я старший разработчик в команде средств стабильности и контроля. Мы занимаемся системой, которая всем микросервисам Ozon выставляет рейтинг. Высокий рейтинг позволяет получить разные преимущества, например автоматическое увеличение ресурсных квот сервиса. Низкое значение рейтинга требует повышенного внимания руководителей команд к деплоям.

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

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