Барух Садогурский — заморский гость и частый спикер на минских конференциях: он уже был в Минске зимой и планирует приехать снова. Обычно его представляют как гуру DevOps и Developer Advocate в JFrog. На его доклады собирается полный зал слушателей, потому что он устраивает целый спектакль в стиле греческой трагедии или расследования преступления.

Читать далее...

Трагедия в трёх актах

Барух, вы уже приезжали в Беларусь из Калифорнии. О чём рассказывали белорусским айтишникам?

Один из докладов, например, назывался так: «DevOps в масштабе — греческая трагедия в трёх актах». На сцену мы с напарником вышли в тогах и рассказывали о масштабировании разработки от 3 до 100 инженеров: какие этапы предстоит при этом пройти и какие проблемы могут появиться на каждом из них. Нам обоих DevOps в масштабе напоминает классический сценарий: завязка, кульминация, развязка. В конце все умирают — всё как мы любим.

В другом докладе «Data Driven DevOps» была техасская, а точнее «кремниево-долинная» резня бензопилой. Там были ужасы и расчленёнка: что делать, когда в три часа ночи проект горит и рушится. Это нишевый доклад про ИТ-дежурство: о том, как правильно выстроить трансформацию DevOps культуры и её измерить, какие данные для этого нужны, какие грабли могут встретиться и как их обойти.

Для чего устраиваете на сцене целое театральное представление? Это способствует усвоению информации?

Мы стараемся вносить какую-то фишку, чтобы доклады не были сухими и скучными. От этого и нам, докладчикам, веселее, и зрителям интереснее, когда доклад с изюминкой. Обычно названия приходят спонтанно. Например, «Data Driven DevOps» мы придумали на барбекю, когда пекли стейки. Сначала мы тыкали мясо вилкой, чтобы понять, прожарилось оно или нет, а потом у нас появился термометр. И бац — это же Data Driven! Мы можем на основе данных (времени и температуры) принять решение, убирать стейк с огня или нет.

Для java-конференции, например, у нас есть доклад в жанре детектива. Поиск решения какой-то проблемы напомнил нам расследование преступления, в стиле Шерлока Холмса и доктора Ватсона.

Какие вопросы задают белорусские айтишники?

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

Один из ваших докладов посвящён DevOps культуре. Что такое DevOps культура и как её измерить?

Это сочетание трёх вещей: Ops, Dev и QA. Можно настроить уйму инструментов, но если разработчик считает, что его работа закончилась, как только он перестал писать код, то никакого DevOps не будет. Здесь нет такого: я написал код и точка — забирайте, тестируйте, выкатывайте в продакшн — меня это уже не интересует. Тот, кто написал код, ответственен за его качество, развёртку, поддержку, фидбэк. И это больше культурное изменение, чем техническое.

Меряется эта культура по результатам работы. Мы объединяем несколько дисциплин, поэтому у нас получается междисциплинарный метод измерения.

Бывают метрики, за которые отвечает один отдел, а влияют они на другой. Например, у нас нестабильная среда разработки. Кто за неё отвечает? Казалось бы, QA (по старому подходу). Кто от этого страдает? — разработчики, которые пишут тесты для нестабильной среды.

Бог, идол и космос DevOps — Келси Хайтауэр из Google

В какой момент вы заинтересовались DevOps?

Начинали мы 10 лет назад с разработки инструментов для программистов. Потом появился DevOps, и выяснилось, что наши инструменты для построения пайплайнов нужнее DevOps-специалистам, чем разработчикам. Как программисты пользуются нашими инструментами? Нужен им, скажем, репозиторий для их артефактов. Они берут опенсорсное решение и используют его «из коробки». А у DevOps-команды совсем другие требования, потому что она обслуживает всю компанию, с несколькими, как правило, дата-центрами. У неё другие проблемы, ей нужно больше помощи от нас, да и нам с ней интереснее.

Вы в ИТ уже более 18 лет, прошли путь от девелопера и архитектора до консультанта и евангелиста. Считаете ли, что уже реализовались?

Мне кажется, что свой путь в Developer Advocate я только начинаю. Если говорить о карьерном потолке, то здесь, наверное, его не существует. Каждый раз я открываю новые горизонты. Есть эксперты, лидеры мнений, на которых можно равняться. Что касается DevOps, то у нас есть всеобщий бог, идол — Келси Хайтауэр из Google. Это вообще космос, до которого ещё расти и расти.

Чему вы посвящаете больше времени: общаетесь с девелоперами и сисадминами, пишете код или выступаете на конференциях?

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

Вас продолжает плавно уносить от технологий в сторону бизнеса и психологии?

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

Я почти не бываю на конференциях, где я не спикер, потому что то количество мероприятий, на которых я выступаю, покрывает всё.

Не очень sexy аспект разработки

Вы работаете в компании, которая занимается разработкой инструментов для DevOps. По сути, вы помогаете ИТ-компаниям быстрее разрабатывать ПО?

Мы занимаемся необходимым, но не очень sexy аспектом разработки в DevOps. Если сравнивать нашу деятельность с каждодневными предметами, то, можно сказать, мы делаем трубы. Надеюсь, что не для канализации, а для воды. Такие вещи нужны всем, но обычно никто не хочет ими заниматься.

У нас есть набор инструментов для работы с артефактами, бинарными файлами, дистрибуции ПО. Например, JFrog Artifactory — универсальный менеджер хранилищ, поддерживающий все основные форматы упаковки, инструменты сборки и серверы CI. Bintray — масштабируемый сервис в облаке.

Пайплайн, о котором сейчас так часто говорят, происходит как раз в тех самых «трубах», которыми мы занимаемся.

У вас достаточно необычная позиция — Developer Advocate. Это что-то вроде защитника и адвоката компании?

Это такая должность «эйчара», который занимается техническим PR. Я езжу по конференциям — за прошлый год их было около 40 — и рассказываю разработчикам про инструменты и решения, которые у нас есть. Не просто «вот мы в JFrog такие крутые», а «у нас есть то, что поможет решить ваши проблемы». Если мне встречается команда, проблемы которой я не могу решить нашими тулами, я всё равно стараюсь ей помочь. Иногда даже предлагаю продукты конкурентов.

Какие компании могут позволить себе нанять Developer Advocate — и главное, нуждаются в нём? Зависит это, видимо, не от размера компании?

Зависит это от аудитории, к которой компания обращается. Традиционный маркетинг, даже Digital, не работает в случае с разработчиками. Любой айтишник подтвердит, что рассылки или телефонные звонки — это худшее, что может быть. Нанимать Developer Advocate на ранней стадии нужно компаниям, которые предлагают решения для разработчиков. Сначала этим занимаются фаундеры и разработчики, а потом вырастает отдельная функция. JFrog существует уже 9 лет, и 7 из них в компании есть девелопер-адвокат.

Фото: Андрей Давыдчик