Управление ИТ

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

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

1. Емкость и ее утилизация

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

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

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

2. Пропускная способность и ее использование

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

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

3. Вычислительная мощность и ее использование

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

4. Окно резервного копирования

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

Компаниям, использующим технологии резервного копирования, которые относятся к категории инкрементных – непрерывную защиту данных (continuous data protection, CDP), почти непрерывную защиту (near-CDP), инкрементное резервное копирование на блочном уровне, резервное копирование с исключением дублирования и т.д. – как правило, не нужно беспокоиться об окне резервного копирования. Дело в том, что процедура резервного копирования запускается на очень короткий срок, и при этом передается относительно небольшой объем данных. Такие операции обычно не оказывают существенного воздействия на производительность основных систем. Вот почему клиенты, использующие системы такого рода, чаще всего выполняют резервное копирование днем – один раз в час или даже через каждые пять минут. Истинная система CDP действительно работает непрерывно, пересылая каждый новый байт практически сразу после того, как он был записан.

5. Точка восстановления и время восстановления: цель и реальность

На самом деле продолжительность резервного копирования мало кого волнует – интересует время восстановления. Целевая продолжительность восстановления (recovery time objective, RTO) – это согласованный всеми заинтересованными сторонами временной промежуток, в течение которого работоспособность должна быть восстановлена в случае возникновения такой необходимости. Для любой компании приемлемое значение RTO определяется той суммой денег, которую она теряет за время пребывания ее систем в неработоспособном состоянии. Если, к примеру, компания потеряет за час простоя миллионы долларов, уровень RTO для нее весьма критичен. У компаний, занимающихся выполнением финансовых операций, показатель RTO должен приближаться к нулю. У тех же организаций, на работе которых простой компьютеров практически не отражается, RTO может измеряться неделями. Важно лишь, чтобы значение RTO соответствовало потребностям бизнеса компании.

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

Целевая точка восстановления (recovery point objective, RPO) – это объем допустимых потерь данных, выраженный во времени. Например, если мы готовы потерять данные, накопленные в течение одного часа, то значение RPO составляет 1 час. Большинство компаний, впрочем, готовы к гораздо более значительным потерям – от 24 часов и больше. Чем меньше значение RPO, тем чаще вы должны запускать процедуру резервного копирования. Многие компании, вероятно, хотели бы уменьшить интервал RPO, но понимают, что при имеющейся системе резервного копирования это невозможно. Как и в случае с RTO, в компании может быть определено множество различных RPO в зависимости от важности имеющихся наборов данных.

Реальные параметры точки восстановления и времени восстановления (recovery point reality, RPR и recovery point reality, RTR) измеряются только по результатам выполнения процедуры восстановления – реального или тестового. Если RTO и RPO – это целевые параметры, то RPR и RTR позволяют оценить уровень соответствия целевым показателям после восстановления. Проведение соответствующих замеров и последующее сравнение их с RTO и RPO имеет важное значение для определения того, нужно ли вам вносить коррективы в свою систему резервного копирования и восстановления.

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

Что делать с метриками

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

Автоматизация становится все более популярным инструментом оптимизации ИТ-операций. Одной из организаций, исповедующих такую стратегию, является компания 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 следует рассматривать как путь вперед, на котором можно организовать выполнение автоматизированных операций для отдельных сегментов, оставляя другие области (например, сложные производственные системы) в руках человека. Это вполне достижимо и действительно может быть сделано. Думаю, что свести число операций, выполняемых вручную, к минимуму возможно».

Предлагаемая публикация является фрагментом из книги There's No Such Thing as an IT Project: A Handbook for Intentional Business Change.

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

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

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

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

Задать первую часть обычно легко, со второй дело обстоит сложнее. Например, в SLA может быть указано, что длительность перебоя в работе до восстановления обслуживания может составлять не более часа. При этом, согласно второй части, это правило должно соблюдаться для 99% всех перебоев.

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

Стопор инноваций

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

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

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

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

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

