Статьи

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

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

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

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

Революция без жертв: смешанные команды в проектах Agile+DevOps

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

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

Очевидно, сегодня далеко не все компании хотя бы идейно готовы так работать – без заседаний всевозможных комитетов, бесконечных процессов согласования и утверждения ТЗ, но это новый долгосрочный тренд. И новый перспективный рынок для смешанных ИТ-команд, объединяющих разработчиков, экспертов из сервисных компаний, специалистов по ИБ. Этот рынок возник ради большей гибкости и адаптивности прикладных решений, которые (наконец-то!) действительно способны поддержать постоянные изменения и внутри компании, и снаружи – в ужесточившейся конкурентной среде и меняющемся технологическом ландшафте.

Самостоятельная разработка и поддержка микросервисов: что и как

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

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

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

ИТ-инфраструктурщики на DevOps-проектах: чем полезны

Быстро создают и развертывают сразу несколько разных сред

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

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

Помогают выбрать площадку для сервисов и рассчитать ресурсы под проект

В DevOps-проекте инженеры сервисной компании очень часто помогают разработчикам приложений заранее определить, какую вычислительную мощность нужно выделить под сам проект (для каждой из трех сред). Позже их услуги нужны при тиражировании на новые подразделения, ИТ-инфраструктура которых практически всегда имеет особенности, а иногда и принципиальные отличия. Также эти специалисты правильно и эффективно по затратам организуют ИТ-инфраструктуру для работы приложений в облаках (AWS, GCE, Azure), чтобы впоследствии, когда число пользователей и объем задач будут возрастать, не пришлось тратить время и ресурсы на авральный «переезд» на более подходящую площадку.

Развертывают ИТ-инфраструктуру для запуска приложений

ИТ-специалисты заранее готовят и настраивают средства автоматизированного управления конфигурациями(Puppet, Ansible и др.), резко снижающие сложность оперативного развертывания и настройки серверов, снижают количество ошибок и зависимость от квалификации администратора. Такая подготовка сокращает время на развертывание приложений для клиента в 3-10 раз.

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

Автоматизируют управление инфраструктурой

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

Работают с контейнеризированными приложениями

Также инфраструктурщики автоматизируют установку, масштабирование и управление контейнеризированными приложениями с помощью кластеров Kubernetes. Благодаря их настройке (включая правила доступа к API и правила межсетевого взаимодействия для приложений), разработчики могут сделать свое приложение доступным даже во время пиковых нагрузок. А также в любой момент расширить или сжать кластер – буквально за пару секунд. Это экономит время и силы разработчиков, спасает их от многочисленных сложностей и ошибок.

Выполняют требования к SSO

Зачастую новые системы работают на разных СУБД (PostgreSQL, MySQL), а при разработке приложений используются разные платформы. Естественно, у разработчиков, а потом и у пользователей, должен быть простой и безопасный доступ ко всем нужным им сервисам и инструментам, а также сквозная аутентификация (Single Sign-On, SSO). Кроме того, над проектом работают разные команды – здесь обязательно нужно разделять права доступа к сервисам, инструментам, задачам, делать технически невозможным такое совмещение прав, которое создает высокие риски для бизнеса. К сожалению, об этом функционале думают не всегда.

Отслеживают «здоровье» информационной системы

Тиражируя и масштабируя новые приложения, важно следить за их состоянием, желательно в режиме реального времени. Специалисты по ИТ-инфраструктуре могут предоставить разработчикам приложений доступ к данным, помогающим анализировать возникающие ошибки в работе приложений с помощью инструментов open source (Graylog и Elasticsearch). Они также организуют сбор всех нужных разработчикам метрик с элементов инфраструктуры и приложений, на всех уровнях (Zabbix, Prometheus, TICK Stack). Также «инфраструктурщики» могут настроить удобную визуализацию и умные предупреждения о возможных ИТ-проблемах и авариях, отслеживать и корректировать поведение разных модулей приложения при высоких нагрузках.

