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

По данным отчета компании RightScale, разрабатывающей ПО в сфере универсального управления облачными инфраструктурами, в этом году к применению тех или иных практик DevOps перешло 84% крупных компаний и 72% компаний СМБ. Привлекательность DevOps легко объяснима: из числа её преимуществ можно выделить повышение гибкости компании, улучшение удовлетворенности клиентов, формирование духа командного сотрудничества в коллективе, что влияет на производительность труда и в конечном итоге приводит к росту бизнес-показателей.

Но значит ли это, что если компания переходит на рельсы DevOps, то она автоматически получает эти преимущества? Ответ на этот вопрос можно найти в исследовании, проведённом компанией Puppet в прошлом году. И этот ответ — вовсе нет: если вы неэффективно внедряете DevOps — на позитивные сдвиги можете не рассчитывать. Более того, разрыв между эффективным и малоэффективным применением практики очень значительный. В исследовании говорится, что объём кода, поставляемый эффективно «настроенными» командами разработчиков, зачастую в 200 раз превосходит объём, который удается выдавать на гора командам, которые должным образом не обучены или работают не слаженно.

Профессиональные DevOps-команды в 24 раза быстрее восстанавливаются после сбоев и в три раза реже получают проблемы при внесении изменений. Помимо этого они тратят на 22% меньше времени на незапланированные работы и переработки и имеют на 29% больше времени для новых разработок; на борьбу с проблемами безопасности они тратят на 50% меньше времени. Согласно результатам исследования, сотрудники компаний, которые применяют DevOps, в 2,2 раза чаще рекомендуют друзьями и знакомым своих работодателей как место работы, плюс они гораздо сильнее вовлечены в работу компании и довольны жизнью.

Наконец, в отчёте CA Technologies «Accelerating Velocity and Customer Value with Agile and DevOps», отмечается, что с помощью внедрения DevOps передовые компании сумели на 26% сократить ИТ-расходы и на 31% повысить эффективность работы и операционные процессы. Помимо этого им удалось улучшить опыт работы с клиентами (на 23%), создать более качественные приложения (на 33%), повысить производительность труда (на 30%), качество найма нового персонала и его заинтересованность в работе поднялись на 31%. Рост этих показателей сказался на общем росте бизнеса — он вырос на 37%. Двухзначные показатели роста наверняка привлекут к DevOps и без того повышенное внимание, но чтобы их достичь — нужно не повторять чужих ошибок.

Издание InformationWeek приводит девять наиболее распространенных ошибок, которые совершают компании-новички при внедрении DevOps.

1. Акцентирование на скорости вместо качества. Многие организации ставят своей первостепенной задачей уменьшение количества затраченного времени на разработку и внедрение нового кода, однако эксперты считают такой подход неправильным, говоря, что увеличение скорости влечет за собой потерю качества. В конце концов, некачественный код приносит мало пользы (если не наносит вреда) — какой смысл спешить? Чтобы поддерживать разработку на высоком уровне, советуют специалисты, команды разработчиков должны проводить тестирование кода на ранних этапах. Такая практика называется «смещением влево». Как показывает выпущенный в этом году отчет Dimensional Research, лишь 17% компаний проводят различные тесты и проверки кода на предварительном этапе внедрения.

2. Редкое развертывание кода. Выше говорилось, что в погоне за скоростью разработки страдает качество, но промедления и задержки также не лучшим образом сказываются на разработке. В отчёте Puppet говорится, что наиболее успешные команды способны производить развертывание кода по нескольку раз в день, тогда как менее производительные коллективы могут делать это ежемесячно или хуже того — несколько раз в год. Эксперты подсчитали, что эффективные команды в среднем обновляют код 1460 раз в год, тогда как уступающие им в скорости коллеги делают это лишь семь раз в год. Способность к скорострельному развертыванию влечет за собой более быструю реакцию на выполнение заказов: эффективные команды реагируют на них в 2555 раз быстрее, чем менее активные исполнители.

3. Затянувшийся эксперимент. Большинство экспертов советует начинать эксперименты с DevOps, довольствуясь незначительными внедрениями. По данным RightScale, в основном компании следуют этому совету: только 30% предприятий внедряют методологию на уровне всей компании, тогда как 28% стыкуют её на уровне бизнес-подразделений или дочерних структур и ещё 27% применяют DevOps только для отдельных проектов или команд. Исследование другой компании, Sauce Labs, показывает несколько другие данные: подход к разработке кода и развертыванию приложений по методологии DevOps по всему периметру инфраструктуры применяют 10% предприятий.

