Всем привет, меня зовут Александр Колесов, я – директор направления Cloud&Infra международного ИТ-холдинга Tietoevry, который специализируется на облачных и не только managed-решениях для крупных (они же enterprise) компаний.

Предисловие

    Если посмотреть статистику поисковых запросов для ITIL/ITSM, выясняется, что чаще всего люди задаются вопросом “Что это такое?” и “Кому нужен/когда нужен/зачем нужен ITIL”. Первому вопросу посвящено множество хороших статей, на второй часто отвечают “если вы не знаете, что это такое, значит, вам это не нужно”.

В этой статье мы рассказываем, как научили заказчика радоваться ITIL-у, а еще о том, как сделать ITSM c человеческим лицом для энтерпрайза  и не сойти с ума.

История 1. Как мы настраивали CMDB*

Вводные

Заказчик – крупная международная корпорация с присутствием в России (а также в 130 странах), топ-3 своей отрасли. 

Имел (и продолжает иметь) внушительный бюрократический аппарат и сложные цепочки согласования процессов, руководитель ИТ – в Европе, а отдел, который отвечает за ITSM-инструмент – в Азии. Основной ITSM-инструмент заказчика – ServiceNow, общее число пользователей в компании – около 90 000 (включая ИТ), поэтому требовалось максимально встроиться в существующие ИТ-процессы. База CMDB существовала, активно использовалась, но описывала только собственные on-premise объекты и никак не описывала облачную инфраструктуру.

Задача

Перенести 50+ eCommerce b2b и b2c приложений из приватного облака в публичное, а также внести данные о CI (configuration item, конфигурационный элемент) этих приложений, их связей друг с другом и остальным ИТ-ландшафтом в CMDB. Описать регламенты управления процессами и настроить эти процессы. Сделать так, чтобы всё обновлялось автоматически.

Зачем

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

Почему связи между сущностями важны

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

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

Дополнительные задачи при реализации:

• Возможность делать inventory;

• Возможность вести отчетность;

• Возможность получить осязаемый ландшафт – на самом деле, важно понимать, что у тебя 307 серверов, а не три сотни.

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

Организационные проблемы

1. Бюрократия в процессах. Публичная компания, отчетность перед гос. инстанциями + коммуникация с азиатским ИТ-офисом, нельзя просто так взять и что-то согласовать;

2. Заказчик использует ITSM систему – ServiceNow, в которую занесены в основном ИТ ассеты, находящиеся в своём периметре. Модели, описывающей облачные ассеты, нет. У нас нет доступа к администрированию ServiceNow, соответственно, все требуемые изменения происходят по запросу, в рамках плановых релизов. Учитывая сжатые временные рамки, нам пришлось использовать текущий функционал системы, в частности, нам был не доступен встроенные механизм автодискавери объектов.

Технические проблемы

1. Отсутствует согласованная CMDB модель, подходящая для облачных инстансов;

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

3. Модифицированная платформа публичного облака (openstack), к которой не подойдут интеграционные решения "из коробки";

4. Внести несколько тысяч объектов (CI) в CMDB, включая виртуальные сервера, PaaS инстансы, DNS-имена, SSL-сертификаты и другие, а также связать их между собой и с существующим объектами CMDB.

Как мы это реализовывали

Часть 1. Как не надо. Гуманистическая

Здесь могла быть драматичная и правдоподобная история о том, что мы сначала сделали неправильно, а потом раскаялись, но мы сразу всё поняли правильно:) Я всё равно расскажу, как не надо, потому что точно знаем, что кто-то до сих пор совершает некоторые из перечисленных ошибок, иногда даже все сразу.

1. Не надо брать все типы объектов и пытаться сразу добавить их в базу CMDB под предлогом “раньше начнешь – раньше закончишь”. Почему? Как мы знаем, “данные устаревают, как только ты внес их в базу”.  Внесение информации должно занимать половины времени/сил и происходить в последнюю очередь. Сфокусируйтесь на обновлении информации в базе.

2. Не вешайте бюрократию на конечного пользователя, это всегда плохо заканчивается.* Сюда входит “ничего не делать, пока мы не получим подробное ТЗ для всех случаев”. Возможно, это и нормально для inhouse-разработки (и то, если вы не друг бизнесу своему), но совсем не нормально для концепции ITSM.
   * если вы хотите, чтобы от вас все отстали с дурацкими задачами, то, конечно, вешайте!

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

4. Делать одну документацию на всех. См. пункт первый: если вы хотите, чтобы люди чем-то пользовались, объясните им, как. Желательно, в понятных юзеру терминах.

5. Бросать юзера в воду и ждать, пока он поплывет.Предположим, вы настроили всё идеально, все работает почти без участия клиента. Дело сделано? Скорее нет: как минимум, нужно получить какие-то исторические данные о том, что все продолжает работать, использоваться и приносить пользу (лишних пунктов нет). Желательно написать документацию и научить людей ловить рыбу.

Часть 2. Как надо/Как было

• Разработайте MVP

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

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

На этом этапе все заводилось и переносилось вручную. После запуска MVP мы получили подтверждение, что всё матчится с уже имеющимися объектами (CI), процессы работают и приносят пользу.

Как это выглядело:

_{Требования к MVP основываются на данных, которые вы получили после коммуникации с заказчиком, анализа его бизнес-процессов, сбора требований и т.д. Вы можете упомянуть своё готовое испытанное решение при продаже своих услуг (если вы внешний подрядчик), но не надо его реализовывать :)}

• Убедитесь, что всё работает и приносит пользу уже в виде MVP

  В нашем случае – еще и вписывается в существующие ITSM-процессы. Если нет, возможно, вы что-то делаете не так и нужно внести изменения, прежде чем идти дальше.

• Делайте следующую версию

  Мы разработали конфигурационную модель 2.0, в которой увеличили количество классов объектов и добавили несколько типов, сделали автоматизированный апдейт. Основная часть – скрипт, который работает через REST API (если что, у ServiceNow и у публичного облака N есть свои REST API). Этот скрипт:

  • Создает новые объекты

  • Выполняет обратное удаление (удалилось в публичном облаке – «удалилось» в ServiceNow, т.е. стало retired и потеряло связи с объектами)

  • Обновляет данные о текущих объектах (CPU, RAM, Storage, ID, IP, описания, связи, и т.п.)

  • Скрипт запускается раз в сутки, ночью, чтобы избежать лишней нагрузки (частота, разумеется, согласовывалась с заказчиком)

Напишите документацию, займитесь оценкой эффективности и просвещением

Мы обучили менеджмент, ИТ-отдел и отдельно первую линию поддержки.

Для справки: всё вышеперечисленное заняло у нас два календарных месяца

Часть 3. Чем все закончилось

Мы почти на 100% автоматизировали пополнение и обновление CMDB. Вручную теперь осуществляется только контроль – анализ логов апдейтов, это занимает полчаса-час в неделю.  Для сравнения: на стадии MVP тратился час в день.

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

История 2, про Change Management

Вводные

Те же самые, что и в предыдущей истории, плюс: функциональность ServiceNow используется не полностью, к ITSM-процедурам подходят формально, управление процессом изменений очень тяжеловесное. Если бы мы внедряли CM в текущие процессы “как есть”, заказчик бы никогда в этом не разобрался и не заставил себя им пользоваться. Получился бы негатив для компании, подрыв образа IT, ITSM, фрустрация.

Задача. Зачем заказчику CM

Нам нужно было адаптировать change management для новой части инфраструктуры так, чтобы заказчик мог:

1. Согласовывать изменения;

2. Иметь возможность разрабатывать и анализировать, аппрувить дизайн изменений перед самим изменением;

3. Легко и понятно хранить историю изменений;

4. Сделать систему CM понятной для пользователя и радикально улучшить ее usability.

Что мы делали

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

C одной стороны, процесс change management соблюдался, с другой участие заказчика получилось минимальным, то есть, мы добились того, к чему стремились. Если разбить действия по этапам, получается:

1. Выделили основные этапы из change-процесса;

2. Упростили change для рядового (и не только) пользователя (в “что получилось” расскажем подробнее);

3. Разделили весь процесс на две части – фронт  (конечный юзер) и бэк (мы плюс ИТ-команда заказчика), юзеру оставили минимум действий – он заполнял два поля;

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

Лучше всего результаты нашей деятельности описывает сравнение этапов участия пользователя в change management.

До. Процесс, который должен быть пройти юзер при создании Change Ticket

1. Этап инициализации: 
   

   1. Выбрать Сервис(ы), к которому относится изменение; 

   2. Определить Тип (нормальный, стандартный, emergency); 

   3. Указать риск (none, high, medium, low);

   4. Указать причину (maintenance, improvement, security, correction, etc.); 

   5. Выбрать категорию (application / infra); 

   6. Сказать, будет ли проходить изменение в рамках специфичных compliance процессов; 

   7. указать географическую зону, где выполняется изменение; 

   8. Указать все среды, к которым оно относится (Dev, QA, PRD); 

   9. Кратко описать изменение; 

   10. Детально описать изменения, отвечая на вопросы и шаблона; 

   11. Указать время начала и конца проведения изменения для каждой из сред. 
       

2. Этап анализа изменения 
   

   1. Заполнить опросник оценки рисков;

   2. Указать все ассеты, задействованные в изменении (выбрать из CMDB);

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

3. Этап одобрения 
   

   1. Initial согласование с владельцем сервиса/сервисов;

   2. Привязать запись о релизе (если есть);

   3. Заполнить опросник “operational readiness”;

   4. Получить согласование от владельца сервиса/сервисов к выполнению изменения.

4. Этап проведения изменений
   

   1. Если есть несколько шагов, каждый из них описывается отдельно.

5. Этап верификации и закрытия
   

   1. Проверка выполнения по триггерам и документация;

   2. Описание процедур принятия изменения;

   3. После выполнения изменения, верифицируем результат с юзером (acceptance).

После. Наш процесс

Юзер заполняет 2 поля: 

1. Сервис (выбирает из списка);

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

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

• План отката и анализ рисков;

• Время выполнения для каждой из сред.

После выполнения изменения верифицируем результат с юзером (acceptance).

Чем всё закончилось. Выводы

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

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

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

Предоставляйте ITIL, как будто вы предоставляете SaaS (а не IaaS, PaaS и т.д., не коробочку, шкафчик, мануал, набор рекомендаций, человекочасы), и вам воздастся!