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

Рисунок: цикл Devops

Что такое DevOps?

DevOps — это набор методик, которые помогают автоматизировать и интегрировать процессы команд разработчиков и ИТ-специалистов, чтобы они могли быстрее и надежнее собирать, тестировать и выпускать релизы программного обеспечения. Термин DevOps создан из двух слов — development (разработка) и operations (операции). Он отражает изменение культуры разработки и стремление компании преодолеть разрыв между командами разработчиков и операционными командами, которые до сих пор функционировали изолированно друг от друга. 

Знак бесконечности Atlassian DevOps

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

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


DevOps — это задача не для одного человека. Это задача для всех сотрудников.

Кристоф Кэйпел
старший менеджер по продукту Jira Service Desk

Логотип Chef.io

Кто использует DevOps?

Chef — компания, разработавшая платформу Chef Automate для рабочих процессов DevOps. Десятки тысяч разработчиков используют решения Chef для тестирования, автоматизации и управления инфраструктурой. Эта австралийская компания с головным офисом в Сиэтле возглавляет эволюционное движение DevOps. Она выпустила такие продукты, как Chef, InSpec, Habitat и Chef Automate, предоставляющие новые возможности для разработки и выпуска программного обеспечения и приложений. Для проведения экспериментов и совершенствования собственных методов DevOps компания Chef выбрала платформу Atlassian.

История DevOps

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

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

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

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

Вы используете методики agile для планирования и разработки, но по-прежнему сталкиваетесь с проблемами при выпуске кода? Возможно, вы кое-что слышали о DevOps и его почти волшебном действии на команды. По данным опроса, проведенного компанией Atlassian¹ среди 500 специалистов по DevOps, почти все (99 %) команды DevOps уверены в успехе своего кода, передаваемого в рабочую среду. 

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

В отличие от топ-менеджеров, специалисты по DevOps «на местах» скорее согласятся с тем, что трудно измерить влияние успехов в освоении методологии DevOps. С этим утверждением согласны 62 % специалистов и 46 % руководителей высшего звена.

Опрос Atlassian среди специалистов сферы DevOps

Преимущества

Значок: связи между людьми

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

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

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

Значок: спидометр

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

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

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

Значок: биение сердца

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

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

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

Значок: инструменты

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

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

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

Платформа CALMS для DevOps

CALMS — это платформа для оценки готовности компании к внедрению процессов DevOps, а также способ измерения успешности внедрения DevOps. Эту аббревиатуру придумал Джез Хамбл, один из авторов книги The DevOps Handbook. Она расшифровывается так:


Значок: джерси

Культура

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

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

DevOps можно рассматривать как развитие команд agile — однако в нем учитывается наличие операционных команд. Шагом в верном направлении будет формирование команд, ориентированных на проект или продукт, а не на выполнение определенных функций. Подумайте, какие умения понадобятся для реализации проекта — это может быть разработка, контроль качества, управление продуктом, дизайн, операционная деятельность, управление проектом и т. д. Не стоит поручать все одной команде или нанимать «профессионалов DevOps»; гораздо важнее сформировать проектные команды, которые будут эффективно сотрудничать.  

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

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

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

Рисунок: шестеренки

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

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

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

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

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

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

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

Значок: бережливость DevOps

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

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

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

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

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

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

Рисунок: линейка

Измерения

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

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

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

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

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

Рисунок: пузырьки сообщений

Обмен

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

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

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

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

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

Если вы хотите узнать подробнее об опросе, который проводился совместно с Cite Research, свяжитесь с нами по адресу press@atlassian.com.

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