Закрыть

DevOps: устранение разногласий между разработчиками и операторами

Что такое DevOps?

Культура DevOps помогла нам

«С DevOps мы смогли выпускать релизы очень часто и получили преимущество при выводе продукта на рынок. Если раньше цикл составлял около полугода, то теперь мы можем выпускать релизы ежедневно и отправлять клиентам исправления за пару часов».

Хамеш Чавла, технический вице-президент, Zephyr

DevOps — это набор методик, с помощью которых можно автоматизировать процессы между командами разработчиков и ИТ-специалистов, чтобы они могли быстрее и надежнее собирать, тестировать и выпускать релизы программного обеспечения. Концепция DevOps основана на построении культуры сотрудничества между командами, которые исторически работали в условиях относительной разрозненности. Среди ее преимуществ — рост уровня доверия, повышение скорости выпуска релизов программного обеспечения, быстрое устранение критических неполадок и готовность лучше справляться с внеплановой работой.

В Atlassian термин DevOps — второе по популярности слово-гибрид после «Бранджелины» (Брэд Питт + Анджелина Джоли). Здесь объединено все лучшее от разработки программного обеспечения и ИТ-операций. Наверное, это стоит пояснить (как мы пояснили нашу шутку). 

По сути, DevOps — это культура, направление, философия.

Это крепкое партнерство между командами разработчиков и операционными командами с упором на перестройке мышления, более продуктивном сотрудничестве и более тесной интеграции. Здесь объединяются agile-методология, непрерывная доставка, автоматизация и многое другое — все для повышения эффективности команд разработчиков и операционных команд, ускорения внедрения инноваций и формирования дополнительной выгоды от сотрудничества для организаций и клиентов.

История DevOps

Движение DevOps начало формироваться в 2007–2008 годах, когда сообщества специалистов по ИТ-операциям и разработчиков программного обеспечения, наконец, заговорили о серьезнейших проблемах, существующих в отрасли.

Они выступали против традиционной модели разработки программного обеспечения, предписывающей организационное и функциональное разделение между теми, кто пишет код, и теми, кто выполняет развертывание и поддержку этого кода.

У разработчиков и специалистов в сфере ИТ/операционной поддержки были разные и зачастую противоречащие друг другу цели, собственные руководители подразделений и ключевые показатели производительности, по которым оценивалась их работа. Их кабинеты зачастую располагались на разных этажах и даже в разных зданиях. Эти разрозненные команды волновали только собственные интересы, что приводило к сверхурочной работе, сорванным релизам и недовольству клиентов.

Но, как говорится, все можно изменить. Поэтому два сообщества объединились и начали переговоры. Возглавили их Патрик Дюбуа, Джин Ким и Джон Уиллис.

То, что однажды началось на онлайн-форумах и местных сходках, теперь стало актуальным трендом в области разработки ПО, и, возможно, как раз привело вас сюда. Вы и ваша команда видите, какой ущерб наносят разрозненность и нарушение коммуникации внутри компании.

Вы используете agile-методики для планирования и разработки, но по-прежнему сталкиваетесь с проблемами при выпуске кода. Вы кое-что слышали о DevOps и об его, можно сказать, волшебном действии на команды ИТ-специалистов, и подумали: «Хотелось бы мне воспользоваться этой магией!».

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

Благодаря принципу «инфраструктура как код» мы сделали в 10 раз больше сборок, не увеличивая численность команды. Майкл Найт, инженер по сборкам, Atlassian

В чем преимущества?

Сотрудничайте и выстраивайте доверительные отношения

Культура — залог успеха в DevOps. Построение культуры совместной ответственности, прозрачности и быстрой обратной связи — вот основа каждой высокопроизводительной команды DevOps.

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

Выпускайте релизы быстрее и работайте эффективнее

Скорость решает все. Команды, использующие DevOps, выпускают релизы чаще, при этом уровень качества и стабильность повышаются.

Недостаточное количество циклов автоматизированного тестирования и проверок не позволяет запустить релиз в работу, а медленное реагирование на инциденты снижает скорость и боевой дух команды. Из-за разрозненности инструментов и процессов повышаются операционные расходы, что приводит к переключению контекста и снижению динамики. Благодаря автоматизации и стандартизированным инструментам и процессам производительность повышается, релизы выпускаются чаще, а количество проблем уменьшается.

