Почему вам не нужно бояться ITIL, или как мы оптимизировали процессы для корпорации с 90к пользователей

Kate

Administrator
Команда форума

Всем привет, меня зовут Александр Колесов, я – директор направления 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 и т.д., не коробочку, шкафчик, мануал, набор рекомендаций, человекочасы), и вам воздастся!
 
Сверху