В конце мая издательство «Открытые системы» провело очередной, уже пятнадцатый, форум 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 в России

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

Германская компания Paessler специализируется на разработке решений для мониторинга ИТ-инфраструктуры. Ее флагманский продукт PRTG широко используется многими компаниями в Европе, в США и других странах. Аналитики Gartner, оценивая рынок решений в области мониторинга и диагностики сетевой производительности, позиционируют Paessler как нишевого игрока, производителя решений для сетей среднего размера, особо обращая внимание на простоту нустановки, удобство эксплуатации, а также выгодную модель лицензирования продукта. На российском рынке продукция Paessler также известна, однако до недавнего времени компания работала в нашей стране исключительно через партнера. Сегодня она выходит на рынок самостоятельно. В ходе форума ITMF 2018, организованного издательством «Открытые системы», мы поговорили с Юлией Миро, менеджером по развитию бизнеса Paessler в России и странах СНГ.

- Как давно работает ваша компания и сколько лет вы присутствуете на российском рынке?

Юлия Миро: «Мы можем не только охватить всю ИТ-инфраструктуру, но и включить в контур мониторинга ряд нестандартных видов»

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

Наши решения используются как предприятиями среднего и малого бизнеса, так и крупными корпорациями. У нас имеется более 200 тыс. установок в 170 странах мира. Основные рынки – это, конечно, Европа и США. В России среди наших заказчиков в основном средние и крупные предприятия.

- Собираетесь ли вы расширить клиентскую базу в России за счет малого бизнеса?

В России средний и малый бизнес развит не так, как в Европе и в Америке. Многим представителям малого бизнеса лицензия на наш продукт кажется слишком дорогой. Почему о нас не было слышно в России долгое время? Мы работали через партнера, а напрямую на рынок не выходили. Но сейчас мы впервые сами присутствуем на ИТ-мероприятии в России, на форуме ITMF 2018. Мы будем заявлять о себе больше и чаще, чтобы такое направление, как мониторинг сетей, устойчиво ассоциировалось и с нашим продуктом PRTG.

- Вы много лет работали с Softline, но сейчас решили выйти на российский рынок самостоятельно. Чем обусловлен этот шаг?

Здесь, скорее, речь идет не о самостоятельности, а о расширении нашего присутствия. То есть, это не смена политики, а просто увеличение степени нашего присутствия в России.

- Будет ли расширяться ваша партнерская сеть в России?

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

- Вы планируете региональное расширение. Как обстоит дело с санкционными ограничениями? Готовы ли вы работать с партнерами и заказчиками в Крыму и Севастополе?

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

- Какой потенциал, по вашему мнению, может иметь ваш продукт на российском рынке?

Я считаю, неплохой. В России сетевой мониторинг как таковой еще не так широко распространен, как на Западе. Многие компании недооценивают его важность. Наш продукт PRTG относится к классу систем комплексного мониторинга. Мы можем охватить максимально широкий спектр различных устройств, не только охватить всю ИТ-инфраструктуру, но и включить в контур мониторинга ряд нестандартных видов. В качестве курьезного примера могу рассказать, что сотрудники одного нашего клиента с помощью PRTG узнают, находится ли их босс в офисе или нет, соответственно, надо ли находиться на рабочем месте в костюме и галстуке (таково требование босса) или можно убрать галстук в ящик.

- Является ли ваш продукт открытым для сторонних разработок на его основе?

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

- Смогут ли сторонние компании зарабатывать на PRTG?

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

- В каких отраслях сегодня работают ваши российские заказчики? Каков размер этих компаний?

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

- Тем не менее, в России вы до недавнего времени не были столь известны, как ваши конкуренты. Чем вы могли бы заинтересовать отечественных заказчиков?

