Перевод статьи Олега Скрынника The biggest problem with DevOps is the name

Статья в Википедии, посвящённая DevOps, начинается с заявления о том, что DevOps – это слияние слов «разработка» и «эксплуатация». Таким образом, это методология, которая объединяет разработку программного обеспечения (Dev) с эксплуатацией ИТ (Ops). Оно, конечно, верно, если мы рассматриваем морфологию и орфографию. Никто не станет спорить, что три первых буквы (или около того) каждого из двух слов использовались для обозначения термина.

К сожалению, этого недостаточно, чтобы объяснить, что такое DevOps на самом деле. Из-за этого самого термина DevOps часто воспринимается неправильно, с очень небольшой добавленной ценностью. Позвольте мне рассказать про три взгляда на DevOps, которые я встречал.

Первый взгляд, упрощённый

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

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

Решением, конечно же, является гибкая разработка программного обеспечения. Разработчик может работать с небольшими инкрементами, предоставляя заказчику части решения для получения ценной обратной связи, а затем изменять ход разработки в соответствии с новыми требованиями и идеями. Большинство команд будут называть эти итерации «спринтами», назначать кого-то со стороны клиента «владельцем продукта», собираться каждые две недели для «ретроспективы»: вот у вас и появился Scrum – неплохая штука, но и не единственный Agile-метод.

Но как насчёт ИТ-эксплуатации? Не стоит волноваться! У разработчиков будет пара человек, чтобы установить новую версию программного обеспечения в продуктивную среду. Несколько лет назад эти ребята из эксплуатации работали медленно и, по большей части, вручную. Теперь же у них есть CI, CD, конвейеры, облака, контейнеры и другие современные модные штуки, чтобы ускорить развёртывание программного обеспечения. На большинстве конференций и мероприятий по Agile Вы встретите подобный упрощённый и удобный взгляд: DevOps – это просто использование специальных программных инструментов для построения конвейера CI/CD, когда новая версия программного обеспечения готова к развёртыванию.

Неудивительно, что это представление приносит очень мало пользы. Многие Agile-команды борются с долгими сроками развёртывания программного обеспечения и с огромными простоями при внесении изменений в продуктивную среду. Следовательно, снижаются все преимущества быстрой и гибкой разработки ПО.

Второй взгляд, получше, но всё же «мы можем ещё постараться»

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

Современные разработчики хотят развертывать программное обеспечение быстро, выпуская его в продуктив каждый спринт (в случае Scrum) или даже постоянно, каждый день или несколько раз в день (в случае Канбан). Чем чаще выпускаются релизы – тем выше оценивается работа аналитиков, программистов, тестировщиков – всей команды разработки. Как правило, определены некоторые ключевые показатели эффективности, которые отражают следующее: чем больше изменений, тем лучше; поддерживайте быстрый темп; разворачивайте новые версии чаще; обеспечивайте быструю обратную связь.

С другой стороны, сотрудники эксплуатации очень беспокоятся о стабильности. ИТ-инфраструктура хрупка; мы склонны не трогать её часто. Чем меньше релизов мы делаем, тем выше время бесперебойной работы. Каждый релиз – огромная боль, мы знаем по опыту что всё может пойти не так, как надо, и наверняка так и будет. Поэтому сотрудники эксплуатации тратят много времени и усилий для того, чтобы релиз заработал в среде эксплуатации. Для полной картины добавлю, что типовые KPI для эксплуатации включают в себя такие вещи, как время бесперебойной работы, MTBF, MTTR и тому подобное. Поэтому, чем меньше изменений – тем лучше работает подразделение эксплуатации. Разработчики, пожалуйста, дождитесь согласованного времени выпуска релиза в следующем квартале, потому что у нас есть политика релизов, которая защищает нашу ИТ-инфраструктуру.

Итак, возникла ещё одна стена, на этот раз между разработкой и эксплуатацией.

Решение этой проблемы можно найти в DevOps. В самом деле, если бы мы могли как-то управлять разработчиками и сотрудниками эксплуатации, так чтобы они: сидели вместе, работали бы как единая команда, использовали бы одни и те же инструменты и методологии, то тогда мы могли бы найти некоторые возможности не только для быстрой и частой разработки программного обеспечения, но и быстрого и частого развертывания. Этот взгляд на DevOps можно обобщить следующим образом: DevOps – это средство для совместной работы разработчиков и сотрудников эксплуатации в одном направлении для быстрого, частого и надёжного развёртывания программного обеспечения. Такая точка зрения, выраженная несколькими уважаемыми международными экспертами, гораздо полезнее, чем предыдущая. Тем не менее, можем ли мы добиться большего? Оказывается, да.

Финальный, целостный взгляд

Есть две большие проблемы с предыдущим сценарием. Во-первых, всё почему-то завершается на сотрудниках эксплуатации (справа на картинке),  в то время как на самом деле программное обеспечение используется конечными пользователями, и большую часть отзывов мы получаем именно от них. Это довольно странно – не включать пользователей в общую картину, от этого она определённо будет неполна.

Вторая проблема ещё больше. Из опыта мы знаем, что очень трудно создать один гибкий процесс из двух совершенно разных методологий и наборов инструментов – Agile и DevOps (в прошлом сценарии). Известны неудачные попытки: потрачены время, деньги, усилиям, а польза и выгода невелика. Глядя на картину выше, мы должны как-то убрать не только стены, но и сами стрелки.

Нам нужен унифицированный и единый процесс для разработки и развертывания программного обеспечения.

Такое представление, в котором DevOps – это непрерывное скоростное течение работы в едином потоке создания ценности для конечных пользователей, основанное на идеях и методологиях Agile и Lean, позволяющее быстро получать обратную связь. Обратите внимание на то, что в предложении выше не упоминается ни разработка, ни эксплуатация. На мой взгляд, более важно понимать, что поток начинается от бизнеса и заканчивается бизнесом. Dev и Ops, конечно же, включены в поток, как и аналитики, дизайнеры UI/UX, DBAs, ребята из безопасности и все, кто требуется для создания современных программных решений.

Заключение

Достаточно трудно осознать последнее определение, просто взглянув на термин «DevOps». Пришлось прочитать целую статью, чтобы понять, что же означает DevOps и какие проблемы помогает решить. Будучи прагматичным, я отношусь к ITIL/ITSM, COBIT, PRINCE2, TOGAF, Agile, Lean и, конечно же, DevOps, как к инструментам в моем наборе. Я могу выбрать лучшее решение для клиента в зависимости от поставленной проблемы.

Интересно, что потребовалось несколько десятилетий для того, чтобы по достоинству оценить ITSM (управление ИТ-услугами) и, в конце концов, понять, что это не просто, когда «ИТ предоставляет услуги, работая по процессам». Компании, использующие ITSM помимо Service Desk, каталога ИТ-услуг и SLA, добиваются получения больших преимуществ от методологии, обеспечивая высокую ценность для бизнеса.

Я искренне надеюсь, что понимание и принятие DevOps займёт значительно меньше времени. Этот новый инструмент  перспективен и уже приносит значительные результаты.

Более подробную информацию по этой теме можно найти в моей книге «DevOps для ИТ-менеджеров» и на учебном курсе «Основы DevOps».

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы