Сегодня разработка программного обеспечения по большей части выполняется командами, обращающимися к одному или нескольким репозитариям кода, которые управляются системами контроля версий. Индивидуальные разработчики выбирают области кода, которые требуют изменений, и должны решить, как отразить эти изменения в системе контроля версий.

Иногда изменения в коде достаточно просты и не несут серьезных рисков. В этом случае разработчик вносит правки с минимальным риском вмешательства в работу товарищей, имеющих дело с той же самой базой кода.

Но что, если команда занимается реализацией более серьезной функции, на разработку которой уходит несколько дней, недель или даже месяцев? Когда внесенные в код изменения целесообразно отражать в системе контроля версий? И как при регистрации этих изменений добиться того, чтобы код, созданный командой разработчиков, интегрировался без ошибок сборки и других функциональных дефектов?

Для чего нужна непрерывная интеграция?

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

Однако интуиция подсказывает, что такой способ разработки не является оптимальным. Каждая функциональная ветвь в процессе разработки отклоняется от основной линии. И если такие функциональные ветви используются в течение достаточно продолжительного времени, процесс интеграции становится затруднен, на разрешение конфликтов уходит слишком много времени, а ошибок возникает все больше.

Крупные команды, испытывающие постоянную потребность в разработке и развертывании, быстро придумали новый подход, при котором изменения вносятся часто, а проверка сборки и функциональности выполняется с помощью средств автоматизации. Такой подход получил название непрерывная интеграция (continuous integration, CI).

Определение непрерывной интеграции

Непрерывная интеграция – это философия написания кода и связанный с этим набор правил, регламентирующих внесение небольших изменений и частую проверку кода в репозитариях с системами контроля версий.

Поскольку большинство современных приложений требуют разработки кода на различных платформах и с помощью различных инструментальных средств, команде нужны технологии, позволяющие интегрировать и проверять эти изменения. Техническая цель непрерывной интеграции заключается в создании согласованного и автоматизированного способа сборки, объединения и тестирования приложений. При согласованном процессе интеграции команды чаще фиксируют изменения, что приводит к улучшению взаимодействия и повышению качества программного обеспечения.

Как непрерывная интеграция работает на практике

Непрерывная интеграция – философия и методология разработки, опирающаяся на процессы и автоматизацию сборки программного обеспечения. Придерживаясь CI, разработчики часто фиксируют изменения кода в системе контроля версий, причем у большинства команд процедура фиксации выполняется не реже одного раза в день.

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

В процессе внедрения непрерывной интеграции команды зачастую начинают с настройки конфигурации и определения правил управления версиями. Несмотря на частые проверки кода реализация новых функций и внесение изменений могут занимать как короткие, так и длительные промежутки времени. Команды разработчиков, практикующие непрерывную интеграцию, используют различные технологии проверки готовности функционала и кода к выпуску.

Команды, придерживающиеся CI, предпочитают фиксировать код в единственной ветви или стволе разработки. При использовании нескольких ветвей продолжительность их существования стараются минимизировать, объединяя одну ветвь с другой.

Существуют технологии управления функциями, которые требуют более длительной разработки, но при этом по-прежнему интегрируются в ветви. Некоторые команды используют функциональные флаги – свойство конфигурации, позволяющее включать и отключать нужные функции и код прямо в процессе исполнения программы. Функциям, находящимся в процессе разработки, ставятся в соответствие функциональные флаги, они вставляются в основную ветвь и отключаются до момента готовности.

Процесс сборки автоматизируется путем упаковки всего программного обеспечения, базы данных и других компонентов. Например, если вы разрабатываете приложение Java, средства CI упакуют все статические файлы веб-сервера (HTML, CSS и JavaScript) вместе с приложением Java и скриптами базы данных.

Большинство инструментов CI позволяет разработчикам создавать сборки по требованию, программно фиксируя код в репозитарии контроля версий или выполняя соответствующие операции по заранее заданному расписанию. Командам необходимо обсудить расписание сборки, которое наилучшим образом подходит бы для группы заданной численности, количество фиксаций в течение дня и другие вопросы проектирования приложения. Рекомендуется убедиться, что фиксации и сборки выполняются быстро, в противном случае они могут препятствовать прогрессу команд, пытающихся писать код быстро и фиксировать его часто.

Рабочие процессы здесь называются конвейером CI.

Разработка и тестирование с использованием непрерывной интеграции

При внедрении конвейера CI у разработчиков формируется новый технологический процесс. Они вносят правки в код в редакторе, интегрированной среде разработки или в своей собственной, «локальной» среде. В идеале в локальной среде должна присутствовать исполняемая среда, позволяющая запускать основные функциональные тесты. Затем выполняются автоматизированные модульные тесты, которые также легко запускаются в указанных средах.

После успешного прохождения основных тестов выполняется фиксация кода. Платформа CI (например, Jenkins или Travis) запускает сборку, в которой все элементы кода помещаются в один или несколько строительных блоков. Затем процедура CI проводит анализ статического кода и сообщает разработчикам об обнаруженных в сборке ошибках.

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

После того, как программное обеспечение упаковано, инструменты CI могут помочь вам перенести сборку программного обеспечения в среду его поставки, активизировать необходимые сервисы (например, перезапустить серверы приложений) и выполнить любые автоматизированные тесты. Эти шаги обычно называют непрерывной поставкой (continuous delivery, CD), а функции тестирования, встроенные в конвейер непрерывных интеграции и поставки (CI/CD), становятся компонентами непрерывного тестирования.

Команды, использующие в своей деятельности CI/CD, способны быстрее предлагать пользователям новые функции и расширения. Средства автоматизации и технологические процессы позволяют сократить объемы написания кода и уменьшить число функциональных дефектов. Технологические процессы такого рода укрепляют взаимодействие в команде и помогают создавать интеллектуальные, еще более инновационные решения. И все это начинается с непрерывной интеграции.

Правда ли, что agile и проекты в госорганизациях – «вещи несовместные»? Доклады сессии «Опыт» практической конференции «Agile.DevOps.ITSM 2018», проведенной издательством «Открытые системы», демонстрировали, что это не так.

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

Полноценному проникновению гибких подходов в госпроекты мешает множество объективных условий, некоторые из них перечислил Добриднюк. Это необходимость долгой экспертизы и согласований любого изменения («в итоге, когда все сделано, реализовывать проект, возможно, придется другому поколению чиновников»), строгие правила финансирования (их нарушение исключено), фискированные рамки проекта, недостаток высококвалифицированных кадров, избыточная отчетность.

Тем не менее в реальной практике элементы agile, необходимые для успешного и оперативного завершения проекта, удается интегрировать с этими, казалось бы, «железобетонными» принципами госИТ. Добриднюк поделился некоторыми рецептами на примере запуска в июле этого года «Перспективной платежной системы России», инициированного Банком России, реализованного государственным «МСП банком» в партнерстве с компанией «Диасофт» и задействовавшего все банки страны.

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

