Хотя понятие DevOps на слуху уже далеко не первый день, о нём до сих пор не прекращаются споры, начиная с вопроса «что это вообще такое». Словосочетание «DevOps-конференция» тоже порождает вопросы: например, если тут сходятся «dev» и «ops», то мероприятие рассчитано на зрителей с бэкграундом в разработке или в администрировании?
Есть круг людей, знающих обо всём этом не понаслышке: программный комитет нашей конференции DevOops, которая впервые пройдёт этой осенью в Петербурге. От них зависит, какими окажутся доклады на мероприятии, поэтому мы решили расспросить их и о DevOps, и о самой конференции — чтобы всем стало яснее, чего от неё ждать. В беседе поучаствовали:
- Барух Садогурский (JFrog)
- Олег Анастасьев (Одноклассники)
- Алексей Акопян (Dell EMC)
- Кирилл Толкачёв (Альфа-Лаборатория)
- Александр Тарасов (Одноклассники)
А в ходе обсуждения спонтанно возник вопрос к вам всем — так что при чтении этого текста вы можете ещё и лично повлиять на программу конференции!
JUG.ru: В связи с понятием «DevOps» можно увидеть споры. А у вас по таким вопросам солидарность, или есть внутренние дискуссии?
Барух Садогурский: По-моему, что такое DevOps, все уже давно определились.
Александр Тарасов: А по-моему, немного по-разному воспринимают до сих пор. У нас всех разный бэкграунд, и все мы видим разное. Как и с любым словом, которое является довольно большим обобщением. Безусловно, у людей есть общее понимание, но в деталях оно порой очень сильно разнится, а уж способов имплементации этой идеи на реальном ландшафте вообще зоопарк.
Барух: Я с тобой соглашусь в том, что если начинать говорить «окей, а как мы это делаем», то всё по-разному. Но как мне кажется, есть понимание общей идеи, таких вещей, как «you build it, you own it». А как именно это имплементировать, уже не так важно.
Александр: Часто DevOps понимают в узком смысле, когда developers — это именно разработчики, а operations — именно системные администраторы (а не сопровождение в целом, которое может быть разным). Но для меня это более широкое понятие: чтобы Continuous Delivery и прочие подобные вещи взлетали, как правило, требуется участие всей команды. Есть аналитики, тестировщики, есть сам процесс деплоймента, а после этого сопровождение в виде мониторингов и прочих штук. Хотя в самом слове «DevOps» нет ничего про QA, даже если просто открыть Википедию, сразу видишь на диаграмме три круга, одним из которых является QA.
JUG.ru: В девопсе сходятся разные стороны — а с какой приходит основная активность? От людей из разработки или из администрирования?
Барух: Большинство девопсников приходят со стороны администрирования. Грубо говоря, в чём наша задача в девопсе? Мы хотим, чтобы разработчики вместо перекидывания написанного на сисадминов могли всё это протаскивать прямо в продакшен, и если там это упало, то это их проблемы.
Это значит, что они должны научиться этой второй половине: грубо говоря, должны стать новыми сисадминами. Там совсем другой skill set, совсем другой набор инструментов, и так далее. Кто их может научить, кто может написать все приложения, которые им нужны, кто может построить автоматизацию внутри их конторы? Те самые бывшие администраторы, которых нынче порой называют devops engineers. То есть люди, которые приходят со стороны администрирования, становятся devops enablers, они настраивают все и инструменты и процессы, переучивают культуру, ходят и рассказывают, почему вам нужно теперь делать вот так — это все как раз бывшие админы. А бывшие программисты будут пользоваться вот этим всем, грубо говоря, для того, чтобы этот девопс выполнять.
Олег Анастасьев: А я вот в корне не соглашусь с Барухом, должна же быть интрига! Я скажу, что скорее наоборот: это движение идёт от программистов. Потому что админы до возникновения этого термина традиционно выполняли какие-то ручные процедуры, у них были свои процессы, свои инструкции, они их вручную или полускриптами решали. А программистам надоедает выполнять команды на машинах через админа, получается такой испорченный телефон: когда админ доходит до границы своей компетенции по поводу какого-то продукта, начинает программиста спрашивать. Программист сам не знает, что делать, и начинает командовать: ну посмотри, что в этой директории, а даты какие, а вот то что показывает, а это…
Раз на тридцатый такое выполнение команд через консоль скайпа задалбывает, и естественно, что программист хочет, с одной стороны, иметь больше контроля над продакшен-системой, а с другой — чтобы это не отнимало у него слишком много времени. А мы как программисты очень хорошо умеем писать всякие программки, и понаписали часть таких программок, которые нам облегчают жизнь, потом ещё понаписали, как-то это отмоделировали, архитектурку построили, ещё накрутили, здесь подкрутили — опа, и девопс получился. А потом научили админов, как им это всё завести, поставить и настроить, чтобы они тоже начинали получать бенефиты от этих программок.
Барух: Ну, Олег, я так подозреваю, что тут мы оба правы и необходимость возникает с обеих сторон, но популярные инструменты, про которые мы говорим (кроме CI-серверов, просто потому что они были созданы до девопса), всякие Infrastructure-as-a-Service, Chef, Ansible, тот же самый Docker и так далее — они созданы людьми из администрирования, а не разработки. То есть это их инструменты.
Олег: Ну, не знаю, у нас в Одноклассниках как-то наоборот. По перечисленным инструментам мне нечем аргументировать по поводу персоналий, я их просто не так хорошо знаю, но всё-таки мой пойнт в том, что если бы это было нужно только админам, то никто бы ничего и не делал. Здесь важно, что синергия получается тогда, когда у обоих лагерей есть свои бенефиты.
Барух: Я тут так скажу: это нужно бизнесу.
Алексей Акопян: Мне хочется добавить вот что. По-моему, важно, что в последнее время стало много сервисов, идущих на смену продуктам. Традиционно большую часть софтверного бизнеса составляли коробочные продукты, которые команда писала, затем отдавала в энном количестве заказчикам, они должны были где-то у себя разворачивать. Соответственно, нужны были инструкции, потому что админы сидели в первую очередь на стороне заказчика. А сейчас индустрия довольно сильно эволюционирует в сторону публичных сервисов (да и внутренних тоже). Соответственно, мы чаще сталкиваемся с тем, что есть сервис, с которым пользователи взаимодействуют зачастую через единственный размазанный в каком-нибудь облаке деплоймент, который надо поддерживать. И это, на мой взгляд, дало очень большой толчок всей идеологии девопса: совместное владение не кодом, а именно работающим сервисом.
JUG.ru: А что всё это означает применительно к конференциям? На кого в первую очередь рассчитана DevOops: людей с бэкграундом в разработке или администрировании?
Барух: Традиционно практически все западные девопс-конференции (вроде DevOps Days, DevOps Enterprise Summit и так далее) очень ориентированы на DevOps из администрирования. Они там обсуждают кишки своих инструментов и, грубо говоря, «как выдрессировать программистов, чтобы они делали правильный девопс».
И мне кажется, в нашей конференции интересно как раз то, что у нас будут и программисты. Основная аудитория всех конференций JUG.ru Group вообще программистская. Подход «даже если вы не админы, приходите на конференцию по девопсу» — он вообще всегда правильный, но для нас особенно правилен и интересен: во-первых, потому что это для нас естественная аудитория, а во-вторых, потому что это достаточно необычно для традиционных конференций по девопсу.
Александр: Я бы даже не стал ограничиваться «разработчиками и администраторами». Мне кажется, должно быть интересно большому кругу людей, которые в принципе интересуются вопросами автоматизации, улучшением организации процесса разработки и внедрения для ускорения доставки ценности клиенту, какие средства для этого можно сейчас использовать, и как они будут решать его проблему. Одним будет интересно послушать про хардкорную часть, «как сделать супермониторинг, который будет мониторить десять тысяч сервисов». Другим более интересны решения организационных проблем. Хотя у нас преобладают технические доклады, чаще всего проблемы в этой области — как технические, так и организационные, потому что в процессе участвует много сторон, каждая как с общими, так и со своими интересами.
JUG.ru: Уже по списку ключевых тем очевидно, что доклады действительно будут сурово техническими: везде сразу указаны конкретные инструменты. Не просто «Continuous Delivery», а с перечислением «Jenkins, TeamCity, Bamboo». А более общие выступления, не привязанные к конкретному продукту, предполагаются?
Барух: Мне кажется, тут есть две составляющих. Во-первых, разговоры про какой-то общий Continuous Delivery — они абстрактны, ни о чём. Это будет или что-то очень поверхностное, или что-то совершенно без конкретного приложения. А два наших основополагающих фактора при выборе докладов, как обычно с конференциями JUG.ru Group — во-первых, полезность, во-вторых, хардкорность. И какие-то общие доклады будут не особо полезны, не особо технологичны, не особо хардкорны.
Во-вторых, есть вопрос, который мы, на мой взгляд, пока что не решили. Из-за бэкграунда JUG.ru у нас заточенность под конкретные технологии и инструменты: кишочки, хардкор и технологии, а не soft skills и аджайл.
Но в приложении конкретно к девопсу это оказывается проблемой, потому что любой человек, реально имеющий к нему отношение, скажет вам, что инструменты и технологии в девопсе — не первое дело. Да, мы любим об этом говорить, и нам удобно об этом говорить: мы все технологи, программисты, нас немедленно туда тянет, давайте-ка посмотрим на конфиги.
Однако проблемы — они в поведении людей. Как изменить его так, чтобы из двух лагерей — программистов и админов — получился один процесс? И это у нас пока никто не затрагивает: во-первых, в принципе не очень понятно, как это затрагивать, а во-вторых, такой доклад по меркам JUG.ru будет заклеймён лайтовым и софт скиллзом.
Я надеюсь, что открывающий кейноут будет именно такой. По крайней мере, мой с Леонидом Игольником закрывающий кейноут будет не на 100% о технологиях. Но вопрос тут остаётся.
Кирилл Толкачёв: Ещё на других конференциях бывают доклады, которые можно назвать BizOps. Условно, я как начальник большой компании рассказываю про плюсы внедрения девопса в своей компании с цифрами, объясняющими формулу успеха. Слушайте, а мы вот такое хотим?
Барух: Очень зависит от доклада. Как раз к моему стону по поводу того, что у нас из треугольника «people-process-tools» сплошные tools: вот такой доклад бы очень здорово привнёс people и process, если бы это была не просто болтовня «я сказал моим подчинённым, и они сначала были против...», а именно с выкладками, числами, с процессами, что изменилось, кого уволили, а кого наняли. Вот это всё, мне кажется, было бы не просто хороший доклад, а прекрасный кейноут.
Александр: Это интересный взгляд со стороны, с upper-level. Очень часто люди, которые работают на рядовых позициях, просто не понимают, какие там проблемы могут быть и почему в крупных компаниях принимаются те или иные решения, которые с первого взгляда кажутся нелогичными. Если об этом красиво и хорошо рассказать, то может получиться очень интересно.
Барух: А может быть, сделать какой-то парный доклад? Грубо говоря, кто-то достаточно высокого уровня со стороны бизнеса, кто-то со стороны разработки. И показать вот эту дискуссию: с одной стороны, как разработчикам уговорить начальство, а с другой стороны, как начальству тяжело с разработчиками? Или даже собрать нескольких людей C-level и устроить панельную дискуссию?
Алексей: А можем сделать опрос на тему того, будет нашей аудитории интересна такая дискуссия?
JUG.ru: Да не вопрос. Читатели, у которых есть мнение по этому поводу — пожалуйста, пройдите по ссылке и ткните в один из вариантов, вы поможете нам сделать конференцию лучше.
Возвращаясь к «доклады привязаны к инструменту»: а докладчиками будут преимущественно те, кто эти инструменты активно использует, или и те, кто их создаёт?
Барух: Есть разные случаи. У нас есть докладчики из компании HashiCorp, производящей очень большое количество очень хороших продуктов для девопса, которые мы все любим. У нас, надеюсь, будет один из разработчиков Google Cloud Platform — их, естественно, тоже очень любят. Будет даже человек, который имел отношение к разработке JFrog Artifactory, поверите вы или нет!
JUG.ru: В связи с тем, что ты сам работаешь в JFrog, и с тем, что некоторые другие спикеры будут представлять собственные проекты, небось найдутся желающие сказать «да будет сплошной ужасный маркетинг, никакой пользы». Хочется на это что-то ответить?
Барух: Ну, само собой разумеется, что мы стремимся делать доклады максимально глубокими и интересными, а ни в коем случае не каким-то рекламным product pitch. Доклады выбираются по своей технической составляющией, мы делаем прогоны и репетиции, чтобы быть уверенными, что они не будут product pitch. Те, кто был на других конференциях JUG.ru Group, в этом уже могли убедиться.
Но определённые люди считают, что если ты представляешь фирму и упоминаешь название её продукта в докладе, то совершенно не важно, что ты о нём говоришь, ты представитель зла и тебя надо закидывать помидорами. Извините, наболело!
Скажу так: если ты какой-либо проект использовал или планируешь использовать, то доклад об этом проекте на DevOops тебе будет интересен и полезен. Если не используешь и использовать не думаешь, то ты на этот доклад просто не идёшь. У нас будет несколько треков, всегда можно выбрать. Но я не сомневаюсь, что если человек использует Terraform или Packer, то он с огромным удовольствием пойдёт на доклад человека, который работает в HashiCorp.
И ещё благодаря тому, что конференция в России, мы более-менее защищены от натиска желающих порекламироваться. В России пока что недостаточно развита разработка продуктов для девопса. У нас практически нет кого-то, кто подаётся сам «вот я вам хочу рассказать про свой продукт». Большинство продуктов, которые будут обсуждаться на этой конференции — и CI-сервера, и средства развёртки, и виртуализация — разработаны за рубежом. И поэтому докладчик из этой компании может к нам попасть, только если мы сами его приглашаем. А когда мы его приглашаем, естественно, принимаем все необходимые меры, чтобы гарантировать, что это не будет product pitch.
Александр: Бывают ещё случаи, когда человек вроде и не особенно топит за технологию, но доклад оставляет сахарно-ватное ощущение, что всё так замечательно, прям бери и будет сразу работать, никаких подводных камней… Как правило, такие доклады относятся к категории «101», это обзорные доклады, или доклады начального уровня. Они полезны людям, которые ничего не знают про данную технологию или знают очень мало.
А тем, кто уже сам что-то изучает, использует в продакшене, более интересны внутренние детали реализации и особенно подводные камни. Поэтому очень здорово, если докладчик не только хорошо знает свой продукт, библиотеку, технологию и рассказывает позитивные стороны, но и знает проблемы пользователей и может рассказать про различного рода трейд-оффы, которые есть в любом инженерном решении.
JUG.ru: На других конференциях JUG.ru, например, Joker, уже были «околодевопсные» доклады. Что происходит теперь, когда появилась отдельная конференция — они все переезжают туда, или на Joker такие по-прежнему можно будет увидеть?
Барух: Это очень хороший вопрос, который я, будучи в программном комитете обеих конференций, вижу с обеих сторон.
С одной стороны, да, существует большое желание все девопсные доклады в DevOops. Но, с другой стороны, когда тема интересная, не хочется человека, который придёт только на Joker и не собирался идти на DevOops, оставить без этих тем вообще. Поэтому мы стараемся те доклады, которые имеют отношение и к девопсу, и к Java, оставить на Joker, а на DevOops принести те, которые к Java не имеют отношения.
Олег: Добавлю, что даже если темы на двух конференциях окажутся одинаковыми, то на DevOops они будут в большей степени про процессы и какие-то менеджмент-операционные части, а на Joker будут больше в хардкор и программирование. Тема та же, но рассматриваться будет с разных сторон.
JUG.ru: Спасибо за ответы. Хочется ли ещё что-то добавить?
Алексей: Что после DevOops сбор фидбэка поможет нам ответить на все те же вопросы к следующей конференции. Поймём на практике, чего тем людям, которые реально пришли, хватило на DevOops, а чего не хватило.
JUG.ru: То есть от людей, которые придут на первую конференцию, очень зависит, какой станет вторая? Хороший стимул идти.
DevOops впервые состоится 20 октября в Санкт-Петербурге, билеты уже в продаже (и дорожают со временем!). Ключевые темы:
— Контейнеры, Оркестрация (Docker, Kubernetes, Clusters, etc).
— Виртуализация, Облачные технологии (AWS, Azure, Heroku и другие).
— Мониторинг и аудит приложений (Prometeus, OkMeter, DataDog, BPF, Dynatrace, XRebel, Glimpse, Zipkin, OpenTrace и другие).
— Continuous Delivery (Jenkins, TeamCity, Bamboo).
— Configuration Management (puppet, chef, ansible).
— Security (Vault, etc.)
— Разбор полетов на примерах крупных проектов, внедряющих DevOps: успешных и провальных.
Автор: phillennium
