Привет, друзья!
Меня зовут Дмитрий, и я инженер отдела 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 выставляет рейтинг. Высокий рейтинг позволяет получить разные преимущества, например автоматическое увеличение ресурсных квот сервиса. Низкое значение рейтинга требует повышенного внимания руководителей команд к деплоям.
В Сети много материалов, по которым можно подготовиться к собеседованиям на должность разработчика: статьи, видео, дорожные карты, телеграм-каналы и прочее. Однако мало информации о том, что делать после получения офера и выхода на новую работу. Как быстро освоиться и влиться в коллектив, чтобы успешно решать поставленные задачи?
За последний год я наблюдал, как несколько моих знакомых в разных командах продолжили работать после испытательного срока, но были и те, с которыми, к сожалению, расстались. Изучив их опыт, я составил советы, которые помогут успешно пройти испытательный срок. В большей степени они подойдут разработчикам с небольшим коммерческим опытом, а также тем, у которых в команде появился новый сотрудник.
Всем привет!
Меня зовут Катя Громова. Я работаю руководителем продуктового дизайна в Ozon Travel.
Сложно коротко рассказать о своём опыте — за что я только не отвечала в Travel. Мои основные обязанности — формирование единого визуала продукта и развитие продуктовой команды. Одним словом, делаю всё, чтобы пользователь возвращался к нам.
В этой статье я отвечу на следующие вопросы. Возможно ли вырасти от стажёра до руководителя в одной компании? Как сделать так, чтобы бизнес считался с дизайном? Что должен делать руководитель дизайн-команды? Или это всё простые истины, и вы уже заряжены на успех и готовы закрыть эту статью? Нет? Значит, пристегните ремни — и поехали!
В предыдущей статье мы рассказали об истории создания нашего измерительного устройства и о том, как появилась идея собственного решения. Во второй части мы сосредоточимся на технической стороне проекта: разберём алгоритмы измерения и инженерные решения, которые позволили добиться высоких точности и скорости замеров. Мы также поделимся опытом преодоления ключевых технических вызовов и расскажем, как пришли к текущему виду устройства.
Привет! Меня зовут Аня, я менеджер продукта в департаменте информационной безопасности Ozon Tech. Сейчас я занимаюсь проектом по внедрению дополнительных механизмов проверки прав пользователей при доступе к корпоративным ресурсам. Этот опыт помог мне иначе взглянуть на угрозы, с которыми сталкиваются сотрудники, работающие удалённо и при этом часто меняющие место работы.
В этой статье я хочу поделиться своими наблюдениями. Возможно, они помогут вам лучше защитить себя в дороге и заодно по-новому взглянуть на риски мобильной работы.
Ни для кого не секрет, что в нашей стране практически любой руководитель в сфере IT начинал свою профессиональную карьеру рядовым сотрудником. Причины, побуждающие специалиста начать двигаться в сторону руководящих позиций, могут быть разными, и в зависимости от причин скорость этого пути также может существенно различаться. Однако сам процесс становления «молодого» руководителя почти всегда сопряжён с одними и теми же проблемами. Основываясь на личном опыте и опыте наших коллег и подчинённых (которые тоже руководители), мы хотим коротко разобрать проблемы, особенно беспокоящие и мешающие вчерашним разработчикам, выбравшим сегодня путь своего развития в качестве руководителя группы или отдела. Более высокопоставленным руководителям эта статья также может быть полезна при менторстве «младшего командного состава».
Привет! Меня зовут Геннадий, я руковожу командой разработки системы учета товаров в Ozon. Мы активно используем Kafka как основной инструмент для асинхронного взаимодействия между нашими сервисами. Для нас Kafka — это не просто очередь сообщений, а один из ключевых компонентов всей архитектуры. Поэтому мы постоянно погружаемся в его тонкости и нюансы, чтобы грамотно настраивать и использовать его возможности. Думаю, многие из вас сталкиваются с тем же — когда Kafka становится критически важной частью вашего решения.
Хотя информации о ребалансировке Kafka достаточно, она часто либо слишком разрозненная и техническая, либо наоборот — поверхностная и без акцента на важные детали. Я собрал для вас самое важное и объясню это простым и понятным языком.
Продукты 1С так или иначе на разных этапах карьерного пути бегло попадались в моём поле зрения, и в какой-то момент захотелось собрать воедино хотя бы часть всего того неочевидного, с чем мне уже довелось столкнуться там в контексте информационной безопасности.
Коротко о важном
• Статья не является рекламной и не имеет под собой намерения похвалы или критики программных продуктов 1С. Любая внедряемая система потребует необходимости уметь её «готовить», и продукт 1С не исключение.
• Поскольку я не являюсь разработчиком 1С, далёк от профильной терминологии и в целом целевая аудитория статьи — всё-таки специалисты по информационной безопасности, которым уже пришлось или только предстоит плотно столкнуться с программными продуктами 1С, многие вещи будут трактоваться довольно свободно и в упрощённом для понимания виде.
• В статье не будет охватываться раздел пентеста платформы 1С, а также связанной с этим эксплуатации уязвимостей — эта тематика не нова, и на просторах «Хабра» (и не только) уже давно можно найти отличные публикации.
• Статья не претендует на истину в первой инстанции. Она своего рода первая проба пера, попытка структурировать опыт знакомства с продуктами 1С и консолидировать основные узкие места безопасности, свойственные построению бизнес-процессов с использованием 1С.
• Если вы из тех, кому необходим пошаговый чек-лист, то спешу вас огорчить, так как универсального ответа не будет, но надеюсь, что вопросы, поднятые в статье, смогут подтолкнуть вас к составлению по итогу своего собственного.
Привет! Меня зовут Анна Дубенюк, я выпускница и преподаватель ФКН ВШЭ, автор канала всё предельно, и недавно было 3 года, как я работаю в Ozon Tech. За это время из пары математиков в команде разработки мы выросли в отдельную команду RnD, помогаем оптимизировать процессы, находим точки роста и снижаем неопределённость с помощью математического моделирования и исследований.
В статье приведён обзор того, как математика помогает в реальном мире для оптимизации складских процессов. Причём именно та математика, которая не внутри модных нейронок, а более классические подходы, которым сейчас в университетах уделяют всё меньше внимания. Если из всей статьи вы запомните только одну мысль, то пускай это будет тезис, что математика — это не только ML.
Привет! Меня зовут Олег Стрекаловский, я старший разработчик в команде корзины маркетплейса. Сервис корзины Ozon отвечает за хранение корзин покупателей и за отрисовку соответствующего экрана в приложении и на сайте. Слежение за стабильностью сервиса — важная задача. В этой статье я расскажу о нюансах интерпретации данных, которые предоставляет система мониторинга Prometheus. Если вы тоже часто всматриваетесь в графики, чтобы понять, как чувствует себя сервис, эта статья для вас.
Всем привет! Меня зовут Ира, я руковожу отделом тестирования мобильной платформы в Ozon Tech. Наш отдел занимается разработкой инструментов для автоматизации тестирования мобильных приложений Ozon и тестированием внутренних библиотек.
До того как прийти в компанию, я занималась мобильной разработкой и знаю, какие вопросы задают разработчикам на собеседованиях. Про многопоточность разработчика точно спросят, но у QA-инженеров про работу процессов и потоков в мобильных приложениях мы, как правило, не спрашиваем. На мой взгляд, в этом имеет смысл разобраться, чтобы эффективно взаимодействовать с разработчиками и говорить с ними на одном языке.
В этой статье расскажу о том, как приложение работает «под капотом», что такое многопоточность, какие потоки бывают, и какие ошибки, связанные с реализацией многопоточности, могут возникать в приложении.
Всем привет! Меня зовут Женя, я руководитель отдела разработки «Аккаунт» в мобильном приложении для продавцов платформы Ozon Seller. Поделюсь нашим опытом работы над улучшением скорости сборки Android-проекта.
Скорость сборки проекта напрямую влияет на time to market продукта и (внезапно) удовольствие от процесса разработки. Если каких-то 50 лет назад время компиляции могло доходить до нескольких дней, и это считалось нормальным, то сейчас даже лишняя пара минут сборки проекта в Android Studio может заставить понервничать. Чтобы сберечь здоровье себе и CI, скорости сборки проекта нужно уделять внимание. Нетерпеливые читатели могут сразу посмотреть итоговую таблицу с результатами в конце статьи.
Kelp — мощный плагин для Android Studio, разработанный для улучшения поддержки кастомных дизайн-систем на Jetpack Compose в Android Studio.
Основные фичи:
🔧 Настраиваемые иконки для компонентных функций
🎨 Иконки дизайн-системы
🌈 Предпросмотр цветов
📱 Интеграция демоприложения (автоматическое скачивание и установка APK-файла и deeplinking на страницу компонента)
🖼️ Рендеринг изображений в KDoc
⌨️ Шаблоны кода (Live Templates)
И 🐘 Gradle Plugin, скачивающий демоприложение и проверяющий наличие IDE-плагина.
Привет! Меня зовут Аня Салугина, я технический писатель в Ozon Tech. Наша команда готовит и актуализирует документацию для покупателей, продавцов, партнёров, разработчиков и сотрудников Ozon. Недавно мы решили, что хотим улучшить наш стайлгайд и сделать его публичным.
Эта статья о том, как мы это сделали: искали новую структуру, обсуждали спорные моменты с командой и запускали обновлённый стайлгайд в работу.
Спойлер: командная работа — ключ к успеху.