Сергей Добриднюк рассказал, что мешает проникновению гибких подходов в госпроекты и как их тем не менее можно там использовать

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

С платформой постоянно работают около 700 пользователей, в ней функционируют десятки взаимосвязанных процессов, что необходимо учитывать при проведении изменений («меняя одну функцию, нельзя сломать множество других»). При этом технологическое окно для вывода изменения в продуктив – несколько ночных часов, в рабочее время никакие простои не допустимы.

До недавнего времени удавалось выполнять три-четыре запроса на изменения в месяц, скопилась солидная очередь нереализованных изменений. Для того чтобы увеличить скорость выполнения запросов, работы были распараллелены. Но возникла проблема – как в этих параллельных потоках разработки организовать тестирование, чтобы в очередной итоговый релиз попадали только работоспособные функции. Решение оказалось на первый взгляд очевидным, но, как рассказал Потоцкий, оно потребовало серьезной трансформации не только процессов, но и культуры работы команд.

Теперь в параллель выполняется только рабочее тестирование, и за него отвечают команды разработки, а приемочное реализуется для релиза в целом и выполняется с минимальными затратами, поскольку в итоговый релиз попадают отфильтрованные рабочим тестированием, полностью готовые функции (а не компонуются технологически близкие, как это делалось раньше). В итоге скорость выполнения запросов на изменения выросла до 20-30 в месяц, очередь запросов сократилась почти на половину.

«Это было не упражнением по изменению технологий тестирования, но трансформацией подхода к работе, синтезировавшей несколько методологий управления. Из принципов Lean была взята нацеленность на результат – ускорение обработки запросов – и отсечение всего лишнего, что достижению этого результата мешает. Из ITSM – организация процессов, из Agile – коллективные методы работы. И очень важна корпоративная культура – проведение этих идей в жизнь стало плодом совместной работы команды, а не бездумным исполнением воли руководителя», – рассказал Потоцкий.

В ИТ-индустрии модные словечки быстро сменяют друг друга, и термин DevOps рассматривается многими в качестве очередного кандидата на эту роль.

Вместе с тем концепция DevOps известна уже достаточное время, а стремительный рост ее популярности начался еще в 2016 году.

Многие полагают, что DevOps – уже нечто большее, чем просто модное словечко, вобравшее в себя передовой опыт ведения бизнес-операций.

Вобрав в себя термины «development» (разработка) и «operations» (эксплуатация), DevOps представляет собой симбиоз двух сфер деятельности ИТ-персонала, которые традиционно рассматривались в изоляции друг от друга.

DevOps объединяет их для обеспечения стабильности изменений и оптимизации процесса поставки программного обеспечения.

DevOps оказывает влияние на взаимодействие, автоматизацию и рабочую культуру, объединяя рабочие процессы и группы исполнителей.

Чтобы внедрить культуру DevOps в организации, нужно быть готовым к радикальным переменам и полной самоотдаче.

Только после этого можно ощутить преимущества быстрого и автоматизированного подхода к организации ИТ и бизнес-операций, учитывающего существующие взаимосвязи.

Приведем ряд рекомендаций, которые упростят внедрение культуры DevOps.

Внедрение DevOps – очень масштабная инициатива, и вам придется обосновать свое решение перед генеральным директором и советом директоров.

Необходимо собрать доказательства, подкрепляющие ваше предложение, и продемонстрировать потенциальные преимущества, которые принесет культура DevOps.

Нужно разработать стратегию уменьшения рисков и максимизации выгод от внедрения.

Наилучшей стратегией здесь будет принятие ориентированного на пользователя подхода, которые согласуется с общими бизнес-целями.

В конечном итоге ценность технологии определяется теми преимуществами, которые она приносит клиенту.

Если в вашей организации ощущается сопротивление переменам, имеет смысл придерживаться подхода «сделай сам» и попытаться применить концепцию DevOps к какому-то небольшому конкретному проекту. Возможно, результаты его начнут говорить сами за себя, и убедить руководство вам будет гораздо проще.

Переосмысление процессов

В ходе эксплуатации и разработки формируются глубоко укоренившиеся системы и цели. Объединение внутри организации усилий специалистов в различных областях помогает выстраивать жизнеспособную стратегию внесения изменений, которые в противном случае могут выглядеть пугающе.

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

Интеграция, интеграция, интеграция!

Объединение усилий подразделений, занимающихся разработкой и эксплуатацией, – сложная задача, для успешного решения которой нужны открытые коммуникации и прозрачность.

Формирование у команд общих целей поможет преодолеть разобщенность и ощутить дух взаимодействия, имеющий фундаментальное значение для менталитета DevOps.

Непрерывная интеграция и доставка программных систем (Continuous Integration and Continuous Delivery, CI/CD) являются основными составляющими стратегии DevOps. Развертывание и интеграция нового программного обеспечения в бизнес-подразделениях происходят непрерывно. Благодаря CI/CD разработчики получают возможность объединять рабочие задания и продукты в одном репозитории.

Главное преимущество заключается в том, что благодаря совместным усилиям развертывание программного обеспечения происходит быстрее, вопросы решаются оперативнее, а ошибки выявить проще.

Внедрение программного обеспечения для автоматизации поможет персоналу сосредоточиться на более важных составляющих разработки, тестирования и поддержания надлежащего качества, тратя при этом меньше времени на выполнение более трудоемких задач.

Обратная связь на каждом этапе

Рассматривая DevOps главным образом в качестве культурного сдвига, а не чего-то еще, важно устанавливать на каждом из этапов обратную связь.

Это поможет определить все слабые места и области, которым потребуется более серьезная поддержка, чем ожидалось.

Использование при внедрении DevOps взвешенного подхода предполагает, что все рабочие процессы, от проектирования и тестирования до выпуска готового продукта, будут своевременно проконтролированы и завершены.

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

Обмен информацией будет способствовать повышению эффективности реализации проекта в целом.

Подход «быстрых неудач»

В ходе внедрения DevOps перед тем, кто встал на этот путь, неизбежно будут вставать различные вопросы, требующие решения. В конце концов, в организации происходят масштабные культурные изменения и смена стратегии.

Принимая концепцию «быстрых неудач», можно извлечь из них максимум пользы, учась на собственных ошибках.

Лучше совершить ошибку на раннем этапе, с тем чтобы не повторять ее в будущем.

Выравнивание иерархии

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

Впрочем, одними лишь регламентированными процедурами дело тут не ограничивается. Нужно поощрять развитие культуры общения, устраивать открытые встречи, на которых люди смогут обсуждать насущные вопросы и высказывать свои идеи.

Необходимо устранять любые физические барьеры, мешающие взаимодействию. Это подразумевает организацию открытого офисного пространства с перестановкой столов.

Инвестиции в ChatOps

Многие предприятия территориально распределены, поэтому целесообразно инвестировать в сервис мгновенного обмена сообщениями.

Более того, внедрение подобного инструментария означает, что вы сможете в любую секунду связаться с нужным человеком и оперативно начать работу над любым вопросом, который вас волнует. Это особенно ценно в ситуациях, не терпящих отлагательств.