Доводы против SLA

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

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

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

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

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

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

Единственная характеристика ИТ-отдела, имеющая смысл

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

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

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

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

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

Цифровая трансформация и BusOps

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

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

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

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

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

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

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

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

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

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

Бой, согласно Сунь Цзы, «всегда идет за сердца и умы», так что начнем с согласования терминологии. Добавив новое слово в свой лексикон, вы, возможно, приятно удивитесь результатам.

В конце марта этого года X5 Retail Group объявила о внедрении системы управления ИТ-мощностями. Автоматизация процессов, спроектированных на базе методик ITIL, помогли реформировать управление ИТ-инфраструктурой, состоящей из 173 тыс. конфигурационных единиц в трех дата-центрах и более 14,5 тыс. магазинов (сейчас уже более 15 тыс. магазинов – Н.С.). Как результат, за прошедший год расходы на закупку оборудования удалось сократить более чем на 300 млн руб. О реализации проекта в рамках форума «Инфраструктура 2019», который 18 июня проведет издательство «Открытые системы», расскажет Наталья Ким, начальник управления инфраструктурных решений ИТ X5 Retail Group.

- Как исторически в X5 управляли инфраструктурой? Какие были проблемы?

По сути управления как такового не было. Скорее это был учет инфраструктурных мощностей, размещенных в ЦОДе, который велся вручную в Excel. При этом невозможно было оценить критичность каждой конкретной единицы оборудования, их взаимосвязи с ИТ-системами. В компании порядка 300 ИТ-систем и изменения в конфигурациях инфраструктуры происходят ежедневно. Мы не знали достоверно, какая из систем сколько ресурсов потребляет, реальную загрузку оборудования с учетом индивидуального режима функционирования каждой ИТ-системы. Увеличение мощностей происходило реактивно – например, при снижении производительности приложения мы просто срочно добавляли ему ресурсов. Если такие были в резерве. Если нет – инициировалась длительная закупка. Иногда владелец системы мыслил проактивно и, зная о планируемых изменениях в ней, заранее заботился о добавлении ресурсов, основываясь на собственной экспертной оценке.

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

- В чем заключался переход на методику ITIL, как он был произведен?

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

- Как в общих чертах это все работает?

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

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

- Планировалось ли изначально автоматизировать работу по новой методологии, или эта идея пришла уже в ходе проекта?

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

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

- Что сейчас представляет собой система управления ИТ-инфраструктурой? Из чего состоит, какие решения используются?

Построенное нами решение состоит из четырех важных компонентов.

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

- Какой достигнут бизнес-эффект и за счет чего?

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

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

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

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

Резерв формируется исходя из статистики запросов бизнеса за предыдущий период. Она обновляется раз в квартал и, в зависимости от полученных показателей объёма тактического резерва мощностей, динамически меняется.

- Что внесло больший вклад: «наведение порядка» по ITIL или автоматизация процессов?

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

- Есть ли планы по развитию управления инфраструктурой?

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

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

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

Насколько важно управлять работой ИТ-службы на основе метрик и KPI?

По мнению ИТ-директоров, контрольные показатели и ключевые показатели эффективности (Key Performance Indicators, KPI) играют очень важную роль. Именно с их помощью лучше всего оценивать успехи и неудачи вносимых с помощью ИТ изменений. Они должны служить ориентиром при контроле за достижением поставленных целей в части производительности, эффективности, надежности и отказоустойчивости.

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

ИТ-директора убеждены в том, что большинство организаций испытывают потребность в сбалансированной системе показателей, помогающей внедрять инновации, стремиться к операционному совершенству, управлять рисками и определять культурные KPI. В соответствии с моделью RGT (run, grow, transform — «запуск, развитие, трансформация») важно проводить различия между показателями на этапах запуска (здесь важен контроль за ситуацией), развития (обновления, дополнительный функционал) и трансформации (совершенно новый бизнес или технологические возможности).

ИТ-директора утверждают, что KPI действительно важны. Среди таких индикаторов:

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

