При всех достоинствах DevOps, этот, особенно популярный сейчас, подход к организации процессов разработки и эксплуатации ПО, не лишен недостатков. Сегодня мы поговорим о том, когда лучше обойтись без девопс и как его внедрить, если он не очень подходит, а очень хочется. Также расскажем, почему DevOps – не панацея и какие проблемы поджидают вас после его внедрения.
Когда не нужен девопс
На первый взгляд может показаться, что безбарьерная организация процессов разработки и эксплуатации приложений подходит любой ИТ-компании. Однако, это не совсем так. Прежде всего, считается, что малый бизнес и стартапы могут вполне обойтись без DevOps, т.к. тестирование, развертывание и поддержку небольших проектов можно выполнять и вручную, без использования сложных инструментов автоматизации (а также дорогих специалистов, которые умеют с ними работать).
Кроме того, иногда не стоит внедрять DevOps и в «тяжелый enterprise», несмотря на то, что изначально этот подход был придуман для решения проблем именно корпоративного ИТ-мира. В частности, для «монолитных» приложений, когда все функции программы реализованы в едином структурированном пространстве взаимосвязанных файлов и пакетов, DevOps в чистом виде не нужен. Несмотря на растущую популярность микросервисной архитектуры, ее поддерживают далеко не все программные решения. Например, очень многие, особенно давно существующие, финансовые системы (в банках, процессинговых услугах) организованы по принципу «монолита», который они только сейчас постепенно начинают «распиливать» на микросервисы. Именно в этом ключе они присматриваются к интегрированным концепциям DevOps [1]. Ведь в «монолите» обновления не так часты и справляться с выпуском нескольких сборок раз в 2-4 недели вполне по силам одному специалисту, без привлечения сложных средств автоматизации. А если система состоит из множества отдельных модулей, которые постоянно обновляются с разной регулярностью, потребуется уже автоматизированное решение для поставки готового продукта в работу [2].
Также следует помнить об организационной стороне вопроса: в корпоративном мире существует четкое разделение труда. У разработчиков и эксплуатационщиков отдельные департаменты, начальники и зарплаты, привязанные к разным показателям эффективности, которые не связаны друг с другом. Поэтому внедрение DevOps невозможно до тех пор, пока деятельность не согласована, а бизнес-процессы и финансовые фонды не выстроены вокруг общего результата.
Наконец, DevOps предполагает не только использование новых инструментов и перекраивание процессов, но и изменение самой корпоративной культуры. Если сотрудники или руководство игнорируют принципы и ценности подхода, не стоит тратить время и ресурсы на попытки его адаптации. В частности, опыт «Манго Телеком» показывает, что, несмотря на поддержку принципов Agile, внедрить DevOps в Scrum-команду не так просто, т.к. сотрудники не могут/не хотят отвлекаться на нововведения, когда необходимо уложиться в спринт. Кроме того, для автоматизации существующего процесса необходима документация, ценность которой не слишком высока в гибких методологиях, и потому ее полнота и качество могут не соответствовать нужному уровню актуальности [3].
Как внедрить DevOps, если он не походит, но очень хочется
Тем не менее, даже тяжеловесные мастодонты (банки, нефтегазовая отрасль, машиностроение и др. отрасли промышленности) соблазняются преимуществами, которые обещает Agile вообще и DevOps в частности. Поэтому вопрос о внедрении звучит не так: «Быть или не быть?», а «Как сделать хорошо, быстро, просто и не слишком дорого?».
Как и любая идея, DevOps невозможно внедрить в чистом виде – на практике каждая компания старается взять из этого подхода самое лучшее, адаптировав его под свою специфику и вводя в пользование постепенно. Например, как это сделал «Центр Финансовых Технологий» — отечественная компания с несколькими офисами, распределенными по всей стране, которая занимается разработкой ПО для финансового сектора [1].
Постепенное внедрение девопс можно свести к следующим шагам [4]:
- Четко сформулируйте задачи, которые вы хотите решить с помощью девопс, например, обеспечивать выпуск 100 работоспособных сборок ежедневно, создать конвейер развертывания и т.п.;
- Обсудите решение с командой (разработчиками, тестировщиками, администраторами, техподдержкой), чтобы определить самые проблемные места в процессах и выбрать, какие инструменты автоматизации стоит внедрять прежде всего.
- Обеспечьте сотрудникам понимание и принятие CALMS — 5 главных принципов DevOps: культуры, автоматизации, бережливости, измерений и общения. Перестройте бизнес-процессы и организацию команд вокруг продукта, а не по функциональному разделению.
- Автоматизируйте ту часть IT-процессов, которая больше нуждается и подходит для этого, например, тестирование или подготовка окружений на сервере для рабочего решения. Определите метрики для оценки успешности автоматизируемых процессов.
- Анализируйте изменения: процессы, отношение сотрудников, ключевые показатели. Покрывают ли результаты от использования DevOps усилия, потраченные на внедрение этого подхода? Если нет, необходимо вернуться к шагу 1, пересмотреть поставленные задачи или попробовать другие организационные и технические инструменты. Если польза от частичного внедрения DevOps уже видна, следует масштабировать подход на другие процессы и проекты.
Почему DevOps – не панацея: проблемы после внедрения
Однако, как уже было отмечено ранее, DevOps не является серебряной пулей для решения всех ИТ-проблем. Более того, использование этого похода способно спровоцировать новые, в частности [3]:
- временное падение производительности труда в начале использования новых методов организации работы и технических инструментов, т.к. команда только привыкает к изменениям. Это может негативно отразиться на финансовых результатах, поэтому не стоит делать глобальные выводы о неэффективности девопс по первым неудачам.
- DevOps не работает «в одиночку» — не стоит ждать тотального сокращения сроков вывода продукта на рынок, внедрив его только в ИТ-процессы. Если маркетинговые исследования, как и раньше, длятся годами, ускорение разработки, тестирования и развертывания ПО, не поможет быстрее доставить продукт потребителю. Поэтому, например, Райффайзенбанк расширяет ценности DevOps и на другие бизнес-процессы.
- расширение штата сотрудников, выполняющих аналогичную работу, и увеличение объема работ – к примеру, если, согласно Agile-принципам быстрого реагирования на запросы клиентов, техническая поддержка постоянно создает новые заявки, необходимо увеличивать частоту релизов. Это, в свою очередь, приводит к найму новых разработчиков, тестировщиков и эксплуатационщиков, но не всегда кардинально повышает прибыль от итогового продукта, как справедливо отмечает директор по разработке ПО в группе «Альфастрахование».
- повышение квалификационных требований к сотрудникам (DevOps-инженерам), которые должны глубоко разбираться во множестве технологий. Таких профессионалов на ИТ-рынке немного и стоят они достаточно дорого. А популярность термина DevOps привела к еще большему ажиотажу вокруг этого понятия. Есть такая расхожая шутка, что системный администратор со знанием Docker от DevOps-инженера со знанием Docker, отличается не знаниями, а зарплатой: 1 девопс стоит как 2 администратора [5].
Тем не менее, несмотря на указанные проблемы, DevOps и прочие Agile-инструменты цифровизации продолжают внедряться в нашу жизнь, меняя рабочие процессы и сознание их участников. Концепция девопс тоже продолжает свое развитие, трансформируясь в обеспечение эксплуатационной надежности — SRE, о чем мы рассказываем в следующей статье.
Как взять лучшее от девопс и не навредить бизнесу, а также получить реальную выгоду от гибких подходов к разработке ПО и управлению проектами, мы рассматриваем на практическом курсе «Аналитика больших данных для менеджеров» в нашем учебном центре для руководителей, аналитиков, архитекторов, инженеров и исследователей Big Data в Москве.
Источники
- https://habr.com/ru/company/oleg-bunin/blog/328256/
- https://habr.com/ru/company/netcracker/blog/421423/
- https://habr.com/ru/post/449666
- https://vc.ru/hr/50165-chto-takoe-metodologiya-devops-i-komu-ona-nuzhna
- https://habr.com/ru/company/oleg-bunin/blog/358480/