Культура DevOps предполагает объединение двух дисциплин и нескольких команд, а надежная система взаимодействия значительно улучшит выполнение операций и будет способствовать формированию атмосферы товарищества в коллективе.

Корпорация Microsoft представила платформу Azure Devops, которая включает в себя набор облачных сервисов для непрерывной интеграции и доставки (Continuous Integration/Continuous Delivery, CI/CD), тестирования и проектных канбан-досок. Платформа бесплатно предлагается для проектов с открытым кодом и для команд разработчиков, в состав которых входит не больше пяти человек. Для более крупных команд цена с учетом скидок составит от 3 долл. в месяц на каждого пользователя.

С помощью дополнительных сервисов Azure Devops позволяет работать с любым языком и любой платформой.

В состав Azure Devops включены следующие сервисы:

• Azure Pipelines предлагает CI/CD с возможностью работы со множеством языков и подключением к GitHub. Программный код можно извлекать из популярных систем с открытым кодом. Поддерживаются агенты сборки для MacOS, Linux и Windows. Интеграция с Visual Studio App Center позволяет осуществлять мобильную доставку. Артефакты можно извлечь из других систем CI, например, из Jenkins.
• Azure Boards предназначен для отслеживания работ с канбан-досками, незавершенными заданиями, коллективными инструментальными панелями и клиентскими отчетами. Работы могут отслеживаться в пределах отдельных команд.
• Azure Artifacts позволяет создавать и совместно использовать каналы пакетов Maven, NPM и NuGet из общедоступных и закрытых источников.
• Azure Repos с неограниченным облачным частным репозитарием Git обеспечивает извлечение запросов, управление файлами и поиск кода в процессе совместной работы. При извлечении запросов можно оставлять комментарии.
• Azure Test Plans – набор инструментов для тестирования вручную и произвольного тестирования. Управление тестами можно осуществлять на различных платформах и в различных конфигурациях.

Поддерживаются конфигурации публичных и частных облаков. Разработчики, к примеру, могут использовать Azure Pipelines для построения и тестирования сервиса Node из репозитария GitHub и развертывания его в контейнере на Amazon Web Services.

Azure Devops приходит на смену Visual Studio Team Services (VSTS) – облачному спутнику платформы управления жизненным циклом приложений Team Foundation Server (TFS). Пользователи VSTS будут переведены на проекты Azure Devops автоматически, получив возможность сквозного отслеживания и интеграции.

Azure Devops предлагает обновленный пользовательский интерфейс, поддержку языка проектирования Fluent и улучшения навигации. Пользователи увидят происходящие изменения: URL-адрес abc.visualstudio.com, например, изменится на dev.azure.com/abc.

Пользователи системы TFS, развернутой на их собственной территории, будут получать обновления с учетом функционала Azure Devops. Название продукта изменится на Azure Devops Server.

Многие организации обращаются к DevOps без учета рисков и последствий для бизнеса, в условиях, когда персонал не вооружен необходимыми для этого средствами и подходами.

«Они обращаются к концепции DevOps ради самой DevOps», – утверждают в своем новом отчете исследователи Gartner Джордж Спаффорд, Кристофер Литл и Скотт Эткин. И это лишь одна из пяти ошибок, о которых говорится в отчете.

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

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

«Несмотря на то, что эта проблема неоднократно, на протяжении многих лет поднималась в исследованиях Gartner, некоторые клиенты продолжают игнорировать важность организационных изменений и сосредотачивают усилия на инструментах DevOps, – отмечается в отчете. – В долгосрочной перспективе такой подход не принесет желаемого результата. С помощью инструментов нельзя решить культурные вопросы».

Руководство должно осознать, что требуемые для DevOps организационные изменения не могут считаться необязательными. Сотрудникам необходимо понять, что эти изменения происходят как с их участием, так и без него. Тем не менее, указание «сделать это так или иначе» получают далеко не все. Люди должны понимать, почему изменения необходимы, а руководству следует принять все возможные меры, чтобы помочь людям.

Третья причина заключается в слабом взаимодействии. Многие усилия DevOps ограничены единственной областью (чаще всего, рамками ИТ-подразделения) и не направлены на вовлечение других групп и заинтересованных лиц.

DevOps требует, чтобы люди придумывали решения, разрушали барьеры и функционировали как единая команда, подобно тому, как это происходит в военной сфере и профессиональном спорте. Улучшение системы требует вовлечения и четкого понимания общих перспектив. Разобщенность и отсутствие координации здесь неприемлемы.

Четвертая причина неудач заключается в стремлении внедрить DevOps за один шаг, однако история показывает, что такому подходу редко сопутствует успех.

По мнению исследователей, у DevOps слишком много параметров, чтобы подобный подход увенчался успехом в крупной ИТ-организации. В ИТ-подразделениях, где работает свыше ста человек, в этом случае возникает масса различных осложнений.

И наконец, последняя причина связана с отсутствием управления ожиданиями, которыми сопровождаются инициативы DevOps.

Вместо того, чтобы утверждать, что мы станем гибче и быстрее, оцените реальное положение дел в организации и продвигайтесь к цели постепенно. DevOps – это не решающий рывок, а непрерывное итерационное улучшение.

В конце мая издательство «Открытые системы» провело очередной, уже пятнадцатый, форум IT Management Forum. В юбилейном мероприятии приняли участие более 400 представителей предприятий и организаций из разных отраслей.

Если центральной темой ITMF 2017 была роль ИТ-департамента в реализации стратегии цифровой трансформации, то девизом ITMF 2018 стало «Стратегия и практика управления ИТ. В ответе за цифровое предприятие», что подразумевает существование такого предприятия как реальной сущности.

Теория не всегда суха

ITIL, cвод лучших из применяемых на практике способов организации работы сервисных ИТ-подразделений или компаний, не обновлялся довольно давно. Его последняя, третья версия вышла в 2011 году. Роман Журавлев, менеджер по развитию ITSM-портфеля компании AXELOS, владельца ITIL, заверил, что этой осенью ITIL ожидает обновление, дал общее представление о грядущих изменениях, а на круглом столе попробовал выяснить, чего от новой версии ITIL ждут российские пользователи.

Доклад, посвященный теории и практике применения DevOps, прочитал Марк Смолли, всемирный посол ASL BiSL Foundation и DevOps Agile Skills Association. Он предложил «убить DevOps» — правда не любые инициативы такого рода, а «DevOps ради DevOps», не взаимодействующий с бизнесом. Эту тему он развил в ходе мастер-класса, посвященного тому, как наладить эффективное взаимодействие бизнеса и ИТ.

Еще один мастер-класс по «оживлению» теории дал Олег Скрынник, управляющий партнер компании Cleverics, который провел несколько временных проектных команд через все стадии применения методологии канбан для простого процесса. Постичь за 45 минут все премудрости японского «пути бережливого производства», конечно, невозможно, но общие представление участники и зрители получили.

