Привет! Сегодня я хочу познакомить вас с ПО, которое мы разрабатываем в нашей компанией — кластерной СУБД и сервером приложений на языке Rust. Мы профессионально занимаемся созданием и эксплуатацией решений на основе Tarantool и с некоторых пор начали разработку своего ПО, о котором и пойдёт речь.

Picodata — это дальнейшее развитие истории Tarantool, в которой учтен опыт эксплуатации этой СУБД и предложены решения как архитектурных, так и функциональных недостатков открытой версии Tarantool. Также, наше ПО проще запускать, настраивать и поддерживать в рабочем состоянии благодаря единой точке входа и интеграции всего инструментария в одном исполняемом файле. Мы создавали Picodata как изначально кластерную СУБД, которой удобно пользоваться. Если не верите, что российская СУБД может быть удобной, попробуйте — в конце этой статьи есть раздел Практикум, где можно сразу же попробовать собрать кластер самому на паре-тройке виртуальных машин или на вашем локальном компьютере. Сейчас же будет немного теории о том, как вообще работает распределенный кластер, что именно не так в “ванильном” Tarantool и что нам пришлось сделать чтобы это исправить.

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

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

В своем докладе на конференции TestDriven Conf 2022 Станислав Васенков предлагает за минуту создать из ручного теста проект с автотестами в боевой инфраструктуре. О том, как разрабатывался генератор, можно узнать из интервью.

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

Однажды мне повезло попасть на запредельно крутой митап. Сотрудники одной компании объединились вокруг своего интереса и с завидным постоянством встречались для его обсуждения. У них было всё серьёзно, для каждой встречи собирали статистику, сколько человек к ним присоединилось, а сколько — пришло, но по какой-то причине ушло и не вернулось. На несколько месяцев вперед у них были расписаны темы, о чем поговорить. В общем, они были великолепны!

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

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

Tarantool, как известно, поддерживает любой язык, который совместим с C и компилируется в машинный код. В том числе есть возможность реализации хранимых функций и модулей на Lua и C. Тем не менее, уже в двух своих проектах мы использовали Rust (в одном полностью перенесли Lua-код на Rust) и получили 5-кратное увеличение производительности по сравнению с Lua и сопоставимый результат, который дает по производительности C.

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

Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.

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

Первоначально сегменты создавались вручную: поступал запрос от заказчика, после чего проводилась аналитическая работа по сбору требований. Количество заявок на создание сегментов со временем только увеличивалось. Чтобы автоматизировать процесс создания сегментов мы решили сделать конструктор сегментов для DMP — Data Management Platform. Это относительно молодой проект, ему чуть больше двух лет, но он полностью себя оправдал. Сегодня расскажу вам о нашем опыте. Меня зовут Евгений Чмель, и я руковожу командой DMP & CDP.

Когда тренер Ливерпуля Юрген Клопп, который сделал команду чемпионом Англии и победителем Лиги Чемпионов, только появился в команде, то в первую очередь он встретился с начальником академии Ливерпуля. Почему?  Потому что Клопп, как тимлид, знает, кто будет играть у него в команде и какие требования к ним он предъявляет. Самым важным для него было рассказать об этом начальнику академии, чтобы тот знал, как воспитывать игроков для Клоппа.

А как, думаете, с этим обстоит дело в мире SW development? Мы с завидным постоянством пытаемся отдать работу с молодыми специалистами — ребятами, которые учатся в университетах —  на откуп рекрутерам. И считаем, что только они должны заниматься сотрудничеством с вузами.

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

PaaS (Platform as a Service) — внутренняя платформа для запуска и разработки приложений. Если коротко, то наш PaaS позволяет легко и, можно сказать, при нулевом знании внутренней кухни создать свой сервис и начать пилить продуктовые компоненты. Более длинное объяснение — в этом видео. Под катом небольшой рассказ о том, с какими проблемами пришлось столкнуться при первом приближении к тестированию продукта, как происходил сам процесс тестирования платформенных решений на примерах и какую пользу это принесло.

