Некоммерческая организация 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
→ Временные и постоянные ошибки
Комментарии (45)
olku
31.05.2025 11:11Спасибо за оригиналы. Действительно, усложнять легко, упрощать сложно. Было бы любопытно выяснить, если ли корреляция между внедрением CI/CD и микросервисов.
artemlight
31.05.2025 11:11Смешались в кучу кони, люди...
С каких вообще пор необходимость выкатить только что написанный код в продакшн стала чем-то хорошим? Нормальный процесс разработки включает в себя следование релизному циклу, да даже хотфиксы редко в тот же день ставятся.
И что это вообще за метрика такая - скорость деплоя? Одно дело - просто поменять айдишку образа и триггернуть CD, другое дело - пилить новые пайплайны\манифесты под какие-то мажорные изменения. В первом случае - это maintenance / professional services, во втором - development. И мы на полном серьёзе тут обсуждаем какую-то общую для этих двух процессов метрику?
Про восстановление сервиса в течение недели - а какой Target RTO в SLA\договоре? У нас есть сервисы, которые могут и дольше валяться. Это ж история про управление рабочими ресурсами, а не про профессионализм. SLA не нарушен - нет проблемы. А если выясняется, что проблема всё же есть - то дело опять же не в девопсе, а в некорректно заданных параметрах SLA.
Описанные в статье проблемы, имхо, куда больше намекают на кризис в качестве управления проектами. Вот отткуда как раз и тайм ту маркет за пару часов, и ллм вместо джунов, и прочие непотребства. А причина - перегретый рынок и огромное количество случайных людей в профессии.
oneastok Автор
31.05.2025 11:11Отчасти соглашусь, но своего мнения высказывать не стану, так как не считаю себя вправе спорить по этому вопросу. Поскольку тема мне очень интересна, я постарался разобраться в отчете (насколько смог) и попробую ответить как бы от имени автора оригинальной статьи. Замечу, что не полностью разделяю его взгляды, да и он сам не выходит за рамки выводов State of CI/CD Report, поэтому и я буду отталкиваться от того же отчета.
Необходимость выкатить только что написанный код в продакшн
Не каждый коммит предназначен для немедленного развертывания. Отчет же, как я понял, стремится к тому, чтобы команды имели возможность безопасно и быстро это делать при необходимости.
Lead time for code changes
Высокие показатели здесь не обязательно означают, что все коммиты идут в прод немедленно, а процесс отлажен и быстр. Хотфиксы, требуют скорости, а эффективные CI/CD пайплайны этому способствуют. Отчет показал, что только 14% разработчиков могут задеплоить код за день, 41% же вообще тратят на это месяц.
Скорость деплоя и ее неоднозначность
В отчете речь идет про Deployment frequency — одну из ключевых метрик DORA. Она измеряет частоту развертывается кода (стр. 21 отчета). При этом метрика никак не оценивает сложность каждого конкретного развертывания (будь то смена ID образа или создание нового пайплайна). Она отражает общую способность команды регулярно поставлять работающий код.
«Пилить новые пайплайны/манифесты»
Сложность подготовки к развертыванию скорее отразится на Lead time for code changes — время, затраченное до того, как изменение будет готово к деплою и запущено. Цель — сделать даже сложные развертывания более управляемыми и менее трудоемкими (за счет автоматизации и стандартизации).
Отчет не смешивает maintenance и development с точки зрения самих задач. Однако результативность процессов доставки ПО действительно оценивается в целом — тут не поспоришь.
Восстановление сервиса в течение недели и SLA/RTO
Вы совершенно правы, что SLA и RTO (Recovery Time Objective) — это бизнес-параметры, которые и определяют допустимое время простоя. Метрика DORA Time to restore service как раз измеряет, сколько времени уходит на восстановление сервиса после незапланированного сбоя (стр. 22).
С точки зрения DORA, это показатель операционной эффективности команды. Даже если SLA позволяет сервису «валяться дольше», способность быстро восстанавливаться — это признак зрелости процессов, качества архитектуры и экспертизы команды.
Действительно, если SLA не нарушен, формально «нет проблемы» с точки зрения контракта. Но с точки зрения конкурентоспособности, удовлетворенности клиентов и репутации бизнеса, длительные простои редко бывают желательны, даже если укладываются в SLA. Исследование стремится улучшить именно фактическую способность быстрого восстановления.
Кризис в качестве управления проектами и другие факторы
Ваше наблюдение о том, что описанные проблемы могут указывать на более глубокие системные недочеты в управлении, перекликается с некоторыми выводами отчета:
подчеркивается «важная роль, которую организации и руководители команд играют в направлении своих команд к более высокой производительности»;
указывается на необходимость «обеспечить, чтобы новые разработчики были лучше знакомы с DevOps в целом, а также с практиками, используемыми в организации»;
отмечается, что некоторые организации не внедряют и не стандартизируют лучшие практики, что приводит к зависимости производительности от индивидуального опыта разработчиков — это тоже можно рассматривать как недостатки в управлении.
artemlight
31.05.2025 11:11только 14% разработчиков могут задеплоить код за день
М, надеюсь, что это неточность перевода. Разработчиков на пушечный выстрел нельзя к деплойменту подпускать, это не их зона ответственности и не их компетенция.
Но "деплой за день" - это странная отсечка, если честно. Приведу пример из жизни, с которым наверняка сталкивались практически все здесь присутствующие.
У нас есть unmockable API - и unmockable он в силу разных причин (трудоемко, нужны данные с реального оборудования, частая смена контракта делает мок бессмысленным). Гипотетический пример - нам нужно, чтобы над нашим оборудованием проехал грузовик, и оно там что-то с него записало. Грузовик ездит раз в неделю. Или в месяц. Тестово гонять грузовик - дорого, столько денег никто не даст. Более того - пустой грузовик гонять бессмысленно, а набивать его нечем (и это ещё дороже).
Вывод - для интеграционного тестирования нужно или ждать, пока грузовик приедет по делу, или тратить миллиарды золота на тестовый заезд, грузчиков и 12 тонн кирпичей.Сможет ли в таком случае разработчик задеплоить код за сутки? Да, и будет немедленно казнен за скип CI stage.
Снижает ли это Deployment frequency? Безусловно.
Самый главный вопрос - а проблема ли это? Ответ - нет, это всего-навсего специфика продукта, отраженная в том числе в оптимизации затрат на интеграционное тестирование.
Но... а как же метрики? Напрашивается ответ - метрики имеет смысл сравнивать только в динамике, и только для конкретной задачи. Нет ничего удивительного в том, что у криптостартапа, государственного API и прошивки для Вояджер-1 разный тайм ту маркет и разная частота деплоя. И дрифт среднего арифметического по перегретому рынку может означать в том числе и уход с этого самого рынка "быстрорастущих" проектов по причине их массового банкротства.длительные простои редко бывают желательны, даже если укладываются в SLA
Так SLA как раз и нужен затем, чтобы определить - какие простои допустимы, а какие - нет. Именно SLA определяет, будет ли мы мутить High Availability со всеми сопутствующими оверхедами по стоимости сопровождения и обслуживания, или сделаем docker-compose up на виртуалке и забудем. Как клиент скажет (читай - заплатит), так и сделаем. Удовлетворенность клиентов, репутация и прочее - это бизнес-метрики, а SLA - отражение этих метрик в виде технического задания на разработку.
adrozhzhov
31.05.2025 11:11Есть добрый пример про 29 февраля. Баги, связанные с обработкой этого события наблюдаются не чаще 1 раза в 4 года. Воспроизводить их достаточно просто. Но фикс нужен или прямо сейчас (на прод выкатывать опасно, особенно если баг в прошивке SIP телефона) и спешка ну никак не оправдано.
Важность бага - высокая, приоритет не очень (пример основан на тру стори, фикс был через 2 минуты после обнаружения, выкатили через 3 месяца со следующей плановой прошивкой)
LinkToOS
31.05.2025 11:11Поскольку тема мне очень интересна, я постарался разобраться в отчете (насколько смог) и попробую ответить как бы от имени автора оригинальной статьи. Замечу, что не полностью разделяю его взгляды
Не следовало вообще делать перевод оригинальной статьи. Можно было сослаться на нее как на источник. Тем более название той статьи неудачное.
Надо было сделать свой материал, на основе State of CI/CD Report, и оригинальной статьи. То что вы сейчас пишите в комментариях, тоже должно было быть в статье.
У вас акценты расставлены неверно. Вы делаете акцент на абсолютных цифрах, хотя важны только изменения по годам.
Вы сразу вбрасываете спорный тезис - "сообщает о том, что DevOps‑инициативы, похоже, зашли в тупик."
Общая структура статьи должна быть примерно такая.
Цель исследования - оценка эффективности внедрения devops за последние годы.
Методы исследования - по косвенным показателям. Используются метрики, без учета дополнительных параметров (например без учета сложности проекта).
Факты - метрики падают за последние годы.
Вопрос - действительно ли это показатель малой эффективности devops, или выбранный метод исследования дает ложные результаты?Скорость деплоя и ее неоднозначность
Она отражает общую способность команды регулярно поставлять работающий код.Даже этого не отражает. В отдельных проектах регулярность и частота деплоя не имеют никакого значения, и при внедрении devops они не изменятся. Это не прямой признак. Просто этот показатель должен улучшаться в среднем, по мере расширения использования devops.
Восстановление сервиса в течение недели
Как вариант - devops был прикручен как опция. Упал сервис - ну и ладно, работаем по старинке. Почему не поднимают быстро - потому что не особо-то и нужен.
Равноправные варианты - "devops слишком сложен, поэтому долго восстанавливают", и "devops хоть и есть, но не является необходимым, поэтому не торопятся восстанавливать".
olku
31.05.2025 11:11ИТ компании бывают очень разные - у одних релизный цикл эта одна фича или фикс (привет канбан), у других приложение к договору (привет водопад).
nehaev
31.05.2025 11:11А ведь еще сравнительно недавно были времена, когда весь деплой заключался в копировании нескольких файлов на единственный сервер по ssh. Весь мониторинг - в подключении по тому же ssh, чтении единственного лога и наблюдении за метриками top'ом. Да, это было не круто. Но этому можно было за час на пальцах научить любого джуна, и дальше они вполне справлялись с поддержкой.
Современные подходы к инфраструктуре, типа service mesh, пошли по пути добавления новых и новых слоев абстракции. Теперь у вас три экземпляра приложения, каждое в своем поде, каждое - за своим прокси, гейтвей, лоад балансер, собиралка логов, собиралка метрик, физическая машина, на которой это в конечном счете крутится (часто, все так же одна единственная, ведь "мы же не гугл"). И у каждого компонента естественно есть свои логи, свои метрики, своя конфигурация при деплое. Каждый компонент - потенциальная точка отказа. Теперь, для того, чтобы с этим всем справится, нужен отдельный специалист. Джун-программист не просто не сможет выполнять такую работу, он скорее всего даже не сможет коммуницировать с таким специалистов в рамках своих задач. Стало ли как-то лучше глобально? Для супер большиъ проектов - наверное да. Остальные и 10 лет назад, и 20 лет назад тоже как-то работали, вполне нормально. Что точно изменилось - современные практики DevOps создали огромное количество рабочих мест собственно для девопсов. Не вижу в этом ничего плохого.
BugM
31.05.2025 11:11А ведь еще сравнительно недавно были времена, когда весь деплой заключался в копировании нескольких файлов на единственный сервер по ssh. Весь мониторинг - в подключении по тому же ssh, чтении единственного лога и наблюдении за метриками top'ом.
Конечно же нет. Мониторили Веблоджики всякие с Джейбоссами. И деплоили на них же всякое. И это было не очень. Сейчас лучше.
nehaev
31.05.2025 11:11Вот кстати да. EJB ведь тоже шел путем добавления абстракций и приводил к кратному увеличению сложности системы. Где сейчас EJB?
И да, я не пытался сказать, что сейчас хуже. Я пытался сказать, что в целом позитивный движ как будто свернул немного не туда. Надеюсь, на следующем витке прогресса народ додумается как получить те же преимущества, но без этой сложности.
BugM
31.05.2025 11:11Многие хорошие технологии развиваются по спирали. Что-то хорошее сделали, потом накручивают фичи и усложняют, а потом приходит новый уровень и на нем снова делают что-то простое и хорошее без всей шелухи прошлой технологии.
artemlight
31.05.2025 11:11Три экземпляра приложения, гейтвей, лодбеленсер, метрики. В пределах одного bare metal сервера, ну или availability зоны. Такого - процентов 95, наверное. И ничего там сложного нет, минут за 20 всё подымается. Можно даже без всяких там кубернетесов и сервис мешей, в GCP есть Cloud Run для таких сценариев. Мышкой накликал, и оно само попёрло.
У нас в большинстве случаев девопс вообще на деплоях присутствует исключительно для галочки. Ну если вдруг чего не так пойдет. А так - релизные теги у нас забивают менеджеры, а одну циферьку в манифесте поправить кто хошь сможет.
К чему я всё это
Для меня когда-то в молодости ансибль с применением идемпотентных методов стал откровением. Вторым таким же откровением стала immutable инфраструктура. Все эти штуки придуманы не столько для решения технической задачи, сколько для минимизации человеческого фактора. Копипастить бинарь - это круто, конечно, но вспонмите, какого размера у вас были preflight чеклисты для установки всего на свете на этот сервер. Вспомните, как часто у вас всё ломалось после apt-get/emerge/yum/etc, как приходилось грузить ос в рековери и что-то там ковырять. Вспомните про километровые портянки iptables/ufw/ipfw, про забытые открытые порты, про fail2ban, который чаще банил сам себя, чем кого-то злобного со стороны.
Вспомните, как грепали сислоги, как часами накликивали шаблоны в заббиксе (это отдельный вид мазохизма был). Как разные сервисы писали логи в разных форматах и с таймстемпами в разных таймзонах. И как, несмотря на всё это, основной фидбек давали не нотификации, а реальные пользователи по телефону.В общем, сейчас всё гораздо лучше и гораздо проще.
Kelbon
31.05.2025 11:11Есть курсы тестировщиков, разработчиков, они конечно почти всегда бесполезны или вредны, но они есть. А вот девопсу никто не учит, нет кафедры devops в вузе, в итоге непойми кто на этих должностях оказывается
lazy_val
31.05.2025 11:11A DevOps team includes developers and IT operations working collaboratively throughout the product lifecycle
Under a DevOps model, development and operations teams ... merge into a single team where the engineers work across the entire application lifecycle
отсюда, к примеру
Если появляется отдельная должность DevOps-инженер между разработчиками и администраторами - значит люди не поняли что такое DevOps и зачем он нужен. Справедливости ради следует заметить, что таких (не понявших) процентов 90. А то и 99.
А то что
девопсу никто не учит
это безусловная и печальная правда. Как и то, что во многих случаях и разработке учат так, что лучше бы не учили.
Kelbon
31.05.2025 11:11должность DevOps-инженер
в больших проектах нужно выделять отдельные команды девопс инженеров, конечно они должны работать плотно с разработчиками, но просто сказать что разработчики теперь и девопсы это кончится плохо
Ndochp
31.05.2025 11:11Если появляется отдельная должность DevOps-инженер между разработчиками и администраторами - значит люди не поняли что такое DevOps и зачем он нужен
Kelbon
31.05.2025 11:11И с чего вы взяли, что это истина не терпящая других подходов?
Ndochp
31.05.2025 11:11С того что "команда ХХХ, общающаяся с разработчиками, но не являющаяся ими" это админы, а не девопсы. По определению девопса. Они тупо не DEV
BugM
31.05.2025 11:11Админы выучили Питон, переименовались в Девопсов и получают теперь х2 зарплату. Всем хорошо. Хорошо даже разработчиком. Админовские баш скрипты читать было совершенно невозможно, Питон заметно понятнее.
lazy_val
31.05.2025 11:11Автор оригинальной статьи - журналист с опытом 30 лет, написавший более 10.000 статей. И не более того. Просто классический пример про слышу звон ...
oneastok Автор
31.05.2025 11:11Автор оригинальной статьи пишет об IT с тех пор, как CP/M стала самой популярной операционной системой. Мне кажется, если просто сказать «журналист» — на ум может прийти неверная ассоциация.
Кроме того, автор оригинальной статьи ничего не добавил к отчету State of CI/CD Report. Если кажется, что какие‑то высказывания в отчете неверны, то правильнее обратить критику на Continuous Delivery Foundation, а также на организаторов cdCon и Open Source Summit North America за то, что тех пригласили.
cahbeua
31.05.2025 11:11Восстановить за час звучит конечно круто, но есть некие сомнения. Если речь за зелёную кнопку, которая в приложении вдруг стала красноватой это одно, а если это залип кеш редиса на одном из кластеров или в прод утёк конфиг дева одного из микросервисов, который от этого взбесился то ж совсем другое. Да банально выковырять что либо из бекапа при базах данных размером с терр это уже не всегда в час укладывается.
ky0
Ничего не понятно.
От какого момента считается тот день, в течение которого только 14% компаний в состоянии доставить код на прод? От момента, когда ветка полностью протестирована и код смержен? Ну, это смешно.
Чем занимаются те компании, эксплуатация которых не может восстановить сервис в течение часа/дня/недели(?!)? Почему они не выгоняют на мороз таких специалистов после подобных прецедентов?
Может, конечно, мне так с местами работы повезло - но описанные проблемы нигде не были прямо проблемами, консёрны совсем другие.
pnmv
уточните, пожалуйста, что такое "консёрны"?
по поводу же четырнадцати процентов компаний - вероятно, это процент от числа делегатов, на симпозиуме. если у компании не бывает сбоев, значит она ни чем не занята (в сравнении с другими, внутри отрасли). это не говорит о том, что сбои обязаны быть, но, когда всё без сбоев, контора начинает "экономить на главном", и сбои не заставляют себя дожидаться.
ky0
То есть, развивая вашу логику - инфраструктура должна быть достаточно ненадёжна, чтобы менеджмент понимал, за что платит? :)
У меня, знаете, был один знакомый сисадмин, лет на 15 меня старше, приходящий. Так он в ранг правила это возводил - раз в пару месяцев что-нибудь "ломал", а потом приезжал и героически чинил.
Мне такое не близко, сорян. Надо делать хорошо - и уметь объяснять руководству, какой ценой оно сохраняется хорошим.
pnmv
это не моя. моя логика - лучший админ (или программист), это тот, которого не видно, а всё работает "как-бы само".
к сожалению, вынужден заявить: ну и правильно делал.
менеджероориентированные организации по-другому не понимают.
желаю успехов. (в вашем возрасте, я уже не был столь наивен. отучили.)
Tim_L
"Прод должен падать, техдир должен плакать. Это IT" ©
novoselov
Могу предположить. Считается от момента поднятия pull request. То есть с того момента когда начинает работать CI/CD и до момента когда приложение запущено на проде.
Что значит восстановление за неделю? Это значит что за первые несколько часов откатывается версия или применяется patch/workaround и это НЕ считается полноценным восстановлением, т.к. ожидаемое состояние отличается от реального. А дальше уже идет расследование проблемы, поиск и подготовка решения, снова полный цикл CI/CD и иногда ожидание ближайшего запланированного релиза, а такое уже сплошь и рядом в корпоративной среде.
Всегда можно обойти все процедуры, проверку прав, прогон тестов и наживую пропатчить приложение на проде. Так что если вы считаете только время до фикса, то это не про DevOps это про менеджмент инцидентов.
oneastok Автор
Почему компании с этим мирятся? Почему не выгоняют на мороз?
Выскажу гипотезу. Если кратко: некого забирать «с мороза» взамен.
Отчет, который в основе оригинальной статьи, основан на масштабном опросе. За 3,5 года в нем приняло участие 150 000 респондентов из более чем 135 стран. По сути он отражает общие усредненные тенденции по индустрии и в какой‑то степени иллюстрирует известный анекдот про среднюю температуру по больнице.
Одна из задач исследователей — как раз обратить внимание на существующие в индустрии вызовы и зоны для роста (без учета отдельных компаний и стран). Тревожная тенденция — рост доли команд с низкой производительностью по всем ключевым метрикам развертывания.
Теперь по вашим вопросам (Я где‑то мог ошибиться — поправьте, пожалуйста, если заметите неточность.)
Речь идет о метриках DORA — например, Lead time for code changes. Разработчикам задавался вопрос: «В среднем, сколько времени у вас уходит с момента коммита кода до его успешного запуска в production?» (On average, how long does it take you to go from code committed to code successfully running in production?).
Отсчет времени идет именно от коммита, включая все последующие стадии: сборку, все виды автоматизированного и, возможно, ручного тестирования, мерж (если он не является самим коммитом в основную ветку), развертывание на различные окружения и успешный запуск на проде.
Еще задавался вопрос: «В среднем, сколько времени у вас или вашей команды уходит на восстановление сервиса после незапланированного сбоя или нарушения работоспособности?» (On average, how long does it take you or your team to restore service from an unplanned outage or service impairment?).
Данные из отчета (Q1 2024) следующие:
менее чем за час — 11% (этот показатель снизился с 17% в Q3 2020 и остается на уровне около 11% с Q3 2022),
от часа до дня — 29%,
от дня до недели — 19%,
больше недели — 41% (эта доля показывает устойчивый рост).
У менее опытных разработчиков показатели восстановления хуже значительно.
С опытом менее 2 лет:
5% — могут восстановить сервис менее чем за час,
67% — тратят на это более недели.
С опытом более 16 лет:
22% — восстановят за час,
9% — будут возиться две недели.
Также нужно учитывать, что не все сбои одинаковы — не все из них катастрофичны, некоторые могут быть и незначительными.
Еще отчет подчеркивает, что тимлиды играют ключевую роль в улучшении метрик — например, стандартизируют инструменты или обучают новичков. Когда этого не происходит, проблемы носят системный характер, и увольнение специалистов их никак не решит.
sotland
Мне кажется, что сам термин: восстановление после сбоя, требует расшифровки. Что понимается под сбоем...
Иначе некая глупость возникнет. Скажем у нас для того чтобы при крахе сервиса по нехватке памяти потребуется примерно 5-10 минут. Правка в деплой файле мастер ветки, пуш, выкатка на 4 кластера с выполнением юнит тестов и всякими линерами.
Но если как-то умрёт кластер базы, тут конечно будет дольше, раскатать новый быстро, а вот вкатить туда бекап, время займёт.
Так что я не очень понял, про какие сбои идёт речь?
oneastok Автор
Я о том же примерно написал, что не все сбои одинаковы. Согласен с вами — степень тяжести можно оценивать по времени, нужном для восстановления сервиса. И говорим мы, конечно, чисто о технической стороне (без учета репутационных и прочих сопутствующих потерь).
sotland
Тогда в чём смысл статьи?
Правильно понимаю, время самого простого действия от нажатия enter при команде git push до выкатки сервиса в прод выросло на x%?
Или раскатка систем связанных брокерами, корректностью апи и протобафов, доступностью апстримов, ингрисов и всего вот этого, превращается в многочасовые (а у особенно одарённых и в многодневные) квесты?
oneastok Автор
Речь не о том, что «самое простое действие от нажатия enter при команде git push» стало дольше. Ключевая метрика, о которой говорится, — Lead time for code changes — измеряет время от момента коммита кода до его успешного запуска в production. Сюда входит вся цепочка: сборка, тестирование, развертывание и т. д., а не только git push.
Для многих (41% в Q1 2024) доставка изменений действительно превращается в «квесты» на месяц. Доля таких команд выросла (в Q3 2020 их было 34%). В то же время сегмент наиболее быстрых команд, у которых этот процесс занимает менее одного дня, остается относительно стабильным (14% в Q1 2024).
Смысл статьи (и отчета, на котором она основана) — показать актуальное состояние DevOps, оценить эффективность доставки ПО, а также выявить факторы, которые на всё влияют.
Отчет предполагает, что одна из причин наблюдаемых трендов — рост сложности проектов, который нивелирует некоторые выгоды от внедрения DevOps. Я не возьмусь делать самостоятельные выводы, так это или нет. Мне показались интересными и само исследование, и оригинальная статья, которая является его обзором.
sotland
1) я так и написал, "от нажатия enter при команде git push до выкатки сервиса в прод выросло на x%?" Извиняюсь конечно, если выкатка в прод имеет многозначную трактовку...
В нашем случае от git push до момента факта ответа нового кода из прод окружения минимально достигаемое время: 5 минут. Максимально 10 минут. Зависит от нагрузки на сервере гитлаба. Включает прогон линтера, тестов, нескольких доп проверок...
Естественно речь не может идти о выкатке новой фичи, только минимальные модификации кода или деплой файлов с целью исправления не корректного поведения.
Ибо правки связанные с изменением апи, контрактов, добавлением полей в базу, изменением бизнес-логики - это всё вообще не измеримое по времени. Тут действительно зависит от того кто вносит правки: джун или лид.
Пожалуй я переспрошу. У 41% команд из обзора более чем суточные квесты с выкаткой в прод при правке например одной строки кода (понятной, безопасной, однозначной)???
mirwide
Самое неприятное что может случиться при релизе, это потеря консистентности или частичная потеря данных. Приложение начинает писать частично некорректные данные и это обнаруживается через часы или дни. Восстановить из бэкапа как есть уже нельзя, потому что потеряются данные добавленные за время пока обнаружили проблему. Без хорошего аудита в БД и готовых инстументов, RTO в неделю и больше вполне реально в таком сценарии.
BugM
Логировать все не пробовали? Прямо весь поток изменений в нормальном формате в котором потом можно что-то понять. Это довольно типовое решение, которое позволяет восстановить все.
mirwide
Логи лучше чем ничего, но это плохое решение. Логи не консистентны: хранилище для логов обычно делается с низкими гарантиями консистентности, при передаче стандартными тулзами возможны потери(файлбит мог не успеть прочитать файл, передача через gelf это udp, в elasticsearch не совпали мапинги сообщение не записалось и тд). Гарантировано писать логи, это сложно, дорого. Второе, если мы пишем все данные в логи, система логирования становится такого же уровня критичности по доступу как БД приложения. К логам обычно имеют доступ большее количество людей, если в БД номера телефонов, светить ими в логах для всех плохая идея.
Нужен аудит, который пишется в одной транзакции с данными.
BugM
Из всего могу согласиться только с доступами и аудитами. Да, доступы должны быть как к проду и аудит безопасности проводить надо как на проде.
С остальным все проще чем вам кажется. Врайт онли системы заметно дешевле rw систем. Просто пишем, не заботясь о том насколько эффективно оно читаться будет. В случае факапа расход ресурсов на восстановление не принципиален вообще.
Консистентность тоже делать проще когда не надо думать как данные читать. Пишем диффы с меткой времени и не думаем. Читать это крайне неэффективно, зато писать просто и приятно.
Чтобы далеко не ходить wal mysql это примерно правильного лога для уровня абстракции sql бд. Стоит заранее научиться надежно его хранить и работать с ним.
mirwide
Аудит - имеется ввиду аудит логи. В обычные логи приложения писать аудит плохо потому что они заточены чтобы их терять. Отдельные аудит логи то что нужно.
sotland
Проблемы с релизами и возможность их крайне тяжкого влияние на работоспособность системы в целом, это должна быть отдельная песТня.
Вот я ни как и не могу добиться, кто и что понимает под термином сбой!
1) не корректное поведение нового функционала через неделю после релиза?
2) отвал одной ноги у кластера базы
3) резкий рост потребления памяти/проца - постоянный перезапуск подов
4) развал кластера базы
5) внезапный отказ внешнего апи с данными и звонок в 17:00 в пятницу вечером: а не могли бы вы переключиться с mega-api.company.ru на super-api.company.ru
6) внезапное изменение у внешнего апи с данными контракта ответа?
Что такое сбой?
mirwide
Мне кажется, все понимают разное, в некоторых компаниях ещё и терминология своя - не сбой, а НШС(нештатная ситуация) или инцидент,
хлопок.В моём понимании всё перечисленное вполне подходит под сбой, если это влияние на пользователя или потеря отказоустойчивости для п2.
ky0
Да, спасибо, стало понятнее.
Пенять на недостаток девопса, суммируя время ревью, сборки, тестов живым человеком, согласований релиза в одну кучу - как-то странно, на мой взгляд. Узким местом может быть CI, который два часа выполняется - а может и загруженность QA, которая сегодня есть, а завтра нет.
В общем, кажется, у меня произошла финтеховская профдеформация - когда полчаса неработоспобности сервиса это повод обсудить работу отдела с CTO, а дальше можно просто начинать вещи паковать :) А места, где не так, кажутся странными.
novoselov
Пока ваш финтех маленький, можно сколько угодно хвалиться скоростью поднятия сервисов, которые можно пересчитать по пальцам. Поднять ≠ починить, можно и нужно считать время и того и другого, но решение каждой проблемы может достигаться кардинально разными способами.
Хотите быстро подниматься? Держите green/blue деплой и вторую копию базы и кешей через mcrouter, при падении в автоматическом режиме переключаем нагрузку на старую версию и спокойно разбираемся с проблемой, downtime минимальный. Повторюсь на небольших проектах это разумно и оправдано, работает в 99% случаев.
Теперь попробуйте провернуть то же самое через 15 лет, когда у вас уже 50 систем связанных между собой, а количество программистов перевалило за 1000. Из данных в статье я бы сделал вывод что скорость с которой растет сложность разработки обгоняет скорость с которой инструментарий позволяет управлять этой сложностью (что неудивительно, т.к. инструментарий пишут такие же программисты). С учетом многолетнего тренда перевода разработки в Индию и наступающей волне vibe-кодеров вангую что будет только хуже.
ky0
Большой финтех перестаёт быть финтехом, а становится замшелым банком-мастодонтом :) Желательно предвосхитить этот момент и отчалить.
gogie
По поводу метрики lead time for code changes, у нас в команде есть джуны и мидлы и доверять их коду достаточно сложно, а сеньёры вечно чем-то заняты чтобы досконально проверить всех остальных, времени на контрактное программирование или написание смоков, каких то тестов у них тоже нет. Поэтому неделя у всех кроме сеньёроа от комитета до деплоя на прод выглядит, как мне кажется, вполне нормально.