Налаживают резервное копирование

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

Подведем итоги

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

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

Автор — Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group

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

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

«Среда, в которой фактически нет операций, выполняемых вручную, способствует ускорению разработки и развертывания, – указал вице-президент Mindtree по вопросам инфраструктуры Рене Хед. – Это открывает перед бизнесом дополнительный простор для запроса новых функций и сервисов. Речь идет не только о совершенствовании доставки ИТ-услуг, но и о выигрыше непосредственно для бизнеса. Развивающаяся тенденция NoOps уже выводит некоторые ИТ-организации за рамки автоматизации DevOps и формирует инфраструктурную среду, не требующую операционной активности».

Что такое NoOps?

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

Проясним сразу, NoOps – не то же самое, что и аутсорсинг ИТ-операций. Речь не идет о переходе к модели SaaS или к облаку, где операции будут выполнять поставщики услуг, хотя провайдеры управляемых сервисов, такие как Mindtree, и облачные компании действительно уже пошли по дороге NoOps, добиваясь увеличения скорости и гибкости своей инфраструктуры.

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

NoOps не является и платформой, которую можно купить.

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

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

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

Эволюция NoOps

В своем докладе Tech Trends 2019 аналитики Deloitte отнесли NoOps к «бессерверному миру». На следующем этапе эволюции облачных вычислений ключевые задачи будут автоматизированы, что позволит ИТ-специалистам сосредоточиться не на операциях, а на конечных результатах.

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

Да, идея NoOps не нова, как и споры о том, является ли это достижимым состоянием, громким призывом или несбыточной мечтой. Публичные споры об этом понятии между руководителями технических направлений Etsy и Netflix разгорелись еще в 2012 году.

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

ИТ-службы отреагировали на это переходом на новые технологии (например, облачные вычисления) и внедрением новых методологий (Agile и DevOps).

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

Континуум NoOps

Глава Deloitte Consulting и технический директор облачного направления компании Кен Корлесс называет NoOps «вершиной горы DevOps».

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

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

«Наша цель состоит в том, чтобы сократить численность команд, выполнять больше операций, ускорять продвижение вперед и делать это устойчиво, – пояснил Корлесс. – Никто еще не придумал, как обойтись без ИТ-службы вовсе, но всем хочется уделять больше внимания не поддержке, а разработке. ИТ-директора, движущиеся к NoOps, сокращают число людей, требуемых для выполнения каких-либо операций с программным обеспечением. В конечном итоге пользователь уже не направляет запрос и не спрашивает разрешения, а просто нажимает нужную кнопку, и все происходит само собой. Рост уровня автоматизации приводит к уменьшению числа задач, начиная от администрирования DNS и заканчивая управлением обновлениями».

Однако эксперты предупреждают, что ИТ-службы пока далеки от создания истинной среды NoOps.

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

Неприятие концепции

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

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

«Вам в любом случае придется поддерживать то, что вы выстроили, – указал ведущий аналитик Forrester Research Чарльз Бетц, занимающийся вопросами инфраструктуры и операционной деятельности. – Представьте, что у вас есть клиенты, желающие иметь доступ ко всему этому. Что произойдет с ними, если что-нибудь сломается? Следовательно, нужна поддержка. И чем сложнее система, тем выше вероятность того, что вам понадобятся люди для ее поддержки. ИТ-службы должны использовать автоматизацию, чтобы обеспечить предоставление инфраструктуры для разработки программного обеспечения так быстро, как этого хочет бизнес. Вместе с тем ИТ-службе необходимо понимать пределы возможностей автоматизации продаж. Переход к NoOps не означает отказа от финансирования службы поддержки и операционных подразделений. От автоматизации не стоит ждать чудес – вам все равно придется решать проблемы и устранять неисправности. Но это может означать, что в отличие от традиционной операционной организации, которая функционирует как отдельная бизнес-единица, вы распределяете некоторых или всех операционных инженеров между различными командами разработчиков, двигаясь таким образом от проекта к продукту. По мере дальнейшего развития операции становятся все сложнее. Мы постоянно слышим это от наших клиентов. Те же, кто утверждают, что на операции нужно тратить меньше, занимают откровенно деструктивную позицию».

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