В ходе даже короткого практического занятия можно получить знаний больше, чем от длинной лекции. Марк Смолли показывает участникам мастер-класса DevOps на практике

Инструментарий цифрового преображения

Для того чтобы следовать лучшим практикам, описанным в ITIL, ИТ-отделам необходим адекватный инструментарий. На ITMF 2018 свои разработки продемонстрировали ряд зарубежных и отечественных вендоров.

Илья Масленкин, генеральный директор Axios Systems в России и СНГ, представил возможности Axios Assyst, решения, позволяющего управлять ИТ-активами и сопутствующими бизнес-процессами на протяжении всего их жизненного цикла, от приобретения до списания. Возможности продукта он подтвердил списком клиентов, в котором немало громких имен, в том числе таких разных по бизнес-процессам и активам организаций, как полиция Дубаи и российская сеть магазинов «М.Видео».

У компании Naumen есть ITSM-решения как для малого и среднего, так и для корпоративного бизнеса. Однако рост сложности задач, встающих в ходе создания цифрового предприятия, подвигнул компанию к использованию в своих продуктах искусственного интеллекта.

У Softline «своего» ITSM-решения нет, необходимые инструменты она может получить от своих партнеров-вендоров, которых более 3 тыс. Зато у компании сфомирована оригинальная концепция Enterprise Service Management, которую представил Яков Рутман, руководитель направления продажи и развития решений ITSM.

Классическая роль ITSM – управление ИТ с целью обслуживания нужд бизнес-подразделений. Однако, поскольку «обязанности» информационных технологий на цифровом предприятии выходят за рамки услуг,  на ИТ возлагается создание и вывод на рынок новых товаров и услуг, управление рисками, создание новых возможностей для бизнеса. Соответственно Enterprise Service Management — применение принципов ITSM к управлению всеми сервисными подразделениями предприятия, не только связанными с информационными технологиями.

Олег Скрынник показывает участникам мастер-класса практическую реализацию метода «канбан»

Критерий сервиса — практика

Традиционно на форуме ITMF слово предоставляется не столько теоретикам и производителям, сколько представителям компаний, внедривших сервисный подход самостоятельно или с помощью сторонних специалистов. На ITMF 2018, как и на предыдущих мероприятиях, был представлен ряд проектов самого разного уровня и значимости.

Андрей Заварзин, директор дивизиона «Массовая персонализация» Сбербанка, рассказал, что из трех десятков лет «в ИТ» большую часть времени он стремился перейти на позицию бизнес-руководителя. Пока не попал на нынешнюю должность в Сбербанке, где средствами ИТ стал решать бизнес-задачи. Управление проблемами и инцидентами, почерпнутые из ITIL, а также средства быстрой разработки позволили ИТ-службе резко снизить количество ошибок в деятельности подразделения, причем связанных не только с технологиями, но и с бизнес-процессами и человеческим фактором.

В компании «Мечел», в которую входят более двух десятков производственных предприятий, сервисный подход был применен к созданию системы мониторинга инфраструктуры. В отсутствие средств мониторинга ИТ-службы узнавали о неполадках в подведомственной инфраструктуре «по факту». После того, как из-за отключения кондиционера перегрелись сервера, отвечавшие за большую группу сервисов, в компании начали проект внедрения платформы мониторинга компании Paessler. Среди ее преимуществ Андрей Кисляков, заместитель директора департамента ИТ-инфраструктуры «Мечел-БизнесСервис», назвал наличие бесплатной версии (до ста датчиков), простоту установки, возможность добавления датчиков без программирования, создания сложных датчиков — комплексных, из нескольких устройств или запрограммирорванных при помощи скриптов. Сейчас в системах «Мечела» работают 2,3 тыс. датчиков в Москве и около 1 тыс. — в регионах.

Евгений Карасик, менеджер по продукту Mobile Center из Центра разработок ADM Micro Focus, поделился опытом внедрения Micro Focus DevOps Suite. Этот процесс потребовал изменений бизнес-процессов, структурных преобразований и изменения зон ответственности, однако теперь разработчики способны выдавать новые версии ПО по запросу бизнес-заказчиков с минимальным (3-5%, ранее — до 30%) увеличением объема кода, 80% тестирования выполняется автоматически и качество продукта от итерации к итерации растет.

Обычно компании, рассказывающие о проектах в области ITSM, предстают едва ли не образцами бесконечного успеха и непрерывного благополучия. В страховой компании «Югория» решение Omnitracker немецкой компании Omninet и Agile-подход к совершенствованию продуктов и процессов внедрили в ситуации более чем тревожной: 2012 год «Югория» закончила с убытком в 2,1 млрд руб., 2013-й — около 1 млрд. Но нет худа без добра — по словам Виталия Шишаева, руководителя отдела внедрения и сопровождения сервисов «Югории», подробно обосновывать топ-менеджменту востребованность преобразований необходимости не было. Несколько лет напряженной работы дали результат — более 650 млн руб. прибыли в 2017 году.

Награда за сервис

Завершился форум церемонией награждения премией ITMF Award, учрежденной издательством «Открытые системы». За выдающиеся заслуги в деле продвижения передовых методик и лучшего опыта управления ИТ были отмечены члены экспертного сообщества, практики, разработчики программных средств. В этом году лауреатов выбирали представители «Открытых систем» и организаторы ITMF 2018, в дальнейшем премию планируется сделать ежегодной и выбирать лауреатов на конкурсной основе.

Лауреатами премии ITMF Award 2018 стали:

• Марина Аншина, председатель правления Союза директоров ИТ России, президент Фонда поддержки стандартизации, системного моделирования и управления проектами, в номинации «Бессменному лидеру движения за профессиональное становление ИТ-менеджмента в России»;
• Максим Григорьев, куратор факультета цифровой трансформации Московской школы продвинутых коммуникаций MACS, в номинации «Многолетнему эффективному лидеру профессионального ITSM-сообщества»;
• Михаэль Добнер, генеральный директор Omninet в России и СНГ, в номинации «Активному проводнику лучшего международного опыта управления ИТ в российское профессиональное сообщество»;
• Роман Журавлев, менеджер по развитию ITSM-портфеля компании AXELOS, в номинации «Бескомпромиссному пропагандисту лучших практик управления ИТ-сервисами»;
• Михаил Потоцкий, начальник управления ГБУ г. Москвы «Информационный город», в номинации «Пионеру и патриарху российского рынка ITSM»;
• Олег Скрынник, управляющий партнер компании Cleverics, в номинации «Неутомимому просветителю российского сообщества ИТ-менеджеров»;
• Максим Тищенко, независимый эксперт, в недавнем прошлом — CIO Банка России, в номинации «Лидеру продвижения передового опыта управления ИТ в российской финансовой отрасли»;
• Роберт Фариш, руководитель IDC в России, в номинации «Честному «зеркалу» отечественного рынка управления ИТ»;
• Кирилл Федулов, сооснователь и директор по развитию компании «Облачные решения», в номинации «Главному энтузиасту продвижения отечественных ITSM-платформ»;
• Илья Хает, член наблюдательного совета itSMF России, директор по развитию бизнеса «Витте-Консалтинг», в номинации «Лучшему пропагандисту теории и практики управления ИТ-сервисами».