Главное здесь – согласовать показатели, найти простые способы их измерения и действовать исходя из полученных результатов. Сегодня очевидно, что нужны параметры, позволяющие оценивать гибкую (agile) разработку и DevOps. Важно вести осознанные дискуссии о выборе и измерении параметров и результирующих KPI. Как гласит старая мудрость, что измеряем, тем и управляем. Поэтому к измерению правильно подобранных параметров необходимо подходить со всей ответственностью.

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

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

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

Один из ИТ-директоров, с которыми мне довелось общаться, заметил, что ежеквартальные оценки не слишком помогли его компании при внесении изменений в проекты, и предложил оценивать показатели исходя из этапов проекта. Другое предложение предполагало поиск оптимального баланса с учетом стоимости клиентских покупок, доходов полученных от каждого клиента за всю историю взаимоотношений с ним, окупаемости рекламных затрат (return on advertising spending, ROAS), общей стоимости владения (total cost of ownership, TCO), сроков выхода на рынок (time to market, TTM), характера удержания клиентов и ценных сотрудников, окупаемости инвестиций и продуктовой маржи, а также выполнения внутренних и внешних соглашений об уровне обслуживания. Все это непосредственно зависит от поставляемых ИТ-услуг и инноваций.

Нужны ли ИТ-службе внутренние KPI?

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

• не допускать дефицита талантов и бюджета;
• следить за соответствием реализованных проектов принятой стратегии;
• фильтровать проекты (актуальные, но незапланированные).

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

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

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

Измерять то же самое, что и генеральный директор

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

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

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

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

Нужны ли ИТ-руководителям такие же системы BSC, как генеральному директору?

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

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

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

Маурисио Корона, как отмечается в его официальной биографии, «признан отраслевыми организациями одним из лидеров, чье мнение в области технической поддержки и управления услугами является авторитетным, он входит рейтинг Top 100 Influencers and Brands и в число 27 мировых лидеров в сфере ИТ; также он один из самых высокопрофессиональных экспертов в сфере ITSM».

Мексиканец по происхождению, Корона работает с компаниями и их руководством по всему миру, помогая в адапатации и освоении комплесных решений в области управления сервисами. Он занимает должность директора по трансформации в Service Desk Institute (Великобритания) и входит в правление компании BP Gurus (Мексика), партнера SDI в Латинской Америке.

Корона является архитектором и автором ITIL 4, имеет 20 официальных сертификатов ITIL и еще целый ряд профессиональных сертификатов в области управления ИТ, а также ученую степень в области управления бизнесом. В числе тем, представляющих для него сегодня наибольший интерес, Корона называет цифровую трансформацию, «высокоскоростное» управление сервисами (High-Velocity Service Management), гибкость (agility) и устойчивость (resilience) организации, пользовательский (user) и клиентский (customer) опыт, системное мышление, бережливые практики, оркестрацию сервисов, роботизацию бизнес-процессов (Robotic Process Automation, RPA), искусственный интеллект и машинное обучение.

На форуме ITMF 2019, который издательство «Открытые системы» проводит 4 июня, Маурисио Корона выступит в пленарной сессии с докладом «Бережливый интеллектуальный Service Desk — залог качественного клиентского опыта» и затем более подробно раскроет эту тему в своем мастер-классе. В преддверии непосредственного знакомства российской аудитории с Маурисио Корона мы задали ему несколько вопросов.

- Мир ИТ находится в состоянии постоянных перемен. Как это отражается на развитии методов и процессов управления ИТ?

Управление ИТ постоянно эволюционирует, стремясь соответствовать меняющимся задачам организации. ИТ и управление ИТ сегодня должны быть Lean и Agile. От управления ИТ-сервисами (ITSM) мы переходим к управлению корпоративными сервисами (Enterprise Service Management, ESM), то есть к предоставлению заказчикам ценности в виде сервисов независимо от того, где и кем эти сервисы реализуются.