«NoOps формирует неверный посыл и порождает неверные ожидания, – подчеркнул он. – Необходимо обсуждать вопросы автоматизации, ее достоинства и недостатки. Мы вступаем в эпоху парадокса автоматизации и самоуспокоения ею. Что произойдет, если автопилот совершит что-то вам совершенно непонятное? Самоуспокоенность несет в себе риски для ИТ-директора».

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

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

С этим согласны и другие. Панетта, к примеру, считает, что навыки человека всегда будет востребованы при решении отдельных задач мониторинга, при устранении неисправностей и проведении ремонта.

«В своем чистом виде концепция NoOps фактически нереализуема, но это весьма эффективный призыв к сплочению, – добавил Корлесс. – То, что происходит в сфере инфраструктурных операций более точно отражают термины AIOps и эвристическая автоматизация».

Рене Хед также признает ограниченный характер NoOps.

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

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

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

Какие проблемы данных и архитектуры требуют внимания

Полезным будет разделить стандарты в области данных и архитектуры на две категории.

1. Стандарты архитектуры, например, модели данных, конвейеры данных, базовые технологии микросервисной архитектуры, стандартные конвейеры непрерывной интеграции и доставки программных решений (continuous integration/continuous delivery, CI/CD), проверки концепций для новых технологий. Внедрение таких стандартов требует подготовительной работы.
2. Стандарты для практик, в том числе соглашения об именовании, требования к тестированию, стандарты интерфейсов микросервисов и шаблоны удобства использования (usability) — все это будет служить для участников группы руководством при реализации функций и устранении технического долга. Кроме того, в данную категорию можно включить стандарты процессов, определяющие принципы расширения моделей данных, проверки усовершенствований конвейера CI/CD, составления документации по новым конечным точкам микросервисов и т. д.

Когда стандарт требует инженерной работы, ее лучше оформить в качестве ситуаций (epic), функций и историй (story) в журнале пожеланий и назначить соответствующей группе. Для этой группы другие команды разработки становятся клиентами, соответственно, она должна сформулировать условия приемки своей работы. Владельцем продукта при этом может быть архитектор данных, приложения или решения. Его задача — выпустить компонент, которым легко смогут воспользоваться agile-команды и который будет полезен бизнесу.

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

Agile-разработка требует систематического планирования

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

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

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

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

Разработка эталонных архитектур и моделей данных

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

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

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

— концептуальная модель данных, изображающая бизнес-объекты, связи и основные транзакции;

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

— модель интеграции данных, на которой показаны источники данных, операции преобразования и базы данных;

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

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

Составьте согласованные со стандартами условия приемки нового кода

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

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

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

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

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

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

Крупные организации с многочисленными командами исследователей инвестируют в платформы исследования данных (Alteryx Analytics, Databricks и Dataiku), представляющие собой набор инструментов для разработки, тестирования и развертывания аналитических моделей. Эти инструменты конкурируют друг с другом с точки зрения операций с данными, аналитических возможностей, средств интеграции, управления, инструментов для бизнес-пользователей и функций развертывания.

Отличия потребностей в DevOps у исследователей данных и разработчиков приложений

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

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

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

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

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

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

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

Поддержка исследователей данных требует понимания имеющихся отличий. Только после этого можно переходить к внедрению практик DevOps. Начать же следует вот с чего.

Формирование у исследователей данных необходимого опыта

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

Начать имеет смысл с инфраструктуры для исследователей данных. На каких языках они пишут программный код: на Python, R или чем-то еще? Какие инструменты (Jupyter, Tableau, Apache Kafka или NLTK) используются для анализа и моделирования? Какие базы данных и облака выступают в роли источников данных и служат для хранения данных, используемых в обучении, и для развертывания моделей?

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

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

