Несколько лет назад многие организации рассматривали DevOps как перспективный эксперимент, а не основной подход к разработке программного обеспечения. Сейчас DevOps — проверенный и мощный набор практик и инструментов разработки и развертывания, позволяющий ускорить релизы новых продуктов и повысить производительность труда. Что еще важнее: эффект DevOps направлен на общий рост бизнеса и увеличение его прибыльности.
Команда Mail.ru Cloud Solutions перевела самое интересное из отчета 2019 Accelerate State of DevOps Report, составленного экспертами DevOps Research & Assessment (DORA). В исследовании участвовали 31 000 специалистов со всего мира. Посмотрим, что изменилось в отрасли в 2019 году и как бизнес может повысить эффективность доставки программного обеспечения.
Как на состояние DevOps влияют отрасль и размер компании
В исследовании не выявили связи между эффективностью DevOps и отраслью организации, за исключением розничной торговли, где показатели были чуть лучше. Это, в частности, связано с тем, что ритейлерам надо оперативно реагировать на колебания спроса и потребности покупателей. По данным исследования, высокого уровня в DevOps может достичь любая компания, включая финансовый сектор и госсектор.
Показатели эффективности DevOps в компаниях, где более 5000 сотрудников, были ниже, чем в компаниях, где менее 5000 сотрудников. Скорее всего, это связано с тем, что в крупных организациях более масштабные процессы, строже контроль, сложнее архитектура IT-систем, что вносит задержки в процесс разработки и выкатки кода. При этом эксперты считают, что масштаб компании не препятствует успеху в построении DevOps, просто в некоторых случаях это может потребовать больше усилий.
Как оценить уровень DevOps в компании
Эксперты сравнивали процессы DevOps с эталонной оценкой, разделив участников опроса на четыре группы с лучшими, хорошими, средними и низкими показателями.
Для отчета взяли четыре ключевые метрики оценки эффективности DevOps: время выполнения изменений при разработке ПО, частота развертывания, частота провалов и время восстановления.
Четыре уровня DevOps — оцените, на каком находится ваша компания:
| Метрика оценки эффективности доставки ПО для основных сервисов и приложений компании | Команды с лучшими показателями | Команды с хорошими показателями | Команды со средними показателями | Команды с низкими показателями |
|---|---|---|---|---|
| Частота развертывания Как часто компания развертывает код в производство или выпускает его для конечных пользователей. |
По запросу, несколько развертываний в день | От одного раза в день до одного раза в неделю | От одного раза в неделю до одного раза в месяц | Один раз в месяц/несколько месяцев |
| Время выполнения изменений Сколько времени занимает переход от теста до ПО, успешно работающего в производстве. |
Меньше чем за день | От одного дня до недели | От одной недели до месяца | От месяца до шести месяцев |
| Время восстановления сервиса Сколько времени уходит на восстановление сервиса после инцидента или бага, влияющего на пользователей. |
Меньше часа | В течение дня | В течение недели | От недели до месяца |
| Частота провалов при изменениях Какой процент обновлений или новых релизов приводят к ухудшению обслуживания и требуют исправлений. |
0-15% | 0-15% | 0-15% | 46-60% |
Исследование выявило следующую тенденцию: число команд с высоким уровнем показателей почти утроилось, увеличившись с 7% от всех респондентов в 2018 году до 20% в 2019 году.
Распределение групп разработчиков по уровням производительности.
По сравнению с командами в группе с низкой эффективностью, команды DevOps с высокими показателями:
- Выполнили в 208 раз больше развертываний кода.
- В 106 раз меньше времени тратили на развертывание кода.
- В 7 раз реже сталкивались с провалами.
- В 2,604 раза быстрее восстанавливали работу ПО после сбоев.
Кроме того, у команд DevOps с высокими показателями в два раза больше шансов достичь или превзойти свои организационные показатели эффективности, чем у команд с низкими показателями.
Многие специалисты думают, что нельзя достичь увеличения всех показателей одновременно, надо идти на компромисс. Так, некоторые считают, что увеличение скорости выкатки релизов может негативно повлиять на надежность процесса доставки ПО и оказания услуг. Однако исследования показали, что скорость и стабильность результатов не исключают друг друга.
В росте числа DevOps-команд я не вижу ничего удивительно, он закономерен: философия DevOps сейчас популярна, а количество стартапов растет.
Но, на мой взгляд, эксперты выбрали не совсем корректные параметры оценки эффективности DevOps.
Оценивать ее по скорости выкатки кода, по меньшей мере, странно. Это применимо только к стартапам, где ключевым параметром будет скорость вывода продукта на рынок, при этом часто продукт выводится в сыром виде. В таких условиях механизмы, ускоряющие разработку и доставку в продакшен, являются жизненно необходимыми. А вот для устоявшегося ПО, например финансового или медицинского, параметра частоты провалов может не существовать — провалы могут быть недопустимы.
Аналогично с временем восстановления сервиса: для любого развитого сервиса оно должно исчисляться секундами, а для многих сервисов простой недопустим, для этого придумали технологии бесшовной выкатки (например green/blue).
Также не стоит ориентироваться на количество развертываний кода — оно зависит от необходимости и компетенций команды разработки. Если развертывание связано с добавлением нового функционала — это одно, а если с исправлением ошибок, допущенных при предыдущих развертываниях — совершенно другое.
Денис Романенко, внештатный эксперт Mail.ru Cloud Solutions
Как улучшить процессы DevOps
В отчете представлены два направления, которые помогут улучшить DevOps: повышение эффективности разработки и доставки ПО и улучшение производительности труда.
В каждое из направлений входят свои компоненты, улучшив которые, можно достичь нужной цели.
По данным отчета, ключ к цифровой трансформации — корпоративная культура. Высокоэффективным командам DevOps нужна культура доверия и психологическая безопасность, понимание результатов работы и четкие цели. Такая среда позволяет членам команд принимать взвешенные решения, высказывать свое мнение и быть более творческими.
Улучшить эффективность разработки и доставки ПО также помогут облачные технологии, непрерывная доставка, тестирование аварийного восстановления, управление изменениями. Производительность труда можно повысить, вкладывая средства в простые в использовании инструменты, уменьшая техническую задолженность, то есть снижая процент неэффективного кода и устаревших технологий, организуя корпоративную базу знаний и доступ к внешним решениям.
Я думаю, что методология и идеология DevOps как раз в том, чтобы эти процессы не зависели от внешних условий, таких как облако или свое железо. Само по себе облако — не более чем инструмент, где-то он поможет, где-то помешает или будет не востребован.
Денис Романенко, внештатный эксперт Mail.ru Cloud Solutions
Ниже рассмотрим некоторые составляющие улучшения эффективности DevOps-команд.
Облачные технологии способствуют успеху DevOps
В 2019 году все больше организаций выбирают облачные решения, значительно повышающие производительность DevOps-команд.
Какие инфраструктуры используют DevOps-команды.
DORA обнаружила, что 80% респондентов размещают основные приложения или сервисы на облачной платформе. Тем не менее только 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: некоторые из них разрабатываются на уровне команды, другие требуют усилий на уровне организации.
Какие направления роста выделены для DevOps-команд в 2019 году:
| На уровне организации |
|
| На уровне команды |
|
| На уровне команды и организации |
|
Исследование подтвердило положительное влияние слабосвязанной архитектуры на эффективность DevOps.
Слабосвязанная архитектура — это когда команды могут независимо тестировать, развертывать и изменять системы по требованию, независимо от других команд, без дополнительной поддержки, ресурсов, одобрения, с меньшим количеством обратной связи. Это позволяет эффективнее работать, но требует высокого уровня организации и управления.
Такой подход возможен только для стартапов и с некоторыми оговорками. В других компаниях может быть иная ситуация. Хороший пример: банковская сфера/финтех. Там могут использоваться исключительно проприетарные решения, однако будут применяться практики DevOps.
Денис Романенко, внештатный эксперт Mail.ru Cloud Solutions
Успешные DevOps-команды автоматизируют всё
Непрерывная интеграция и доставка (CI/CD) позволяет выводить сервисы и приложения в прод с меньшими затратами и рисками, а также поддерживать релизы в соответствии с целями организации.
Успешный CI/CD также означает, что команды могут внедрять изменения в производство по требованию, им сразу же доступна обратная связь о качестве развертывания, ее можно быстро отработать и улучшить следующий цикл развертывания.
Отчет показывает, что успешные DevOps-команды инвестируют в широкий спектр вспомогательных процессов, практик и инструментов:
- 92% используют автоматизированные инструменты для сборки;
- 87% используют автоматизированные юнит-тесты;
- 57% распространяют автоматизацию на приемочные испытания;
- 72% автоматизируют развертывания в тестовых средах, 69% делают то же самое для развертывания в проде;
- 69% интегрируют чат-ботов в процесс развертывания;
- 57% интегрируются с инструментами мониторинга.
Важно выбрать правильные инструменты и технологии
При построении сложных систем и управлении критически важными для бизнеса инфраструктурами важно подобрать технологии:
- которые легко использовать как при первом подключении, так и в постоянной эксплуатации;
- которые помогают достичь поставленных целей.
В отчете изучили инструменты, используемые при развертывании программного обеспечения через 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
Аварийное восстановление
Каждая организация, работа которой зависит от работы программного обеспечения, должна иметь план аварийного восстановления. В отчете показано, какие виды тестирования катастрофоустойчивости используют различные компании.
Какие типы испытаний используют компании для аварийного восстановления
| Тип испытания | Команды с низкими показателями | Команды со средними показателями | Команды с хорошими показателями | Команды с высокими показателями | В среднем |
|---|---|---|---|---|---|
| Тесты, которые не затрагивают реальные системы | 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-команд на высоком уровне поможет легкий поиск информации для решения проблем. Это особенно актуально в современной технологической среде, которая состоит из сложных систем.
Источники такой информации можно разделить на две группы:
- Внутренние источники: документация компании по созданию и поддержке кода, корпоративные базы знаний, репозитории и другое. Те DevOps-команды, которые использовали внутренние источники знаний, были в 1,73 раз более продуктивными.
- Внешние источники: поисковые системы и пополнение стека. DevOps-команды, прибегающие к внешним источникам, были в 1,67 раз продуктивнее. Внешние технологии дают большое преимущество для обучения и роста, особенно применение общедоступных облаков и инструментов с открытым исходным кодом.
Компаниям важно снижать технический долг
Технический долг включает код или системы с известными, но не исправленными ошибками; недостаточным покрытием тестами; низким качеством кода или дизайна; артефактами, которые не используются, но не удалены; реализациями, которые команда не может эффективно поддерживать; устаревшими технологиями; неполной или устаревшей документацией.
Эксперты обнаружили, что технический долг отрицательно влияет на эффективность DevOps. Команды с высоким техническим долгом были в 1,6 раза менее продуктивными. Команды с высокими показателями в 1,4 раза чаще имели низкий технический долг.
Ключевые выводы исследования о состоянии DevOps
- Процент команд DevOps с высокими показателями почти утроился и составляет 20%. Это означает, что бизнес понимает перспективность практик улучшения разработки и доставки ПО, компании активнее внедряют DevOps в своих IT-отделах.
- Быстрая доставка приложений и сервисов лежит в основе трансформации технологий и организационных показателей. Скорость и стабильность выкатки релизов повышает прибыль и удовлетворенность клиентов.
- Облачные технологии продолжают быть ключевыми для достижения высоких результатов DevOps-команд. Использование облаков позволяет организовать доставку ПО с нужной скоростью, обеспечивает доступность, масштабируемость и производительность инфраструктуры.
- Эффективность DevOps-команд можно улучшить, если уделять внимание продуктивности работы участников команды, обеспечить комфортную психологическую атмосферу и использование удобных инструментов.
- Повышение скорости выкатки релизов при правильном подходе не влияет на стабильность работы сервисов и приложений компании.
Автор: KushnirEA