Но начав с малого, не следует на этом останавливаться. В обзоре CA Technologies говорится, что только около трети предприятий достигли зрелости при работе с методикой DevOps. Следствием неудач стала половинчатость внедрений — компании попросту недооценили преимущества методики и не смогли внедрить её более широко. Отсюда — перерасход средств, замедление роста, задержки развертывания приложений и снижение пользовательской удовлетворенности.

4. Нежелание менять корпоративную культуру. Многие предприятия, которые уже применяют DevOps-методологию, не всегда получают ожидаемые результаты. Эксперты единодушны: этому препятствуют традиционные методы софтверной разработки, тогда как более современный подход влечёт за собой смену корпоративной культуры в компании. Участники опроса, проведенного CA Technologies, прояснили ряд деталей, которые препятствуют успешному внедрению DevOps. 34% опрошенных заявили, что этому мешают образ мышления и корпоративная культура; в качестве причин, тормозящих принятие DevOps, ещё 28% указали, что ими являются косность мышления и непонимание сути технологии высшим руководством компании. Если предприятие хочет достичь значимых успехов, её руководителям нужно подавать пример подчиненным и оказывать им всяческую поддержку.

5. Идти напролом, не имея достаточного опыта и подготовки. DevOps — это не столько техника разработки, сколько культура отношений, которую нужно взращивать в коллективе. Обычно это происходит тогда, когда между командами разработчиков хорошо налажена связь, в иных случаях требуются тренинги. В отчёте SdxCentral под названием «Облачная автоматизация и DevOps» за 2016 г. говорится, что 68% организаций ссылаются на отсутствие экспертизы. Сходные результаты дает исследование CA Technologies: 32% опрошенных компаний заявили, что на пути к внедрению DevOps они сталкиваются с недостающими навыками и отсутствием опыта. Исправить эту ситуацию может планомерное инвестирование в обучение программистов или наём опытных практиков — такой подход сгладит процесс адаптации методологии. Отсутствие практики и обученных специалистов сведёт на нет имплементацию DevOps на вашем предприятии.

6. Автоматизация полумер. В истории DevOps имело место одно очень неудачное развертывание. Сотрудник ИТ-службы компании Knight Capital вручную установил на восьми серверах новое ПО для торговли. Всё бы ничего, но на одном из них работник забыл установить софт. В итоге серверы стали постепенно выходить из строя, что привело к убыткам на сумму в 440 млн. долл. В результате инцидента акции Knight Capital обесценились.

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

7. Неправильные инструменты. Каждая работа требует соответствующего инструмента. DevOps — не исключение. Как гласят данные опроса CA Technologies, в качестве одного из наибольших препятствий для внедрения методики 36% респондентов обозначили интеграцию правильных инструментов и техник, ещё 35% посетовали на сложность выбора инструментов. Приобретение инструментов непрерывного развертывания или развертывание Docker не имеет смысла без их тонкой подстройки инструментов автоматизации. Только должным образом настроенная среда разработки, требуемые именно вам инструменты позволяют ощутить все преимущества DevOps. Непременный залог успеха — отвязка при выборе софта от жестких корпоративных политик. В случае DevOps он должен подходить команде, а не спускаться по приказу.

8. Избыточное разветвление разработки. Создание мастер-кода или магистрального кода взамен применения бранчинга (ветвления кода) для параллельной разработки — один из основополагающих принципов в методологиях Agile и DevOps. Программистам, привыкшим к традиционным методам разработки и желающим испытать свои силы в DevOps, придется изменить своим привычкам. К тому же предотвращение растекания кода может быть весьма эффективным. В отчёте Puppet говорится: «Наличие кодовых разветвлений или форков в количестве не больше трёх и непременно с очень коротким жизненным циклом (до одного дня) является важным аспектом непрерывной разработки и способствует более высокой производительности. Этому также способствует ежедневное слияние промежуточного кода в мастер-код».

9. Пренебрежение безопасностью. Как показывает практика, одной из самых больших проблем для DevOps-команд остается безопасность. 38% опрошенных CA Technologies посчитали её проблемой № 1 при внедрении DevOps. Тем временем в исследовании Puppet говорится, что высокопроизводительные команды тратят наполовину меньше времени на выявление уязвимостей, чем их более медлительные коллеги. Удаётся им это за счёт того, что они объединяют свои задачи в области безопасности ещё на ранних стадиях разработки.