Обеспечение эффективного взаимодействия подразделений разработки и эксплуатации информационных систем – одна из наиболее актуальных проблем предприятий, вступивших на путь цифровой трансформации. От всех подразделений сегодня требуются высокие темпы реагирования на изменения; недопустима ситуация, когда одни оперативно создают новые и модернизуют существующие приложения, а другие их саботируют, оберегая стабильность инфраструктуры. Облака, большие данные и машинное обучение способны предоставить бизнесу конкурентные преимущества за счет своевременного вывода на рынок востребованных сервисов, однако полная реализация их потенциала зависит от того, насколько эффективно применяются инструменты поддержки разработки и оперативного изменения сервисов и приложений для создания новых бизнес-моделей — иначе говоря, от уровня развития культуры 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), но в любом случае бизнес-менеджеры должны будут в состоянии сформулировать требования в терминах ИТ, как сегодня вы платите за кубометры или киловатты – ресурсы, фактически поставляемые из «облака». Иначе говоря, не будет четкой границы между ИТ и бизнесом, а ИТ-подразделение как таковое станет неотъемлемой частью бизнеса, а не его отдельным подразделением.