Лауреаты первой премии ITMF Award имеют огромные заслуги в деле продвижения ITSM в России

Еще в 2014 году инвестуионная компания Thoma Bravo в рамках 2,5-миллиардной сделки вернула разработчика программного обеспечения Compuware, завоевавшего свою славу еще во времена мейнфреймов, с биржи в частное владение.

На должность генерального директора Compuware был приглашен Кристофер О'Малли, решивший осуществить ускоренный переход от «водопадной» модели к DevOps и Agile-разработке, охватив при этом практически все аспекты бизнеса, начиная от организации групп разработки и эксплуатации и заканчивая маркетинговыми и финансовыми подразделениями, а также бухучетом.

За четыре года Compuware не прибегала к массовым увольнениям, нарушив тем самым тенденцию, сложившуюся в процессе крупных поглощений частными инвестиционными фондами.

«Мы, если хотите, переживаем сейчас второе рождение, – заявил вице-президент компании по продуктам Дэвид Риццо. – В Compuware стремятся предлагать инновационные решения для мэйнфреймов, а это требует перехода от нашей традиционной водопадной модели к DevOps и гибким методикам организации бизнес-процессов».

Кристофер О'Малли решил осуществить ускоренный переход к DevOps, охватив при этом практически все аспекты бизнеса

Вновь получив частный статус, компания начала с определения своей новоей миссии, которая предусматривает наряду с поддержание партнерских отношений с пользователями мэйнфреймов на протяжении последующих 50 лет с предложением новых продуктов или функций каждые три месяца.

«У нас был очень опытный персонал и укоренившиеся процессы, но нам требовалась трансформация, позволяющая энергично продвигаться вперед, – подчеркнул Риццо. – И мы осознанно приступили к этому, прекрасно понимая, что столкнемся с проблемами, поскольку масштабные изменения всегда влекут за собой определенные сложности».

Персонал, по сути, остался тем же, что и прежде, если не считать нескольких вышедших на пенсию сотрудников, на смену которым пришли выпускники вузов. И за прошедшие четыре года компании удалось заметно вырасти.

«Наша цель заключалась в том, что сохранить специалистов и предоставить им возможность работать новым, иным способом, используя преимущества гибкой разработки и DevOps, – пояснил Риццо. – Конечно, главные трудности связаны с людьми – мы должны содействовать их развитию, предоставлять официальное обучение, приглашать преподавателей, давать инструменты, которые им нужны для успеха. На начальном этапе удовлетворению необходимых потребностей уделялось особое внимание. Мы хотели убедиться в том, что у нас формируется правильная культура, правильная среда и есть правильные инструменты. Реформы коснулись не только процесса разработки продуктов. Они затронули всю организацию, через это должен был пройти каждый – продукты требовали кооперации с юридическим отделом, с финансовым отделом, с договорами, продажами, словом, со всеми нашими сотрудниками».

Помимо всего прочего требовалось определить конкретные сроки, и в результате было принято решение о том, что с ноября 2014 года вся компания переходит на DevOps. «Нам понравилась идея сжечь за собой мосты и просто двигаться вперед, – вспоминал Риццо. – Теперь, по прошествии времени, мы видим, что добились значительных успехов, поскольку выбрали правильный путь».

Новое руководство поощряло чтение сотрудниками романа «Проект 'Феникс'» (бестселлер Джина Кима, Кевина Бера и Джорджа Спаффорда «Проект 'Феникс'. Роман о том, как DevOps меняет бизнес к лучшему». — Прим. ред.) и его коллективное обсуждение, в котором принимали участие представители разных подразделений. Таким образом, представители кадровой службы, финансового отдела и разработчики активно общались друг с другом. Они видели, как все это отражается на их повседневной жизни и деятельности их групп, а не только на разработке. Таким образом, процесс перехода получил полную поддержку и понимание.

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

Инструменты управления исходным кодом программного обеспечения использовались в Compuware на протяжении уже 20 лет и безнадежно устарели. Разработчики решили самостоятельно опробовать ряд инструментов, которые могли бы помочь им решать стоящие перед ними задачи более эффективно – в том числе управлять одновременно множеством строк кода и расширений.

В итоге выбор инструментария привел к тому, что Compuware купила разработавшего его компанию, и теперь система ISPW развивается под крылом Compuware.

Аналогичным образом, когда разработчики анализировали незнакомый им код, один из них выдвинул идею создания нового инструмента графической визуализации, который бы четко иллюстрировал приложение, а также все файлы и данные, которые оно затрагивает. Совместными усилиями разработчикам удалось подготовить минимально жизнеспособный продукт за 84 дня.

«И вот тогда мы впервые оглянулись назад и признали, что это действительно работает, – отметил Риццо. – Новая методология раскрыла наши творческие и инновационные способности, позволив нам действовать быстрее, чем раньше, особенно в сфере, традиционной для мира мейнфреймов».

Традиционные ключевые показатели эффективности оценивают число дефектов, о которых сообщают клиенты, и начиная с 2014 года количество этих дефектов в Compuware неуклонно снижается. Кроме того, компании удалось успешно вписаться в новый 90-дневный цикл разработки продуктов, на который она и ориентировалась, приступая к трансформации.

Обеспечение эффективного взаимодействия подразделений разработки и эксплуатации информационных систем – одна из наиболее актуальных проблем предприятий, вступивших на путь цифровой трансформации. От всех подразделений сегодня требуются высокие темпы реагирования на изменения; недопустима ситуация, когда одни оперативно создают новые и модернизуют существующие приложения, а другие их саботируют, оберегая стабильность инфраструктуры. Облака, большие данные и машинное обучение способны предоставить бизнесу конкурентные преимущества за счет своевременного вывода на рынок востребованных сервисов, однако полная реализация их потенциала зависит от того, насколько эффективно применяются инструменты поддержки разработки и оперативного изменения сервисов и приложений для создания новых бизнес-моделей — иначе говоря, от уровня развития культуры DevOps в организации. Об особенностях освоения DevOps в Центре разработки ADM Micro Focus в Израиле рассказал в ходе форума ITMF 2018 Евгений Карасик, руководитель проектов, технический директор по направлениям Mobile/Cloud/DevOps.

- Что собой представляет лаборатория Mobile Center?

В 2015 году для разработки инструментов тестирования и мониторинга мобильных приложений в городке Иехуд, недалеко от Тель-Авива, была создана лаборатория HPE Mobile Center на базе образованной еще в 1996 году исследовательской лаборатории компании Mercury Interactive. Сегодня центр, структурное подразделение компании Micro Focus, занимается созданием продуктов для тестирования и мониторинга любых мобильных приложений и устройств в произвольных рабочих средах, охватывающих практически все платформы и типы устройств. Мы работаем на корпоративных клиентов во всех сферах бизнеса, в основном в финансах, но не ограничиваемся только ими: в конечном счете, наша задача состоит в удовлетворении потребностей заказчиков, благодаря регулярной и ранней поставке ценного для их бизнеса программного обеспечения, что возможно сегодня благодаря DevOps.

