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

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

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

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

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

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

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

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

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

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

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

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

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