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

До этого я работала в команде Compliance, где активно занималась защитой данных. Сейчас моя зона ответственности охватывает безопасность в логистике и товарных операциях: склады, пункты выдачи заказов, курьерская доставка и все сопутствующие процессы.

На первых этапах погружения в профессию, когда я была студенткой и только начинала разбираться в защите данных, проблемы безопасности казались мне чем-то далёким и почти гипотетическим. Мысль о том, что личная информация — адрес, электронная почта или данные банковской карты — может попасть в чужие руки, не вызывала у меня особого беспокойства. Утечка данных? Да, неприятно, но ведь это происходит где-то далеко и вряд ли касается меня напрямую.

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

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

За время своей работы в e-commerce-компаниях я собрала некоторый перечень подходов и инструментов защиты, которые реализую в своём направлении. Сегодня я хочу рассказать о маскировании вам, моим коллегам, которые так же, как и я, стремятся сделать данные безопасными, а жизнь пользователей — спокойной.

Всем привет! 

Меня зовут Курилкина Арина, я почти год являюсь фронтенд-разработчиком интеграционных и инфраструктурных сервисов склада. Также я 2,5 года разрабатывала мессенджер для сайтов Покупателя (Buyer Experience или же, как мы у себя говорим, — BX) и Продавца (Seller Experience — SX). Таким образом, я успела поработать с продуктами трёх крупных структур Ozon: BX, SX и Warehouse (Складские сервисы*).

Каждая структура уникальна, имеет свои потребности, свои проблемы и свои решения. И каждая является неотъемлемой частью функционирования компании Ozon. Своеобразные три кита, на которых стоит маркетплейс. Поработав с каждым из них, я посмотрела на клиентскую разработку и на работу с дизайн-системами и UI-kit’ами, в частности, с разных сторон. И теперь я хочу поделиться своим опытом.

Моя статья может быть полезна всем тем, кто хочет разобраться в принципах взаимодействия с дизайн-системами и UI-kit и научиться эффективно использовать их в своих проектах.

Привет, Хабр! Меня зовут Антон, я — тимлид в Ozon. За более чем 20 лет работы в IT, где свыше 15 из них выпало на управленческие должности, меня покидало по разным проектам разработки ПО. Познавая управленческое мастерство, я нередко замечал, как на проектах игнорировали самую важную часть — ориентированность на Клиентов, то есть для кого мы, собственно, эти проекты и продукты реализуем.

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

Проблемы Agile отмечают не только рядовые пользователи, но и такие мастера, как Роберт С. Мартин и Кент Бек — двое из тех, кто составил Agile Manifesto. Как отмечает Ален Холуб, Agile в последнее время стал означать: делать половину задач (активностей) из Scrum плохо с использованием Jira.

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

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

Итак, подслушано в баре об Agile: некомедия в пяти актах...

Привет, Хабр! На связи команда Seller API, а именно её тимлид Саша Валов и старший разработчик Никита Денисенко. В этой статье мы разберём одну из проблем большого API и расскажем, как мы её решили.

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

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

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

Кто-то может сказать: «А что тут такого? Просто стандартное управление ожиданиями одной из заинтересованных сторон» и будет прав, но не совсем. Управление «вверх» — это управление не только теми ресурсами, которые тебе выделили для выполнения проекта, удовлетворение пожеланий и ожиданий высшего руководства. Это обеспечение успеха проекта, одновременное жонглирование вниманием топ-менеджеров, и это непростая задача. 

Менеджеры проектов находятся на стыке лидерства и исполнения задач. Их роль требует координации команд при подотчётности заинтересованным сторонам. Последняя обязанность может быть сродни присмотру за активными детьми, которые хотят делать и получать всё и сразу.  

Привет, меня зовут Иван Курак, я Android-разработчик приложения Ozon Job. Если в первой статье мы разбирали фреймворк Koin, то во второй на наш исследовательский стол попадёт Dagger, который мы используем на большинстве проектов Ozon, в том числе на приложении Ozon Курьер Экспресс, за которое отвечает наш отдел.  Это мобильное приложение, которое позволяет курьерам-фрилансерам и водителям службы доставки взять подработку в Ozon и доставлять экспресс-заказы от селлера напрямую клиенту или в ПВЗ Ozon.

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

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

Эта статья будет полезна тем, кто использует Dagger 2 в своих приложениях и иногда/часто попадает в ситуации непонимания, почему Dagger 2 ведёт себя не так, как мы ожидаем. А это может создавать определённые трудности, особенно при отладке сложных проблем или при необходимости настройки более сложных сценариев внедрения зависимостей.

