Можно бесконечно спорить о понятии «DevOps» — вроде и вакансии есть, и должности, и инструкции, и KPI… Вот только я по-прежнему постоянно вижу совершенно разное восприятие этого понятия между бизнесом, админами и разработчиками. Первые воспринимают девопс как методологию, вторые — как набор инструментов для автоматизации рутины, а третьи — как набор инструментов для деплоя. В чем-то правы все,
Мы решили взглянуть на эти практики с каждой из перечисленных позиций и спросили об этом тех, кто давно в этом варится. Что получилось? Смотрите под катом.
Барух Садогурский — один из наиболее заметных 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 человек), и о проверенных способах и решениях этих проблем с помощью правильных кадровых, методологических и технических средств.
Полная программа конференции и условия участия доступны на сайте мероприятия.
Автор: ValeriaKhokha