Решайте проблемы быстрее

Команда с самым быстрым циклом обратной связи — самая успешная команда. Благодаря полной прозрачности и эффективной коммуникации команды DevOps могут сокращать простои и решать проблемы невероятно быстро.

Если не устранять ключевые проблемы в кратчайшие сроки, удовлетворенность клиентов будет стремительно падать. При отсутствии открытого взаимодействия эти проблемы будут оставаться незамеченными, что приведет к росту напряженности и недовольства внутри команд. Открытое взаимодействие позволяет командам разработчиков и операционным командам вместе штурмовать проблемы, быстрее устранять инциденты и приводить конвейер релизов в действие.

Выполняйте внеплановую работу эффективнее

С внеплановой работой сталкивается каждая команда, и это явление зачастую отрицательно сказывается на производительности. Благодаря установленным процессам и четкой расстановке приоритетов команды разработчиков и операционные команды могут эффективнее справляться с внеплановой работой, не теряя из виду запланированные задачи.

Распределять внеплановую работу между различными командами и системами, дополнительно определяя приоритетность тех или иных элементов, не очень эффективно, к тому же это отвлекает специалистов от решения предстоящих задач. Однако в условиях повышенной прозрачности и упреждающей ретроспекции команды смогут предвосхитить и более эффективно распределить внеплановую работу.

Культура

Если попытаться описать культуру DevOps одним словом, этим словом станет «сотрудничество», а если парой слов — это будет «кроссфункциональное сотрудничество». (Хотя это уже больше похоже на три слова.)

Никакие инструменты и автоматизация не помогут, если нет искреннего стремления к совместной работе со стороны разработчиков и специалистов в области ИТ/операций. DevOps не решает проблемы с инструментарием — DevOps решает проблемы, связанные с человеческим фактором. Поэтому не стоит рассчитывать, что вы однажды подниметесь с рабочего места, оглянетесь по сторонам и обнаружите, что все команды в вашей компании уже исповедуют культуру DevOps. Для ее развития следует предпринимать определенные — довольно простые — действия.

Подход DevOps в целом похож на agile-методологию, только в нем учитывается наличие операционных команд. Одним из шагов в верном направлении станет формирование команд, ориентированных на проект или продукт, а не на выполнение определенных функций. Подумайте, какие умения понадобятся для реализации проекта — это может быть разработка, контроль качества, управление продуктом, дизайн, операционная деятельность, управление проектами и т. д. В Atlassian мы также включили маркетинг в сферу ответственности команд по выпуску продуктов.

Есть вещи, которые укрепляют сотрудничество: например, стремление к общей цели и наличие плана для ее совместного достижения. В некоторых компаниях внезапный переход к формированию проектных команд может стать слишком радикальной и преждевременной мерой. Поэтому нужно предпринимать более осторожные действия. Команды разработчиков могут (и должны) пригласить соответствующих членов операционных команд к участию в планировании спринтов, ежедневных стендапах и демонстрациях спринтов. Операционные команды могут пригласить к себе главных разработчиков. Так — легко и непринужденно — можно оставаться в курсе проектов, идей и проблем других команд. Время, затраченное на прослушивание и взаимовыгодный обмен знаниями в предметной области, вознаграждается за счет значительного повышения эффективности процессов управления релизами и экстренного устранения неполадок.

И раз уж речь зашла об экстренных ситуациях: они как нельзя лучше проверяют наличие культуры DevOps. Способны ли разработчики, операционные команды и служба поддержки вместе штурмовать проблему и решать ее, как одна команда? Все ли исходят из предположения, что их коллеги приняли наилучшие решения с учетом имеющейся на тот момент времени информации и доступных ресурсов? В ходе анализа причин неудачи делается ли акцент на вопросах восстановления процессов вместо того, чтобы искать виноватых? Если ответ на эти вопросы «Да», значит, в основе действий вашей команды лежит культура DevOps.

