Привет, меня зовут Иван Курак, я 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. Но основные принципы могут быть полезны при проектировании похожих систем.

Привет! Меня зовут Анастасия. Я старший продуктовый дизайнер внутренних сервисов в Ozon Tech. Чтобы быстро решать вопросы клиентов Ozon, мы используем чат-ботов и постоянно их улучшаем. Такие боты встроены в клиентский чат, чат с продавцами, чат Ozon Travel и другие.

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

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

Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon Profit. Изначально я собирал материал для приватной страницы онбординга руководителя в нашу команду, но получилось выделить общие моменты (убрать всю секретную информацию) и составить цельную картину того, с чем может столкнуться начинающий менеджер. Этим я и хочу поделиться с сообществом.

Материал статьи не претендует на объективность. Все упомянутые истории происходили в моей практике или в практике моих сотрудников, совпадения не случайны. Без лишних предисловий, начнём!

Всем привет! Меня зовут Люба, и я инженер по тестированию в команде Ozon Partners Platform. Наша команда занимается поддержкой и развитием системы, предназначенной для развития сети пунктов выдачи Ozon. Одним из компонентов этой системы является Открытая карта.

Хочу рассказать, как мы научили автотесты находить на ней точки, подходящие для открытия нового ПВЗ.

Однажды мы решили, что грамотных инженеров эффективнее всего растить самим. Так 3 года назад родился Route 256 — курсы Ozon для разработчиков и тестировщиков уровней junior и middle.

Во время курса ведущие специалисты Ozon погружают в индустрию e-com, знакомят с актуальным стеком и бизнес-задачами. Самые успешные выпускники получают оффер в команду Ozon.

В статье рассказали, почему для отбора мы используем алгоритмы, и показали разбор задач с контеста.  

Привет, Хабр! Я Женя, ведущий продуктовый дизайнер в Ozon, и за 10+ лет в дизайне повидала всякого: ошибок в макетах (своих и чужих), недостаточно полных спецификаций, неучтённых корнер-кейсов, сотни сообщений в тредах с разработкой и переносы релиза из-за досадных багов. 

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

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

^{Осторожно, количество мемов в статье зашкаливает}