Следует учитывать, что в некоторых сервисах SaaS и платформах корпоративных данных нет встроенной системы контроля версий и отсутствуют интерфейсы со средствами управления версиями, применяемыми при написании программного кода. У многих из этих платформ имеются API для проведения интеграции и развертывания или какие-то другие средства, позволяющие имитировать процесс непрерывной интеграции и развертывания (CI/CD).

Формирование конвейеров развертывания и настройка инфраструктуры

При стандартизации среды развертывания и непрерывной интеграции DevOps-консультантам следует обратить внимание и на другие аспекты тестирования автоматизации и построения производственных сред. Это можно сделать путем внедрения конвейеров развертывания с инструментами наподобие Jenkins и настройки инфраструктуры с использованием Chef, Puppet, Ansible или каких-то других инструментов.

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

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

Союз разработчиков, ИТ-администраторов и исследователей данных

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

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

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

Компания iiko занимается написанием и продажей программного обеспечения для управления ресторанным бизнесом. Пять лет назад iiko стала предоставлять свои разработки по модели SааS (ПО как сервис), и тогда ей потребовалось создать блок эксплуатации и обслуживания. Компания практикует DevOps; об этом в преддверии конференции «Корпоративный DevOps 2019», посвященной DevOps как управленческому подходу и его роли в цифровой трансформации, которую издательство «Открытые системы» проведет в Москве 26 ноября, рассказал Сергей Гнутов, руководитель эксплуатации и технической поддержки компании iiko.

- Почему компания прибегла к DevOps?

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

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

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

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

Сергей Гнутов: «Внедрение DevOps в конце концов делает команду единым целым, с общим инструментарием, целеполаганием, задачами»

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

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

- Как у вас сочетаются SAFe и DevOps?

DevOps – концепция, SAFe – конкретный инструмент организационного и технического характера одновременно (Scaled Agile Framework, SAFe – фреймворк для реализации принципов Agile в крупных организациях – М. С.). И если технический аспект у agile-компаний разный (например, могут быть различные производственные среды), то управленческий – универсальный. Во всех таких компаниях есть этапы планирования, оценки эффективности исполнения и пр. SAFe объединяет команду для выполнения бизнес-задач. При этом в нем есть элементы, которые подходят для различных организационных моделей.

- Чем вам нравится именно SAFe?

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

- Если DevOps – мировоззренческая концепция, то как вы меняете мышление людей?

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

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

- А эти шаги надо продумывать заранее, или они скорее интуитивные?

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

- Как новые люди внедряются в команду? Если с имеющимися сотрудниками надо провести немалую работу, то тяжело ли обучать новичков?

В DevOps это проще, чем в других средах, благодаря гибкости и горизонтальности подхода. Если новый человек приходит в систему, система сама его научит всему необходимому. Сначала вы выстраиваете систему, потом она начинает работать на вас. Поэтому с каждым конкретным человеком не нужно проходить все этапы – вы погружаете его в среду, и она делает свое дело.

- Как часто у вас меняются люди?

У нас довольно стабильная команда. Ротация кадров на уровне 10-15% в год. Это немного с точки зрения рынка.

- Покажете на конкретных примерах, как внедряли DevOps, что получалось, что нет?

Давайте оставим примеры для конференции.

Управление бизнес-процессами считается важной, если не обязательной, составляющей цифровой трансформации. Действительно, как поговаривали еще во времена увлечения первыми ERP, «нельзя автоматизировать хаос». Невозможно построить цифровое предприятие, опираясь на «аналоговые» бизнес-процессы, однако, как продемонстрировала конференция «BPM 2019. Процессы цифрового предприятия», организованная издательством «Открытые системы» в конце октября, подход к ВРМ может быть разным. Можно начинать со строгого описания текущих бизнес-процессов и затем цифровизировать все подряд как есть, а можно стартовать с внедрения системы BPMS. Но, пожалуй, лучше рассматривать ВРМ как составную часть инициатив цифровизации и пересмотреть бизнес-процессы: возможно, некоторые из них существуют только потому, что существуют, и не стоит их брать в светлое цифровое будущее?

