- PVSM.RU - https://www.pvsm.ru -
Несколько лет назад многие организации рассматривали DevOps как перспективный эксперимент, а не основной подход к разработке программного обеспечения. Сейчас DevOps — проверенный и мощный набор практик и инструментов разработки и развертывания, позволяющий ускорить релизы новых продуктов и повысить производительность труда. Что еще важнее: эффект DevOps направлен на общий рост бизнеса и увеличение его прибыльности.
Команда Mail.ru Cloud Solutions [1] перевела самое интересное из отчета 2019 Accelerate State of DevOps Report [2], составленного экспертами DevOps Research & Assessment (DORA). В исследовании участвовали 31 000 специалистов со всего мира. Посмотрим, что изменилось в отрасли в 2019 году и как бизнес может повысить эффективность доставки программного обеспечения.
В исследовании не выявили связи между эффективностью DevOps и отраслью организации, за исключением розничной торговли, где показатели были чуть лучше. Это, в частности, связано с тем, что ритейлерам надо оперативно реагировать на колебания спроса и потребности покупателей. По данным исследования, высокого уровня в DevOps может достичь любая компания, включая финансовый сектор и госсектор.
Показатели эффективности DevOps в компаниях, где более 5000 сотрудников, были ниже, чем в компаниях, где менее 5000 сотрудников. Скорее всего, это связано с тем, что в крупных организациях более масштабные процессы, строже контроль, сложнее архитектура IT-систем, что вносит задержки в процесс разработки и выкатки кода. При этом эксперты считают, что масштаб компании не препятствует успеху в построении DevOps, просто в некоторых случаях это может потребовать больше усилий.
Эксперты сравнивали процессы DevOps с эталонной оценкой, разделив участников опроса на четыре группы с лучшими, хорошими, средними и низкими показателями.
Для отчета взяли четыре ключевые метрики оценки эффективности DevOps: время выполнения изменений при разработке ПО, частота развертывания, частота провалов и время восстановления.
Четыре уровня DevOps — оцените, на каком находится ваша компания:
Метрика оценки эффективности доставки ПО для основных сервисов и приложений компании | Команды с лучшими показателями | Команды с хорошими показателями | Команды со средними показателями | Команды с низкими показателями |
---|---|---|---|---|
Частота развертывания Как часто компания развертывает код в производство или выпускает его для конечных пользователей. |
По запросу, несколько развертываний в день | От одного раза в день до одного раза в неделю | От одного раза в неделю до одного раза в месяц | Один раз в месяц/несколько месяцев |
Время выполнения изменений Сколько времени занимает переход от теста до ПО, успешно работающего в производстве. |
Меньше чем за день | От одного дня до недели | От одной недели до месяца | От месяца до шести месяцев |
Время восстановления сервиса Сколько времени уходит на восстановление сервиса после инцидента или бага, влияющего на пользователей. |
Меньше часа | В течение дня | В течение недели | От недели до месяца |
Частота провалов при изменениях Какой процент обновлений или новых релизов приводят к ухудшению обслуживания и требуют исправлений. |
0-15% | 0-15% | 0-15% | 46-60% |
Исследование выявило следующую тенденцию: число команд с высоким уровнем показателей почти утроилось, увеличившись с 7% от всех респондентов в 2018 году до 20% в 2019 году.
Распределение групп разработчиков по уровням производительности.
По сравнению с командами в группе с низкой эффективностью, команды DevOps с высокими показателями:
Кроме того, у команд DevOps с высокими показателями в два раза больше шансов достичь или превзойти свои организационные показатели эффективности, чем у команд с низкими показателями.
Многие специалисты думают, что нельзя достичь увеличения всех показателей одновременно, надо идти на компромисс. Так, некоторые считают, что увеличение скорости выкатки релизов может негативно повлиять на надежность процесса доставки ПО и оказания услуг. Однако исследования показали, что скорость и стабильность результатов не исключают друг друга.
В росте числа DevOps-команд я не вижу ничего удивительно, он закономерен: философия DevOps сейчас популярна, а количество стартапов растет.
Но, на мой взгляд, эксперты выбрали не совсем корректные параметры оценки эффективности DevOps.
Оценивать ее по скорости выкатки кода, по меньшей мере, странно. Это применимо только к стартапам, где ключевым параметром будет скорость вывода продукта на рынок, при этом часто продукт выводится в сыром виде. В таких условиях механизмы, ускоряющие разработку и доставку в продакшен, являются жизненно необходимыми. А вот для устоявшегося ПО, например финансового или медицинского, параметра частоты провалов может не существовать — провалы могут быть недопустимы.
Аналогично с временем восстановления сервиса: для любого развитого сервиса оно должно исчисляться секундами, а для многих сервисов простой недопустим, для этого придумали технологии бесшовной выкатки (например green/blue).
Также не стоит ориентироваться на количество развертываний кода — оно зависит от необходимости и компетенций команды разработки. Если развертывание связано с добавлением нового функционала — это одно, а если с исправлением ошибок, допущенных при предыдущих развертываниях — совершенно другое.
Денис Романенко, внештатный эксперт Mail.ru Cloud Solutions
В отчете представлены два направления, которые помогут улучшить DevOps: повышение эффективности разработки и доставки ПО и улучшение производительности труда.
В каждое из направлений входят свои компоненты, улучшив которые, можно достичь нужной цели.
По данным отчета, ключ к цифровой трансформации — корпоративная культура. Высокоэффективным командам DevOps нужна культура доверия и психологическая безопасность, понимание результатов работы и четкие цели. Такая среда позволяет членам команд принимать взвешенные решения, высказывать свое мнение и быть более творческими.
Улучшить эффективность разработки и доставки ПО также помогут облачные технологии, непрерывная доставка, тестирование аварийного восстановления, управление изменениями. Производительность труда можно повысить, вкладывая средства в простые в использовании инструменты, уменьшая техническую задолженность, то есть снижая процент неэффективного кода и устаревших технологий, организуя корпоративную базу знаний и доступ к внешним решениям.
Я думаю, что методология и идеология DevOps как раз в том, чтобы эти процессы не зависели от внешних условий, таких как облако или свое железо. Само по себе облако — не более чем инструмент, где-то он поможет, где-то помешает или будет не востребован.
Денис Романенко, внештатный эксперт Mail.ru Cloud Solutions
Ниже рассмотрим некоторые составляющие улучшения эффективности DevOps-команд.
В 2019 году все больше организаций выбирают облачные решения, значительно повышающие производительность DevOps-команд.
Какие инфраструктуры используют DevOps-команды.
DORA обнаружила, что 80% респондентов размещают основные приложения или сервисы на облачной платформе [3]. Тем не менее только 29% респондентов внедрили все пять основных характеристик облачных вычислений Национального института стандартов и технологий — это важнейший стандарт для оценки ценности облака в рамках DevOps.
Характеристика | Процент использовавших |
---|---|
Самообслуживание по требованию Потребители могут автоматически предоставлять вычислительные ресурсы по мере необходимости, без участия провайдера. |
57% (+ 11% с 2018 года) |
Широкий доступ к сети Возможности облака доступны через разные платформы, такие как мобильные телефоны, планшеты, ноутбуки и рабочие станции. |
60% (+ 14% с 2018 года) |
Пул ресурсов Ресурсы провайдера объединяются в мультитенантную модель, где физические и виртуальные ресурсы, динамически назначаются по требованию. |
58% (+ 15% с 2018 года) |
Масштабируемость и эластичность Ресурсы масштабируются горизонтально или вертикально по требованию, они практически не ограничены и могут выдаваться в любом количестве в любое время. |
58% (+135 с 2018 года) |
Прозрачность Облачные системы автоматически контролируют, оптимизируют и сообщают об использовании ресурсов в зависимости от типа услуги: хранение и обработка данных, количество трафика, активные учетные записи пользователей. |
62% (+ 14% с 2018 года) |
«Платформа как услуга» (PaaS) все больше переходит к модели развертывания, сосредоточенной вокруг контейнеров. Облачные платформы упрощают развертывание ПО, в итоге командам нужно беспокоиться только о выполнении самого кода приложения. Масштабирование, планирование ресурсов, администрирование и обслуживание инфраструктуры также переходит на сторону провайдеров.
Для облачных провайдеров универсальным стандартом становится предоставление разнообразных услуг: сети виртуальных машин, управления идентификацией и доступом (IAM), хранилищ и баз данных, машинного обучения, интернета вещей (IoT), контейнерных решений, решений для безопасности и других.
Клиенты облачных провайдеров оплачивают только те ресурсы, которые используют, что обеспечивает прозрачность расходов, в отличие от традиционных ЦОД, где информацию о стоимости разработки сложно или невозможно добыть. Респонденты из компаний, отвечающих облачным характеристикам, перечисленным выше, в 2,6 раза точнее оценивают стоимость работы ПО, в 2 раза чаще понимают, на какие приложения уходит больше ресурсов, в 1,65 раза чаще остаются в рамках бюджета, выделенного на IT.
Иногда оказывается, что нанять грамотного специалиста и взять выделенные мощности в дата-центре выгоднее, чем оплачивать облако. Какой вариант лучше, зависит от профиля и масштаба компании, наличия собственного штата IT-специалистов и экспертизы. Например, облако удобно использовать на старте бизнеса или если в компании нет своего IT-отдела. При масштабировании может быть рентабельнее содержать всю инфраструктуру или ее часть on-premise.
Денис Романенко, внештатный эксперт Mail.ru Cloud Solutions
Многие организации, желающие внедрить DevOps, ищут набор инструкций или лучшие практики. Однако одинаковых компаний нет, поэтому то, какие практики выбрать, зависит от текущего состояния бизнеса и его целей.
При этом есть общие направления, помогающие улучшить эффективность DevOps: некоторые из них разрабатываются на уровне команды, другие требуют усилий на уровне организации.
Какие направления роста выделены для DevOps-команд в 2019 году:
На уровне организации |
|
На уровне команды |
|
На уровне команды и организации |
|
Исследование подтвердило положительное влияние слабосвязанной архитектуры на эффективность DevOps.
Слабосвязанная архитектура — это когда команды могут независимо тестировать, развертывать и изменять системы по требованию, независимо от других команд, без дополнительной поддержки, ресурсов, одобрения, с меньшим количеством обратной связи. Это позволяет эффективнее работать, но требует высокого уровня организации и управления.
Такой подход возможен только для стартапов и с некоторыми оговорками. В других компаниях может быть иная ситуация. Хороший пример: банковская сфера/финтех. Там могут использоваться исключительно проприетарные решения, однако будут применяться практики DevOps.
Денис Романенко, внештатный эксперт Mail.ru Cloud Solutions
Непрерывная интеграция и доставка (CI/CD) [4] позволяет выводить сервисы и приложения в прод с меньшими затратами и рисками, а также поддерживать релизы в соответствии с целями организации.
Успешный CI/CD также означает, что команды могут внедрять изменения в производство по требованию, им сразу же доступна обратная связь о качестве развертывания, ее можно быстро отработать и улучшить следующий цикл развертывания.
Отчет показывает, что успешные DevOps-команды инвестируют в широкий спектр вспомогательных процессов, практик и инструментов:
При построении сложных систем и управлении критически важными для бизнеса инфраструктурами важно подобрать технологии:
В отчете изучили инструменты, используемые при развертывании программного обеспечения через CI/CD, и инструментарий автоматизации тестирования — именно эти технологии лежат в основе DevOps.
Какие технологии используют DevOps-команды:
Технологии | Команды с низкими показателями | Команды со средними показателями | Команды с хорошими показателями | Команды с высокими показателями |
---|---|---|---|---|
Сочетание проприетарных, open source и коммерческих коробочных продуктов | 30% | 34% | 32% | 33% |
В основном open source и сильно кастомизированные коробочные решения | 17% | 8% | 7% | 10% |
В основном open source и коробочные решения с небольшой настройкой | 14% | 21% | 18% | 20% |
В первую очередь коробочные коммерческие решения | 8% | 12% | 8% | 4% |
Внутренние разработки и проприетарные решения под компанию | 20% | 6% | 5% | 6% |
В первую очередь open source с сильной кастомизацией | 6% | 7% | 5% | 12% |
В первую очередь open source с небольшой настройкой | 5% | 12% | 24% | 15% |
Удобство инструментов существенно влияет на способность команды максимизировать ценность выбранного стека технологий: инженеры с простыми в использовании технологиями в 1,5 раза чаще принадлежат к командам с высокими показателями.
На мой взгляд, из этой таблицы складывается ощущение, что для того, чтобы быть успешной DevOps-командой, нужно следовать моде, а не технической задаче.
Грамотный специалист выбирает инструменты под задачу, а не наоборот. Для решения любой задачи существует всегда несколько инструментов и подходов. Конкретный инструмент определяется: спецификой задачи; насколько с этим инструментом знаком персонал (насколько велик порог входа, если инструмент новый); финансовой составляющей, если таковая присутствует.
Денис Романенко, внештатный эксперт Mail.ru Cloud Solutions
Каждая организация, работа которой зависит от работы программного обеспечения, должна иметь план аварийного восстановления [5]. В отчете показано, какие виды тестирования катастрофоустойчивости используют различные компании.
Какие типы испытаний используют компании для аварийного восстановления
Тип испытания | Команды с низкими показателями | Команды со средними показателями | Команды с хорошими показателями | Команды с высокими показателями | В среднем |
---|---|---|---|---|---|
Тесты, которые не затрагивают реальные системы | 35% | 26% | 27% | 30% | 28% |
Аварийное переключение инфраструктуры (в том числе ЦОД) | 27% | 43% | 34% | 38% | 38% |
Тестирование отказа приложения | 25% | 46% | 41% | 49% | 43% |
Моделирование инцидентов с нарушением работы тестовых систем | 18% | 22% | 23% | 29% | 23% |
Моделирование инцидентов с нарушением работы рабочих систем | 18% | 11% | 12% | 13% | 12% |
Создание автоматизации и систем, которые нарушают производственные системы на регулярной, постоянной основе |
9% | 8% | 7% | 9% | 8% |
Только 40% респондентов проводят тестирование аварийного восстановления ежегодно, используя один или несколько перечисленных методов. При этом в компаниях, которые проводят испытания аварийного восстановления, более высокий уровень доступности сервисов. Отчет показывает, что DevOps-команды с высокими показателями в 1.4 раза чаще учитывают данные тестов аварийного восстановления в процессах разработки и развертывания ПО.
Поддерживать производительность DevOps-команд на высоком уровне поможет легкий поиск информации для решения проблем. Это особенно актуально в современной технологической среде, которая состоит из сложных систем.
Источники такой информации можно разделить на две группы:
Технический долг включает код или системы с известными, но не исправленными ошибками; недостаточным покрытием тестами; низким качеством кода или дизайна; артефактами, которые не используются, но не удалены; реализациями, которые команда не может эффективно поддерживать; устаревшими технологиями; неполной или устаревшей документацией.
Эксперты обнаружили, что технический долг отрицательно влияет на эффективность DevOps. Команды с высоким техническим долгом были в 1,6 раза менее продуктивными. Команды с высокими показателями в 1,4 раза чаще имели низкий технический долг.
Автор: KushnirEA
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/oblachny-e-servisy/343064
Ссылки в тексте:
[1] Mail.ru Cloud Solutions: https://mcs.mail.ru/
[2] отчета 2019 Accelerate State of DevOps Report: https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
[3] основные приложения или сервисы на облачной платформе: https://mcs.mail.ru/blog/cloud-native-prilozheniya-bystro-zagruzhayutsya-snizhayut-riski-stimuliruyut-rost-biznesa
[4] Непрерывная интеграция и доставка (CI/CD): https://mcs.mail.ru/blog/ci-cd-kubernetes
[5] план аварийного восстановления: https://mcs.mail.ru/blog/plan-avariynogo-vosstanovleniya-disaster-recovery-plan
[6] Источник: https://habr.com/ru/post/483444/?utm_campaign=483444&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.