Обратите внимание: наиболее успешные компании используют культуру DevOps в каждом отделе и на всех уровнях организационной структуры. У них есть открытые каналы для коммуникации, команды часто общаются. Они следят за тем, чтобы все цели были согласованы, и вносят необходимые корректировки. Они руководствуются принципом, что удовлетворенность клиента в равной степени зависит от усилий команды по управлению продуктами и команды разработчиков. Они понимают, что DevOps — задача не для конкретной команды. Это задача для всех сотрудников.

Автоматизация

Инвестирование в автоматизацию позволяет устранить монотонную ручную работу, сформировать воспроизводимые процессы и создать надежные системы.

Создание сборок, тестирование, развертывание и реализация автоматизации — вот с чего обычно начинают команды, еще не использующие эти принципы в работе. И еще: какая цель может сплотить разработчиков, тестировщиков и операторов лучше, чем построение систем, пользу от которых получат все участники процесса?

Команды, ранее не использовавшие автоматизацию, обычно начинают с непрерывной доставки — метода, предполагающего прогон каждой правки кода через серию автоматизированных тестов, часто использующих облачную инфраструктуру, и последующую упаковку успешных сборок с дальнейшим перемещением на рабочий сервер с помощью автоматизированных развертываний. Как вы, наверное, уже догадались, организация непрерывной доставки — процесс достаточно трудоемкий, но возврат инвестиций, получаемый с ее помощью, стоит этих усилий.

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

Еще одно важное преимущество DevOps — использование принципа «конфигурация как код». Разработчики стремятся создать модульные приложения с возможностью компоновки: такие приложения надежнее, да и обслуживать их удобнее. Этот принцип применим и к инфраструктурам, в которых расположены приложения, — как к облачным, так и к локальным сетевым ресурсам компании.

Конечно, системы меняются — это неизбежно. Но с помощью кода распределения можно создать неизменяемый интерфейс: тогда на повторное распределение вышедшего из строя сервера потребуется меньше времени, чем на его ремонт, да и уровень надежности будет выше. Это также позволит снизить риски. С помощью кода распределения команды разработчиков и операционные команды могут внедрять новые языки или технологии. Проблемы совместимости станут видны сразу, а не будут проявляться в процессе подготовки релиза.

«Конфигурация как код» и «непрерывная доставка» — этим варианты автоматизации в мире DevOps не ограничиваются, но они заслуживают отдельного упоминания, так как позволяют улучшить взаимодействие между разработчиками и операционными командами. И когда DevOps использует автоматизированные развертывания для отправки тщательно протестированного кода в идентично сконфигурированные среды, проверка работоспособности ПО на отдельных машинах теряет свою актуальность.

Бережливость

При упоминании слова «бережливый» в контексте программного обеспечения на ум сразу приходят мысли об устранении действий с низкой полезностью и ускорении процессов — то есть о том, как стать более решительными, не потеряв гибкости. Еще более актуальными для DevOps являются понятия непрерывного совершенствования и принятия поражений.

Люди с мышлением DevOps везде видят возможности для непрерывного совершенствования. Некоторые возможности — например, проведение регулярных ретроспектив в целях совершенствования процессов в вашей команде — лежат на поверхности. Другие — например, раздельное тестирование различных подходов к сопровождению новых пользователей вашего продукта — не столь очевидны.

Благодаря agile-разработке идея о непрерывном совершенствовании стала модной. Первые приверженцы agile-методики доказали, что простой продукт, отданный клиенту сегодня, гораздо ценнее идеального продукта, отданного клиенту через полгода. Если продукт постоянно совершенствуется, клиент будет и дальше использовать его.

Кстати, вы знаете, что неудачи неизбежны? Поэтому стоит учить свою команду принимать поражения, восстанавливаться после них и делать соответствующие выводы (некоторые называют этот процесс «антихрупкостью»). Мы в Atlassian считаем, что если вы периодически не сталкиваетесь с неудачами, значит, вы работаете не в полную силу.

Мы ставим перед нашими командами серьезные, сложные и смелые цели, предоставляя им свободу действий и все необходимые ресурсы. Мы нанимаем умных и амбициозных людей и понимаем, что иногда они могут совершать ошибки.