Ведущий круглого стола Анатолий Белайчук, президент ассоциации ABPMP Russian Chapter, предложив сторонникам разных взглядов обсудить роль BPM в цифровую эпоху, отметил, что сегодня наблюдается очередная волна интереса к BPM, и вызвана она появлением таких технологий, как Интернет вещей, машинное обучение, Low code, RPA и др. Однако, по замечанию Елены Березовской из инвестиционного банка «Веста», «если человек не понимает, как устроен мир, то ему не помогут ни BPM, ни CRM, ни даже искусственный интеллект — технологии вторичны».

Действительно, бизнес-процессы появились задолго до автоматизации, и BPM – это ядро платформы цифрового бизнеса. Однако Анна Кузнецова, руководитель практики BPM компании Naumen, уверена: «На пути к цифровой трансформации разные компании находятся в разных стадиях развития, работают в различном конкурентном поле, и этим-то, в каждом конкретном случае, определяются степень заинтересованности в BPM и пути внедрения соответствующих систем автоматизации».

Владимир Репин из ассоциации ABPMP Russia напомнил, что компании неоднородны и в разных подразделениях бытуют свои взгляды на цифровизацию, а главное – нельзя забывать про людей: «За каждой схемой стоит конкретный человек, и задача BPM – уменьшить «трение» в системе. Даже простой сбор предложений по изменению бизнес-процессов организуется среди людей, а не среди роботов». С ним согласна и Кузнецова: «BPM — для людей, а не против них. И задача любой автоматизации в том, чтобы освободить людей от рутины. Человек должен ощущать себя не 'винтиком', а главным звеном в единой машине организации».

Алексей Пестриков, управляющий директор дивизиона «Кредитные продукты и процессы» Сбербанка, отметил: «Все, что можно описать, можно и автоматизировать, однако людям свойственно ошибаться». Для минимизации ошибок можно использовать роботизацию бизнес-процессов (RPA), однако такие решения направлены на автоматизацию задач, а не процессов.

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

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

Все больше компаний позиционируют себя как data-driven, пытаясь сделать свои процессы более интеллектуальными, подвести под каждое решение объективный фундамент. Не случаен и рост популярности такой позиции в штате, как директор по данным. Мы побеседовали о подходах компаний к организации работы с данными, их успехах и проблемах с Александром Тарасовым, управляющим партнером DIS Group и членом экспертного совета CDO Award.

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

Российские компании осознали необходимость системной работы с данными — это бесспорно. Другое дело, что в зависимости от отрасли уровень зрелости компаний весьма разнится. Исходя из личных контактов, могу сказать, что директора по данным (Chief Data Officer, CDO) уже появились не только в финансах и ретейле, но и в медицине. Есть очень много интересных инициатив в промышленности, связанных с большими данными и созданием института data science.

В качестве позитивного изменения можно отметить, что уже не приходится слышать: мы назначили CDO, что ему делать? С таким приходилось сталкиваться два-три года назад. Зачем компании нужно управлять данными, объяснять уже тоже не надо. Более того, сложился рынок CDO, появились первые их переходы из одной компании в другую.

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

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

- А каков внешний показатель того, что компания фактически стала относиться к данным как к полноценному активу?

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

У клиентоцентричных компаний — банков, телекома, ретейла и т. п. — фокус направлен на клиента: его действия, социальное окружение, интересы. Здесь маркером является персонализация предложений для клиентов, а в качестве показательных можно выделить проекты с применением технологии Customer 360. В эту историю пока готовы идти далеко не все, и в будущем можно ожидать роста именно в этом направлении.

- Видите ли вы какие-то «национальные особенности» в развитии подходов к управлению данными у нас?

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

- Но ведь выход новых технологий на российский рынок традиционно запаздывает на пару лет…

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

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

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

