Если посмотреть статистику поисковых запросов для ITIL/ITSM, выясняется, что чаще всего люди задаются вопросом “Что это такое?” и “Кому нужен/когда нужен/зачем нужен ITIL”. Первому вопросу посвящено множество хороших статей, на второй часто отвечают “если вы не знаете, что это такое, значит, вам это не нужно”. В этой статье мы рассказываем, как научили заказчика радоваться ITIL-у, а еще о том, как сделать ITSM c человеческим лицом для энтерпрайза  и не сойти с ума. IT Service Management – область знаний об управлении деятельностью по оказанию ИТ-услуг. ITIL (IT Infrastructure Library) – описание лучших практик по организации работы отделов, подразделений или компаний, предоставляющих ИТ-услуги. 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. Здесь могла быть драматичная и правдоподобная история о том, что мы сначала сделали неправильно, а потом раскаялись, но мы сразу всё поняли правильно:) Я всё равно расскажу, как не надо, потому что точно знаем, что кто-то до сих пор совершает некоторые из перечисленных ошибок, иногда даже все сразу. Не надо брать все типы объектов и пытаться сразу добавить их в базу CMDB под предлогом “раньше начнешь – раньше закончишь”. Почему? Как мы знаем, “данные устаревают, как только ты внес их в базу”.  Внесение информации должно занимать половины времени/сил и происходить в последнюю очередь. Сфокусируйтесь на обновлении информации в базе. Не вешайте бюрократию на конечного пользователя, это всегда плохо заканчивается.* Сюда входит “ничего не делать, пока мы не получим подробное ТЗ для всех случаев”. Возможно, это и нормально для inhouse-разработки (и то, если вы не друг бизнесу своему), но совсем не нормально для концепции ITSM.* если вы хотите, чтобы от вас все отстали с дурацкими задачами, то, конечно, вешайте! Не надо идти от реализации, которая есть у кого-то или от “учебника”. ITIL – фреймворк, перечень лучших практик, а не руководство к действию. Идите от бизнес-процессов заказчика, адаптируйте, пишите, задавайте наводящие вопросы, сокращайте. Делать одну документацию на всех. См. пункт первый: если вы хотите, чтобы люди чем-то пользовались, объясните им, как. Желательно, в понятных юзеру терминах. Бросать юзера в воду и ждать, пока он поплывет.Предположим, вы настроили всё идеально, все работает почти без участия клиента. Дело сделано? Скорее нет: как минимум, нужно получить какие-то исторические данные о том, что все продолжает работать, использоваться и приносить пользу (лишних пунктов нет). Желательно написать документацию и научить людей ловить рыбу. Разработайте MVP Мы сделали конфигурационную модель (configuration model, описание типов объектов и связей между ними, т.е. универсальную схему, которую нужно будет тиражировать, заполняя CMDB). В первом шаге мы наполняем базу по минимуму, который необходим для выполнения поставленной задачи (назначить владельцев, описать связи). На этом этапе все заводилось и переносилось вручную. После запуска MVP мы получили подтверждение, что всё матчится с уже имеющимися объектами (CI), процессы работают и приносят пользу. Как это выглядело: Требования к MVP основываются на данных, которые вы получили после коммуникации с заказчиком, анализа его бизнес-процессов, сбора требований и т.д. Вы можете упомянуть своё готовое испытанное решение при продаже своих услуг (если вы внешний подрядчик), но не надо его реализовывать :) Убедитесь, что всё работает и приносит пользу уже в виде MVP В нашем случае – еще и вписывается в существующие ITSM-процессы. Если нет, возможно, вы что-то делаете не так и нужно внести изменения, прежде чем идти дальше. Делайте следующую версию Мы разработали конфигурационную модель 2.0, в которой увеличили количество классов объектов и добавили несколько типов, сделали автоматизированный апдейт. Основная часть – скрипт, который работает через REST API (если что, у ServiceNow и у публичного облака N есть свои REST API). Этот скрипт: Создает новые объекты Выполняет обратное удаление (удалилось в публичном облаке – «удалилось» в ServiceNow, т.е. стало retired и потеряло связи с объектами) Обновляет данные о текущих объектах (CPU, RAM, Storage, ID, IP, описания, связи, и т.п.) Скрипт запускается раз в сутки, ночью, чтобы избежать лишней нагрузки (частота, разумеется, согласовывалась с заказчиком) Напишите документацию, займитесь оценкой эффективности и просвещением Мы обучили менеджмент, ИТ-отдел и отдельно первую линию поддержки. Для справки: всё вышеперечисленное заняло у нас два календарных месяца Мы почти на 100% автоматизировали пополнение и обновление CMDB. Вручную теперь осуществляется только контроль – анализ логов апдейтов, это занимает полчаса-час в неделю.  Для сравнения: на стадии MVP тратился час в день. В чем, собственно, трудность в этой и подобных ситуациях? Понять, что нужно заказчику (не только понять его ITSM процедуры, но и бизнес-процессы, сделать так, чтобы проект на всех этапах приносил пользу. Те же самые, что и в предыдущей истории, плюс: функциональность ServiceNow используется не полностью, к ITSM-процедурам подходят формально, управление процессом изменений очень тяжеловесное. Если бы мы внедряли CM в текущие процессы “как есть”, заказчик бы никогда в этом не разобрался и не заставил себя им пользоваться. Получился бы негатив для компании, подрыв образа IT, ITSM, фрустрация. Change management – процесс и набор практик, который нужен, чтобы любые изменения и обновления происходили с минимальным негативом для ИТ. Нам нужно было адаптировать change management для новой части инфраструктуры так, чтобы заказчик мог:   Согласовывать изменения; Иметь возможность разрабатывать и анализировать, аппрувить дизайн изменений перед самим изменением; Легко и понятно хранить историю изменений; Сделать систему CM понятной для пользователя и радикально улучшить ее usability. Весь дизайн и согласования мы взяли на себя, если в change description не хватало данных, мы сами все выясняли, при необходимости назначали встречи, то есть во всей этой истории мы выступали фасилитаторами.   C одной стороны, процесс change management соблюдался, с другой участие заказчика получилось минимальным, то есть, мы добились того, к чему стремились. Если разбить действия по этапам, получается: Выделили основные этапы из change-процесса; Упростили change для рядового (и не только) пользователя (в “что получилось” расскажем подробнее); Разделили весь процесс на две части – фронт  (конечный юзер) и бэк (мы плюс ИТ-команда заказчика), юзеру оставили минимум действий – он заполнял два поля; Провели информационную кампанию, провели обучение пользователей, сделали лендинг с мануалом, внутреннюю документацию в confluence. Лучше всего результаты нашей деятельности описывает сравнение этапов участия пользователя в change management. Этап инициализации:  Выбрать Сервис(ы), к которому относится изменение;  Определить Тип (нормальный, стандартный, 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 и т.д., не коробочку, шкафчик, мануал, набор рекомендаций, человекочасы), и вам воздастся!