Другие компании, как правило, предлагают решения для управления сетью в целом, а не просто для мониторинга. Это более сложные в установке и гораздо более дорогостоящие системы. PRTG предназначен именно для мониторинга и получения информации для своевременной реакции на инциденты. Конечно, сенсоры можно настроить таким образом, чтобы они не только уведомляли, но и выполняли определенные команды, но, все-таки, это не будет считаться активным управлением сетью. Те же наши конкуренты, которые специализируются, как и мы, только на мониторинге, предлагают покупать модули по отдельности, в итоге цена лицензии существенно возрастает. Мы предлагаем в составе PRTG полный набор функций, все сенсоры, все возможности, а стоимость лицензии зависит только от количества установленных сенсоров. Важно отметить, что мы предлагаем мониторинг без агентов. В состав PRTG уже включена база данных для хранения результатов мониторинга, поэтому не нужно покупать и устанавливать дополнительную СУБД. Данные без агрегирования мы храним в течение года, о при необходимости этот срок можно увеличить до двух-трех лет. Наконец, есть очень удобные средства визуализации данных. Можно создавать отчеты с высокой степенью детализации для технических специалистов, либо обобщенные для демонстрации бизнес-руководителям.

- Сегодня на российский рынок на волне импортозамещения выходит множество производителей оборудования, в первую очередь из Китая. Как обеспечивается его поддержка в PRTG?

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

- Кто обеспечивает техническую поддержку PRTG в России?

Техническую поддержку мы осуществляем своими силами в Нюрнберге, на английском языке. У нас нет сторонних контакт-центров, где работают люди, не являющиеся сотрудниками Paessler. Если заказчика интересует поддержка на русском языке, он может обратиться к нашим партнерам, к Softline. Первый уровень поддержки они обеспечивают, а за решением более сложных задач они обращаются к нам.

Цифровая экономика усилила один из ключевых принципов экономики традиционной: необходимо как можно быстрее выводить на рынок новые продукты и услуги, причем их качество должно быть достаточно высоким. Методика 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 в обозримом будущем?

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

ITIL, библиотека, описывающая лучшие применяемые на практике способы организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий, обновляется довольно редко, как и всякий основополагающий документ. Последняя версия, ITIL 3.0, вышла в 2007 году. С тех пор ИТ-мир радикально изменился, и все чаще представителей компании AXELOS, отвечающей за развитие ITIL, спрашивают о том, когда ждать новой версии библиотеки.

В AXELOS отвечают, что принципы, на которых основан ITIL, остаются неизменными (на то они и принципы), что многие компании только-только «доросли» до ITIL второй версии(см. «ITIL — рекомендации, опередившие время», Computerworld Россия, 6 июня 2017), и что библиотека модернизируется: в 2011-м вышло масштабное обновление ITIL v.3, а в 2016-м — ITIL Practitioner Guidance.

Тем не менее 1 ноября 2017 года было официально объявлено, что работа над новой версией библиотеки ведется. И, как заявил на форуме ITMF 2018, организованном издательством «Открытые системы», Роман Журавлев, менеджер по развитию ITSM-портфеля AXELOS, новостей стоит ждать «позже лета, но не в декабре».

Роман Журавлев заверил, что в новой версии ITIL будет учтен «опыт по-настоящему цифровых организаций» — таких как Google и Amazon

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

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

Создатели обновления в ITIL следуют ключевым принципам, сформулированным в ITIL Practitioner Guidance, – упор на ценности для потребителей, целостный подход, совместная работа и т.д.

Среди новшеств, которые упомянул Журавлев, — переход от «4P» (People — Process — Product — Partner) к концепции «4 измерений ITSM» (Organizations and people — Information and technology — Partners and suppliers — Value streams and processes). И от описания процессов — к описанию практик, охватывающему все эти измерения. Кроме того, в новой версии будет учтен «опыт по-настоящему цифровых организаций» — таких как Google и Amazon.