В контексте DevOps сбои не рассматриваются как проступки, за которые последует наказание. Команды руководствуются принципом, что однажды все может пойти наперекосяк, поэтому при выполнении сборки закладывается возможность быстрого обнаружения проблем и незамедлительного восстановления. (Изучите отличный пример — Chaos Monkey от Nexflix.) Во время рассмотрения аварийных ситуаций акцент делается на местах «падения» процессов и путях их укрепления, а не на поиске виноватых. Почему? Потому что непрерывное улучшение и сбои тесно связаны между собой.

В рамках развития DevOps осуществлялась передача функций операционных команд командам разработчиков — и именно так работает Chef. Мы больше не можем самоустраняться от участия в процессе. Наши инженеры несут ответственность за контроль качества, написание кода и проведение собственного тестирования для отправки ПО клиентам. Джулиан Данн, менеджер по продукту, Chef

Измерения

При отсутствии данных сложно подтвердить, что усилия, затраченные на непрерывное улучшение, действительно приносят какие-то плоды. К счастью, существует множество инструментов и технологий измерения производительности: продолжительность работы пользователей с продуктом, количество продаж, вызванных публикацией в блоге, или частота появления в логах сообщений о критических ошибках.

Измерить можно практически все. Но это не значит, что вам обязательно нужно измерять все показатели. Давайте обратимся к agile-разработке и начнем с основ.

  • Сколько времени проходит от разработки до развертывания? 
  • Как часто ошибки или сбои возникают повторно?
  • Как долго выполняется восстановление после системного сбоя?
  • Сколько человек использует ваш продукт в настоящее время?
  • Каким был приток/отток пользователей на этой неделе?

При наличии прочного основания проще фиксировать более сложные показатели по использованию возможностей, циклам взаимодействия с клиентом и соглашениям об уровне обслуживания (SLA). Полученные данные пригодятся при разработке планов действий и определении дальнейших шагов.

Благодаря этим замечательным данным вашей команде будет проще принимать решения, и, что еще важнее, этой информацией можно делиться с другими, в частности, с командами других подразделений. Например, ваша маркетинговая команда хочет получить новые крутые возможности для продажи. Но в данный момент вы наблюдаете высокий отток клиентов из-за значительного технического долга в продукте. Подкрепите план действий пользовательскими данными (даже если продукт требует большого количества исправлений при малом количестве функций) — тогда достигнуть консенсуса, а также получить одобрение со стороны участников процесса будет проще.

DevOps — это задача не для одного человека. Это задача для всех сотрудников. Кристоф Кэйпел, старший менеджер по продукту, Jira Service Desk

Обмен

Извечный конфликт между командами разработчиков и операционными командами обусловлен отсутствием общих целей. Мы полагаем, что совместная ответственность и разделение успехов помогут значительно сгладить имеющиеся разногласия. Отношение к разработчикам сразу улучшится, если они помогут операционной команде выполнять одну из самых тяжелых задач: работать со списком заявок. DevOps руководствуется идеей, что выпуск и обеспечение работы приложения должны осуществляться теми же людьми, что выполняли его сборку.

Это не значит, что вам нужно нанять разработчиков, и они по мановению волшебной палочки сразу станут отличными операторами. Это значит, что разработчикам и операторам нужно взаимодействовать на каждом этапе жизненного цикла приложения.

В командах, использующих DevOps, часто вводится совмещенная должность, в рамках которой разработчики решают проблемы, выявленные конечными пользователями, и одновременно выявляют и устраняют неполадки в рабочей версии продукта. Такие специалисты занимаются решением срочных проблем, выявленных клиентами, при необходимости создают патчи и работают в бэклоге с неисправностями, выявленными клиентами. «Разработчик на поддержке» получает обширную информацию о работе приложения в реальных условиях. А благодаря его высокой доступности для операционной команды между командами разработчиков возникает доверие и взаимное уважение.

Если вместе преодолевать препятствия, коллективная победа будет слаще для всех. Вы поймете, что культура DevOps установилась в вашей компании, когда в день релиза команда разработчиков угостит операционную команду булочками.

Положительные отзывы от коллег мотивируют нас не меньше, чем премии или карьерные амбиции. Публичное признание заслуг коллеги, обнаружившего серьезную ошибку до того, как она попала в финальный продукт, значит многое. Если в вашем подразделении есть отдельный бюджет на поощрение сотрудников, используйте его!

Готовы познакомиться с DevOps?

Знакомство