DevOps — новый уровень взаимодействия групп разработки и эксплуатации

    Создание приложений — комплексный процесс, который включает в себя несколько элементов: написание кода, тестирование, устранение ошибок, проверку и, наконец, запуск в эксплуатацию. Можно сказать, что в этом процессе участвуют три независимых «государства» — разработчики, тестировщики и сотрудники отдела эксплуатации. Каждая из этих групп выполняет собственные задачи и пользуется разными критериями оценки эффективности своей работы. Для разработчиков — это скорость написания и количество реализованных в программном коде функций, для тестировщиков — число выявленных ошибок, для отдела эксплуатации — стабильность функционирования систем и минимальное количество инцидентов. Подобная модель работы нередко приводит к конфликту интересов: первые стараются как можно быстрее написать код и отдать его на проверку, вторые готовы проверять и тестировать сколь угодно долго, чтобы выявить все баги, а третий с трудом принимает код, поскольку любые изменения влекут за собой потенциальные риски для всей ИТ-инфраструктуры. В итоге весь процесс создания приложений растягивается надолго, что с учетом сложной экономической ситуации совершенно недопустимо, ведь бизнес должен быть максимально гибким и клиентоориентированным, а выпуск новых продуктов и услуг своевременным.



    Разумеется, многие компании уже давно осознали неэффективность подобной модели выпуска приложений и начали поиски способов её оптимизации. Одним из таких способов является модель Agile, которая предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности. При этом отдел эксплуатации все еще остается «за рамками» модели Agile. Если разработчики и тестировщики заинтересованы в как можно более быстром создании работоспособного кода, ошибок в котором нет, то эксплуатация, как и прежде, не готова к новым подходам. Ведь любое изменение, вносимое с появлением нового программного кода, чревато потенциальными аварийными ситуациями и другими нежелательными инцидентами в работе ИТ-инфраструктуры. Существует вероятность того, что с установкой новой версии программного обеспечения, все попросту «рухнет». Именно этого и опасаются специалисты служб эксплуатации, и зачастую такие опасения небезосновательны.

    Необходимо устранить последнюю преграду между разработчиками и тестировщиками, с одной стороны, и службами эксплуатации, с другой. Эту задачу призвана решить методология DevOps, которая, по сути, расширяет рамки Agile, вовлекая в них подразделения по эксплуатации, но не только. Ее можно реализовать и в традиционной классической модели разработки Waterfall. Возможны варианты, когда одна часть команды работает по методологии Agile, а другая — по Waterfall. При этом переход на DevOps позволит учесть общие интересы и критерии, чтобы наладить совместное эффективное взаимодействие буквально всех подразделений — разработчиков, тестировщиков и специалистов по эксплуатации. Ведь суть DevOps не только в формализованных процессах, но в изменении культуры разработки программного обеспечения.

    Что же поможет реализовать методологию DevOps в компании? В первую очередь нужны такие подходы, которые максимально автоматизируют все процессы и цикл разработки в целом. Поскольку цикл разработки велик и многогранен, для его автоматизации используется широчайший спектр продуктов, среди которых и решения компании HPE, и приложения сторонних разработчиков, в том числе свободное ПО.

    image

    Ho DevOps состоит не только из технологий. Не менее важная роль отводится взаимодействию людей и процессам. По данным Gartner, опубликованным в конце прошлого года, 50% успеха проектов DevOps кроется именно в человеческом факторе, 37% — в процессах, и только 8% — в технологиях. Зачастую заказчики надеются, что после установки и интеграции всех необходимых программных продуктов у них заработает DevOps, но подобные проекты проваливаются чаще всего. Пока люди не станут единой командой с общими интересами и критериями эффективности, DevOps функционировать не сможет. Пока специалисты по эксплуатации не осознают свою ответственность еще на этапе постановки требований, а разработчики не будут отвечать за качество кода в эксплуатации, методология DevOps останется невостребованной.

    Что же необходимо предпринять для создания единой команды по правилам DevOps? Прежде всего нужно выяснить, как работают сотрудники, что им помогает, а что мешает. Существует немало различных образовательных курсов по построению DevOps, есть такие курсы и у HPE. Если в организации используются не только классические Waterfall-подходы к разработке, но и методы Agile, следует подумать о масштабировании всего процесса, в котором участвует несколько команд. В качестве наиболее эффективного инструмента для решения этой задачи HPE рекомендует Scaled Agile Framework.

    HPE активно готовит и уже запустила часть учебных курсов по переходу и освоению методологии DevOps. Один из них, DevOps Awareness, доступен и в России; в нем рассказывается об общих принципах методологии и о специализированных подходах компании HPE. Кроме того, для российских пользователей уже практически готовы другие курсы: углубленный по DevOps, по его использованию на практике, а также по сопутствующим программным продуктам.

    Какую реальную экономическую выгоду для заказчика способен принести переход на модель DevOps? Методологически она базируется на Scaled Agile Framework, который позволяет вычислить преимущества в рублях и процентах при переходе на DevOps с Waterfall, Agile и в случае смешанных вариантов. По сути, DevOps можно сравнить с автомобильным конвейером, максимально быстро выводящим готовый автомобиль от инженера до потребителя. В сравнении с Waterfall, к примеру, у DevOps есть неоспоримое преимущество: максимальное снижение рисков при развертывании благодаря автоматизации всех процессов. При разработке по модели Waterfall примерно треть всех погрешностей обусловлена человеческим фактором: люди ошибаются при внесении изменений, при подготовке инфраструктуры и т.д. Чаще всего эти ошибки возникают из-за того, что у различных подразделений, участвующих в создании программного обеспечения, нет общих инструментов и отсутствует возможность делиться полученными знаниями. Еще один немаловажный момент — размывание ответственности, когда каждый специалист отвечает только за свой узкий участок.

    image

    Теперь немного о том, как реализована продуктовая поддержка DevOps. Сначала в продуктах HPE Project Portfolio Manager и Service Manager происходит планирование изменений. Сюда относятся потребности и запросы, о которых сообщает бизнес.

    Кроме того, при помощи Service Manager служба эксплуатации может сообщить, какие изменения нужно внести в программный код для устранения конкретного инцидента, и эти изменения сразу же трансформируются в задачу для Project Portfolio Manager. Еще один продукт, с которым интегрируется Project Portfolio Manager — HPE Agile Manager, в нем задача связывается с User story. Таким образом, назначив задачу в Project Portfolio Manager, мы можем указать, что эта задача будет реализовываться по гибкой методологии в Agile Manager, то есть интегрируем их, и в результате все User story Agile Manager отображаются в Project Portfolio Manager.

    Следующий этап — разработка. Можно использовать абсолютно любую среду разработки — Visual Studio, Eclipse и т.д. Все эти продукты тоже интегрируются с Agile Manager и имеют доступ к User Story. Разработчик в привычной среде получает уведомления из Agile Manager о назначении ему той или иной User Story, после чего принимает её в работу и начинает менять программный код в соответствии с поставленной задачей. После изменения кода можно произвести контроль безопасности с помощью HPE Fortify Static Code Analyzer и при необходимости осуществить другие вспомогательные операции, а затем дать команду на выполнение последующих операций. Созданный код сохраняется в хранилище (Git или любом другом), после чего автоматически компилируется с сохранением артефактов компиляции. Одновременно происходит обновление универсальной базы данных управления конфигурациями (UCMDB), которая автоматически переходит на новую версию разрабатываемого ПО. Всем этим процессом, как правило, «руководит» Jenkins или другой Continuous Integration Tool — интеграционная платформа, обеспечивающая непрерывность процессов разработки программного обеспечения.

    Далее Jenkins готовит среды для тестирования. Здесь можно использовать HPE Codar, VMware, Docker или другие продукты. Наиболее распространены статичные тестовые контуры, в которые изменения вносятся в автоматическом режиме. При необходимости тестовые среды — как физические, так и виртуальные либо смешанные — могут быть созданы полностью «с нуля». Именно на этом этапе удается избежать той самой трети конфигурационных ошибок, возникающих при выполнении этой процедуры в ручном режиме. В тестовые среды встраивается мониторинг, позволяющий как можно раньше выявить возможные ошибки. В дальнейшем скрипты мониторинга будут применены и в промышленной среде.

    После развертывания тестовой среды, Jenkins запускает процедуру автоматического тестирования: функциональные, нагрузочные, производительные, интеграционные, регрессионные или другие виды тестов. В случае их успешного прохождения на всех контурах код автоматически разворачивается на промышленной среде и в последний раз проверяется на работоспособность.

    По словам многих заказчиков, ценность описанного подхода состоит в том, что он позволяет получить полную картину модели разработки — с участием абсолютно всех заинтересованных сторон, с четко обозначенными процессами и интеграционными механизмами. В заключение следует подчеркнуть, что стратегия Hewlett Packard Enterprise по отношению к DevOps подразумевает использование не только продуктов HPE, но и любых других решений, ведь главное, как уже говорилось выше, отнюдь не технологии, а люди и процессы.
    • +12
    • 14.4k
    • 5
    Hewlett Packard Enterprise
    89.43
    Company
    Share post

    Comments 5

      +6
      Основная мысль которую должны понимать современные компаний занимающиеся разроботкой ПО/Web-приложений/и пр. должна быть следующей:
      процесс разработки тестирования и эксплуатации ПО неразрывен. Программисты, админы и тестировщики всегда должны быть одной командой. Не нужно никаких модных слов. Нужна хорошая командная работа и грамотный менеджмент без матоков и размахивания пренадлежностями, и тогда и только тогда на выходе будет получаться хороший программный продукт. Без должного отношения друг к другу и нормального отношения к задачам не будет хорошего результата. В общем разработка это сложный процесс который требует слаженности и ответственности и не более.
        +7
        Угу… А то как в некоторых конторах — все по agile, вокруг одни techlead да devops в casual, с важным видом попивающие свои smoothies, постоянные seminars & techdays, по выходных — посещение co-working, иногда даже с co-living. А на выходе через полгода проекта — the bolt…
          0
          Плюсануть не могу, но согласен, кто же будет спорить с тем, что дело должно быть впереди пустых деклараций.

          Попробую аналогию. Тут сказано, что все должны дружить и нужен клевый менеджмент. Супер, а куда деть реальность? Предположим, что организация это как клетка: есть органеллы, что делают свою работу и есть оболочка через которую идет взаимодействие- менеджмент. Новые идеи, чтобы они проникли внутрь организации и были восприняты менеджментом приходится как ДНК вируса обрамлять в оболочку способную помочь в проникновении в клетку. В данной аналогии такой оболочкой служит «маркетинг». Как ни хотелось бы чтобы дримтим был, в реальности требуются капитальные усилия, чтобы люди купили простые и понятные идеи. А «маркетинг» способствует тому, что если поблизости окажется эффективный менеджер, то он не будет активно противодействовать, восприняв адаптированную идею.

          Ну и разумеется, есть те кто за видимым фасадом прячут пустоту. Мое мнение, плевать на тех, кто декларирует, что он develop'ит по agile, deploy и Test у него по Devops, хотя организация лишь перевесила таблички и перепечатала визитки. Если то, что мы пишем, будут читать разумные люди и делать определенные выводы, значит написали не зря.
            0
            Есть еще один подход: «мы тут в enterprise, нельзя делать плохо, надо делать хорошо и быстро, то что вы не успеваете по срокам — это недоработка менеджмента, да, нужно над этим работать (из уст руководителя отдела, он же ставит сроки), нужно… (длинная терада про то что МЫ не умеем ставить сроки)» а потом, пятница, вечер, подходят к devops и говорят — «нужно внедрить, знаем что не протестировано, значе что перед выходными, но сроки горят, нужно было вчера… » И тут в голове DevOps'a всплывает «у нас же enterprise» а по факту у нас «The Bolt»
          0
          «Основная преграда» между разработкой, включая анализ, постановку и тестирование, и эксплуатацией — это ошибки во внедряемых сервисах, на самом деле это не преграда, а простой конфликт интересов, устранить его невозможно, но можно уменьшить, и пути на мой взгляд всего два — снижать количество ошибок, и увеличивать скорость их устранения. Чем больше автоматизируется разработка, тем конечно меньше ошибок просачивается в эксплуатацию, и тем больше возможностей появляется для анализа слабых звеньев. Но при некачественной постановке или несоответствии квалификации разработчиков сложности задач никакой DevOps не превратит плохой проект в хороший, он только может поспособствовать превратить хороший проект в еще чуть более хороший.

          Only users with full accounts can post comments. Log in, please.