Всем привет, меня зовут Александр Колесов, я – директор направления 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 серверов, а не три сотни.
Проблемы, сопутствующие реализации, можно условно разделить на два блока – технические и организационные/управленческие, причем, как мы вскоре увидим, организационные проблемы оказались куда более тяжеловесными.
Организационные проблемы
Бюрократия в процессах. Публичная компания, отчетность перед гос. инстанциями + коммуникация с азиатским ИТ-офисом, нельзя просто так взять и что-то согласовать;
Заказчик использует ITSM систему – ServiceNow, в которую занесены в основном ИТ ассеты, находящиеся в своём периметре. Модели, описывающей облачные ассеты, нет. У нас нет доступа к администрированию ServiceNow, соответственно, все требуемые изменения происходят по запросу, в рамках плановых релизов. Учитывая сжатые временные рамки, нам пришлось использовать текущий функционал системы, в частности, нам был не доступен встроенные механизм автодискавери объектов.
Технические проблемы
Отсутствует согласованная CMDB модель, подходящая для облачных инстансов;
Нужно наполнить CMDB данных об ИТ-ассетах публичного облака, вписать их в существующий ИТ-ландшафт, определить связи и владельцев при том, что у клиента нет стандартизированного решения этой задачи;
Модифицированная платформа публичного облака (openstack), к которой не подойдут интеграционные решения "из коробки";
Внести несколько тысяч объектов (CI) в CMDB, включая виртуальные сервера, PaaS инстансы, DNS-имена, SSL-сертификаты и другие, а также связать их между собой и с существующим объектами CMDB.
Как мы это реализовывали
Часть 1. Как не надо. Гуманистическая
Здесь могла быть драматичная и правдоподобная история о том, что мы сначала сделали неправильно, а потом раскаялись, но мы сразу всё поняли правильно:) Я всё равно расскажу, как не надо, потому что точно знаем, что кто-то до сих пор совершает некоторые из перечисленных ошибок, иногда даже все сразу.
Не надо брать все типы объектов и пытаться сразу добавить их в базу CMDB под предлогом “раньше начнешь – раньше закончишь”. Почему? Как мы знаем, “данные устаревают, как только ты внес их в базу”. Внесение информации должно занимать половины времени/сил и происходить в последнюю очередь. Сфокусируйтесь на обновлении информации в базе.
Не вешайте бюрократию на конечного пользователя, это всегда плохо заканчивается.* Сюда входит “ничего не делать, пока мы не получим подробное ТЗ для всех случаев”. Возможно, это и нормально для inhouse-разработки (и то, если вы не друг бизнесу своему), но совсем не нормально для концепции ITSM.
* если вы хотите, чтобы от вас все отстали с дурацкими задачами, то, конечно, вешайте!Не надо идти от реализации, которая есть у кого-то или от “учебника”. ITIL – фреймворк, перечень лучших практик, а не руководство к действию. Идите от бизнес-процессов заказчика, адаптируйте, пишите, задавайте наводящие вопросы, сокращайте.
Делать одну документацию на всех. См. пункт первый: если вы хотите, чтобы люди чем-то пользовались, объясните им, как. Желательно, в понятных юзеру терминах.
Бросать юзера в воду и ждать, пока он поплывет.Предположим, вы настроили всё идеально, все работает почти без участия клиента. Дело сделано? Скорее нет: как минимум, нужно получить какие-то исторические данные о том, что все продолжает работать, использоваться и приносить пользу (лишних пунктов нет). Желательно написать документацию и научить людей ловить рыбу.
Часть 2. Как надо/Как было
Разработайте MVP
Мы сделали конфигурационную модель (configuration model, описание типов объектов и связей между ними, т.е. универсальную схему, которую нужно будет тиражировать, заполняя CMDB).
В первом шаге мы наполняем базу по минимуму, который необходим для выполнения поставленной задачи (назначить владельцев, описать связи).
На этом этапе все заводилось и переносилось вручную. После запуска MVP мы получили подтверждение, что всё матчится с уже имеющимися объектами (CI), процессы работают и приносят пользу.
Как это выглядело:
![Схема первой версии Configuration model, с которой мы начали. Эти объекты создавались вручную. Проектов – десятки. Серверов – сотни, поэтому заводили не все – выборочно для тестирования «как пойдёт». Схема первой версии Configuration model, с которой мы начали. Эти объекты создавались вручную. Проектов – десятки. Серверов – сотни, поэтому заводили не все – выборочно для тестирования «как пойдёт».](https://habrastorage.org/getpro/habr/upload_files/3f3/94f/f62/3f394ff62a578814e3c30398cd72edc6.png)
Требования к MVP основываются на данных, которые вы получили после коммуникации с заказчиком, анализа его бизнес-процессов, сбора требований и т.д. Вы можете упомянуть своё готовое испытанное решение при продаже своих услуг (если вы внешний подрядчик), но не надо его реализовывать :)
Убедитесь, что всё работает и приносит пользу уже в виде MVP
В нашем случае – еще и вписывается в существующие ITSM-процессы. Если нет, возможно, вы что-то делаете не так и нужно внести изменения, прежде чем идти дальше.
Делайте следующую версию
Мы разработали конфигурационную модель 2.0, в которой увеличили количество классов объектов и добавили несколько типов, сделали автоматизированный апдейт. Основная часть – скрипт, который работает через REST API (если что, у ServiceNow и у публичного облака N есть свои REST API). Этот скрипт:
Создает новые объекты
Выполняет обратное удаление (удалилось в публичном облаке – «удалилось» в ServiceNow, т.е. стало retired и потеряло связи с объектами)
Обновляет данные о текущих объектах (CPU, RAM, Storage, ID, IP, описания, связи, и т.п.)
Скрипт запускается раз в сутки, ночью, чтобы избежать лишней нагрузки (частота, разумеется, согласовывалась с заказчиком)
![Число проектов осталось тем же, что и в MVP, но серверов и прочих инстансов – сотни. Заведены все, у всех автоапдейты, автоудаление, и т.д. Остальные объекты тоже заводятся автоматически. Число проектов осталось тем же, что и в MVP, но серверов и прочих инстансов – сотни. Заведены все, у всех автоапдейты, автоудаление, и т.д. Остальные объекты тоже заводятся автоматически.](https://habrastorage.org/getpro/habr/upload_files/3aa/7d9/fe4/3aa7d9fe494a2dabc3b8cc2703f55bcf.png)
Напишите документацию, займитесь оценкой эффективности и просвещением
Мы обучили менеджмент, ИТ-отдел и отдельно первую линию поддержки.
Для справки: всё вышеперечисленное заняло у нас два календарных месяца
Часть 3. Чем все закончилось
Мы почти на 100% автоматизировали пополнение и обновление CMDB. Вручную теперь осуществляется только контроль – анализ логов апдейтов, это занимает полчаса-час в неделю. Для сравнения: на стадии MVP тратился час в день.
В чем, собственно, трудность в этой и подобных ситуациях? Понять, что нужно заказчику (не только понять его ITSM процедуры, но и бизнес-процессы, сделать так, чтобы проект на всех этапах приносил пользу.
История 2, про Change Management
Вводные
Те же самые, что и в предыдущей истории, плюс: функциональность ServiceNow используется не полностью, к ITSM-процедурам подходят формально, управление процессом изменений очень тяжеловесное. Если бы мы внедряли CM в текущие процессы “как есть”, заказчик бы никогда в этом не разобрался и не заставил себя им пользоваться. Получился бы негатив для компании, подрыв образа IT, ITSM, фрустрация.
Change management
Change management – процесс и набор практик, который нужен, чтобы любые изменения и обновления происходили с минимальным негативом для ИТ.
Задача. Зачем заказчику CM
Нам нужно было адаптировать change management для новой части инфраструктуры так, чтобы заказчик мог:
Согласовывать изменения;
Иметь возможность разрабатывать и анализировать, аппрувить дизайн изменений перед самим изменением;
Легко и понятно хранить историю изменений;
Сделать систему CM понятной для пользователя и радикально улучшить ее usability.
Что мы делали
Весь дизайн и согласования мы взяли на себя, если в change description не хватало данных, мы сами все выясняли, при необходимости назначали встречи, то есть во всей этой истории мы выступали фасилитаторами.
C одной стороны, процесс change management соблюдался, с другой участие заказчика получилось минимальным, то есть, мы добились того, к чему стремились. Если разбить действия по этапам, получается:
Выделили основные этапы из change-процесса;
Упростили change для рядового (и не только) пользователя (в “что получилось” расскажем подробнее);
Разделили весь процесс на две части – фронт (конечный юзер) и бэк (мы плюс ИТ-команда заказчика), юзеру оставили минимум действий – он заполнял два поля;
Провели информационную кампанию, провели обучение пользователей, сделали лендинг с мануалом, внутреннюю документацию в confluence.
Лучше всего результаты нашей деятельности описывает сравнение этапов участия пользователя в change management.
До. Процесс, который должен быть пройти юзер при создании Change Ticket
Этап инициализации:
Выбрать Сервис(ы), к которому относится изменение;
Определить Тип (нормальный, стандартный, emergency);
Указать риск (none, high, medium, low);
Указать причину (maintenance, improvement, security, correction, etc.);
Выбрать категорию (application / infra);
Сказать, будет ли проходить изменение в рамках специфичных compliance процессов;
указать географическую зону, где выполняется изменение;
Указать все среды, к которым оно относится (Dev, QA, PRD);
Кратко описать изменение;
Детально описать изменения, отвечая на вопросы и шаблона;
Указать время начала и конца проведения изменения для каждой из сред.
Этап анализа изменения
Заполнить опросник оценки рисков;
Указать все ассеты, задействованные в изменении (выбрать из CMDB);
Разработать дополнительную документацию для подготовки (в зависимости от выбранных выше полей) и приложить, включая планы отката изменения и ссылки на DR сценарии.
Этап одобрения
Initial согласование с владельцем сервиса/сервисов;
Привязать запись о релизе (если есть);
Заполнить опросник “operational readiness”;
Получить согласование от владельца сервиса/сервисов к выполнению изменения.
Этап проведения изменений
Если есть несколько шагов, каждый из них описывается отдельно.
Этап верификации и закрытия
Проверка выполнения по триггерам и документация;
Описание процедур принятия изменения;
После выполнения изменения, верифицируем результат с юзером (acceptance).
После. Наш процесс
Юзер заполняет 2 поля:
Сервис (выбирает из списка);
Текстовое описание того, что требуется сделать. При необходимости прикладываются шаблоны или документация.
Все остальные шаги выполняет внутренний ИТ, в структуру которого мы временно включаемся. К юзеру выходим с запросом об увеличении бюджета (если требуется), за согласованием плана проведения изменения, включающим:
План отката и анализ рисков;
Время выполнения для каждой из сред.
После выполнения изменения верифицируем результат с юзером (acceptance).
Чем всё закончилось. Выводы
Change менеджмент стал использоваться, заказчик был счастлив, поддержка обучена, процессы запущены, изменения стали происходить быстрее в 5 раз.
Важно помнить, что ITIL – фреймворк/набор рекомендаций. Вы можете применять его, сокращать и дополнять как угодно, пока это не вступает в противоречие со здравым смыслом. Основной вызов – разобраться в бизнесе заказчика. Идите от потребностей и не усложняйте.
Если вы - внутренний отдел IT, которому “сверху” пришло распоряжение о внедрении ITSM, в принципе, все рекомендации остаются теми же – идти от задач компании, а не от себя и не от теоретического понимания процессов. Помогать, а не мешать – хотя никто в здравом уме вам не посоветует обратного.
Предоставляйте ITIL, как будто вы предоставляете SaaS (а не IaaS, PaaS и т.д., не коробочку, шкафчик, мануал, набор рекомендаций, человекочасы), и вам воздастся!