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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Меня зовут Семён Факторович, с 2012 года я занимаюсь технической документацией. Последние три года я руковожу собственным агентством documentat.io, помогая российским IT-компаниям создавать качественную документацию.

Мы пишем документацию с нуля (руководства пользователя, справочники API, архитектурную документацию) и поддерживаем уже имеющуюся и проводим консультации по настройке документационных процессов. И почти каждый запрос от наших клиентов начинается с признания: «Кажется, с нашей документацией что-то не так».

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

1) Документация полностью отсутствует.
2) Документацию неохотно пишут.
3) Документацию неохотно читают.
4) Документация есть, ее пишут и читают, но она кажется бесполезной.

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

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

Дмитрий Костюк совмещает преподавание в университете и работу в Percona. А еще он активно занимается организацией опенсорс-конференций, инфраструктурой GNU/Linux, базами данных с открытым исходным кодом и эргономикой графического интерфейса и UI/UX. На TestDriven Conf вместе с Дмитрием разберёмся, как биометрические гаджеты помогают в usability-тестах. 

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

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

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

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

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

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

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

Но статья будет не про сравнение систем мониторинга или методов, а про простые практики, которые каждый из вас может применить. Про здравый смысл в применении этих практик. И про опыт ЦФТ — про те боль и проблемы, с которыми столкнулась компания, как их решала и к чему в итоге пришла. Эта история о том, как перестроить процессы внутри компании, чтобы мониторинг перестал быть стихийным и стал актуальным и управляемым.

Нормально делай — нормально будет, и Виталий Медведев, инженер по автоматизации ЦФТ, разделяет эту истину. Эта статья написана по его выступлению на конференции Saint HighLoad 2021.

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

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

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

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

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

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

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

Мы с Аней не тестировщики. Мы относимся к эволюционирующему классу IT-специалистов — системным администраторам или operations-инженерам. Но в нашей повседневной жизни мы тоже не обходимся без тестов. И сегодня мы хотим немного поговорить про Splunk. Точнее, вся наша статья будет именно про него.

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

100% персонала нанимается, вы их приводите в команду через найм, через собеседования. Но многие тимлиды считают, что создание команды с необходимыми компетенциями — исключительно задача HR. Но даже если они вместе пригласили кандидата и провели собеседование — не факт, что человек выберет именно эту команду и присоединится к ней.

Не все тилиды не знают, как можно сообща с эйчаром проводить собеседования, чтобы было интересно кандидату и полезно команде. Я хочу рассказать, как можно им вместе провести действительно классное собеседование. Моя статья основана на опыте 200+ собеседований, которые я провел, чтобы отдел из 40 с лишним человек в ЦФТ.

О роли формата JSON в эволюции реляционных баз данных я недавно рассказал на двух конференциях — HighLoad++ и Saint HighLoad++ 2021. А также о том, что мешает эффективно использовать JSONB (бинарный JSON)  и как с этим можно бороться.

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