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

Предисловие

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

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

ITSM

IT Service Management – область знаний об управлении деятельностью по оказанию ИТ-услуг. ITIL (IT Infrastructure Library) – описание лучших практик по организации работы отделов, подразделений или компаний, предоставляющих ИТ-услуги.

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

CMDB

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

Вводные

Заказчик – крупная международная корпорация с присутствием в России (а также в 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), процессы работают и приносят пользу.

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

Схема первой версии Configuration model, с которой мы начали. Эти объекты создавались вручную.  Проектов – десятки. Серверов – сотни, поэтому заводили не все – выборочно для тестирования «как пойдёт».
Схема первой версии Configuration model, с которой мы начали. Эти объекты создавались вручную.  Проектов – десятки. Серверов – сотни, поэтому заводили не все – выборочно для тестирования «как пойдёт».

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

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

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

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

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

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

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

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

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

Число проектов осталось тем же, что и в MVP, но серверов и прочих инстансов – сотни. Заведены все, у всех автоапдейты, автоудаление, и т.д. Остальные объекты тоже заводятся автоматически.
Число проектов осталось тем же, что и в MVP, но серверов и прочих инстансов – сотни. Заведены все, у всех автоапдейты, автоудаление, и т.д. Остальные объекты тоже заводятся автоматически.

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

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

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

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

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

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

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

Вводные

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

Change management

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

Задача. Зачем заказчику 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. Сервис (выбирает из списка);

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

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

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

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

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

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

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

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

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

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

Комментарии (2)


  1. FinGeoMa
    25.01.2022 09:22
    +1

    Спасибо. Все так четко поэтапно и аргументированно расписано. Сразу понятно '"кто на ком стоял" и почему. И главное, вы очень правильно определили главное: нужно понять бизнес заказчика.

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

    Я намедни читала здесь на Хабре статью девочки- бизнес-аналитика диджитал-агентства, тратя по полчаса на каждый абзац, чтобы понять: что они в итоге сделали-то?! ???? Пару дней ходила с ощущением того, что сильно отстала от современной жизни и надо с этим что-то срочно делать. А почитав вашу статью, успокоилась. Так что, ещё раз большое спасибо за статью. ????


    1. KolesOFF Автор
      25.01.2022 14:16

      Спасибо вам за отзыв!