Это модное слово DevOps

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

Этот обзор – видение «Онланты» материала зарубежных коллег. Каким же должен быть настоящий DevOps? Разбираем в этой статье.

Истинная методология DevOps


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

Что улучшает DevOps?
Истинная методология DevOps увеличивает эффективность рабочего процесса, сокращает срок выпуска продукта на рынок и повышает качество продукта по ряду причин.

Интересы тех, кто пишет программное обеспечение и тех, кто его запускает, совпадают, так как это одни и те же люди.

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

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

«НеDevOps»

Сколько признаков не DevOps вы сможете отметить в своей компании?

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

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

Когда-то давно этих людей называли системными администраторами или менеджерами конфигураций. Они кое-что знали о Linux и внедряли код в окружение. Сегодня если вы сисадмин, который знаком с понятиями Puppet/Chef/Salt/Ansible/kubectl, то поздравляем — вас можно называть DevOps и повысить зарплату на 50%! 

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

• Создавать конвейер CI/Jenkins job
• Создавать Git-репозиторий
• Создавать образ Docker из их кода
• Развертывать их код в окружении
• Извлекать журналы событий исполняющейся копии программы

Если специалисты запрашивают такую помощь, то… у вас реализован не DevOps!
Если в компании существует «не DevOps», то бизнес не получает тех преимуществ, которые бы мог.

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

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

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

А если у нас уже есть команда DevOps — что теперь делать?
Дайте этим людям обеспечить разработчиков возможностью самообслуживания путем воспроизводимой автоматизации.

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

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

Если у вас есть такая команда DevOps, которая делает правильные вещи, описанные выше, то почему вы называете их «командой DevOps»? Разе не следует назвать ее в честь продукта, который команда предоставляет?

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