DevOps не умер, нет. Но ему плоховато

Некоммерческая организация Continuous Delivery Foundation ^[1] (далее — CDF) сообщает о том, что DevOps‑инициативы, похоже, зашли в тупик.

На саммите Open Source Summit (OSSummit) North America ^[2], одним из организаторов которого выступил CDF ^[1], в рамках конференции cdCon ^[3] был представлен пятый ежегодный отчет State of CI/CD Report ^[4]. В нем сообщается, что, хотя 83% разработчиков и применяют DevOps‑практики, тем не менее растет доля специалистов с низкими показателями в метриках развертывания — это тревожное наблюдение.

Что же это означает? Разбираемся под катом.

Есть ряд задач, так или иначе, связанных с программным обеспечением. Суть DevOps в том, чтобы помогать разработчикам и системным администраторам выполнять их быстро и эффективно. Однако на практике этого не происходит.

Компания SlashData в рамках исследования Developer Nation опросила десятки тысяч разработчиков. Оказалось, что только 14% опрошенных способны доставить код в production за день. Этот показатель практически не изменился с третьего квартала 2020 года, когда та же SlashData впервые включила данный вопрос в свои исследования.

Если говорить о возможности развертывать код по несколько раз в день, то здесь все еще хуже. Доля таких специалистов даже сократилась — с 11% в 2020 году до 9% сейчас.

Лишь 11% пользователей DevOps сообщили, что способны восстановить работу сервиса менее чем за час.

Но разве не в этом цель CI/CD? Да, именно так — непрерывная интеграция и непрерывная же доставка.

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

Лишь 11% DevOps‑инженеров способны восстановить сервис менее чем за час. Да, это непростая задача. Однако ситуация ничуть не улучшилась по сравнению с тем, что было несколько лет назад. Хуже того, в наши дни 41% опрошенных заявляют, что на восстановление сервиса уходит больше недели. Для сравнения, в 2020 году доля таких респондентов была лишь 34%.

Так в чем же заключается проблема?

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

Иными словами: практики DevOps, вероятно, привели к тому, что скорости разработки проектов стали сопоставимы — сложных с DevOps и простых без DevOps»,

— авторы отчета пытаются объяснить результаты.

Тут явное несоответствие, и оно требует внимания. К примеру, вам нравится Jenkins. Однако все команды, использующие GitHub Actions, показывают бо́льшую продуктивность. Неужели это не будет знаком того, что пора пересмотреть набор DevOps‑инструментов?

Кстати, в отчете отмечается, что использование нескольких однотипных инструментов CI/CD является ошибкой.

«Производительность развертывания ухудшается, если применяются нескольких инструментов CI/CD одного вида. Исследователи предполагают, что это связано с проблемами их взаимной совместимости (interoperability challenges)»,

— из того же отчета.

Есть и смежные проблемы.

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

Еще яркий пример — «усталость от оповещений» (alarm fatigue). Одна программа за другой непрерывно сигнализирует. Сыпятся все новые и новые предупреждения. В таком потоке очень легко утратить бдительность и пропустить реальные проблемы, которые в итоге и попадут в продовый конвейер (production pipeline).

От CI/CD не откажешься. Возникающие сложности не перекрывают преимущества в производительности. Как правило, разработчики, которые по‑настоящему хорошо освоили несколько инструментов, успевают сделать больше, чем их коллеги с арсеналом поскромнее.

При правильном применении — подчеркнем, именно правильном! — использование конвейеров CI/CD неразрывно связано с улучшением показателей развертывания по всем метрикам DORA (DevOps Research and Assessment). Однако при неумелом подходе все обстоит совершенно иначе.

Тревожит и тот факт, что наблюдается некоторое снижение использования CI/CD. В третьем квартале 2023 года 33% разработчиков применяли CI для автоматической сборки и тестирования изменений в коде. В первом квартале 2024 года этот показатель уменьшился до 29%.

Так что же происходит?

Полагаю, компаниям давно пора задуматься над оптимальным сочетанием инструментов и подходов. Необходимо целенаправленно использовать средства DevOps и CI/CD, чтобы извлекать максимальную выгоду. Их полезность не вызывает сомнений ни у кого, кроме разве что убежденных противников прогресса. Однако, судя по всему, над эффективностью еще надо работать.

Возможно, CDF и другим вендорно-нейтральным организациям в сфере DevOps следует провести тщательный и критический анализ того, как именно используются программы. Ведь очевидно: что-то идет не так!

Возможно, эти материалы будут вам интересны:

→ Сломанные прогнозы: технологии, которые «вот-вот взлетят» уже 15 лет ^[5]
→ Как не переплатить за автоматизацию? Разбираем, когда стоит подключать ML ^[6]
→ Временные и постоянные ошибки ^[7]