Конец 2018-го – начало 2019 года стали знаковыми с точки зрения развития методологий и стандартов, ничего подобного мне не приходилось наблюдать в новейшей истории ИТ. Увидели свет Cobit 2019, ITIL 4, ISO 20000 и ряд других фреймворков.

Скорость изменений такова, что организации действительно постоянно сталкиваются с целым рядом проблем. Бизнесу, с одной стороны, жизненно необходимы инновации, а с другой — очень часто ему приходится решать задачу выживания. Технологии сегодня надо рассматривать как один из важнейших элементов успеха организации, а ITSM должен эволюционировать таким образом, чтобы служить инструментом «оркестровки» деятельности всей компании, поддерживая ее усилия реализовать ценность в условиях цифровизации. И чтобы добиться этого, недостаточно привычных нам процессов. Нужны более комплексные, согласованные практики, помогающие организовать ресурсы компании таким образом, чтобы каждый из этих ресурсов можно было с максимальной эффективностью применять для достижения определенных целей (понятие «практика» является одним из ключевых нововведений ITIL 4 — Н.Д.).

- Какие тенденции в мире бизнеса и технологий оказывают наибольшее влияние на ITSM?

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

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

- Искусственный интеллект — одна из самых «горячих» тем в ИТ, он уже находит применение в автоматизации процессов Service Desk, мониторинга ИТ-инфраструктуры. В чем вы видите значение искусственного интеллекта в развитии процессов и технологий управления ИТ?

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

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

- Вы — один из архитекторов ITIL 4. Каково значение новой версии для ITSM-сообщества, для бизнеса в целом? Какие из нововведений ITIL 4 вы бы выделили как наиболее важные?

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

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

Cовместное создание ценности (value co-creation) : ценность создается в процессе активного сотрудничества между поставщиками и потребителями сервиса, а также с другими организациями, которые являются частью соответствующих сервисных взаимоотношений. Поставщикам больше не надо придумывать, что же будет составлять ценность для их клиентов, понимание придет в результате взаимовыгодных, интерактивных связей между ними.

Сервисная система создания ценности (Service Value System, SVS): описывает интеграцию всех компонентов и активностей организации в единую систему, обеспечивающую создание ценности. SVS каждой организации имеет интерфейсы с другими организациями, тем самым формируется экосистема, которая поддерживает создание ценности в этих компаниях.

Цепочка создания ценности (service value chain, SVC) : это базовая концепция SVS – набор взаимосвязанных активностей организации по предоствлению своим клиентам продукта или услуги, несущих в себе ценность.

Потоки ценности (value streams) : cерия шагов, предпринимаемых организацией, для создания и предоставления продуктов и услуг. Предполагается, что каждый поток ценности следует принципам lean и agile.

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

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

- Тема вашего выступления на ITMF 2019: «Бережливый интеллектуальный Service Desk — залог качественного клиентского опыта». По идее, обеспечивать положительный клиентский опыт – это главная задача Service Desk во все времена. В чем актуальность этой темы и какие рецепты решения этой задачи предлагаете вы?

Традиционно ITSM фокусировался на предоставлении ценности, исходя из своих собственных представлений о том, что является ценностью для клиентов. Но сегодня «клиентский» (Customer eXperience, CX) и «пользовательский опыт» (User eXperience, CX) перестают быть модными словечками: это абсолютный императив для организаций, если они хотят выстроить и реализовать правильную стратегию в цифровом мире.

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

Здесь приходят на помощь автоматизация и позиционирование Service Desk как практики в ITIL 4. Есть множество способов взаимодействия Service Desk с клиентами и пользователями, можно задействовать технологии для выявления и прогнозирования их поведения и на основе этой информации выстраивать полный профиль каждой отдельной потребности клиента. Продвинутые алгоритмы обработки данных и визуализации дают нам возможность обеспечивать реальную персонализацию и омниканальное взаимодействие. С помощью гибких, «умных» систем и подходов мы получаем по-настоящему интеллектуальную структуру контакта с клиентами. И все эти компоненты теперь объединяются в практике Service Desk.

