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

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

Популяризация гибких методологий позволила ИТ–компаниям ускорить темп разработки за счет выстраивания всесторонней и регулярной коммуникации между командами.

Development & Operations (Разработка и Эксплуатация)

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

DevOps позволила сделать так, чтобы действия команд были согласованы. Тогда решалось сразу несколько проблем и задач:

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

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

• Руководство может отслеживать прогресс разработки, следить за тем, где есть слабые места, требующие вмешательства.

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

• Вся нагрузка распределена равномерно. Есть возможность назначать ответственных лиц в соответствии с их квалификацией и отслеживать личные показатели.

• Легче документировать все стадии выполнения проекта. Это может пригодиться для повторного использования, обучения новичков и создания отчетности.

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

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

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

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

Поэтому иметь команду разработки хоть и затратнее, но эффективнее.

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

Постоянная интеграция.

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

Автоматизация позволила не только ускорить процесс разработки, но и сократить количество ошибок и багов.

Постоянная поставка и развертывание.

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

Ошибка может произойти только в том случае, если тест завершился неудачно**.**

Постоянное тестирование.

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

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

Известными инструментами для автоматического тестирования можно назвать:

• Selenium – автоматизирует действия веб–браузера. Обычно его используют для тестирования веб–приложений.

• Travis – выступает в качестве хостинга для Open Source ИТ–сообщества. Поддерживает большое количество языков программирования.

• Appium – фреймворк для тестирования мобильных приложений. Имеет открытый код. На заре существования использовался для Android и iOS, но со временем возможности расширились за счет WAD–драйвера, который позволил проводить автоматическое тестирование десктопных Windows–приложений.

Постоянное наблюдение.

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

В качестве метрик эффективности могут быть использованы такие показатели, как:

• степень использования центрального процессора и памяти;

• степень использования дискового пространства;

• соблюдение политики безопасности;

• поведение и действия клиентов.

Нередко для постоянного наблюдения используются такие инструменты, как:

• Nagios – ИТ–продукт с открытым кодом, предназначенный для мониторинга разного типа сетевых устройств. В случае, если какой–то из узлов теряет показатели функциональности, Nagios оповещает об этом, чтобы команда разработчиков могла предпринять необходимые меры.

• Sensu – гибкий фреймворк, обеспечивающий сбор и накопление статистики работы серверов.

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

Инфраструктура как код.

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

Микросервисы.

Микросервисная архитектура нередко используется в DevOps, так как является довольно удобным решением. Для этого существует несколько причин. А именно:

Дает возможность независимого управления ресурсами в рамках компонентов.

Система не имеет общей точки отказа, поэтому становится более доступной.

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

Взаимодействие микросервисов осуществляется через легковесный интерфейс или API.

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

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

Сотрудничество.

Dev- и Ops- команды постоянно взаимодействуют друг с другом. Для DevOps методологии это предоставляет несколько возможностей. Например, таких как:

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

Разработчики получают обратную связь от команды поддержки и учитывают их замечания при написании кода. Это позволяет предотвратить некоторые ошибки.

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

Распределенные операционные обязанности.

Ops выступает инфраструктурой как услуга.

Данная топология внедряется в компаниях с классической ИТ–структурой, но некоторые из их служб расположены в облачных сервисах. Важно условие, что перестройка в ИТ–отделе не подразумевается.

DevOps является внешним сервисом.

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

Временные DevOps–команды.

Ещё одна вариация сотрудничества, когда команды Dev- и Ops- объединяют усилия для достижения общей цели, но лишь временно. Например, компания принимает участие в крупном и сложном проекте, но для усиления команды привлекает дополнительных членов, которые оказывают поддержку. После того, как цель достигнута и проект отдан в эксплуатацию, команда распускается. Дальнейшее сопровождение продукта осуществляется компанией–организатором.

DevOps advocacy.

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

SRE–команда.

Топология придуманная Google. Они добавили в структуру отдельную команду, которая занимается Site Reliability Engineering – проектированием надежности сайта. Задача разработчиков — доказать группе SRE, что их продукт соответствует установленным стандартам. В то время, как команда Site Reliability Engineering имеет возможность откатить изменения и потребовать доработок.

Dev и DataBase Administrator.

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

В этом случае и Dev, и DBA команда определяют взаимосвязанных между собой сотрудников, несущих ответственность за БД. Таким образом устраняется разрыв между этими группами.

Чтобы ещё больше углубиться в понимание методологии, разберемся в том, как она отражается на разных этапах работы над проектом.

Планирование.

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

Разработка.

По написанному ранее техническому заданию, разработчики пишут код и создают сырой программный продукт. На этом этапе DevOps выступает в качестве интегрированной среды разработки (IDE), а также репозиторием с исходными кодами. Здесь же осуществляется покрытие разрабатываемого продукта функциональными и unit–тестами. В целом, мы помним, что каждый этап создания нового ПО или приложения в DevOps сопровождается тестированием на протяжении всего жизненного пути.

Сборка.

Собранный сырой программный продукт после прохождения всех проверок в реестр скомпилированных приложений, ПО, или артефактов.

Тестирование.

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

Создание релиза.

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

Развертывание.

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

Мониторинг.

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

• Performance Monitoring – мониторинг инфраструктуры, серверов, использование процессора, памяти и прочих измеряемых показателей.

• Application performance – осуществляется проверка производительности и доступности программного обеспечения или приложения.

• Business Activity Monitoring – проверка практической пользы программного продукта, соответствует ли он тем целям и задачам, которые были поставлены на этапе планирования.

Какими вопросами должна задаться компания, прежде чем внедрить DevOps в свою структуру?

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

• «Зачем?» – Этот вопрос помогает понять, какую боль решает компания внедряя методологию DevOps.

• «Какую мы получим выгоду?» – расширяет предыдущий вопрос и заставляет ответить ещё более развернуто. Вряд ли компания гонится только за решением проблем. Она стремится к получению выгоды, потому что придется приложить немало усилий для внедрения, а они должны оправдать ожидания и окупиться.

• «Как изменения отразятся на командах?» – вопрос, который заставит задуматься о том, какая реакция будет со стороны сотрудников, привыкших к определенному порядку вещей.

• «Есть ли среди ключевых фигур люди, которые будут оказывать большое сопротивление?» – позволяет предусмотреть некоторые действия со стороны сотрудников. Если в коллективе есть авторитетные фигуры, то они в первую очередь должны поддержать перемены. Однако, если среди них находятся те, кто выступит явно против, то здесь нужна продуманная стратегия ответных действий. Такой человек может настроить команду против руководства, тогда переход на новую систему управления рискует сильно затянуться.

«На кого можно положиться в процессе перехода?»

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