Меня зовут Лариса Седнина, я работаю QA-инженером в Авито в юните QA Center of Excellence. Наш юнит — это центр экспертизы по обеспечению качества, основная задача которого в распространении лучших практик тестирования, помощи в настройке процесса тестирования и разработке инструментов для тестирования.

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

Но давайте по порядку. Меня зовут Александр Клюшкин. Я работаю в Самокате и на нашем примере расскажу о сложностях перехода на новый стек. Зачем и кому это может понадобиться?

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

Чтобы проще и быстрее понимать взаимосвязи между системами, и легко оптимизировать то, что уже было, вам прекрасно подойдет distributed tracing. Но как его выбрать, внедрить и не собрать все грабли?

Безкоровайный Денис, директор подразделения DevOps/DevSecOps в Proto Group и Панычев Дмитрий, руководитель разработки ряда достаточно запутанных проектов в Vprok.ru Перекресток, на конференции DevOps 2021 на примерах показали, как distributed tracing помог им решить бизнес-задачи. Читайте под катом, как они выбирали решение для distributed tracing и обходили грабли.

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

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

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

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

На одной конференции мне задали вопрос (спасибо Александру!): как сделать стрим в PostgreSQL? Представьте, что имеется bytea и вы к нему хотите что-то дописать. Люди столкнулись с тем, что на это в PostgreSQL  тратится гигантское время  и растет WAL-трафик. 

Расскажу, что с этим возможно сделать — это будет еще один пример оптимизации TOAST (о чем я недавно писал), на на этот раз — для быстрой записи потока бинарных данных. На самом деле мой коллега, Никита Глухов, за несколько часов сделал расширение, которое «вылечило» проблему, и мы даже успели рассказать про это на сессии блиц-докладов на PGConf.Online 2021.

В PostgreSQL есть два типа данных: JSON и JSONB. Первый формат является текстовым хранилищем, в котором json хранится "as is",  второй — бинарным, в нем ключи отсортированы  (сначала по длине ключа, а потом по его названию), дубликаты удалены, а пробелы удалены.

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

Однако у постгреса есть серьёзная проблема, которая сказывается и на производительности JSONB  — это TOAST, и о ней я говорил в первой части. Сегодня я расскажу о том, как мы улучшили JSONB для того, чтобы существенно повысить его производительность.

В Ozon поступают сотни тысяч заказов в день — при таком масштабе у пользователей неизбежно возникают очень разнообразные вопросы, которые они пишут в чат поддержки: как оплатить баллами «Спасибо», как вернуть не понравившуюся кофту или есть ли доставка в Норильск. При этом большинство вопросов в поддержку однотипны, а ответа пользователи ожидают мгновенно и в любое время суток. 

Чтобы отвечать на все эти вопросы, в Ozon есть несколько тысяч сотрудников КЦ в Твери и Тамбове, но даже при таком количестве специалистов им нужна помощь, в первую очередь по ответам на часто повторяющиеся вопросы. И самое очевидное решение — автоматизация с помощью чат-бота.

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

Данная статья — взгляд на то, как Kubernetes способен повысить уровень безопасности, упростив управление ею и ускорив внедрение механизмов безопасности с точки зрения специалиста по ИБ, который большую часть своей карьеры занимался наступательной безопасностью. Сейчас на примере Kubernetes я вижу, что на нем можно организовать так называемую self defense (самозащищающуюся) систему.

Меня зовут Дмитрий Евдокимов, я founder и CTO компании Лантри, а кто-то может меня лучше знать, как автора каналаk8s (in)security. Про безопасность я буду говорить, исходя из моего опыта, как человека, который десять лет атаковал различные системы, реализуя угрозы и риски. Ссылка на мое выступление на конференции DevOps Conf 2021 будет в конце статьи.

Это история о том, как увеличить скорость выкатки фич, но сохранить качество продукта. О болевых точках, которые замедляют разработку, и новой «болезни» — микросервисе головного мозга, которую диагностировал Михаил Трифонов, техлид фронтов в SberСloud. Он утверждает, что она приводит к росту функциональности ML Space на 683% при увеличении команды разработки всего в 2 раза. Невероятно, но бизнес-аналитика это подтверждает. Так что давайте разбираться по порядку.

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

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