Привет! Меня зовут Никита, и я тружусь в команде фронтенда платформы в 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-инженерам, продактам и всем, кто заинтересован в качестве конечного решения на проде.

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

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

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

- Как представить новую фичу пользователю?

- Как сделать так, чтобы пользователь не пропустил добавленный функционал?

- Как повысить количество взаимодействий с новым функционалом?

Также возникает вопрос упущенного этапа продажи новой фичи — подача обновления пользователю.

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

Когда занимаешься каким-то делом достаточно долго, начинаешь ощущать себя сидящим на берегу бурной реки. Мимо проносятся годы, теории, подходы и принципы, можно пронаблюдать весь жизненный цикл каких-то явлений и течений. Одним из таких явлений стало появление бизнес-партнёров по информационной безопасности, которых в англоязычном мире принято величать Business Information Security Officer (BISO). Явлению этому менее 10 лет (если говорить о формировании как института и роли), но оно стало уже достаточно популярным как в российском дискурсе, так и в зарубежном. На пути от олдскульного «специалиста по защите информации» к BISO происходило много событий, но, как известно, дорогу осилит идущий.

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

Привет! Это Маша, технический писатель в группе документации Ozon. Мы делаем внутреннюю документацию в департаменте «Поиск, рекомендации, реклама», в который входит 40 команд разработки. Наш департамент постоянно развивается, появляются новые команды и люди, которым нужно побыстрее влиться в компанию и коллектив. Недавно одна из команд планировала набирать новых сотрудников, и коллеги попросили помочь сделать приветственную страницу для новичков — онбординг.

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

Привет, Хабр! Меня зовут Георгий, я руководитель команды Ozon Банк iOS. Я занимаюсь разработкой и развитием мобильного направления финансовых продуктов Ozon.

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

Часто разработчики используют только встроенный API взаимодействия JavaScript c нативными кодом, например Web API, но нам этого оказалось мало, и мы расширили спектр возможностей подхода web-native. Внутри статьи я расскажу, какой подход выбрал, как к этому пришёл и как обошёл возникшие проблемы. Подчеркну плюсы и минусы использования своего решения и в конце предложу несколько идей дальнейшего развития выбранного пути.

Привет, Хабр! Меня зовут Виктория Юльская, и я старший системный аналитик в Ozon.

Я думаю, здесь найдётся много людей, которые хоть раз работали с документацией API в Confluence. Да-да, те самые километровые страницы на каждый метод — с описанием всего и вся в виде текста, таблиц, диаграмм последовательности и т. д.

Зачастую такая документация API в Confluence устаревает ровно в тот момент, как её закончили писать. После передачи задачи в разработку, как только что-то непонятно, куда все идут? Правильно, к аналитику — «А как это работает? А что это значит? А что если...?».

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

Есть ли более эффективный способ ведения и поддержания документации API в актуальном состоянии? Давайте разбираться.