А пока Журавлев посоветовал обратить внимание на ITIL Practitioner Guidance, который, по его мнению, остался недооцененным — в нем видят лишь необязательное дополнение, интересное только знатокам и ценителям. Новая версия, по словам Журавлева, будет во многом базироваться на принципах и моделях, описанных в ITIL Practitioner Guidance.

Чтобы выяснить, чего от новой версии ITIL ждут ее потенциальные читатели, Журавлев провел на ITSM 2018 круглый стол, посвященный эволюции подхода к управлению ИТ-сервисами. Свое мнение могли высказать и эксперты-панелисты (на круглый стол пригласили тех, кто принимает участие в разработке новой версии ITIL), и участники конференции.

Первое, о чем завязалась дискуссия, — об уместности слова «сервис» в нынешних условиях, поскольку оно подразумевает наличие двух неравнозначных сторон, «а сейчас больше принято говорить о партнерстве». Возможно ли партнерство в модели, изначально основанной на разделении «поставщик – потребитель»? Нашелся, впрочем, и достойный ответ: «мы (ИТ-подразделение) — партнеры с бизнесом, поскольку помогаем ему зарабатывать больше и быстрей», но предметом партнерства по-прежнему остаются ИТ-услуги.

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

Высказывались пожелания, «чтобы книжка была максимально понятной и не допускала разночтений» и «ITIL должен быть доступен для понимания не только ИТ-руководителям, но и бизнес-менеджерам».

Относительно включения DevOps и других инновационных подходов в новую редакцию ITIL возникли разногласия. С одной стороны, концепция «все знания под одной обложкой» привлекательна, с другой — «практик DevOps много», и следовательно, включить в ITIL можно только какие-то совсем базовые понятия. Другой вариант — «разобраться, из чего состоит DevOps и «разложить» его по практикам ITIL».

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

В Москве прошел пятнадцатый форум 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 и имеет ли смысл перенимать практики у команд с более развитым культурным кодом.

Рынок информационных технологий непрерывно меняется, меняется роль ИТ для бизнеса. Меняется, соответственно, и сущность ITSM. Выступая на недавнем форуме IT Management Forum 2018, организованном издательством «Открытые системы», в своем докладе «Цифровая трансформация (IT)SM: эволюция в технологиях управления» Дмитрий Рубин, директор департамента систем автоматизации ИТ и процессов обслуживания компании Naumen, отметил, что первоначально сервисные отделы обслуживали преимущественно запросы самих ИТ-подразделений. Делалось это практически «на коленке» — заявки регистрировались по электронной почте или телефону, учет активов велся в Excel.

Усложнение ИТ-систем заставило предприятия внедрять полноценные системы Service Desk, интегрировать с ними средства мониторинга, совершенствовать учет активов. На следующей стадии развития концепции ITSM в зону ответственности сервисных служб попали, кроме управления, собственно, ИТ-услугами, управление контрактами и субконтрактами, активами. Кроме того, все чаще в системах управления ИТ ведут свою работу и другие сервисные подразделения – служба HR, административно-хозяйственные подразделения, контакт-центры и центры обслуживания клиентов.

Naumen — один из крупнейших российских игроков на рынке автоматизации сервисных процессов. Для предприятий малого и среднего бизнеса компания предлагает облачное решение ITSM365, для корпоративного сектора создано целое семейство продуктов, построенных на базе Naumen Service Management Platform — Naumen Service Desk, Naumen ITAM, Naumen Network Manager. Ими можно пользоваться как облачными сервисами или же установить в собственном центре обработки данных.

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

Такое решение у компании уже есть — это Naumen Service Management Intelligent Automation. Опыт его внедрения у ряда заказчиков показал возможность снижения затрат на операционные процессы до 50%, а также добиться повышения качества и скорости принятия решений до 70%.

В результате внедрения решения с применением технологий искусственного интеллекта в «Почте России» было налажено централизованное управление объектами ИТ-инфраструктуры во всех 42 тыс. отделений связи и приблизительно 250 услугами

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

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

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

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

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