DevOops , который впервые пройдет этой осенью в Санкт-Петербурге.
От них зависит, какие будут доклады на мероприятии, поэтому мы решили расспросить их и о DevOps, и о самой конференции — чтобы всем стало понятнее, чего от нее ожидать.
Участники беседы:
- Барух Садогурский (ДжейФрог)
- Олег Анастасьев (Одноклассники)
- Алексей Акопян (Делл ЭМС)
- Кирилл Толкачев (Альфа-лаборатория)
- Александр Тарасов (Одноклассники)
Есть ли у вас солидарность по таким вопросам или есть внутренние дискуссии? 
Барух Садогурский: По-моему, все уже давно определились, что такое DevOps. 
Александр Тарасов: Но, на мой взгляд, они все же воспринимают это немного по-другому.
У всех нас разное прошлое, и мы все видим вещи по-разному.
Как и любое слово, это довольно большое обобщение.
Конечно, понимание у людей общее, но иногда оно сильно различается в деталях, а способов реализации этой идеи на реальном ландшафте – полный зоопарк.
Барух: Я с вами согласен, что если вы начнете говорить «окей, а как нам это сделать», то все будет по-другому.
Но мне кажется, есть понимание общей идеи, таких вещей, как «ты строишь — ты этим владеешь».
Но как именно это реализуется, уже не так важно.
Александр: DevOps часто понимают в узком смысле, когда разработчики — это именно разработчики, а операторы — именно системные администраторы (а не сопровождение в целом, которое может быть разным).
Но для меня это более широкое понятие: чтобы Continuous Delivery и другие подобные вещи взлетели, как правило, требуется участие всей команды.
Есть аналитики, тестировщики, есть сам процесс развертывания, а после этого поддержка в виде мониторинга и прочего.
Хотя само слово «DevOps» ничего о QA не содержит, даже если вы просто откроете Википедию, вы сразу увидите на схеме три кружка, один из которых — QA. 
JUG.ru: В девопсе сходятся разные стороны — и от кого исходит основная деятельность? От людей из разработки или из администрации? Барух: Большинство разработчиков приходят со стороны администрации.
Грубо говоря, какая у нас задача в devops? Мы хотим, чтобы разработчики, вместо того, чтобы кидать написанное сисадминам, могли тащить это всё прямиком в продакшен, и если там не получится, то это их проблемы.
Это значит, что они должны выучить эту вторую половину: грубо говоря, они должны стать новыми сисадминами.
Там совершенно другой набор навыков, совершенно другой набор инструментов и так далее.
Кто сможет их научить, кто сможет написать все необходимые им приложения, кто сможет автоматизировать свой офис? Те самые бывшие администраторы, которых сейчас иногда называют devops-инженерами.
То есть люди, которые приходят со стороны администрирования, становятся devops-активаторами, они все настраивают, инструменты и процессы, переучивают культуру, ходят и рассказывают, почему теперь нужно делать такие вещи — это все бывшие администраторы.
И все это бывшие программисты будут использовать, грубо говоря, для того, чтобы провести этот девопс.
Олег Анастасьев: Но я в корне не согласен с Барухом, интрига должна быть! Я скажу, что скорее наоборот: это движение исходит от программистов.
Потому что до появления этого термина админы традиционно выполняли какие-то ручные процедуры, у них были свои процессы, свои инструкции, они решали их вручную или полускриптами.
А программистам надоедает выполнять команды на машинах через админа, и в результате получается такой сломанный телефон: когда админ достигает предела своей компетенции относительно определенного продукта, он начинает спрашивать программиста.
Программист сам не знает, что делать, и начинает командовать: ну посмотрите, что в этом каталоге, и какие даты, и вот что он показывает, и это.
Каждый тридцатый раз такое выполнение команд через консоль Skype приедается, и естественно, программисту хочется, с одной стороны, иметь больше контроля над продакшн-системой, а с другой, чтобы это не занимало слишком много времени.
своего времени.
А мы, как программисты, очень хорошо умеем писать всякие программы, и написали некоторые из этих программ, которые облегчают нам жизнь, потом написали еще, как-то смоделировали, построили архитектуру, еще раз подправили, подправили здесь — упс, и девопс получился.
А потом научили админов как это все настроить, установить и настроить, чтобы они тоже начали получать пользу от этих программ.
Барух: Ну Олег, я подозреваю, что тут мы оба правы и необходимость возникает с обеих сторон, но популярные инструменты, о которых мы говорим (кроме CI-серверов, просто потому, что они созданы до девопса) - это всякие Инфраструктуры-как- -Service, Chef, Ansible, тот же Docker и так далее — их создавали люди из администрирования, а не разработки.
То есть это их инструменты.
Олег: Ну не знаю, в Одноклассниках как-то наоборот. По поводу перечисленных инструментов, насчет личностей мне нечего спорить, просто я не так уж хорошо их знаю, но все же моя точка зрения такова, что если бы это было нужно только админам, то никто бы ничего не делал.
Здесь важно, что синергия возникает тогда, когда оба лагеря имеют свои выгоды.
Барух: Я скажу так: бизнесу это нужно.
Алексей Акопян: Я хотел бы добавить это.
На мой взгляд немаловажно, что в последнее время появилось много сервисов, заменяющих продукты.
Традиционно большая часть бизнеса по разработке программного обеспечения состояла из пакетных продуктов, которые команда писала, а затем в определенных количествах передавала клиентам; их нужно было где-то разместить.
Соответственно, инструкции были необходимы, ведь администраторы сидели в первую очередь на стороне заказчика.
И сейчас отрасль довольно сильно развивается в сторону государственных услуг (и внутренних тоже).
Соответственно, мы чаще сталкиваемся с тем, что существует сервис, с которым пользователи часто взаимодействуют посредством единого развертывания, разложенного в каком-то облаке, которое необходимо поддерживать.
И это, на мой взгляд, дало очень большой толчок всей идеологии devops: совместное владение не кодом, а работающим сервисом.
JUG.ru: Что все это значит применительно к конференциям? На кого в первую очередь ориентирован DevOops: на людей с опытом разработки или администрирования? Барух: Традиционно почти все западные конференции по DevOps (например, DevOps Days, DevOps Enterprise Summit и т. д.) уделяют большое внимание DevOps со стороны администрирования.
Они там обсуждают внутренности своих инструментов и, грубо говоря, «как обучать программистов, чтобы они делали правильный DevOps».
И мне кажется, что интересно в нашей конференции то, что у нас будут еще и программисты.
Основная аудитория всех конференций JUG.ru Group — это, как правило, программисты.
Подход «даже если ты не админ, приходи на девопс-конференцию» в целом всегда верен, но для нас он особенно правилен и интересен: во-первых, потому что для нас это естественная аудитория, во-вторых, потому что она достаточно необычна.
для традиционных DevOps-конференций.
Александр: Я бы даже не ограничивался «разработчиками и администраторами».
Мне кажется, что большому кругу людей, которые в принципе интересуются вопросами автоматизации, совершенствования организации процесса разработки и внедрения, должно быть интересно, какие инструменты можно теперь будут использованы для этого, и как они решат его проблему.
Некоторым будет интересно услышать про хардкорную часть, «как сделать супермониторинг, который будет мониторить десять тысяч сервисов».
Другие больше заинтересованы в решении организационных проблем.
Хотя у нас и преобладают технические отчеты, чаще всего проблемы в этой сфере носят как технический, так и организационный характер, поскольку в процесс вовлечено множество сторон, каждая из которых имеет как общие, так и индивидуальные интересы.
JUG.ru: Уже из списка ключевых тем очевидно, что доклады действительно будут сугубо техническими: везде сразу указаны конкретные инструменты.
Не просто «Непрерывная доставка», а со списком «Дженкинс, TeamCity, Bamboo».
Ожидаются ли более общие презентации, привязанные к конкретному продукту? Барух: Мне кажется, здесь есть две составляющие.
Во-первых, разговоры о какой-то всеобщей Continuous Delivery абстрактны, ни о чем.
Это будет либо что-то очень поверхностное, либо что-то совершенно без конкретного применения.
И два наших основополагающих фактора при выборе докладов, как обычно на конференциях JUG.ru Group, — это во-первых, полезность, во-вторых, хардкорность.
А какие-то общие отчеты будут не особо полезны, не особо технологичны, не особо хардкорны.
Во-вторых, есть вопрос, который, на мой взгляд, мы еще не решили.
Из-за опыта JUG.ru мы фокусируемся на конкретных технологиях и инструментах: смелости, хардкоре и технологиях, а не на мягких навыках и гибкости.
Но применительно именно к devops это оказывается проблемой, потому что любой человек, который действительно этим занимается, скажет вам, что инструменты и технологии в devops — это не главное.
Да, мы любим об этом говорить, и нам удобно об этом говорить: мы все технологи, программисты, нас сразу туда тянет, посмотрим конфиги.
Однако проблемы заключаются в поведении людей.
Как изменить это, чтобы два лагеря — программистов и администраторов — стали одним процессом? И этого пока никто не касается: во-первых, в принципе не очень понятно, как это касаться, а во-вторых, такой отчет, по меркам JUG.ru, будет заклеймён лайт- и софт-скиллами.
Я надеюсь, что вступительная речь будет именно такой.
По крайней мере, мой заключительный доклад с Леонидом Игольником не будет на 100% посвящен технологиям.
Но вопрос остается.
Кирилл Толкачев: Есть доклады и на других конференциях, которые можно назвать BizOps. Условно, как руководитель крупной компании, я рассказываю о преимуществах внедрения devops в своей компании с цифрами, объясняющими формулу успеха.
Слушай, это то, чего мы хотим? Барух: Многое зависит от отчета.
Как раз к моему стону по поводу того, что наш треугольник «люди-процесс-инструменты» — это все инструменты: такой отчет очень хорошо свел бы людей и процессы, если бы это не была просто болтовня» Я сказал своим подчиненным, и они сначала были против.
», а именно с расчетами, цифрами, процессами, что изменилось, кого уволили и кого взяли на работу.
Все это, мне кажется, было бы не просто хорошим докладом, а прекрасным докладом.
Александр: Интересный вид снаружи, с верхнего уровня.
Очень часто люди, работающие на обычных должностях, просто не понимают, какие могут быть проблемы и почему крупные компании принимают те или иные решения, которые на первый взгляд кажутся нелогичными.
Если об этом красиво и хорошо рассказать, то может получиться очень интересно.
Барух: А может быть сделать какой-то парный отчет? Грубо говоря, кто-то достаточно высокого уровня со стороны бизнеса, кто-то со стороны разработки.
И покажите эту дискуссию: с одной стороны, как разработчикам уговорить начальство, а с другой — насколько сложно руководству с разработчиками? Или даже собрать вместе нескольких людей высшего звена и провести групповую дискуссию? Алексей: Можем ли мы провести опрос, будет ли нашей аудитории интересна такая дискуссия? JUG.ru: Без вопросов.
Читатели, у которых есть мнение по этому поводу - пожалуйста, зайдите на связь и нажмите на один из вариантов, вы поможете нам сделать конференцию лучше.
Возвращаясь к «отчеты привязаны к инструменту»: спикерами будут в основном те, кто эти инструменты активно использует, или те, кто их создает? Барух: Бывают разные случаи.
У нас есть докладчики из HashiCorp, компании, которая производит множество очень хороших DevOps-продуктов, которые мы все любим.
У нас, надеюсь, будет один из разработчиков Google Cloud Platform — они, естественно, тоже очень популярны.
Хотите верьте, хотите нет, найдется даже человек, принимавший участие в разработке JFrog Artifactory! JUG.ru: Ввиду того, что вы сами работаете в JFrog, и того, что некоторые другие спикеры представят свои проекты, наверняка найдутся те, кто захочет сказать «пусть это будет сплошной ужасный маркетинг, никакой пользы».
Вы хотите на это ответить? Барух: Ну и само собой разумеется, что мы стремимся сделать доклады максимально глубокими и интересными, и ни в коем случае не какой-то рекламной презентацией продукта.
Отчеты отбираются по их технической составляющей, мы делаем прогоны и репетиции, чтобы быть уверенными, что они не будут презентацией продукта.
В этом уже могли убедиться те, кто был на других конференциях JUG.ru Group. Но некоторые люди считают, что если ты представляешь компанию и упоминаешь в отчете название ее продукта, то не важно, что ты о нем говоришь, ты представитель зла и тебя следует закидать помидорами.
Извините, это больно! Скажу так: если вы использовали или планируете использовать какой-либо проект, то отчет об этом проекте на DevOops будет вам интересен и полезен.
Если вы им не пользуетесь и не думаете об использовании, то вы просто не зайдете в этот отчет. У нас будет несколько треков, вы всегда сможете выбрать.
Но я не сомневаюсь, что если человек использует Terraform или Packer, он будет очень рад присутствовать на выступлении человека, который работает в HashiCorp. А еще благодаря тому, что конференция проходит в России, мы более-менее защищены от натиска желающих разместить рекламу.
В России разработка продуктов для devops еще недостаточно развита.
У нас практически нет никого, кто говорит: «Я хочу рассказать вам о своем продукте».
Большинство продуктов, о которых пойдет речь на этой конференции — CI-серверы, инструменты развертывания и виртуализации — были разработаны за рубежом.
И поэтому спикер от этой компании может прийти к нам только в том случае, если мы сами его пригласим.
И когда мы его приглашаем, конечно, принимаем все необходимые меры, чтобы это не был питч продукта.
Александр: Бывают и случаи, когда человек вроде бы не особо увлечен техникой, но отчёт оставляет ощущение сладенькой ваты, что всё так замечательно, бери и всё сразу заработает, никаких подводных камней.
Как Как правило, такие отчеты относятся к категории «101».
Это обзорные отчеты, или отчеты начального уровня.
Они полезны для людей, которые ничего не знают или знают очень мало об этой технологии.
А тех, кто уже что-то изучает сам и использует это в производстве, больше интересуют внутренние детали реализации и особенно подводные камни.
Поэтому очень здорово, если спикер не только хорошо знает свой продукт, библиотеку, технологию и рассказывает о положительных моментах, но и знает проблемы пользователей и может рассказать о разного рода компромиссах, которые существуют в любом инженерном решении.
JUG.ru: На других конференциях JUG.ru, например, Джокер уже были сообщения о «почти DevOps».
Что происходит теперь, когда есть отдельная конференция — они все переезжают туда или их все равно можно будет увидеть на «Джокере»? Барух: Это очень хороший вопрос, который я, находясь в программном комитете обеих конференций, вижу с обеих сторон.
С одной стороны да, есть большое желание перенести все devops-отчеты на DevOops. Но, с другой стороны, когда тема интересная, не хочется оставлять человека, который придет только на Джокер и вообще не собирался идти на DevOops без этих тем.
Поэтому те отчеты, которые связаны и с devops, и с Java, мы стараемся оставить Joker, а те, что не связаны с Java, вынести на DevOops. Олег: Добавлю, что даже если темы на двух конференциях окажутся одинаковыми, то на DevOops они будут больше о процессах и какой-то управленческо-эксплуатационной части, а на Joker — больше о хардкоре и программировании.
Тема одна и та же, но будет рассмотрена с разных сторон.
JUG.ru: Спасибо за ответы.
Есть ли что-нибудь еще, что вы хотели бы добавить? Алексей: Что после DevOops сбор обратной связи поможет нам ответить на все те же вопросы к следующей конференции.
Давайте на практике разберемся, чего хватило для DevOops тем людям, которые действительно пришли, а чего нет. JUG.ru: То есть, какой будет вторая конференция, зависит от людей, которые придут на первую? Хороший стимул пойти.
DevOops первый состоится 20 октября в Санкт-Петербурге билеты уже в продаже (и со временем дорожают!).
Ключевые темы: — Контейнеры, оркестровка (Docker, Kubernetes, кластеры и т. д.).
— Виртуализация, Облачные технологии (AWS, Azure, Heroku и другие).
— Мониторинг и аудит приложений (Prometeus, OkMeter, DataDog, BPF, Dynatrace, XRebel, Glimpse, Zipkin, OpenTrace и других).
— Непрерывная доставка (Jenkins, TeamCity, Bamboo).
— Управление конфигурациями (puppet, Chef, Ansible).
— Безопасность (Хранилище и т. д.) — Разбор полетов на примерах крупных проектов внедрения DevOps: успешных и провальных.
Теги: #ИТ-инфраструктура #Системное администрирование #Облачные вычисления #DevOps #devoops
-
Вводное Руководство По Указателям В C
19 Oct, 24 -
Неизвестные Родственники
19 Oct, 24 -
Станут Ли Гонки На Супердронах Суперспортом?
19 Oct, 24 -
Началась Прокладка Подводного Кабеля Google
19 Oct, 24