- Вы впервые будете общаться с российским ITSM-сообществом. Что вы ждете от этого знакомства? О чем хотели бы услышать на форуме ITMF?

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

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

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

Эксперты называют FinOps инструментом оптимизации затрат, которая приобретает критически важное значение по мере того, как компании переводят все больше своих ключевых ИТ-функций из самостоятельно контролируемых ЦОДов с постоянными затратами в облака с затратами переменными. По оценкам Gartner, до 2022 года рынок публичных облачных сервисов будет ежегодно расти почти на 17%, и к концу этого периода достигнет 360 млрд долл.

Как ни удивительно, именно в этом сегменте аналитики обнаруживают исключительное расточительство с точки зрения как расходования драгоценного бюджета, так и использования ресурсов. Из 300 руководителей финансовых и ИТ-служб, опрошенных 451 Research, 80% отметили, что слабое управление финансами в облачной сфере негативно отражается на их бизнесе; 57% ежедневно выражают обеспокоенность управлением облачными затратами, а 69% регулярно превышают заложенный облачный бюджет на 25% и более.

Экономика облака

«Облако – не только технологический феномен XXI века, но и экономическая модель, движимая цифровой трансформацией, – указывает автор облачной стратегии компании Capital One Бернард Голден. (Capital One Financial Corporation — американская банковская холдинговая компания, специализирующаяся на кредитных карточках, ипотечных кредитах, автокредитах, банковских и сберегательных продуктах. — Прим. перев.) – Облако – новая эпоха фабричного производства. Способность облаков автоматизировать функции и повышать эффективность работы компаний аналогична революции Генри Форда, которую тот устроил в автомобильной отрасли путем организации фабричного производства и автоматизации некоторых процессов, позволившей ускорить выпуск автомобилей. Подобно тому, как Форд сократил расходы на производство автомобилей за счет использования средств автоматизации, предприятия должны минимизировать свои затраты на облачное программное обеспечение путем их оптимизации и управления ими».

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

По мере перемещения вычислительных ресурсов в Amazon Web Services и Azure компания Nationwide столкнулась с вопросом выбора оптимальной облачной платформы. Сложность выбора «правильного» облачного сервиса является общей проблемой при переходе в облако. То же самое относится и к «черному ящику» облака в части понимания затрат на конкретные облачные сервисы. Счета за облачные сервисы, выставляемые AWS, Microsoft и другими провайдерами, становятся слишком подробными и громоздкими. FinOps помогает предприятиям отслеживать свои затраты на ресурсы процессора, памяти и хранения, внося соответствующие корректировки, связанные с выбором серверов, которые лучше подходят им с точки зрения ресурсов и требований.

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

Прозрачность расходов имеет решающее значение и для Алекса Ландиса, финансового менеджера проекта разработки платформ AWS в AutoDesk. С его помощью компании удалось добиться серьезного прогресса в области перехода от продаж традиционных программ для построения чертежей к предоставлению аналогичных SaaS-сервисов в AWS и других облаках. Будучи бизнес-аналитиком по образованию, сегодня Ландис учится выстраивать платформу публичных облачных программных сервисов.

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

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

Затраты на использование серверов в модели без серверов

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

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

Провайдеры облачных сервисов все чаще исключают из счетов упоминания о серверах, предлагая в качестве замены функции в виде сервиса (functions-as-a-service, FaaS). В этих условиях компании платят только за использование программного кода, который обеспечивает функционирование их приложений. Эти транзакции выполняются за доли секунды, генерируя еще больше строк еще быстрее, что приводит к значительному увеличению объемов и сложности выставленных счетов. «Когда вы пишете код для новой функции, обращение к сервисам происходит очень быстро, и массу людей можно обслужить за совсем небольшие деньги, – пояснил Фуллер. – Но при выполнении миллиардов транзакций количество таких обращений стремительно растет. И это вызывает у клиентов уже серьезные трудности».

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

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