- Что изменилось с момента образования лаборатории?

Развитие мобильных технологий идет полным ходом, добавились, скажем, такие интересные вещи, как Progressive Web Apps. Однако некоторые новшества себя пока не проявили в полном объеме. Например, большие надежды возлагались на Интернет вещей; предполагалось, что к сегодняшнему дню предприятиями будут востребованы соответствующие инструменты, но этого не случилось – ни у одного из наших заказчиков нет долгосрочной стратегии работы в Интернете вещей. Конечно, сама индустрия развивается, например, «подключенные автомобили» (connected cars), но на корпоративном уровне кардинальных сдвигов не произошло. Так, не оправдали ожиданий «умные» часы, включая Apple Watch, хотя предполагалась, что для них будет создано множество приложений. С другой стороны, весьма востребовано оказалось все, что связано с аналитикой, особенно прогнозной, – есть конкретные запросы на реализацию ее функций на уровне корпоративных приложений.

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

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

- Что означает ваш тезис, прозвучавший в выступлении на форуме: «Всё находится в системе контроля кода»?

Обязательное вовлечение заказчиков, пользователей и разработчиков в процесс создания продукта. Речь, конечно, не идет о том, чтобы заставить бизнес-менеджеров тестировать код — прежде всего требуется в каком-либо виде определить потребности бизнеса, которые со временем могут изменяться и донести эти изменения до разработчиков. Этот процесс эволюционен: запросы, итерации, причем данные постоянно доступны всем и всегда, а не только на совещаниях. На выходе получается либо демосессия, либо интерфейс для самостоятельной проверки приложений бизнесом с целью получения обратной связи для формирования гипотез по дальнейшему развитию продукта. Такая организация может привести к тому, что требуются изменения структуры и нашей компании.

- Какие имеются проблемы при переходе на DevOps?

Основные проблемы не столько технические, сколько организационные — исторически имелась «стена», отделяющая подразделения разработки от служб эксплуатации, сотрудники которых до сегодняшнего дня решали разные, с точки зрения бизнеса, задачи. DevOps позволяет наладить коммуникации, но главное – всем надо понять требования бизнеса, а не пытаться внедрять DevOps ради него самого, тем более, что в его основе лежит здравый смысл, а не некое откровение. Часто структура компании просто не позволяет наладить оперативное взаимодействие – нет горизонтальных связей и для того, чтобы «дотянуться» до коллеги за соседним столом, требуется прежде объясняться с его руководителем. Без структурных преобразований компании, предусматривающих работу по DevOps всех ее подразделений, успех от Agile вряд ли будет возможен.

Как следует из практики, наиболее жизнеспособны виртуальные группы на спринты, включающие представителей всех дисциплин: кодировщики, тестировщики, и пр. У каждого микросервиса имеется свой хозяин, а все участники группы в курсе работы соседа, а потому при необходимости могут его подменить в определенных пределах. Архитектура микросервисов позволяет сконцентрироваться вокруг потребностей бизнеса, динамично отображая его запросы. Кроме того, появляется возможность разрабатывать и развертывать решение независимо и параллельно без привлечения большой группы разработчиков. Упрощается также интеграция и развертка продукта, нет технологической зависимости, но главное даже не это, а наличие зоны совместной ответственности – на всех участниках группы лежит коллективная ответственность за динамичный выпуск качественного, ценного для бизнеса продукта.

Кстати, стоит обратить внимание на то, что термин Agile означает не «быстрый», а «динамичный», «гибкий», и ошибочно думать, что внедрение DevOps сразу ускорит производство и получение ценного продукта. DevOps как культура, способствующая постоянным изменениям потребностей и усилению обратной связи, означает формирование cистемного мышления, призывающего акцентироваться на ценности всей системы, а не ее отдельных элементов.

- Как на ранних этапах проекта определить ценность ПО?

Бизнес-заказчики не задумываются о ценности ПО, а только выдают нам свои проблемы, а мы их конвертируем в приложения, разбиваем решение на этапы, продукты, а потом корректируем. Здесь очень помогают SaaS-решения, позволяющее при взаимодействии с клиентами получить обратную связь. Мы два года выстраивали Agile-цепочку формирования ценности программного продукта, руководствуясь, в частности, принципом MVP (minimum viable product — «минимально жизнеспособный продукт»), согласно которому результатом первых спринтов становится продукт, обладающий минимальным, но уже достаточным для удовлетворения исходных запросов бизнеса функционалом. Не следует сразу пытаться в одном продукте решать все проблемы всех клиентов, но нужно культивировать специалистов, способных сформулировать те 20% требований заказчиков, которые способны отобразить 80% потребностей клиентов.

Ценность — величина не постоянная: если мы решили актуальную проблему заказчика, то отлично, если же нет, то мы в проигрыше и лучше бывает вообще ничего не делать, как это, например, происходит сейчас с Интернетом вещей, в условиях отсутствия у предприятий стратегий его применения.

- Гиганты интернет-индустрии, Facebook, Google и Amazon, способны ежедневно выпускать в промышленную среду по несколько версий продуктов при приемлемом качестве. Достаточно ли для этого инструментов, предлагаемых сегодня Micro Focus?

Да, вполне. Мы применяем сами и предлагаем своим заказчикам интегрированный набор продуктов, помогающий разрабатывать, управлять, тестировать, контролировать и улучшать программное обеспечение. Такие инструменты, как ALM Octane – управление жизненным циклом и потоками DevOps, в частности, автоматизированным тестированием; UFT/StormRunner Functional/LeanFT и другие модули из Application Delivery Management – функциональное тестирование веб и мобильных сред, позволяющие включить в процесс тестирования специалистов по бизнес-процессам; StormRunner Load – нагрузочное тестирование в облаке; AppPulse – мониторинг и адаптация пользовательских возможностей, помогают быстро выпускать качественный продукт. Однако, сегодня ни один заказчик не использует решения только от одного поставщика – как минимум, все они смотрят на открытые решения: Chef – оркестровка развертывания ПО; Jenkins – непрерывная интеграция; средства тестирования Appium и Selenium, которые мы также интегрируем в свои решения.

Вообще говоря, в Agile не рекомендуется жестко регламентировать перечень программных средств. Разработчикам должна быть предоставлена свобода выбора инструментария, но он должен быть аргументирован. Мы стремимся к тому, чтобы процесс формирования набора инструментов шел снизу, создавая надстройку над базовой инфраструктурой и дополнительными инструментами, применяемыми разработчиками по собственной инициативе. Например, Jenkins может эффективно, но по-разному использоваться, хотя его отдельные функции есть и в базовом фирменном пакете. Авторитаризм при выборе инструментов не будет соответствовать долгоиграющей стратегии развития компаний, поэтому технологический стек должен изменяться по мере необходимости. Мы называем это рефакторингом – переходом с одной технологии на другую.

