Мы решили взглянуть на эти практики с каждой из перечисленных позиций и спросили об этом тех, кто давно в этом варится. Что получилось? Смотрите под катом.
Барух jbaruch Садогурский — один из наиболее заметных DevOps-гуру, говорящих по-русски. Последние дни делает в жизни в основном три вещи: зависает с разработчиками, пользователями и клиентами, пишет для них код и рассказывает о впечатлениях в блогах и на конференциях. Developer advocate из JFrog, постоянный закадыка подкаста «Разбор Полетов». Один из главных организаторов swampUP, крутой DevOps-конференции, проходящей в Долине.
Александр Титов — управляющий партнер в Экспресс 42, которая выращивает DevOps в технологических компаниях. В свое время был техническим директором первого облачного хостинга в России Скалакси. Организатор сообщества DevOps Moscow, конференции DevOpsDays Moscow.— DevOps решает проблему взаимодействия команды, занимающейся разработкой и доставкой одного и того же продукта. На каких принципах строится такое взаимодействие среди людей различной специализации? Как обозначить четкие границы ответственности?
Александр Титов: Вопрос одновременно и простой и сложный. Попробую ответить и так, и так.
«Ответственность» — довольно простое слово. Это значит быть в ответе за что-либо, возможность объяснить, разобраться в том деле, которое делаешь. Ни в коем случае это не эквивалентно страху лишения премии или невыполнения какого-либо KPI.
Итак, человек может быть в ответе, если он обладает знаниями в определенной сфере и в том числе его знания помогают ему определять и признаваться себе в незнании чего-либо, это его граница. Человек при этом может также ответственно и знающе выходить за границы своего знания и таким образом знания получать.
Это простой ответ на вопрос об ответственности — достаточно человеку, команде и компании знать границы своих знаний. Тогда можно всегда понять, где мы идем по зыбкому льду, а где мы на твердой земле. Грубо говоря, если человек или команда знают, как работает Kubernetes в их среде, то они могут прекрасно взять ответственность за Kubernetes. Или, например, человек написал приложение и знает, как оно работает, он за него и отвечает.
Сложный ответ состоит в том, что определить знание в компании очень сложно — люди врут, боятся и не признаются в том, что они на самом деле знают, а чего — нет. Зачастую бывает так, что люди сами не осознают того, что чего-то не понимают — это еще называется неосознанная некомпетентность. И здесь может помочь только выращивание культуры доверия и непрерывного диалога в команде. Любой человек может указать другому на ошибку: при этом второй не может игнорировать это указание, ему надо поразмыслить и обсудить это с другими членами команды, ответить им. И эта культура и есть основа взаимодействия в командах, практикующих DevOps.
— Если в компании долгое время придерживались стандартного подхода к разработке, насколько сложно бывает «перестроить» людей на DevOps-методологию? С какими проблемами можно столкнуться при этом?
Александр Титов: Людей сложно перестраивать. Идея перестройки человека вообще попахивает фашизмом, эти ребята тоже думали, что можно «построить» сверхчеловека. Людей нужно образовывать и решать при этом ряд очень сложных задач:
- людям надо показать, что размышления действительно помогают решать проблемы;
- людям надо научиться вести диалог, а не монолог (посмотрите на обычные совещания — там сплошные монологи);
- людям надо быть открытыми и искренними;
- людям надо показать, что разнообразный опыт — это прекрасно, и знания из живописи помогают при разработке ПО.
Большая проблема — непонимание базового принципа: надо не перестраивать людей, как делают многие, а создать среду, в которой эти люди смогли бы сами овладеть перечисленными мной навыками. Такую среду менеджер может создать только тогда, когда изменится сам, и это самая большая проблема здесь.
Мой рецепт по изменению себя — работа в сообществе. Именно сообщество помогает безболезненно в режиме доверия увидеть, как создавать среду. Руководителю очень сложно думать о среде, когда над ним давлеют дедлайны и премии.
Барух Садогурский: Самая большая проблема заключается в том, что техническим людям тяжело правильно оценивать культурные изменения. Технари считают, что сейчас они возьмут Jenkins, заполируют Docker-ом и у них будет DevOps. Но DevOps не только про инструменты, он — про изменение подхода. О том, что больше нет никаких сисадминов и разработчиков. Есть те, кто пишет код, — и они же отвечают за то, чтобы код попадал в продакшн.
Все стремятся настроить правильные инструменты, чтобы те, кто пишет код, деплоили все в продакшн, после чего объявляют, что DevOps внедрен. А на следующем же разборе полетов, когда выясняется, что что-то не попало в продакшн, девелоперы открещиваются: «Мы все сделали, как нам говорили, на кнопочку нажали, теперь это не наши проблемы. Пусть те, кто это настраивал, идут и исправляют». Тут-то и выясняется, что настроить pipeline не значит получить DevOps. Пока те, кто пишет код, не поймут, что фразу «это не наши проблемы» они в принципе не могут использовать, ни о каком DevOps не может идти речи.
У нас сейчас будет прекрасная конференция с техническими темами, созданная техническими людьми. Будет очень много Jenkins, Ansible, Docker, Puppet и других разных отличных инструментов. Будет много докладов о том, как получить DevOps через их правильную настройку. Это то, что мы понимаем, о чем мы любим говорить. То, что мы можем сделать правильно. У нас будут доклады и о том, как изменить культуру, но нам очень сложно это делать. Вообще это вопрос не к технарям, а к психологам, социологам или поведенческим специалистам.
— DevOps-методология подразумевает всевозможную автоматизацию. Означает ли это, что для бизнеса запуск и поддержка продукта становится дешевле? Как определить границу, после которой целесообразно запускать DevOps?
Барух Садогурский: DevOps как раз создан для того, чтобы продукты быстрее попадали в продакшн, чтобы релизы были чаще, а разработка быстрее. Если посмотреть на результаты опросов компаний, внедривших или планирующих внедрить DevOps, 80% из них выделяют быстрые релизы как основной, самый главный драйвер.
С точки зрения границ внедрения: на самом деле, DevOps будет полезен командам любого размера. Задавать вопрос о применимости этой методологии к тем или иным масштабам команды — то же самое, что 10 лет назад спрашивать, с какого размера имеет смысл использовать version control. Сегодня мы этот вопрос больше не задаем, потому что понятно, что даже двоим уже нужны какие-то инструменты для технической коллаборации. DevOps — это тоже набор инструментов. И если сегодня для нас само собой разумеющееся — написать код и отправить в version control, то через 10 лет мы точно так же будем писать код и отправлять в продакшн. Это вещи того же уровня. Просто мы до этого еще не дошли.
Вероятно, результат будет менее заметен, когда в проекте 3 человека. И им не нужны все те инструменты, которые использует команда в 100 человек. Но сама парадигма DevOps (нужно не только писать код, но и взять на себя ответственность за то, чтобы увидеть его в продакшене работающим, гарантировать, что туда доставлено все необходимое, и оно развернуто, как надо, а качество — надлежащее) работает и для одного человека, и для трех, и для команды из 100 человек. Меняется только набор инструментов.
— Можно ли привести примеры того, когда DevOps не помог проекту (или даже помешал)?
Барух Садогурский: С этой точки зрения DevOps похож на Agile. Есть много команд, которые имплементировали Scrum, но у них ничего не заработало. А ответ на это прост: нужно различать культуру и инструменты. Инструменты могут подходить или не подходить, они могут быть хорошо внедрены или плохо. Если они внедрены плохо, это наверняка ничем хорошим не закончится. Но сама культура большей коллаборации, сама концепция, предлагающая убрать еще один барьер, не может быть плохой.
Все культурные изменения в отрасли в последние 20-25 лет ведут в сторону большей коллаборации. Сначала у нас был continuous integration. Он о большей коллаборации — мы хотим, чтобы разработчики задумывались об интеграции на ранней стадии, вместо того, чтобы делать ее раз в год перед релизом. Теперь делаем интеграцию после каждого commit-а (или каждую ночь). Agile — тоже. Мы разбиваем команды таким образом, чтобы коллаборация была лучше, люди больше общались. У нас есть дневные митапы, обмен информацией улучшился. Теперь пришел DevOps. Он абсолютно о том же — мы снимаем еще один барьер. Эффективность такого подхода уже оправдана многолетним опытом — исключение барьеров гарантирует более быстрые релизы, лучше качество и все остальные преимущества. Вопрос только в том, как это реализовано.
— Насколько сложно в наше время организовать эффективную DevOps-команду? Какими компетенциями должны обладать инженеры? И нужны ли «отдельные DevOps-инженеры»?
Барух Садогурский: Мы возвращаемся к вопросу культуры. Мы технари и умеем работать с различными инструментами. А вот организовать команду, которая будет функционировать именно как команда — самое сложное. С технической точки зрения, если у вас есть пара человек из разработки и пара человек из ИТ (из системного администрирования), при этом они хотят работать вместе, больше особо ничего и не надо. Они сами смогут поднять и настроить необходимый инструментарий, научиться друг от друга. Но найти людей, которые понимают, что это значит с культурной точки зрения, — самый большой челлендж.
Александр Титов: Об этом я буду рассказывать в своем докладе. Но если коротко, то «DevOps-инженер» — это, конечно, подход от непонимания, некоторая попытка убежать от неизбежной реальности. Компания выбирает себе путь создания технологического продукта, читает про технологии и решает себе нанять DevOps-инженера или команду, чтобы закрыть направление DevOps, и команду Agile-коучей, чтобы закрыть направление Agile. И в итоге получается как получается.
На самом деле в DevOps уже сейчас можно насчитать несколько отдельных компетенций:
- инфраструктурный инженер (инженер, который дает низкоуровневую платформу — ресурсы, сети, создание машин);
- инженер по общим сервисам (инженеры, создающие мониторинг, логирование, базу данных как сервис);
- инженер-разработчик продукта (непосредственно разработчик приложений и конфигурации для них);
- инженер по CI;
- релиз-менеджер или продюсер релиза (менеджер или инженер, который продюсирует выход версий и управляет всем продуктом как совокупностью компонентов, сейчас часто эту роль играет технический директор).
И это пока только начало выделения компетенций.
— Расскажите о tooling-е, необходимом для разработки и поддержки продукта, согласно канонам DevOps. В каком направлении развиваются современные инструменты?
Александр Титов: Тулинг сосредоточен на построении удобной технологической среды для создания продуктов и проверки гипотез по этим продуктам. Уже есть готовые экосистемы, такие как Amazon, GCP, Azure. Есть инструменты, которые могут быть основой для своей, кастомизируемой экосистемы — Kubernetes, Ansible, Jenkins могут быть ее составными частями. Особую роль сейчас сыграл Docker — он смог стать инструментом упаковки и стандартизации знания по конфигурированию и настройке приложения.
Инструменты будут развиваться в сторону большей стабильности и создания сервисов и услуг для инженеров. Пример — использование machine learning для интеграции приложений и определения проблем или для тестирования.
— Есть ли сейчас нерешенные проблемы в инструментарии?
Барух Садогурский: Инструментов существует множество. Со временем их все больше, сами они — все лучше. Мне кажется, что сейчас тут уже особо нечего искать. DevOps достиг стадии early majority — все уже более-менее все понимают.
Каждый отдельный инструмент, конечно, можно еще развивать и улучшать, но каких-то темных пятен («как мы делаем вот это, никто не знает») больше нет. Есть другие рынки, где присутствуют свои собственные, специфичные проблемы. И там еще есть «темные пятна», интересные для нас — как для провайдеров инструментов.
— Можно ли назвать необходимый минимум инструментов для всех команд?
Барух Садогурский: DevOps можно реализовать на минимуме продуктов. Нужен какой-то issue tracker, например, issue на GitHub; естественно, нужен сам GitHub для кода и контроля версий. Нужен continuous integration server — какой-нибудь элементарный Jenkins или даже облачное решение — их существует множество, и какая-то платформа, чтобы это все запускать, скорее всего тоже в облаке. Чтобы начать, этого достаточно.
Достаточны ли простейшие инструменты для сложных систем, в которых есть много команд, взаимодействующих между собой? Конечно, нет. Но этого базового набора достаточно, чтобы настроить полностью автоматический continuous integration или continuous delivery, получив полноценный DevOps-стек. Значит ли это, что получился DevOps? Нет. Вопрос, как уже говорилось, в культуре.
— Немного о технической составляющей. QA считается одной из составляющих DevOps. Насколько усложняется/упрощается жизнь QA-инженера?
Александр Титов: Жизнь QA-инженера не усложняется и не упрощается, она меняется, он начинает писать код, который отвечает за определение надежности приложения и возможности его интеграции с другими приложениями — это несколько другая задача по сравнению с прокликиванием сайта по сценарию. В общем, всем QA-инженерам, которые не умеют программировать, я бы посоветовал записаться на курсы по программированию, еще не поздно начать.
— Какие преимущества появляются у бизнеса после внедрения методологии DevOps?
Барух Садогурский: Как я уже говорил, бизнес хочет две вещи: релизить быстрее, потому что от этого зависит его успех и конкурентоспособность, и релизить с более высоким качеством. 80% компаний говорят, что они хотят DevOps из-за этих двух фич.
— Действительно ли DevOps позволяет бизнесу быстрее реагировать на внешние изменения? За счет чего так происходит? Или же это заблуждение?
Александр Титов: DevOps для этого и создается (он еще не создан, мы в начале пути) — это такой подход к созданию ПО, который позволяет быстро изучать рынок и проверять бизнес-гипотезы. Это происходит за счет того, что все подходы и инструменты создаются исходя из этой идеи (те подходы и инструменты, которые создаются на других идеях — это не DevOps).
На конференции DevOops, которая пройдет в Санкт-Петербурге уже через две недели, Барух и Александр проведут круглый стол «Как «продать» DevOps коллегам, начальству и прочим равнодушным».
Александр Титов отдельно в докладе «От сисадмина к человеку» расскажет про DevOps как систему. Как он помогает бизнесу, какие компетенции со стороны инженеров должны появиться для DevOps, какие бизнес-задачи можно решать DevOps-методом производства программного обеспечения, а также какие ошибки возможны на пути к DevOps-производству и как их избежать или купировать.
Барух Садогурский (вместе с Леонидом Игольником из CA Technologies) будет говорить о DevOps в разрезе роста бизнеса. Доклад называется «DevOps в масштабе: греческая трагедия в трёх актах». Эксперты расскажут о технологических и методологических сложностях, которые возникают на каждом этапе взросления компании (при росте количества сотрудников от 3 до 100 человек), и о проверенных способах и решениях этих проблем с помощью правильных кадровых, методологических и технических средств.
Полная программа конференции и условия участия доступны на сайте мероприятия.
Комментарии (62)
vektory79
10.10.2017 18:08+4Недавно сформулировал для себя такое определение:
SysOps — это про настройку оборудования, чтобы оно работало правильно и быстро. А DevOps — это про настройку разработчиков, чтобы они работало правильно и быстро.
Полностью подписываюсь под словами Баруха и Александра. Самое сложное — переломить сознание людей. Заставить их сотрудничать и не тянуть одеяло на себя. А инструменты — дело наживное.
wispoz
10.10.2017 18:38DevOps — не разработчиков, а систему в целом разработчики -> разработка -> тестирование -> релиз и так далее.
chupasaurus
10.10.2017 20:22+2SysOps — про настройку и поддержку инфраструктуры (железо, сети, ОС, СХД, СУБД, application-сервера, доступы,… список длинный), в которой работают программы, разрабатываемые программистами. DevOps — про то, что эти две группы должны работать с одними и теми же инструментами и рабочими процессами, т.о. стирая грань между ними.
vektory79
11.10.2017 12:52Ну вот я уже несколько лет вокруг этого кручусь. Что получил в итоге? Инструменты есть, а DevOps'а нет! Почему? Потому, что инструменты должны быть не как цель, а как следствие стремления людей что-то улучшить. Улучшить глобально. Найти общий язык всех со всеми. Понять что таки нужно на самом деле и сделать это.
Инструменты — всего лишь инструменты. Без правильно настроенных на нужный результат людей это так и останется мёртвым грузом.
И камень с мёртвой точки у меня начал смещаться именно когда я понял, что DevOps это про людей и именно про людей. Если правильно нашёл заинтересованных, корректно подал им мысль что и как можно улучшить, порекомендовал полезные решения, помог их реализовать, и т.д. и т.п… Внезапно всё раз — и побежало. И начали появляться решения, эти решения начали использоваться пошол DevOps.
А то, что вы описали — скорее таки SysOps. Да Он тоже нужен. Но это в целом очень другая относительно разработки компетенция. И грамотный сисадмин с классическими подходами тут может оказаться гораздо ценнее.
Сисадмин не должен программировать сложные системы. Программист не должен тюнить СХД. Один человек не в состоянии иметь глубокую компетенцию везде. Иначе будет беда.
А вот взаимодействие этих гатегорий людей ради конкретного результата — вот это уже ближе к DevOps. Но таки людей.
Lsh
11.10.2017 12:56+1И раньше было понятно, что в команду надо брать умных, а мысли свои излагать точно. Зачем нужен этот новый модный термин? Как оно, это взаимодействие людей, измеряется?
vektory79
11.10.2017 13:05В целом про eagel или scrum можно сказать точно так же. Разница лишь в том, что они старше и люди уже чётко договорились что конкретно под этим следует понимать. А с DevOps общественность ещё в поиске. Просто начало формироваться видение, что те-же производственные задачи можно решать ещё одним способом, который меньше полагается на договорённости и человеческий фактор, а больше на автоматизацию и алгоритмически прописанные правила.
Но пока опыт у всех разный. Общий знаменатель ещё не подведён. Потому и получается такой аморфный шум. Для меня тоже ещё много белых пятен в этом. Потому и стараюсь попасть на конференции по этому вопросу, чтобы иметь возможность пообщаться с людьми имеющими свой, альтернативный опыт.
Lsh
11.10.2017 13:12А с DevOps общественность ещё в поиске.
Вот оно и странно. Мне всегда казалось, что обычно сначала придумывают содержание, а потом под это дело новый термин. Тут термин есть, но значение не определено. С таким же успехом можно говорить «Пыщ-пыщ». Подразумевать, что это означает «всё хорошее, без всего плохого». Мы внедрили «Пыщ-пыщ», показатели улучшились на 2%.
arthur_veber
11.10.2017 18:28Зато можно продавать книжки, организовывать конференции…
jbaruch
12.10.2017 08:51Вы так говорите, как-будто это что-то плохое. Вы как сами развиваете профессиональные знания? Не книжками, и не конференциями?
jbaruch
12.10.2017 08:51Содержание вполне себе придумано. Внедрять его оказалось непросто (потому что оно не про технологию). Вот и происходят шатания.
Термин есть, значение определено, но реальность вносит в это значение свои коррективы.
osminog
12.10.2017 11:20Так происходит практически со всеми дисциплинами, они разработаны ровно настолько, насколько они разработаны. Для разработки нужна коммуникация, нужны статьи, конференции. Кто-то знает больше, кто-то меньше.
Вон есть термин Физика, Физика говорит, что она изучает мир, но ничего о нем не знает. А еще есть люди, которые про торсионные поля пишут и тоже это Физикой называют.
А DevOps это вообще практика, тут надо пробовать и переделывать и так бесконечно. Тоже самое происходит во всех областях жизни — абсолютного знания — нет.
KarasikovSergey
11.10.2017 09:52+2Еще несколько месяцев назад термин DevOps был мне совершенно неизвестен, а теперь как минимум один заголовок первой страницы хабра его содержит. Вот оно какое — чувство приближающейся старости!
DistortNeo
11.10.2017 11:01Ничего страшного, пройдёт ещё лет 5-10 и вместо DevOps придумают что-нибудь ещё.
nokogerra
11.10.2017 12:15+5Не знаю на счет старости, мне 28 и для меня это выглядит как маркетинговые понты. Какой-то модный тренд, который не дает четкого понятия, какие у человека должны быть компетенции, чем он конкретно должен заниматься и в какой области. Звучит как специалист по всему, а специалист по всему — это специалист по ничему.
BTW, помню слушал подкаст с linkmeup, касающийся автоматизации работы сетевых инженеров с помощью ансиблов/питонов, там участвовали Наташа Самойленко, был еще один CCIE из Cisco TAC (может и больше, но один точно был), был сотрудник амазона и, кажется, eucariot. И кроме вопросов а-ля «а нужно ли сетевому инженегру писать скрипты» всплыл вопрос про devops. Говорилось о том, что встречается довольно большое количество вакансий «девопс». Так вот, на сколько я понял из подкаста, они вот тоже не очень уверены, что это точно такое, короче, пропорции условны, а границы размыты.
P.S. а может я просто быдло и не понимаю визионерских тенденций.KarasikovSergey
11.10.2017 12:21+5Вы вернули мне ощущение целостности реальности, потому что последний месяц я в панике наблюдаю за этим devops-трендом с полным ощущением себя больным какой-то формой дислексии, не позволяющей понять: откуда это взялось, что это такое и почему вокруг этого столько шума? Я вижу статьи, где DevOps используется как какое-то укоренившееся понятие, с которым каждый сталкивается каждый день в IT-обиходе и мне стыдно просто спросить «что это мать вашу такое, почему и зачем оно, а главное — как оно вдруг захватило все окружающее пространство?!»
Спасибо вам, я хоть вижу, что не один такой.jbaruch
12.10.2017 08:48что это мать вашу такое
Сочетание культуры, знаний и скиллзов.
почему и зачем оно
Чтобы выпускать более качественный софт чаще.
как оно вдруг захватило все окружающее пространство?
Когда некоторые продукты начинают получать преимущество над конкурентами, из-за того, что они выше качеством, и выпускаются чаще, конкуренты перенимают практику. Получается снежный ком, который достаточно быстро захватывает все окружающее пространство.
KarasikovSergey
12.10.2017 08:57У меня возникло стойкое ощущение, что вы сами не понимаете, что это такое, но хотите быть в тренде, потому что все так делают. Вся эта возня новомодными смузи-специалистами напоминает мне эксперимент с обезьянами, бананом и струёй воды — кто-то авторитетный запустил этот загадочный девопс в массы, а остальные уже фантазируют на тему, что это такое, делая вид что знают, потому что так принято.
jbaruch
12.10.2017 09:10У меня возникло стойкое ощущение, что бы переходите на личности, называя "смузи-специалистом", и сравнивая с обезьяной. Напрасно вы это, чести это вам не делает.
KarasikovSergey
12.10.2017 09:15+2Ни в коем разе по обоим пунктам. "Смузи-специалистами" я именую высосанные со скуки из пальца профессии, а ни в коем разе не вас или кого-то ещё. Прошу извинить, если неверно выразился и дал повод так подумать. В эксперименте с обезьянами суть не в обезьянах, а в социальной модели привития бессмысленных традиций и порядков.
jbaruch
12.10.2017 09:20ДевОпс это не профессия, это практика. Высосана она из пальца не от скуки, а в поисках конкурентного преимущества. Если компания может релизить чаще и качественней за счет сноса очередного барьера на пути кода от разработчика к клиенту, эта компания будет зарабатывать больше денег. Скука тут совсем непричем.
KarasikovSergey
12.10.2017 09:26+1Не согласен, фрагментация и разбухание персонала в моем понимании бесконечно далеки от идеалов оптимизации процесса и не убирают барьеры, а создают новые. Бюрократизация ещё никогда не приводила к повышению эффективности. А уж тем качества, что вкладываются в понятие девопс в комментариях к этой статье и вовсе удивляют — это же портрет обычного многостаночника, админа в маленькой компании, который и картриджи меняет, и сети администрирует и код пишет.
ggo
12.10.2017 10:15Ну смотрите.
Вариант А. Команда пилит продукт. На выходе получает war-ник. И отдает его команде эксплуатации, с набором инструкций, как деплоить. Всё, свою часть они сделали, все счастливы, все довольны. У второй команды свой цикл, свои правила, свои особенности. Проблемы с деплоем решает только вторая команда, пока не докажет первой, где ее косяк.
Вариант Б. Команда пилит продукт, и в том числе деплоит (и все остальное, что требуется для доставки продукта клиентам). Все проблемы, в том числе проблемы с деплоем, решает команда, одна команда. Очевидно, у команды должен быть нужный скилл по эксплуатации.
На ваш взгляд, в каком варианте в общем случае будет больше проблем? В каком варианте будет в среднем быстрее доставка?
DevOps — это просто ответ на потребность бизнеса, быстрее и качественнее релизиться. Один продукт — одна команда — один тимлидер, у которого достаточно ответственности и полномочий за весь жизненный цикл продукта.KarasikovSergey
12.10.2017 11:50+1Звучит просто великолепно — два в одном, меньше персонала, меньше головной боли по менеджменту, за это даже можно доплатить. Но почему-то мне, прочитав ваше сообщение, очень хочется добавить «а давайте они еще и продажами будут занимать, сопровождением и юридическими вопросами?»
jbaruch
12.10.2017 20:01Не давайте. Продажи и юридические вопросы — не инженерные практики. Сопроводжение, на определенном уровне — вполне себе, и внезапно, дежурные инженеры им таки занимаются.
KarasikovSergey
13.10.2017 12:13Вы знаете, программирование и администрирование друг от друга столь же далеки, как и оба вместе от продаж. Сегрегация на разработчиков и инженеров всегда была, есть и будет есть. Все универсалы таковыми становятся поневоле, но настоящие профи — они или сильные программисты, или крутые админы, или сосредоточенные руководители-бюрократы (эти, конечно, часто получаются из предыдущих двух с непременной утратой навыка по мере погружения в административную работу)
jbaruch
14.10.2017 17:32Ну вот тут всякие Гуглы с Нетфликсами с вами не согласны. Ни в вопросе насколько близки программирование и администрирование, ни в вопросе есть ли, и должна ли быть сегрегация на разработчиков и админов.
DistortNeo
12.10.2017 11:13Здесь нет противоречений. Разработка DevOps командой обходится дороже, чем классическая, т.к. разработчиков нужно тупо больше. Также за счёт их многостаночности у таких разработчиков ещё и выше аппетиты. Но если эта технология даёт конкуретное преимущество и окупает затраты, в ней есть смысл.
osminog
12.10.2017 11:46DevOps — это практика и методология производства цифровых продуктов и платформ. Это не человек, не команда и не инструмент. Практика живая и постоянно развивающаяся засчет глобального коммьюнити.
Коллеги, я часто сравниваю свою способность объяснить, что такое DevOps c объяснением человеку из Саудовской Аравии какой смазкой надо смазывать лыжи при -5 для бега на лыжах свободным стилем.
Вы скорее всего не пробовали и судите о DevOps исходя из своего прошлого опыта, а он, конечно, не совсем накладывается на ваш опыт или наоборот полностью накладывается и вам кажется, что ничего нового.
Если вам действительно важно узнать, что такое DevOps, то рекомендую посмотреть мой доклад www.youtube.com/watch?v=eIV5D1HSmKI и прочитать книгу www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002
В моем докладе вы узнаете зачем нужен DevOps, а из книги вы сможете взять содержание практики.DistortNeo
12.10.2017 13:24Дело не в опыте, а в том, что сущность DevOps описывают так, как будто это какой-нибудь MLM, бизнес-тренинги или секта. Посмотрите видео, почитайте книгу — слов и философии там много, а смысла мало.
Хотите, я в нескольких предложениях всё это опишу? Да пожалуйста, вот 4 предложения:
1. (Зачем это надо) В условиях высокой конкуренции преимущество получают компании, которые способны как можно быстрее выкатывать релизы в ответ на запросы заказчика.
2. (Чем плох существующий порядок) Существование отдельных команд разработки и внедрения приводит к появлению имеющего значение временного лага как при внедрении, так и при обратной связи.
3. (Что предлагается) Совмещение функций вышеуказанных команд в одной команде позволит уменьшить временной лаг между разработкой и внедрением.
4. (Каким образом) Несмотря на то, что совмещение нескольких функций в одном человеке обычно снижает эффективность его труда, развитие современных инструментов разработки [список инструментов] позволяет это автоматизировать, делая труд разработчиков более эффективным.
Всё остальное — вода и философия.osminog
12.10.2017 14:02Ну вот вы не смотрели видео, книгу не читали, а говорите. В Америке так принято вести дела, что все делают через продажу и обращение к социальной коммуникации. Поэтому невозможно читать их бизнес-книги. Просто сделайте на это скидку и попробуйте разобраться. Вот про что я говорю.
DistortNeo
12.10.2017 15:48Вы правы, я не смотрел видео, не читал книгу, и не собираюсь этого делать. Меня не устраивают предлагаемые вами варианты получения информации: посмотреть часовое видео (со звуком) у меня нет никакой возможности, а книгу вы предлагаете купить в зарубежном магазине.
> В Америке так принято вести дела, что все делают через продажу и обращение к социальной коммуникации. Поэтому невозможно читать их бизнес-книги. Просто сделайте на это скидку и попробуйте разобраться. Вот про что я говорю.
Теперь понятно, почему при прочтении информации о DevOps у меня складывается ощущение разводки в стиле сетевого маркетинга в его негативном смысле.
Поэтому я прошу вас не отправлять меня читать книги, от которых меня будет воротить, а в 5-10 предложениях описать своими словами, что вы понимаете под DevOps, для русскоязычной аудитории с учётом нашего менталитета.
jbaruch
12.10.2017 20:04Ну отлично же всё написали. Лучше DevOps в четырех предложениях, пожалуй и не опишешь.
Дальше начинаются скучные будни. Как совместить нескольких функций в одном человеке с минимальным снижением эффективности его труда, какие инструменты, и как позволяют это автоматизировать, и как сделать так, чтобы человек это захотел.
arthur_veber
13.10.2017 17:56DevOps — это не человек
не получается, потому что на хх.ру написано: «требуется DevOps с 30 и более летним стажем, зарплата такая-то»
то есть бизнес ищет человека.
Lsh
11.10.2017 12:52+5Создаётся ощущение слова «Ку!» из фильма «Кин Дза Дза». Открываешь статью с заголовком «DevOps пыщ-пыщ!», а там просто про контейнеры. Наверное я тоже в этом ничего не понимаю.
jbaruch
12.10.2017 08:49Если игнорировать культурые и поведенческие аспекты ДевОпса, то получается просто про контейнеры, да. Да чего уж, просто про Дженкинс может получиться.
ALexhha
11.10.2017 13:19помню слушал подкаст с linkmeup, касающийся автоматизации работы сетевых инженеров
Так вот, на сколько я понял из подкаста, они вот тоже не очень уверены, что это точно такое
ничего странного, сетевые инженеры и не должны разбираться в задачах devops'ов, имхо.
Просто сейчас такая модная тенденция пошла и любой сисадмин localhost, который видел в глаза ansible и раз в жизни запустивший docker считает себя devops инженером и требует соответствующую зп. А когда ты приглашаешь их на собеседование и начинаешь общаться, то становится страшно (из личного опыта), ибо знаний у них как у сисадмина localhost :)Lsh
11.10.2017 13:25+3Что должен знать настоящий devops?
ALexhha
11.10.2017 16:11+2Как по мне
- Уверенная база системного администратора, хотя бы middle
- Хорошо разбираться в git и различных workflow. Т.е. этот человек должен уметь построить workflow и объяснить команде почему и зачем стоит его использовать. Поэтому знание git на базовом уровне clone/pull/push будет недостаточно. Знание других vcs будет плюсом.
- Реальный опыт использование контейнеров. Docker Swarm/kubernetes/Mesos. А так же четкое представление отличия контейнеризации от виртаулизации. Понимание, когда следует использовать 1е, а когда 2е, какие преимущества и недостатки у каждой из систем.
- Реальный опыт построения CI/CD. Опыт работы с Jenkins/Gitlab CI/TC/etc
- Хороший опыт работы с облачными провайдерами — Amazone/GCP/Azure. Как минимум базовый набор сервисов.
- Хороший опыт в написании скриптов на python/ruby. Отличное знание bash подразумевается по дефолту. Базовое знание одного из яп — java/c/c++/c# будет плюсом.
- Хороший опыт работы с SCM. Хотя бы с ansible. Опыт работы с chef/saltstack/puppet будет плюсом
- Опыт написания тестов. Хотя бы на базовом уровне.
- Опыт профилирование и отладки приложений. Знание top и т.п. утилит это конечно хорошо, но их явно недостаточно. Поэтому человек, который будет знать и иметь опыт работы с perf/gdb/strace будет иметь преимущества
- Уверенное понимание жизненного цикла разработки ПО. Знание и опыт работы по одной из методологий — Scrum/Agile/Kanban будет плюсом.
- Опыт работы с Jira/Confluence/Redmine будет плюсом.
Я бы отбирал кандидатов примерно по такому списку.
Kessian
11.10.2017 16:18+3Так вот ты какой, современный Шива многорукий.
То, что вы описали — требования к команде разработки/развёртывания. Нет, я не спорю, что тот же разработчик должен понимать принципы работы среды, в которую и будет установлено его приложение, но написание скриптов? Сисадминство на уровне middle? Кстати, а что это за чудо-уровень? Я вот умею развёртывать продукты ibm websphere(далеко не все), но в жизни не трогал docker, это какой уровень?
И да, если это то что называют DevOps — ну удачи в поисках. Не, думаю такие люди существуют. Где-то один на пару десятков в профессии.ALexhha
11.10.2017 16:35Нет, я не спорю, что тот же разработчик должен понимать принципы работы среды, в которую и будет установлено его приложение, но написание скриптов?
не совсем понял, а причем тут разработчик к скриптам? Ведь речь шла о devops инженере.
Сисадминство на уровне middle?
как минимум, лучше конечно senior
Кстати, а что это за чудо-уровень?
в каждой компании есть своя градация, поэтому middle из бухгалтерской конторки на 10 рабочих мест и middle с яндекса будут абсолютно разными по уровням. Думаю это очевидно.
Я вот умею развёртывать продукты ibm websphere(далеко не все), но в жизни не трогал docker, это какой уровень?
если вы будете работать на проекте, где не используются докер, но активно используется websphere, то не все ли равно как вас будут называть? :) Насчет градаций см выше
И да, если это то что называют DevOps — ну удачи в поисках.
я их как бы и не ищу, сам работаю devops инженером ;)
Ну и все выше сказанное это мое имхо, а не истина в последней инстанции.Kessian
11.10.2017 16:44не совсем понял, а причем тут разработчик к скриптам? Ведь речь шла о devops инженере.
Моя вина, после чтения списка была уверенность, что бОльшая часть пунктов относится именно к разработчикам. Перечитал, понял что ошибся.
в каждой компании есть своя градация, поэтому middle из бухгалтерской конторки на 10 рабочих мест и middle с яндекса будут абсолютно разными по уровням. Думаю это очевидно.
Мысль понял. Но тогда предполагается дополнительный человек с уровнем знаний используемых систем/железа повыше. То есть сисадмин дополнительно к DevOps'у.
Ну и все выше сказанное это мое имхо, а не истина в последней инстанции.
аналогично :)
nokogerra
11.10.2017 18:50Мидл это мидл, синьор это синьор, в конторке из 10 человек не бывает мидлов, бывают технические специалисты, которые решают какие-то проблемы за 5 копеек денег, потому что в таких конторах к ИТ относятся по остаточному принципу.
Сегодня, учитывая количество технологий, их сложность и «наслаиваемость» трудно найти мидла, тем более реального синьора. А синьору, который умеет все то, что вы там написали про гиты/скрамы/c-плюс-плюсы, можно поручить решение проблемы перенаселения земли, он и с ней справится.
Я так и вижу мидла, который шарит в сетях хотя бы на уровне между ccna и ccnp (в достаточно большой организации по-любому как ccnp), достойно разбирается хотя бы в одной среде виртуализации, достойно разбирается в одной классической платформе ОС (Windows или *nix), достойно разбирается в хранении данных (сюда СХД, резервное копирование, SAN, если это FC, то как минимум FC фундаменталс нужно знать, brocade cli и всякое там) и так, между делом, изучил остальной список из 10 пунктов. ОК. И я забыл про всякие «незначительные» мелочи вроде служб каталогов, систем мониторинга, и прочей сопутствующей мишуры.ALexhha
11.10.2017 19:51Мидл это мидл, синьор это синьор, в конторке из 10 человек не бывает мидлов, бывают технические специалисты
ну начать с того, что в трудовой вообще нет понятия devops и всяких новомодных рангов junior/middle. Я лишь привел для примера.
достойно разбирается в хранении данных (сюда СХД, резервное копирование, SAN, если это FC, то как минимум FC фундаменталс нужно знать, brocade cli и всякое там)
Devops не занимается железом. Я например работаю только с aws стеком и я очень далек от всех проблем с железом, слава богу, в свое время нахлебался 5 лет с hetzner :)
И как правило devops не занимается сетью на серьезном уровне. Слабо себе представляю devops'а, который будет настраивать BGP и MPLS, по ходу дела делая код ревью :) Либо это будет уже netops
И я забыл про всякие «незначительные» мелочи вроде служб каталогов, систем мониторинга, и прочей сопутствующей мишуры.
это все входит в обязанности сисадмина.
Или тогда конкретизируйте понятие сисадмина в вашем понимании. А то у кого то человек, который админит один сервер и меняет мышки и картриджи, тоже считается сисадмином :)
jbaruch
12.10.2017 08:43То, что вы описали — требования к команде разработки/развёртывания
Вот эта команда — devops и есть.
Kylin
12.10.2017 10:18Так вот ты какой, современный Шива многорукий.
ну почему, я вот окончил универ по специальности b.sc. computer science, параллельно работая сисадмином в среднего размера компании, периодически работая на проектах в команде DevOps'ов, 5 лет стажа, сертификат LPIC-2. Это и есть уровень middle. Я прекрасно умею дебажить код, хотя это и не моя основная задача, как и было сказано выше в статье DevOps это культура общения, когда программист будет слушать сисадмина как исправить ошибку в коде, а сисад подправит ulimit -n в системе, потому что дев знает что с меньшим ulimit его софт будет глючить. И да я подхожу под все выше описаные пункты, и да нас очень мало и зарплата у нас соответствующая :)
xtotec
11.10.2017 17:01+2Говорил раньше и повторю сейчас — всё это
любовьDevOps эторусскиеПМы (и прочий отдел маркетинга) придумали, чтобыденег не платитьсисадмина не нанимать. Как в 1997м кричали — «А-а-а-а, Windows NT это просто — любой студент может её админить», в результате имеем отдельную уважаемую и дорого оплачиваемую профессию — MSCE и что характерно *никсовые сервера не устарели и не вымерли массово.
Мозги у админов и программистов работают по разному. Поэтому у них разный круг ответственности и должностные полномочия.
Программист хочет чтобы его код работал, а сисадмин хочет, чтобы работал код, но ещё сервер (облако) (на этом месте программесту стало скучно и он пошёл кодить дальше), свичи, бекап, мониторинг и ещё много чего.
Почему никому не приходит в голову такой чудесный тянитолкай как DevPM — программист менеджер проектов или DevSales — программист менеджер по продажам — можно тоже пару штатных единиц сэкономить.jbaruch
12.10.2017 08:44Почему никому не приходит в голову такой чудесный тянитолкай как DevPM — программист менеджер проектов или DevSales — программист менеджер по продажам — можно тоже пару штатных единиц сэкономить.
Потому что DevOps это не об экономии штатых единиц.
xtotec
12.10.2017 10:00Если вы задумаетесь, то сможете сами ответить себе на вопрос — это именно об экономии штатных единиц и ни о чём другом.
Точка зрения менеджера на cost cutting. А devops — это магнитола «средненькое радио и посредственный магнитофон в одном корпусе».
arthur_veber
11.10.2017 18:49А может по другому всё.
Когда я заканчивал учебу на программиста (где учили и word и pascal и сети) и устраивался на первую работу, тогда для большинства людей слова программист, вебмастер, системный администратор и системный блок означали одно и тоже. Вебмастер делал всё. Дизайн, вёрстка, код.
Но время шло и с развитием веба вебмастер начал делится на дизайнера, разработчика… Сис. админ на эникейщика, сетевого инженера и т.д.
Я к тому, что возможно сейчас только сформировывается некий пласт обязанностей и знаний, который ещё сильно пересекается с другими областями и поэтому у него нету своей четкой позиции. Но со временем, отделившись, будет называться DevOps.
acmnu
Десять лет назад? Например СVS уже 27 лет, а git — 12.
ARG89
Речь про то, что 10 лет назад все это было ощутимо менее распространено. А сегодня в GitHub даже школьники pet-проекты заливают.
acmnu
Возможно мы в разных мирах живем, но когда я начинал работать (примерно 12 лет назад) за неумение пользоваться svn уже били по пальцам.
alan008
А мы 10 лет назад еще сидели на Microsoft Visual Source Safe 6.0, там даже параллельной работы с файлом не было — взял в работу, значит заблокировал файл от изменения другими пользователями.
Danik-ik
А Вы сомневались во множественности миров? В моём мире и 12 лет назад, и сегодня VCS не нужны никому, кроме меня.
Да что удивляться, возьмите стройку. Бригада ух из США собрала здание церкви за неделю. Бригада ох из очень средней азии делает тот же объём за полтора-два месяца. Почему? У первых есть типовой техпроцесс и дорогой, но эффективный инструментарий, который экономит ещё более дорогое время работника. НО: у нас все работают как бригада ох, и не работают, как бригада ух. Скорее всего, потому, что доступные на рынке труда работники убьют или пропьют дорогой инструмент, и толку не будет. Поэтому есть, что есть.
Вот вам и иные миры...
jbaruch
Вопрос не в знании, что такое source control. Вопрос в решении его применимости. 10 лет назад многие, например, считали, что это только для больших команд. Так и с девопсом. Уже многие понимают, о чем это, но считают, что это только для какого-нибудь Гугла, а мы по-старинке, сисадминим. Ну вот через 10 лет никому по-старинке в голову не придет.
chupasaurus
Десять лет назад Торвальдс пиарил git в Google, например. И тогда git был не очень user-friendly, что сам Линус признавал.
acmnu
Ну да, но был уже раскачаный SVN. Даже под винду уже существовали удобные тулы, типа Туртойз. Ну и CVS уже был де факто стандартом. А под винду было много платных систем.