- Может быть, вы работаете с лидерами, а «в среднем по больнице» ситуация гораздо хуже?

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

- Должность директора по данным до сих пор не стала массовой. Она нужна не всем или не все созрели?

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

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

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

- Что мешает эффективной работе с данными? Какие вы видите барьеры?

Один из барьеров — недостаточное законодательное регулирование области управления данными. Кстати, я абсолютно уверен в том, что в скором времени во всех без исключения компаниях будет введен институт compliance-директоров, занимающихся соответствием регуляторным требованиям и требованиям по работе с данными.

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

- Очень многие говорят о специфической культуре, без которой компания не станет data-driven. Насколько она важна и какие изменения подразумевает?

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

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

- Что можно посоветовать компаниям, пытающимся поставить данные в основу своего бизнеса?

Не бояться это делать. Сейчас крайне важна готовность к экспериментам и переменам, готовность выделять бюджеты на инновации. Именно это отличает западные компании: их подход к управлению инновациями является ключевым корпоративным процессом, они тратят бюджеты на инновации в поисках «золотой жилы». Это основа венчурного финансирования — тратить часть прибыли на эксперименты и быть готовым к неудачам.

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

«ИТ-руководители могут способствовать выживанию и процветанию своих компаний за счет совершения цифрового прорыва, убеждая генерального директора и лидеров бизнеса придерживаться более продуманной и взвешенной стратегии», – отмечают аналитики Gartner Ли Макмаллен и Дэйв Арон.

В материалах проведенного ими исследования организациям предлагается пять возможных стратегий.

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

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

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

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

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

Макмаллен и Арон призывают ИТ-директоров иметь дело с теми поставщиками технологий и сервисов, которые помогают организации в освоении и выстраивании цифрового бизнеса.

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

Нас ждут сразу несколько волн цифрового прорыва.

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

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

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

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

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

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

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

Переосмысление стратегии автоматизации

На том или ином уровне процесс автоматизации происходит уже много лет, но по мере дальнейшей разработки и развертывания уровень сложности становится слишком велик. Объемами и типами автоматизации необходимо управлять. Нужен переход к командной разработке, управляемой архитектором автоматизации и стандартизированной в бизнес-подразделениях. Чем здесь можно помочь? По оценкам Gartner, к 2025 году архитектор автоматизации будет присутствовать уже на 90% предприятий, тогда как сегодня таковых насчитывается всего 20%.

Гибридные ИТ влияют на надежность восстановления после аварий

Гибридные ИТ, которые строятся на использовании ресурсов частных и внешних центров обработки данных, сервисов SaaS и PaaS, филиальных вычислительных систем, граничных вычислений, разнообразных сервисов безопасности, затрудняют обеспечение готовности корпоративных ресурсов и создания резервных копий. Чрезмерно упрощенные планы восстановления ИТ после аварий могут привести лишь к частичному успеху. К 2021 году в 90% случаев проблемы с готовностью будут связаны с неспособностью провайдера облачных сервисов задействовать собственные резервные мощности. Предприятиям необходимо использовать инвестиции в автоматизацию и другие ИТ-инструменты для переориентации процесса восстановления систем.

Масштабирование практик DevOps требует переосмысления платформы

Во многих компаниях ИТ-служба практически превратилась в менеджера по продуктам для разнообразных команд DevOps. ИТ-служба должна обеспечивать согласованность в масштабах предприятия, потому что появление островков DevOps внутри компании противоречит ее интересам. К 2023 году 90% предприятий столкнутся с трудностями при масштабировании инициатив DevOps, если не произойдет перехода на совместно используемые платформы самообслуживания.

Инфраструктура – и ваши данные – повсюду

