Некоммерческая организация Continuous Delivery Foundation (далее — CDF) сообщает о том, что DevOps‑инициативы, похоже, зашли в тупик.
На саммите Open Source Summit (OSSummit) North America, одним из организаторов которого выступил CDF, в рамках конференции cdCon был представлен пятый ежегодный отчет State of CI/CD Report. В нем сообщается, что, хотя 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 лет
→ Как не переплатить за автоматизацию? Разбираем, когда стоит подключать ML
→ Временные и постоянные ошибки