В целях систематизации практик FinOps компания Cloudbility объединила усилия с Nationwide, AutoDesk, Here Technologies и прочими, сформировав некоммерческую ассоциацию FinOps Foundation (F2), которая сосредоточена на продвижении передового опыта и стандартов управления финансированием облачных сервисов.

Лучшие практики FinOps

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

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

— Не запрашивайте газонокосилку там, где подойдет триммер. Является ли инстанс EC2 оптимальным для вас или же он избыточен? Используйте и платите только за то, что вам действительно нужно.

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

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

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

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

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

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

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

Вице-президент Constellation Research Дион Хинчклифф призывает ИТ-директоров к 2025 году довести уровень автоматизации до 90% там, где это представляется естественным: в службе технической поддержки, при выполнении запросов на обслуживание, поиске кандидатов на замещение вакантных должностей и приеме их на работу, закупках ИТ, в операционной деятельности, обеспечении кибербезопасности, администрировании проектов и формировании отчетности. «Поначалу эти области с трудом поддаются автоматизации, но все равно они должны быть максимально автоматизированы», – говорит Хинчклифф.

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

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

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

1. Обслуживание клиентов

Для многих руководителей ИТ-служб улучшение обслуживания клиентов является главным приоритетом. В ходе недавнего опроса Harvey Nash/KPMG CIO Survey, проводившегося в Великобритании, 62% ИТ-директоров назвали это своей первоочередной целью.

Результаты исследования DigitalGenius показывают, что у 80% служб техподдержки (service desk) 20% поступающих заявок повторяются и обслуживаются достаточно легко. Соответствующие задачи хорошо поддаются автоматизации, что повышает степень удовлетворенности клиентов и снижает текучку кадров в службе поддержки клиентов.

Чатботы и виртуальные агенты идеально подходят для простых, повторяющихся запросов и для клиентов, отдающих предпочтение самообслуживанию. Для поддержки корпоративных клиентов Microsoft использует в своих контакт-центрах решение AI Solution for Customer Service. За последние полгода число клиентов, сумевших решить свои проблемы, удвоилось. Сегодня их ежедневно обслуживают более 100 тыс. виртуальных агентов. Использующая аналогичную систему компания HP удовлетворяет с ее помощью 70% всех поступающих заявок на техническое обслуживание.

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

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

2. Управление персоналом и наем сотрудников

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

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

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

3. Платежи

Неэффективные системы учета командировок и прочих затрат отнимают много дополнительного времени. В платформы облачного хранения наподобие Box и OneDrive интегрированы средства распознавания, позволяющие считывать информацию из квитанций. Сервис MileIQ отслеживает заявки на поездки, а его разработчики создали новое приложение Spend, подключаемое к банкам и учетным записям банковских карт для автоматической классификации расходов. Аналогичное приложение SAP Concur собирает информацию о платежах за гостиничные услуги и аренду автомобилей. Оно учитывает даже обменные курсы при совершении зарубежных поездок и автоматически переводит деньги на банковские счета сотрудников и кредитные карты компаний.

Растет интерес к таким областям, как автоматизация оплаты по счетам. По оценкам McKinsey, 27% всей финансовой деятельности можно автоматизировать, а треть этого объема поддается автоматизации с помощью программных роботов (Robotic Process Automation, RPA).

4. ИТ-операции

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

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

«Даже сами ИТ-специалисты говорят о том, что почти пятую часть нынешних повседневных задач можно было бы автоматизировать с помощью средств искусственного интеллекта, – указывает Джеймс Денинг, вице-президент компании Automation Anywhere, предлагающую RPA-платформу. – Сюда относятся установка оборудования и программного обеспечения, управление файлами и папками, мониторинг серверов, управление Active Directory, подключение и отключение пользователей и выполнение пакетных обработок».

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

5. Подготовка устройств

Подключение инфраструктуры, находящейся на территории предприятия, к облачным сервисам с помощью Microsoft System Center и Intune позволяет ИТ-службе автоматизировать процедуры развертывания и настройки конфигурации устройств. С помощью функции Windows 10 Autopilot, например, новый ПК при первом включении подключается к Azure Active Directory.

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

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

