Портал №1 по управлению цифровыми
и информационными технологиями

Как внедрять управление лицензиями ПО

Опубликовано 25 сентября 2016
Рубрики: CMDB, конфигурации и активы
Комментарии

software-license-clipart-1Знаю-знаю, миллион статей написан. Сейчас начнёте, как в известном фильме, пальцы загибать: "это – раз, это – два". А я просто хочу наблюдениями поделиться. В очередной раз довелось решать данную задачу, благо могучий OMNITRACKER хорошо подходит для реализации сложносочинённой логики, предназначенной для разных жизненных и не очень ситуаций.

Думаю, не открою вам великой тайны, если скажу, что управление лицензиями работает, если есть тот, кто этим управлением живёт! Не как делом всей жизни, конечно, но близко к тому – как повседневной обязанностью. Всем, конечно, хочется, чтобы "оно там как-то само всё учитывало". В том числе правила лицензирования отдельных вендоров (один только Оракул чего стоит). Но, как показывает практика, без ручного контроля и, частично, обработки, чуда не произойдёт. Не увидим мы волшебный отчёт по использованию лицензий, в котором всё будет актуально. Можно, конечно, попробовать покивать на супер-крутые софты, которые это всё делают буквально по щелчку пальцев. Но не знаю, как у вас, а у меня что-то туго с рабочими примерами. Они, вроде бы, есть, но почему-то почти никогда нельзя вживую посмотреть. Зато случаи, когда внедряли-внедряли, да и бросили, очень даже есть. А вот то, что мы делаем на базе OMNITRACKER, живёт и работает.

А делаем мы следующее:

  • прописываем процедуры учёта приобретения, использования и освобождения лицензий;
  • обеспечиваем в OMNITRACKER нужный функционал для учёта списка ПО, приобретённых лицензий и фактов установки ПО на компьютерах и серверах;
  • налаживаем интеграцию со сканерами сети, "отдающими" информацию об установленном ПО.

На стороне OMNITRACKER возникает проблема – как отсеять ПО, которое контролировать не нужно, а такого подавляющее большинство. Для этого в системе ведём не просто список ПО, а ещё таблицу соответствия названий ПО в OMNITRACKER и в данных сканера. Здесь возникает первая точка, где необходимо вмешательство человека – названия, возвращаемые сканером, далеко не всегда можно автоматически отнести к тому или иному программному продукту. Необходимо регулярно разбирать кучку вручную. А наличие такой таблицы позволяет нам учитывать только факты установки софта, который необходимо лицензировать (мы же про учёт лицензий говорим, и не всего установленного ПО).

Дальше мы настраиваем интеграцию со сканером и ежедневно вытягиваем из него данные по установленному на компьютерах ПО. "Пропускаем" эти данные через нашу таблицу соответствия, а затем проверяем, есть ли уже в системе зарегистрированный факт использования лицензии данного продукта на конкретном компьютере. Если нет – создаём. И тут возникает вторая точка, где требуется вмешательство специально обученного человека. Лицензии ведь бывают разные. Не "чёрные-белые-красные", конечно, но разных типов – на установку, на процессор или два, на ядро или восемь, на подключение и так далее. Что важно – у ряда типов лицензий есть коэффициент. Например, одна лицензия покрывает два процессора. То есть если у вас в сервере стоит 8 процессоров, вам понадобится 4 такие лицензии, а не восемь. А что ещё важнее – сканер нам не скажет, какого типа лицензия. Он об этом ничего не знает. Соответственно, созданные автоматически факты использования лицензий надо обрабатывать вручную – проставлять тип лицензий, чтобы на выходе получить корректный отчёт. И это должен кто-то делать! И сразу возникает вопрос – а оно ему надо?

Я вам обещал поделиться наблюдениями? Извольте. Основное наблюдение следующее: наиболее правильный подход к внедрению – постановка учёта тех лицензий, которые УЖЕ учитываются. Неважно, как, – в excel или в какой-то поделке. Если у людей нет задачи и потребности учитывать что-то ещё, они этого делать не будут. В итоге идея зачахнет на корню. Надо "укладывать" в процессы и автоматизацию только то, что реально наболело. По моим наблюдениям, это могут быть несколько разные вещи. Кому-то принципиально разобраться с учётом ПО от Microsoft, полученного по подписке, кому-то – с кучей фотошопов и прочего "приклада". Что характерно – серверный софт редко попадается в списке приоритетов.

Итак, возвращаясь к вопросу в теме статьи, как же внедрять управление лицензиями ПО?

Ответ включает в себя набор пунктов:

  • "есть по частям", как и подобает поступать со слоном; не пытайтесь сразу получить в системе абсолютно все виды лицензий, вы в них сначала утонете, а потом бросите это бестолковое занятие; потом через год-два будете заново внедрять;
  • ещё до проекта распределить роли; назначить главного пастуха; определиться, какую информацию могут и будут вносить инженеры;
  • рассматривать отчётность по управлению лицензиями на регулярной основе.
«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 2

  • Андрей другой

    Первое, с чем полностью согласен – все это будет работать только если будет организован ПРОЦЕСС управления лицениями – процес будет описан(формализован), будут опреденены роли и на эти роли будут назначены люди, для которых   управление лицензиями будет ОСНОВНОЙ работой, а не факультативным занятием в свободное от работы время. То, что особо нечего посмотреть связано не с недостатками продуктов, а с отсутствием процессов. 

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

    На рынке уже давно есть решения(по крайне мере западные), где вопросы привязки сигнатур(это то, что обнаруживают сканеры) к продуктам (это то, у чего есть part number, указазнный в лицензионных документах) не только решены, но еще и поддерживаются вендором в актуальном состоянии. Так же решены и другие вещи, специфичекие для вопроса учета – лицензионное покрытие предыдущих версий, upgrade, поддержка и т.д. Есть механизмы автоматического получения информации об использовании ПО, которую не сообщают сканеры – конкурентные сессии к серверу, на пример.

    В дополнение – ISO 19770-1 это не только про процесс учета установленного ПО, там еще куча дополнительных процессов.

  • Артем Мукосеев

    Андрей,

    Прошу прощения, что сразу не ответил!

    Вы правы, рекламный слоган, пожалуй, был лишним. Основная идея заключалась в том, чтобы поделиться собственным опытом, который во многом опирается на упомянутую систему.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;