Авторы исследования отмечают, что более половины респондентов (54 %) признались в отсутствии IaaS (т.е. инфраструктуры, которая доступна им как услуга) и в использовании тикетов для управления инфраструктурой. При этом только у 23 % ответивших инфраструктура может быть развёрнута в пределах одних суток, для 33 % участников опроса этот процесс может занимать до месяца, а для 26 % — даже более того.
«Сегодня мы видим большой акцент на скорости, гибкости и необходимости делать всё быстро, а облака и подход as-a-service [IaaS, PaaS и т.п. — прим. перев.] способствуют этому. В результатах опроса мы увидели, что отсутствие доступа к инфраструктуре-как-услуге является очень узким горлом», — подчеркнули авторы из Quali.
Сложности и решения
Как же выглядит весь список главных сложностей на пути к DevOps и что поможет в их решении?
1. Отсутствие культуры
Компаниям необходимо сфокусироваться на построении культуры взаимодействиями с общими (разделяемыми всеми участниками) целями. Важно также находить сотрудников, которые могут возглавлять DevOps-деятельность внутри организации.
2. Автоматизация тестов
Многие компании отбрасывают автоматизацию тестирования, сосредотачиваясь на процессах CI/CD. Однако непрерывное тестирование — ключ к успеху в DevOps. С самого начала надо учитывать и вопросы безопасности.
3. Устаревшие системы
Учёт устаревшей инфраструктуры и приложений должен стать неотъемлемой частью ваших планов по внедрению DevOps. Установка нового оборудования или софта и их одновременное сосуществование с более старыми системами — это всегда трудно.
4. Сложность приложения
При изменении архитектуры приложения закладывайте возможность использования SaaS, облачной инфраструктуры, контейнеров.
5. Отсутствие плана по DevOps
Создайте чёткий план, включающий в себя этапы, ответственных и конкретные результаты.
6. Управление окружением
Стандартизация и автоматизация работы со сложным окружением для DevOps может быть достигнута с помощью контейнеров от облачных сервис-провайдеров и других готовых инструментов.
7. Недостаток навыков
Команды необходимо обучать DevOps. В компании должны быть стандартизированы процессы и общие эксплуатационные процедуры.
8. Бюджет
Помните, что Open Source вовсе не означает бесплатность: за интеграцию и сложность эксплуатации придётся платить.
9. Неподходящие инструменты
Избегайте применения разрозненных утилит (любимых отдельными разработчиками, а не хорошо интегрируемых с другой инфраструктурой) — иначе это увеличит расходы.
10. Поддержка руководства
Расскажите руководителям своей компании о преимуществах DevOps, чтобы заручиться их поддержкой в финансах и ресурсах.
Подводя итог
Показательно, что даже самые главные сложности, занявшие первые 3 места в этом «рейтинге», получили достаточно небольшой процент голосов: для 14 % основным барьером является культура, для 13 % — автоматизация тестов, для 12 % — устаревшие системы. Полученная вариативность говорит о том, что при внедрении практик DevOps нужно учитывать многие разрозненные факторы, которые, как и DevOps, связаны не только с технологиями, но и с людьми, и с самими процессами. Более того, если многие из них являются общими для всех компаний, то некоторые могут быть специфичными.
P.S. Для любителей статистики: наиболее популярными программными инструментами, используемыми респондентами для организации DevOps, стали Jenkins (21 %), Docker (16 %), Puppet (14 %) и Chef (13 %).
* Quali — компания с израильским происхождением и штаб-квартирой в США, которая специализируется на облачных технологиях, DevOps и BizOps. Опрос проводился среди посетителей таких крупных ИТ-событий прошлого года, как Cisco Live, VMWorld, Jenkins World и др.
Некоторые уточнения по итогам опроса были взяты из статьи Madison Moore на SD Times.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (11)
amarao
23.03.2017 15:14+15. Отсутствие плана по DevOps
Создайте чёткий план, включающий в себя этапы, ответственных и конкретные результаты..
Супер. Обожаю планы по вещам, которые не известны.
План научных открытый на 2017 год.
…
Менеджерам по научным открытиям обеспечить неуконснительное исполнение плана в соответствии с утверждённым графиком. Отвественным за научный прорыв назначить shurup.
shurup
23.03.2017 15:24«вещам, которые не известны» — а как вы собрались внедрять что-то, что вам неизвестно, и, главное, зачем вообще это делать?
amarao
23.03.2017 15:44+2Попробовав их! Откуда я знаю, что свежий модный молодёжный aptly лучше, чем старый олдфаговый и работающий reprepro? Попробовал, потом решил, годно оно или нет.
Всё современное IT построено на том, что пробуют внедриться вещи, которые не известно, хорошо или нет. Те, кто так не делают, сидят на виндосапе ровно и не дёргаются, те, кто делают — либо имеют проблемы (потраченные зря ресурсы), либо получают немалый прирост к эффективности.shurup
23.03.2017 16:09Я бы не стал сравнивать такую комплексную вещь, как DevOps, с такими частностями, как reprepro… Но ключевой момент здесь в другом: в статье/опросе речь скорее о тех, кто уже решился на сабж всерьёз, а не просто посмотреть-попробовать. Чтобы попробовать (а в том или ином виде это сделано) — всё описанное не нужно (потребуется на следующем этапе и некоторое понимание тогда уже быть должно).
VolCh
27.03.2017 23:01Такую "комплексную вещь" практически невозможно просто попробовать. Попробовать можно отдельные её аспекты, не более.
zenkz
24.03.2017 18:57+2Жалко что в опросе нет пункта — «Нет желания внедрять DevOps» — думаю это будет один из самых популярных ответов.
DevOps — это карго-культ. Я не говорю что он плох, но говорю о том что его нужно применять выборочно и осознано, а не из-за того что это модно и круто. Тоже могу сказать про автоматизированное тестирование и TDD. Если вы пишите API или сервисы и у вас до сих пор нет Unit-test-ов — мне вас жалко, но если у вас проект-монолит, которому уже 5-10 лет, то 100% покрытия не получится, да и оно не нужно.
На своём примере могу сказать, что работая 8 лет в различных компаниях (по большей части крупных и уважаемых) юнит тесты использовал очень редко т.к. либо за них не был готов платить заказчик, либо невозможно было прикрутить к существующему проекту. То же самое могу сказать про DevOps — если есть выгода для бизнеса — внедряем. Если нет, то нет (он отлично заменяется регламентами и планированием).
zirf
25.03.2017 03:20+2Интересно, что основная трудность. Отсутствие понимания "Что такое DevOps?" Провести опрос и сразу станет все на свои места, 90% респондентов даже объяснить что это не смогут. А, к примеру, CI/CD или TDD — это частности. Разница — метод/методология или идеология кому как удобнее.
erwin_shrodinger
заменяем DevOps на что угодно и получаем название очередного тренинга личностной эффективности =(
zenkz
гы-гы. Если в тексте заменить Dev-Ops на любую методологию или технологию, то можно даже не менять текст.
Для примера:
Сложности и решения
Как же выглядит весь список главных сложностей на пути AGILE/TDD/к вселенскому благоденствию и что поможет в их решении?
1. Отсутствие культуры
Компаниям необходимо сфокусироваться на построении культуры взаимодействиями с общими (разделяемыми всеми участниками) целями. Важно также находить сотрудников, которые могут возглавлять отдел по внедрению AGILE/TDD/вселенского благоденствия внутри организации.
2. Автоматизация тестов
Многие компании отбрасывают автоматизацию тестирования, сосредотачиваясь на процессах CI/CD. Однако непрерывное тестирование — ключ к успеху в AGILE/TDD/вселенском благоденствии. С самого начала надо учитывать и вопросы безопасности.
3. Устаревшие системы
Учёт устаревшей инфраструктуры и приложений должен стать неотъемлемой частью ваших планов по внедрению AGILE/TDD/вселенского благоденствия. Установка нового оборудования или софта и их одновременное сосуществование с более старыми системами — это всегда трудно.