6. Автоматизация обеспечения безопасности

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

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

7. Тестирование приложений

«Автоматизация – ключевая составляющая DevOps, особенно при создании сборок для непрерывного развертывания, – полагает вице-президент Sauce Labs Любош Паробек. – Устранение влияния человека помогает ускорить получение результатов, выполнение процедур и разработку приложений. Кроме того, обеспечивается повторяемость: при наличии средств автоматизации вам уже не нужно изобретать велосипед. Устраняется и источник ошибок: людям свойственно ошибаться, а машинам нет».

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

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

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

Организациям, использующим ITIL, нужно учесть: в популярном своде знаний произошли существенные изменения, направленные на модернизацию управления сервисами ИТ (IT service management, ITSM) и трансформацию их в более гибкий ресурс, приносящий дополнительные ценности бизнесу.

В последний раз ITIL обновлялась в 2011 году, но это были скорее косметические изменения. Обновление же 2019 года вносит гораздо более серьезные коррективы и сравнимо с теми, что произошли в 2007 году. Версия ITIL 4 ориентирована в первую очередь на адаптивность, настраиваемость и гибкость управления ИТ-сервисами.

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

Девять основных принципов ITIL

Два года назад компания AXELOS представила набор руководящих принципов, которые нашли отражение в экзамене ITIL Practitioner, охватывающем вопросы управления организационными изменениями, коммуникациями, измеримостью и метриками. К этим критериям, известным как девять основных принципов ITIL, относятся:

• фокус на ценности (Focus on value);
• работа на людей (Design for experience);
• старт исходя из текущей ситуации (Start where you are);
• системное мышление (Work holistically);
• итерационное развитие (Progress iteratively);
• непосредственный контроль (Observe directly);
• прозрачность (Be transparent);
• взаимодействие (Collaborate);
• упрощение (Keep it simple).

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

Ориентация на культуру

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

По словам директора AXELOS Global Best Practice по продуктам Марго Лич, управление ИТ естественным образом поддерживает «разобщенный стиль работы», который отделяет ИТ от бизнеса и негативным образом отражается на взаимодействии.

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

Переход к Agile-методикам и DevOps

«Фокус прошлых версий на организации советов по управлению изменениями (CAB) привел к негативному восприятию ITIL, – отметила Лич. – Претензии предъявлялись к недостаточной гибкости и созданию препятствий на пути быстрого развертывания. Вместе с тем в ITIL никогда не подразумевалось, что необходимо тщательно оценивать любое простое изменение в ИТ».

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

Построение прочного фундамента для изменений

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

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

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

Больше внимания клиентам

Клиентов всегда причисляли к ключевым аспектам ITSM, но в ITIL 4 им отводится еще более важная роль.

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

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

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

Официальная презентация ITIL 4 состоялась буквально на днях (книга ITIL Foundation book of the ITIL 4 Edition увидела свет 18 февраля 2019 года — Прим. ред.), но обновления будут появляться в течение всего нынешнего года по мере модернизации отдельных модулей. Для обеспечения плавного перехода экзамены, сертификация, книги и аккредитации по ITIL v3 сохранятся до июня 2020 года. Для тех, кто уже проходит процесс сертификации, заработанные кредиты будут переведены в новые схемы.

AIOps (Artificial Intelligence for IT Operations) обещает cэкономить время и усилия ИТ-служб, затрачиваемые на выявление различных неполадок во все более сложной среде, в которой им приходится работать.

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

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

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

Разработка стратегии AIOps

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

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

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

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

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

Предложения вендоров

Бхалла убежден в том, что готовые инструменты AIOps, такие как Splunk IT Service Intelligence и Moogsoft AIOps, станут более популярными, чем решения собственной разработки, поскольку они обеспечивают большую согласованность и позволяют ускорить оценку.

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

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

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

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

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

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

Что дальше?

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

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

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