- Переход на DevOps позволил вам достичь впечатляющих результатов...

Вместо выпуска новой версии продукта раз в год теперь мы выпускаем релизы по запросу бизнеса, а вместо увеличения объема кода от версии к версии на 30% рост сейчас составляет максимум 3-5%. Чем меньше изменений, тем ниже риски и меньше вероятность внесения ошибок. Раньше автоматическим тестированием было охвачено лишь 20% кода, а сейчас 80%. Следствием данных изменений стала не регрессия качества продукта, вызванная хотя бы тем, что через три года объем программ удваивался и разбухшим кодом было все сложнее управлять, а увеличение качества. Весь код мы стараемся разделить на «живой» и «мертвый», инвестируя в первый и отсекая второй. Но для этого надо понять, зачем он был включен и потребуется ли в будущем.

- Agile, DevOps называют инструментами цифровизации, а каким должно стать ИТ-подразделение цифрового предприятия?

Общая тенденция – движение в сторону архитекутуры serverless на основе облаков, когда все необходимые сервисы прозрачны, а необходимые для их поддержки ресурсы предоставляются по запросу. В цифровую эпоху ИТ-подразделения заменят боты, которые сами будут искать необходимые для поддержки бизнеса ресурсы. Как таковой должности CIO не будет, возможно, вырастет роль CDO (Chief Data Officer), но в любом случае бизнес-менеджеры должны будут в состоянии сформулировать требования в терминах ИТ, как сегодня вы платите за кубометры или киловатты – ресурсы, фактически поставляемые из «облака». Иначе говоря, не будет четкой границы между ИТ и бизнесом, а ИТ-подразделение как таковое станет неотъемлемой частью бизнеса, а не его отдельным подразделением.

Цифровая экономика усилила один из ключевых принципов экономики традиционной: необходимо как можно быстрее выводить на рынок новые продукты и услуги, причем их качество должно быть достаточно высоким. Методика DevOps помогает разработчикам за меньшее время создавать и передавать в эксплуатацию цифровые продукты и сервисы, добиваясь при этом необходимого уровня качества. Какова нынешняя ситуация с DevOps, в каком ракурсе ее следует рассматривать и чего можно ждать от этой методики, рассказывает Марк Смолли, консультант компании Smalley.IT в области управления ИТ, всемирный посол фонда ASL BiSL Foundation. Смолли выступил с ключевым докладом на юбилейном, пятнадцатом форуме ITMF 2018 для профессионалов в области управления ИТ, организованном издательством «Открытые системы».

- С чем связана нынешняя шумиха вокруг DevOps?

Эта методика зародилась в 2008-2009 годах в Бельгии: эксперты попытались применить гибкие (agile) методики разработки для управления операционной деятельностью по оказанию ИТ-услуг. DevOps можно рассматривать как продолжение гибкой разработки: она считается завершенной, когда код наконец написан и готов к развертыванию, но еще не развернут. Методика DevOps идет дальше: в ней много внимания уделяется тому, каким образом код может быть развернут, причем быстро и надежно, после чего передан в продуктивную эксплуатацию.

Большое значение в DevOps имеет автоматизация, но также очень существенную роль играет созидательная (generative) культура взаимодействия между заинтересованными сторонами. Нередко в организациях приходится сталкиваться с сильной бюрократией: подразделения представляют собой закрытые структуры, которым трудно взаимодействовать между собой, в них не развита культура передачи полномочий и пр. Встречаются и «патологические» организации с «токсичной» культурой, где увольнения сотрудников становятся обыденным делом.

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

- Так ли нова парадигма DevOps?

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

- Многие из тех, кто говорят о DevOps, часто имеют в виду разные идеи. Возможно ли унифицировать представление разных людей о DevOps? И нужно ли?

DevOps – это достаточно новая парадигма, и ее пока сложно определить однозначно. Вспомним Джеффри Мура: в жизненном цикле инновационного продукта есть стадия инициализации, есть ранние последователи, и есть мейнстрим. DevOps сегодня находится в стадии преодоления разрыва, и только начинается переход в стадию мейнстрима. Сейчас люди, которые приступают к работе по DevOps, говорят, что пока рано проводить стандартизацию. Но, с другой стороны, организациям необходимо сотрудничать, чтобы определить эту методику в деталях, ввести стандартизацию, сертификацию и пр. Найти баланс между этими подходами достаточно трудно. Впрочем, все согласны с тем, что есть обширное поле деятельности, которое сейчас стремительно развивается.

- Каковы на сегодня наиболее сильные стороны DevOps?

Самая сильная сторона – это возможность использовать ИТ в интересах ИТ-специалистов. Я имею в виду автоматизацию процессов разработки. Еще одна сильная сторона в том, что DevOps смещает внимание ИТ-специалистов с инструментария на взаимодействие между людьми. Аббревиатура CALMS, которую ввел Джон Уиллис, включает основные принципы DevOps: культура (Culture), автоматизация (Automation), бережливое производство (Lean), измерение (Measurement) и обмен знаниями (Sharing). Как видим, автоматизация – лишь один из элементов DevOps. Эта методика мотивирует людей переосмыслить свою деятельность, в результате ИТ-команды приходят в движение, и это замечательно! DevOps оказывает очень мощное влияние на ИТ-индустрию.

- Многие специалисты говорят, что DevOps – это методика проектирования и разработки ИТ-систем. Корректно ли рассматривать DevOps шире – например, как культуру проектирования и выстраивания стоимостных цепочек?

Если вы взглянете на то, что содержится в руководстве «The DevOps Handbook», то заметите, что описанная в нем техническая практика во многом концентрируется на разработке и операционной деятельности – на том, чтобы подготовить код к развертыванию и сохранить его в репозитории. При этом базовая область DevOps не охватывает то, что должно предшествовать созданию кода и что должно происходить после того, как работа завершена, и продукт передан в продуктивную эксплуатацию и сопровождение. Думаю, сообщество специалистов по ITSM, впитавшее в себя более чем 30-летний опыт предоставления ИТ-сервисов, сможет обогатить сообщество DevOps дополнительными знаниями, и тогда мы получим более объемлющий взгляд на создание и внедрение ИТ-систем. Таким образом, DevOps в узком смысле – это технические практики, но, полагаю, дополнив эту методику культурными нормами и принципами совместного созидания, а также знаниями из области ITSM, мы сможем трактовать DevOps гораздо шире, выведя разработку на более высокий уровень.

- Как вы расцениваете попытки перенести принципы DevOps на управление операционной деятельностью в ИТ-командах и в бизнес-организациях, а также на управление проектами?

