Привет! Меня зовут Катя, я руководитель команды технических писателей в Ozon.
Недавно разбирала внутренние документы компании и поняла, что есть некоторая путаница в головах — не всегда понятно, что за документы должны быть в компании и кто их должен писать.
Привет, я Паша из Ozon. В рабочее время занимаюсь тестированием поиска, а по вечерам надеваю маску инди-разработчика. И моя самая частая задача — написать скрипт → залить его на сервер → периодически мониторить, что сервер доступен. Эта статья как раз и будет строиться вокруг последнего пункта.
Вы наверняка в курсе, что существуют Grafana, Prometheus, Kibana, LogDNA и другие инструменты для мониторинга, визуализации и анализа данных. C первыми двумя я вплотную познакомился в Ozon, а про Kibana слышал когда-то давно и только в паре со словом «логи». Чтобы графики в Grafana рисовать — придется штат аналитиков нанять (ба-дум-тсс). Для пет-проекта это перебор, нужно что-то сильно проще (с точки зрения стоимости, простоты настройки и удобства). Ниже расскажу, какие готовые инструменты для мониторинга небольших пет-проектов я нашёл в пучинах интернета, а также оставлю комментарии и рекомендации по использованию.
У нас в компании 8 мобильных приложений и почти столько же мобильных команд. Конкретно наша работает с приложением для покупателей. Когда нас было немного, по 6-10 человек в iOS, Android и QA–командах, мы отлично справлялись с задачами. С ростом столкнулись с проблемой: чем больше у тимлида людей в подчинении, тем меньше он может уделить времени каждому, меньше времени имеет на погружение в задачи. В итоге качество управления команд начинало ухудшаться и с этим нужно было что-то делать
Решение мы нашли в распределении команд по стримам.
В этой статье расскажу как у нас организована работа для 30+ мобильных разработчиков и 14 QA: как мы планируем, делимся знаниями и что нам даёт этот подход.
Встречали ли вы баги, где было недостаточно информации для понимания про что это? А тикеты, в которых было сложно найти нужную информацию, хотя где-то она все-таки есть? Кажется, команды сами усложняют себе работу не используя стандарт заведения тикетов-багов. И я решила поделиться шаблоном, который используем мы.
"Хочешь ускорить запросы, построй индекс" – классический первый шаг по увеличению производительности в PostgreSQL. Вот только на практике можно встретить ситуацию, когда индексы в PostgreSQL есть, но тормоза никуда не делись. Не все индексы являются эффективными. Одна из возможных причин тормозов индексов – это отсутствие корреляции данных. Давайте поговорим о пенальти на производительность, которое дает расположение данных: почему это происходит и как это можно предотвратить.
Тимлидами редко рождаются, чаще — становятся. Самый частый пример, который я видел — тимлидом назначают самого ответственного разработчика из команды. Наделить ответственного человека еще большей ответственностью — сильное и эффективное решение, правда же?
Как говорил дядя Бен, большая сила — это большая масса, умноженная на большое ускорение большая ответственность. Поэтому новоиспеченный тимлид (со всей этой растущей ответственностью и силой) может поддаться соблазну принимать как можно больше сильных и эффективных решений.
Давайте рассмотрим десять простых практик, которые помогают ответственному тимлиду добиться нужного результата.
Недавно, проходя очередной уровень в моих любимых третьих Героях, я понял, что игра до удивления похожа на реальную жизнь. И решил сопоставить все этапы устройства-выхода на новую работу со сценарием в Homm3.
Привет, меня зовут Маша, я работаю маркетинговым аналитиком в Ozon. Наша команда "питонит" и "эскьюэлит" во все руки и ноги во благо всего маркетинга компании. Одной из моих обязанностей является поддержка аналитики для команды медийной рекламы Ozon.
Медийная реклама Ozon представлена на разных площадках: Facebook, Google, MyTarget, TikTok и другие. Для эффективной работы любой рекламной кампании необходима оперативная аналитика. В данной статье речь пойдет о моём опыте сбора рекламных данных с площадки TikTok без посредников и лишних заморочек.
- Ребята, кажется, вы таймаутите. Вот трейс, на котором видно, что мы не дождались от вас ответа за 2 секунды.
- Ничего подобного, у нас все норм — мы за 200 миллисекунд отвечаем в 99% запросов. А вот вы по какой-то причине часто преждевременно обрываете соединение.
Такой разговор однажды произошёл у нас в Ozon между моей командой личного кабинета продавца и коллегами, которые пишут сервис аутентификации. Причина проблемы оказалась в дефолтных настройках Go для пула HTTP-соединений. Как так вышло, как мы обнаружили проблему и как исправлять подобные ситуации в микросервисах на Go – об этом моя сегодняшняя история.
Поговорили с Александром Дьяконовым — преподавателем курса по машинному обучению OzonMasters и одним из самых известных специалистов по машинному обучению в России о старте карьеры в Data Science, соревнованиях и о своем опыте преподавания.
Статья для менеджеров, которым необходимо вести управление проектами в изменчивом мире Agile. Поделюсь опытом использования двух приложений Jira Roadmap и Structure Gantt.
Привет! Я Катя, руководитель группы технических писателей в Ozon. Сейчас нас уже 9 человек и целая платформа документации, но коллеги всё ещё не всегда понимают, чем мы занимаемся :)
Из непонимания появляются запросы вида: “Хотим себе собственного техписателя в команду, но не знаем, чем именно он будет заниматься”. В итоге команда подстраивается под тренды и заводит себе документацию, но через пару месяцев оказывается, что доку не читают, а техписатель плавно превратился в аналитика.
Поэтому пришло время делиться опытом и рассказывать о каких-то концептуальных штуках :)
У платформодержателей мобильных сторов множество причин для блокировок. Если напрямую с этим не сталкиваться, то, кажется, что все просто - не нарушай описанные правила и все будет отлично. На деле не все блокировки легко предугадать простым следованием гайдлайнов.
Для Figma написан целый легион плагинов на все случаи жизни. Постоянно появляются рейтинги и топ-листы супер-пупер-мега-лучших. Но этот инструмент используют люди разных конфессий, решая разные свои задачки. Рыцари фриланса рисуют лендинги, студийные братья собирают промо-сайты, еретики даже визитки и плакаты пытаются делать в Figma. И для всех есть свои плагины. Поэтому делать общий топ-100 — пустое занятие.
Но можно накидать локальный местечковый топчик для продуктового дизайнера например. В нём не будет плагинов в духе «смотрите, какая любопытная идея» или «если вдруг вам когда-нибудь понадобится заменить все картинки на фото Николаса Кейджа». Только ежедневные трудяги. Я уверен, этот список будет полезен не только UI-дизайнерам и сочувствующим. Что-то полезное найдут для себя и все остальные фанаты Figma.
Привет, меня зовут Геннадий, я работаю в Ozon, занимаюсь разработкой backend-сервисов.
Избыточностью компонентов, кластеризацией или балансировкой уже никого не удивишь в наши дни. Это очень важные и нужные механизмы. Но так ли они хороши? На сколько они защищают нас от возможных отказов?
В Ozon все перечисленное используется, но мы сталкивается с проблемами, которые выходят за рамки возможностей стандартных решений и нужны иные подходы и инструменты. Я уверен, что и у вас есть кластеризация и она также не спасает на все сто.
В статье я хочу затронуть некоторые из этих вопросов и показать, как мы повышаем надежность сервисов с помощью адаптивной балансировки.
Несколько лет назад в Ozon между двумя релизами приложения на одной платформе могло пройти три месяца. Мы планировали, что хотим выпуститься с определенной большой фичей и пока её не сделаем — не релизим.
С чем мы столкнулись, пока выпускали релизы по этой схеме:
Разработка корпоративных приложений со сложной бизнес-логикой всегда несет за собой немалые затраты. Причём львиная доля затрат приходится не на саму разработку, а на поддержку кода приложения: добавление нового функционала, поиск и исправление допущенных ошибок, рефакторинг и т.п. Мне как разработчику ПО всегда хотелось найти “серебряную пулю” для вопросов, возникающих при конструировании кода приложений, как написать потенциально сложное приложение, чтобы его было поддерживать как можно легче и дешевле. В этой статье хочу поделиться практическими знаниями о проектировании архитектуры кода программного обеспечения, полученными из опыта.
Для организации совместного доступа к данным в PostgreSQL программисты часто использую row-level локи. В статье поговорим об оверхеде, который получается от такого подхода и какие есть альтернативы. Давайте посмотрим, как можно поторопить слона!
Пока одни обсуждают что не так с WebAssembly, я думаю как его можно использовать вне браузера. Например написание wasm фильтров для Envoy. AssemblyScript был взят потому, что это не C++ и не Rust, т.е. ожидается более низкий порог вхождения. Под катом будет дико примитивный код и пару бенчмарков. Картинка взята из бенчмарка.