Например, в приложении Ozon Курьер Экспресс ведутся большие работы по переписыванию приложения на новую архитектуру. Поэтому рядом с существующей DI-архитектурой появилась вторая DI-архитектура.  Чтобы их подружить, пришлось покопаться во внутренностях кода, что генерирует Dagger 2.

Дополнительная (но не менее важная) цель статьи — показать, что базовый код, который генерирует Dagger, не такой уж и страшный :).

Конечно, не планирую передавать этот дневник будущему поколению, ведь я не Уинстон Смит и не живу в антиутопичном мире 1984 года. Но буду очень рад, если мои мысли пригодятся ребятам, которые, как и я, находятся на старте своего карьерного пути и испытывают разные страхи.

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

Привет, Хабр! Меня зовут Елена Сахно, я — старший сетевой инженер в группе сетевых сервисов отдела сетевых технологий в Ozon.

В первой части (ссылка на первую часть) статьи мы выяснили, почему важно мониторить BGP и какие есть решения. Мы узнали, что из себя представляет протокол BMP, для чего он используется, какие у него есть преимущества и недостатки. Рассказали, зачем создали свой сервис для мониторинга BGP и что из этого вышло.

В этой части подробно разберём решение и посмотрим внимательнее на каждый компонент системы.

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

Мы снимаем сотни тысяч метрик и используем их, чтобы повысить стабильность работы нашей сети. В качестве источников метрик мы используем всем известные SNMP, телеметрию, логи, Netstream-статистику, скрипты, а с недавнего времени — протокол BMP.

На основе BMP мы запустили мониторинг EVPN-фабрики ЦОД, получили отличные результаты и хотели бы поделиться опытом. Статья будет интересна всем, кто имеет отношение к сетевым технологиям и протоколу BGP.

Наша история будет состоять из двух частей.

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

Во второй части подробно разберём решение, и посмотрим внимательнее на каждый компонент системы.

Привет! Меня зовут Максим Соколов, я — аналитик в команде “Управление доступностью товаров и категорий”. В нашей команде была выделена отдельная подгруппа, которая создавалась специально под новый продукт-фичу для селлеров. Сразу стало понятно, что для реализации нового функционала требуется разработка нового микросервиса. Командой разработки было принято решение интегрироваться по gRPC, но мне до конца не было понятно, почему выбор именно такой. И тут я решил разобраться подробнее!

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

Могу сказать, что выбор технологии для проекта — задача непростая, требующая совместного участия разных участников технической команды: аналитик, разработчик, тимлид, архитектор.

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

В этой статье я хочу дать точку входа для джун/мидл системных аналитиков, которые хотят разобраться в межсервисной интеграции. Мы пройдёмся по HTTP, REST, RPC и gRPC, разберёмся в их значениях. Выясним, почему эти аббревиатуры появляются, когда происходит проектирование API, и попробуем понять, когда и что следует применять.

Также по ходу статьи буду оставлять ссылки на хорошие (по моему мнению) статьи для более глубокого погружения в поднимаемые темы.

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

Также мы предоставляем инструменты для создания JS-библиотек. И в этой статье я расскажу о том, как мы советуем создавать npm-пакеты. Отмечу, что это не касается UIKit-пакетов, — для них требуется довольно специфичный инструментарий, который заслуживает отдельной статьи.

Недавно у нас проходила актуализация инструментов, которая включала обновление версий Node, TypeScript и прочего. И мы обнаружили, что сейчас правильно упаковать библиотеку ой как нелегко, особенно с началом активной фазы по отказу от CommonJS. В идеале очень хочется иметь инструмент, который бы просто работал. В open-source есть парочка вариантов (unbuild, pkgroll, dnt), но выбрать подходящий мы пока не смогли. А написать свой — довольно трудоёмкая задача. В будущем мы обязательно обзаведёмся таким инструментом, а пока просто погрузились в тему и подготовили для наших разработчиков рекомендованные сетапы, которыми сейчас поделимся и с вами.

Привет, Хабр! На связи команда безопасности Платформы в лице её тимлида Букина Владимира. Основная задача нашей команды — защита CI/CD и, в частности, GitLab с K8s. Дальше я расскажу вам о том, как мы внедряли, поддерживаем и улучшаем наш плагин авторизации для Docker socket.