Совсем недавно мне довелось участвовать в обсуждении того, как принципы и опыт DevOps могли бы быть использованы для управления сервисами. Считаю, что это хорошая идея: и бизнес, и специалисты по управлению проектами используют принципы agile, которые зародились в среде разработчиков ПО. На мой взгляд, переносить любую методику (в том числе DevOps) на новую предметную область следует избирательно, осваивая и адаптируя то, что подходит и что полезно для новой области.

- Каких изменений и наработок можно ожидать в DevOps в обозримом будущем?

Я считаю, говорить об этом несколько преждевременно. В современном цифровом предприятии, активно внедряющем технологии Интернета вещей, можно выделить не только подразделения ИТ и бизнеса, но и подразделения, отвечающие за операционные технологии (в первую очередь технологии автоматизации производственных процессов). Возникает вопрос: кто отвечает за системы Интернета вещей – ИТ, бизнес или ОТ? Прежде ИТ-команда отвечала за все, что связано с автоматизацией. Сегодня наблюдается конвергенция ИТ и бизнеса. Но куда отнести ОТ – к бизнесу или к ИТ? Другими словами, кто должен отвечать за ОТ – ИТ-подразделение или бизнес? Или же блок ОТ должен быть отдельной структурой? И в какой точке, в какой структуре должны находиться рычаги централизованного управления организацией в целом (а оно, уверен, должно быть)? Кто и как должен координировать, оркестрировать деятельность различных блоков – бизнеса, ИТ и ОТ? У меня пока нет ясного ответа.

В Москве прошел пятнадцатый форум IT Management Forum, организованный издательством «Открытые системы» и собравший более 400 представителей отечественных и зарубежных компаний из разных отраслей зарождающейся цифровой экономики. Слоган форума – «Стратегия и практика управления ИТ. В ответе за цифровое предприятие» — весьма точно характеризует современное состояние процесса цифровой трансформации, которая не сводится к последовательной и уже привычной автоматизации. Сама по себе автоматизация не улучшает текущие бизнес-модели – за счет одного лишь применения новых технологий цифрового общества не построить, поэтому требуется, как считают участники сессии «Корпоративный Agile/DevOps и другие инновации в управлении», изменение культуры, профессиональное движение, нацеленное на изменение производственных отношений.

В форумах ITMF регулярно принимают участие ведущие зарубежные и отечественные эксперты. В этом году на форуме выступил Марк Смолли, всемирный посол фонда ASL BiSL и ассоциации DevOps Agile Skills, который на пленарном заседании задал вектор обсуждения вопроса о роли DevOps, сравнив, в частности, разговоры вокруг этой методологии с религиозными спорами, а именно, с дзэн-буддизмом.

Итак, что такое DevOps – культ романтиков, где на любого, пришедшего на обсуждение без принятых артефактов, смотрят с подозрением, либо это лишь рядовой метод разработки программного обеспечения, а может быть, это развивающееся профессиональное движение, нацеленное на укрепление производственных отношений между разработчиками и специалистами подразделения эксплуатации и ускорение выполнения запланированных работ?

В своем докладе «Первые шаги к DevOps и контроль качества ПО» Ольга Тимашева, руководитель центра компетенций по тестированию и обеспечению качества ПО «ЮниКредит Банка», рассказала о движении банка в сторону DevOps. В конце 2017 года была образована инициативная группа с привлечением команд разработчиков приложений, команды развития инфраструктуры и команды тестирования для реализации проекта объединения всех инициатив по автоматизации. В качестве основы на первых порах были выбраны некритичные для бизнеса приложения. Сразу выяснилось, что текущий способ управления изменениями не готов к процессам непрерывной доставки и развертывания, причем невозможно автоматизировать «человеческий фактор» в деле согласования изменений. Однако при развертывании тестовых сред вполне возможно минимизировать субъективизм, а для коллектива из молодых специалистов, стремящихся к освоению новых подходов, нет проблем при движении к DevOps.

Евгений Карасик, менеджер по продукту израильского центра разработок компании Micro Focus, отметил в своем докладе «Как мы внедряли DevOps. Рецепты успеха на основе личного опыта» важность ответственности всей команды за общее дело. Подход DevOps был выбран как способ реализации требований бизнеса за счет регулярной и ранней поставки ПО благодаря организации взаимодействия подразделений разработки, тестирования и эксплуатации. При этом продукты разрабатываются не только на основе принятых методологий, но и с учетом личного опыта разработчиков, а главный принцип звучал как «все,что может быть использовано более, чем один раз, должно быть автоматизировано». Следование DevOps позволяет выявлять и преодолевать организационные, технологические и психологические барьеры для создания управляемого и контролируемого прозрачного процессa с быстрой обратной связью. Однако нельзя делать DevOps наполовину, а эффект будет выше, если всем членам команды интересно работать «по душе, а не по карьерному росту», отметил Карасик. Если до перехода на DevOps новая версия продукта выходила раз в год, то после – по запросу бизнеса, технологический стек стал меняться теперь не раз в несколько лет, а по мере необходимости. Обычно объем кода увеличивался на 30% для каждой версии, а теперь максимум на 3-5%, причем автоматизация тестирования составила 80%, а не 20%, как раньше. Все это позволило резко повысить качество продукта.

Однако, несмотря на такие высокие показатели, не все докладчики сессии рекомендовали слушателям всегда следовать дорогой DevOps. Ирина Марчева, руководитель продуктового офиса компании «М.Видео», в своем выступлении «Нужен ли вам Agile?» обратила внимание на то, что внедрение DevOps не следует считать панацеей. Гибкие методологии итеративной разработки, например Scrum, эффективны в случаях, когда неясен результат и требуется быстро проверить различные гипотезы, а для классических, размеренных проектов с четкими сроками и целями достаточен инкрементальный, эволюционный подход. Проблема может возникнуть в крупных организациях, когда одна часть компании живет в парадигме Agile, а другая – в старой «водопадной», и здесь может помочь SAFe. Проект создания интернет-магазина «М.Видео» с его неясными целями и масштабами изначально относился к Agile, и, по словам Марчевой, его успеху способствовали поддержка со стороны руководства, привлечение консультантов и, главное, – предоставление команде права на ошибку.

Бизнесу нужны конкретные конкурентные преимущества, и ему в конечном счете нет дела до Agile как культуры, отметил в своем докладе «Покажи мне свои практики. Когда Agile краснеет» Олег Егоркин из «Ростелекома». Однако эффективность любой практики, а значит, и результаты бизнеса сильно зависят не только от возможностей команды, но и от способности самих бизнес-руководителей принять культурные преобразования. Свое выступление Егоркин построил вокруг общей многоуровневой модели развития организационной культуры – поведение всех сотрудников компании определяется ее принадлежностью к конкретному уровню: импульсивная (банда), конформистская (церковь), конкурентная (корпорация), плюралистическая (семья) и эволюционная (живой организм). В наибольшей степени практики DevOps начинают работать лишь на четвертом уровне, на втором Dev и Ops существуют раздельно, а на третьем появляется ITIL. Предложенная модель позволяет понять, готова ли команда к DevOps и имеет ли смысл перенимать практики у команд с более развитым культурным кодом.