К 2022 году более половины корпоративных данных будут создаваться и обрабатываться вне ЦОДа или облака, в то время как в 2019 году их доля не превысит 10%. Инфраструктура сегодня находится повсеместно, и всякий раз, когда данные перемещаются, это порождает определенные трудности. Как управлять сценариями, когда данные находятся повсюду? Каппучио выступает за обязательную оценку инфраструктуры, обслуживающей данные, уже на ранней стадии проектирования. Необходимо инвестировать в инструменты инфраструктуры, с тем чтобы управлять данными там, где они расположены, и модернизировать существующие архитектуры резервного копирования для защиты данных, где бы они ни находились.

Всепроникающее влияние Интернета вещей

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

Распределенное облако

Развертывание облачных сервисов на собственной инфраструктуре с предоставлением провайдеру разрешения управлять этим облаком становится все более популярным. У Google, например, уже имеется Athos, а AWS вскоре представит OutPosts, так что в ближайшие два года среда здесь серьезно изменится. Но рынок еще только зарождается, поэтому клиентам надо проявлять осторожность. Предприятиям следует установить необходимые ограничения и определить, кто будет отвечать за обновления программного обеспечения, исправление обнаруженных там ошибок и производительность.

Иммерсивное восприятие

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

Демократизация ИТ-служб

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

Будущее сетевых технологий

В мире сетей формируется масса новых тенденций: ячеистые сети, сервисы безопасности категории SASE (secure-access service edge), управление сетями по требованию, автоматизация сетей и межсетевые экраны в качестве сервиса. После того, как на протяжении десятилетий все ресурсы направлялись на повышение производительности и готовности сетей, нынешние инновации ориентированы на простоту операций, автоматизацию, устойчивость и гибкость бизнес-моделей. Автоматизация нужна предприятиям «повсюду», и им необходимо искать баланс между безопасностью и гибкостью технологий.

Управление гибридной цифровой инфраструктурой

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

С 1 декабря российское отделение Ассоциации профессионалов управления бизнес-процессами начинает прием заявок на конкурс «BPM-проект 2019 года». Об этом Юлия Вагнер, вице-президент ABPMP Russian Chapter, объявила 30 октября на конференции BPM 2019 издательства «Открытые системы».

Конкурс для организаций, которые смогли повысить эффективность управления благодаря процессному подходу и готовы делиться своим опытом, проводится при поддержке ИТ-кластера Фонда «Сколково» и Аналитического центра при Правительстве РФ уже третий раз. Его призеры и лауреаты, а также финалисты прошлого года вошли в число самых ярких докладчиков конференции BPM 2019. Так, Юрий Радыгин, начальник департамента организационного развития и проектного управления Башкирской электросетевой компании, — обладатель приза за самый результативный BPM-проект 2018 года. Примечательно то, что в этой компании трансформируют свои процессы на основе отечественных программных продуктов. Елена Березовская, руководитель процессного офиса инвестиционного банка «Веста», получила специальный приз за создание комплексной промышленной технологии внедрения и автоматизации системы бизнес-процессов. А работа команды Алексея Здюмаева, генерального директора компании Vetro, заслужила сразу две награды — от сообщества ABPMP Russia и от Роскачества за создание федерального оператора по обслуживанию клиентов страховых компаний в части ремонта автомобилей — Российского автостекольного союза.

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

Очень живо восприняла аудитория конференции и выступление Ларисы Зубриловой, генерального директора Центра обслуживания бизнеса КАМАЗа, рассказавшей о проекте создания мобильного приложения для сотрудников автогиганта, который номинировался на конкурс 2018 года. «Проектные команды, приходящие на конкурс, — это люди светящиеся, у них глаза горят», — отметила Вагнер.

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

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

Помимо выбора главного BPM-проекта года, награды вручаются в нескольких специальных номинациях: за самый результативный проект, самый инновационный проект, лучший проект среди государственных организаций, приз сообщества ABPMP Russia и специальный приз жюри. А в этом году список номинаций пополнился еще одной: «За настойчивость в достижении процессного совершенства».

Итоги конкурса планируется подвести в мае 2020 года на конференции издательства «Открытые системы» по роботизации бизнес-процессов.