Так сложилось в нашей индустрии, что ИБ всегда догоняет технологии, которые внедрили в IT. При внедрении технологии всплывают всевозможные риски, о которых не успели подумать при разработке. Для мира ИБ Docker и K8s — ещё совсем свежие технологии. Исследований не так много. Всё ещё куча уязвимостей (в том числе и необнаруженных), и поэтому поработать с ними особенно интересно.

В статье хочу рассказать о том, как мы сделали наши CI/CD-процессы более безопасными: в частности, про shared Docker executor и использование Open Policy Agent (OPA). Поделюсь нашими правилами для ОРА-плагина, которые можно переиспользовать в любой компании для того, чтобы обезопасить ваши контейнеры.

Статья будет особенно полезна инженерам ИБ, DevOps-инженерам, архитекторам и СТО, но и разработчики найдут для себя что-то интересное, я уверен.
Погнали!

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

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

Привет! Меня зовут Пётр Жучков, я руководитель группы хранения секретов и конфигураций в отделе Message Bus в Ozon. Мы отвечаем за поддержку и развитие системы хранения и использование секретов, активно сотрудничаем с ребятами из департамента информационной безопасности, чтобы все сервисы могли безопасно работать с секретами.

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

Если вы хотите безопасно хранить секреты или просто погрузиться в gRPC и Go, то, думаю, вам будет интересно и полезно не повторять наши ошибки.

Далее я расскажу историю о том, как во время стандартной процедуры обслуживания Vault мы смогли положить его и потратили много времени и нервных клеток, чтобы вернуть в рабочее состояние.

Привет, меня зовут Иван Курак, я Android-разработчик приложения Ozon Job. В этой статье мы реализуем свой механизм, на котором построен Koin. Тем самым мы пройдём путь, который проходили его авторы при решении проблемы построения собственного DI.

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

Дополнительная (но от того не менее важная) цель статьи — показать, что базовый механизм, на котором построен Koin, не такой уж и страшный :)

Привет! Меня зовут Кермен, я — аналитик на второй линии SOC. Наша команда исследует данные от инфраструктуры и сервисов Ozon для выявления нелегитимной активности: от нарушения политик информационной безопасности до целенаправленных атак.

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

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

Нам захотелось навести порядок, поэтому позаимствовали опыт разработчиков: сделали новый формат хранения, добавили больше метаинформации, настроили CI/CD, и теперь у наших объектов есть свой жизненный цикл, включающий в себя этапы разработки, тестирования, перенос в продакшн, пересмотр и отключение.

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

Привет! Меня зовут Михаил Мурзак, я продуктовый дизайнер в Ozon Seller (сайт и приложение продавца).

Время от времени мы делаем анимированные онбординги крупных фич в мобильном приложении и долгое время использовали для этих целей Adobe After Effects с плагином Bodymovin (для экспорта в Lottie), но каждый раз для меня это было мучением, поэтому я решил пересесть на официальный клиент Lottie и написал этот гайд для коллег.

Теперь, когда Adobe не продлевает лицензии, этот гайд стал ещё более актуальным, и я решил опубликовать его тут.

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

Меня зовут Егор Прокопьев, и я фронтенд-разработчик в Ozon.

Третья версия полюбившегося многими фреймворка Vue вышла уже давно, и большинство использующих его произвели обновление до новой версии. Но всегда будут такие, как наша команда, кто откладывал этот переход в дальний ящик техдолга — ведь есть более приоритетные задачи! Однако рано или поздно этот день настаёт, и вот и для нас он пришёл.

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

Всем привет!

Меня зовут Ваня Назаров, я работаю менеджером проектов в Ozon Tech.

Одна из основных моих обязанностей — поддержание функции руководителя департамента одного из направлений работы всего Ozon.

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

В термин «функция» я закладываю смысл какой-либо прямой деятельности руководителя.

Давайте вместе попробуем разобраться и понять, есть ли подводные камни в этом вопросе и, если есть, то какие.

Всем привет! Меня зовут Саша, я руковожу группой разработки Composer Core в Ozon Tech. В этой статье я расскажу о том, как устроена пользовательская часть одного из ведущих российских маркетплейсов, в развитии которой на момент написания статьи участвуют сотни специалистов из десятков команд. При наличии такого количества людей разрабатывать новую функциональность, не рискуя сломать уже существующую, является достаточно сложной задачей.

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

Продукт, который мы разработали, вряд ли когда-нибудь станет open-source-проектом, так как он слишком зависит от специфики инфраструктуры Ozon Tech. Но основные принципы могут быть полезны при проектировании похожих систем.