Экономия на лицензиях без потери функций: 5 сценариев

В чем проблема: расходы растут, а пользы не прибавляется

Лицензии часто дорожают даже тогда, когда нагрузка и команда не растут. Причина обычно не в том, что вы стали больше пользоваться продуктом, а в том, как он продается: меняются прайс-листы, правила продления, минимальные пакеты, а иногда и сама метрика (например, "за ядра" вместо "за сервер"). Плюс незаметно копится "зоопарк" экземпляров: тестовые стенды, резервные узлы, временные серверы под проекты.

Попытка сэкономить простым урезанием функций опасна. В какой-то момент "лишний" модуль оказывается тем, на чем держится отчетность, безопасность или интеграции. Экономия превращается в простой, ручной труд или штрафы за несоответствие требованиям.

Поэтому экономия на лицензиях без потери функций почти всегда начинается не с отключений, а с наведения порядка. На практике эффект дают изменения, которые пользователи почти не замечают: консолидация серверов, пересмотр ролей пользователей и прав доступа, оптимизация метрик лицензирования под реальную модель работы, а также отказ от неиспользуемых опций и модулей, которые включены "на всякий случай".

Быстро можно сделать базовую сверку: сопоставить закупки с фактическим использованием, собрать список владельцев систем, найти очевидные лишние лицензии и "мертвые" учетные записи. Подготовки обычно требуют консолидация и смена метрик. Например, если вы обновляете инфраструктуру и ставите более плотные по ресурсам серверы (в том числе стойковые системы уровня GSE S200), стоит заранее оценить, как это повлияет на лицензирование "за ядра", чтобы модернизация не дала обратный эффект по бюджету.

Быстрый аудит: что у вас куплено и что реально используется

Первый шаг к тому, чтобы получить экономию на лицензиях без потери функций, - перестать опираться на предположения. Почти всегда в компании одновременно живут старые договоры, новые подписки и разовые покупки. Часть лицензий "переезжает" вместе с серверами и людьми без учета.

Начните с простого инвентаря: какие продукты и редакции куплены, какие подписки активны, что уже не продлевается, но все еще появляется в счетах. Важно собрать это в одном месте (хотя бы в таблице) и сразу отметить сроки, количество и тип лицензии.

Дальше разберитесь, как именно считается лицензирование. Для одних систем это пользователи, для других - устройства, для третьих - ядра или сокеты. Ошибка здесь стоит дорого: можно платить "по ядрам", хотя нагрузка давно ушла на меньший кластер. Или держать лицензии "по пользователям", хотя половина учетных записей неактивна.

Отдельно зафиксируйте среды. Прод, тест, обучение, резерв (DR) часто лицензируются по-разному. Иногда тестовые контуры можно перевести на другой режим, если они не обслуживают реальную работу.

Чтобы аудит был быстрым и не превратился в расследование, заранее соберите пять вещей: реестр закупок (договор, редакция, количество, срок), выгрузку из консоли или портала вендора по активным лицензиям, данные об использовании (активные пользователи, реально задействованные узлы), карту сред (prod/test/DR) с привязкой к серверам и список владельцев систем, которые подтвердят необходимость.

Простой пример: у вас есть CRM, файловые сервисы и несколько виртуальных хостов. Попросите владельца CRM подтвердить реальное число активных пользователей за 30-90 дней, а администратора инфраструктуры - сколько ядер и узлов реально занято под эту систему. Так вы быстро увидите разницу между "куплено" и "используется" и поймете, где экономия безопасна.

Сценарий 1: консолидация серверов - пошаговый план

Консолидация серверов часто дает быструю экономию: вы уменьшаете число физических хостов, а вместе с ними - лицензии, поддержку и операционные затраты. Важно сделать это так, чтобы не потерять производительность и не попасть на рост стоимости из-за метрик лицензирования. Это один из самых понятных способов снизить расходы без урезания возможностей.

Сначала выберите кандидатов на объединение. Обычно это серверы с низкой загрузкой, одинаковыми ролями (несколько небольших приложений или вспомогательных сервисов) и устаревшим железом, которое все равно планировали обновлять.

Затем проверьте совместимость и правила лицензирования при виртуализации. У одних вендоров лицензия привязана к числу ядер на хосте, у других - к количеству виртуальных машин, пользователей или устройств. Типичная ловушка выглядит так: вы переносите все на более мощный сервер, а лицензии считаются по ядрам, и итоговая цена растет.

Практичный план:

• Соберите факты по текущим серверам: средняя и пиковая загрузка CPU/RAM/диска, роли, критичность.
• Сверьте требования приложений и ограничения виртуализации (поддерживаемые версии ОС, драйверов, кластеров).
• Нарисуйте целевую схему: меньше хостов, понятные пулы ресурсов, запас под рост и обновления.
• Перенесите сервисы по очереди и подтвердите результат тестами (пиковые сценарии, бэкапы, окна обслуживания).
• Пересчитайте лицензии по новой схеме и зафиксируйте решение документально.

Небольшой ориентир: если в организации было 8 разрозненных серверов под "малые" сервисы, их часто удается собрать в 2-3 хоста с нормальной виртуализацией. Но перед финальным решением обязательно посчитайте лицензии по ядрам и правилам кластеров, особенно если планируете ставить новые высокоплотные серверы.

Сценарий 2: пересмотр ролей пользователей и прав доступа

Часто лицензии покупают "на всякий случай": выдают максимальную роль всем, кто хоть иногда открывает систему. В итоге растут счета, а функций по факту используют меньше половины. Пересмотр ролей пользователей помогает сократить расходы без конфликтов с бизнесом, если действовать по данным.

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

Дальше проверьте "широкие" права. Переплата часто сидит в ролях типа Power User или Admin, которые выдали из-за разового проекта. Для большинства задач хватает ограниченной роли с точечными разрешениями.

Практический порядок действий:

• Снимите список активных пользователей и их реальные действия за 30-90 дней.
• Создайте 3-5 типовых ролей под задачи и привяжите к ним лицензии.
• Найдите общие учетные записи, временные доступы и "вечных подрядчиков".
• Настройте процесс выдачи и отзыва прав при переводе, увольнении и выходе из отпуска.
• Зафиксируйте правило: доступ = функция, за которую платим.

Отдельно проверьте временные доступы. Частая ошибка: "на неделю" превращается в год, потому что никто не назначен ответственным за отзыв.

Небольшой пример: в учебном центре 40 сотрудников имели расширенные права из-за старого проекта. После разделения на роли 25 человек перевели на базовый уровень, 10 оставили "редактирование", 5 - админы. Люди продолжили работать как раньше, а переплата ушла в первый же цикл продления.

Сценарий 3: оптимизация метрик - ядра, пользователи, устройства

Многие переплачивают не потому, что "много используют", а потому что неправильно считают. У одного и того же продукта метрика может быть разной: по ядрам CPU, по пользователям, по устройствам, по инстансам или по кластеру. Оптимизация метрик лицензирования начинается с простого вопроса: что именно является "единицей учета" в вашем контракте и в настройках системы.

Сверьте документы и реальность. Бывает, что в учете числятся 64 ядра из-за запаса "на будущее", а фактически сервис крутится на меньшем хосте или использует ограниченное число vCPU. Или лицензия должна считаться по физическим ядрам хоста, но в отчетах почему-то фигурируют ядра всего кластера.

Дальше проверьте, можно ли технически зафиксировать границы, чтобы счет не рос сам по себе. Обычно смотрят на лимиты vCPU и привязку к конкретным хостам (если правила это допускают), реальные границы кластера (какие узлы входят в лицензируемый контур), количество инстансов и окружений (prod, test, dev, DR), учет пользователей (активные, временные, сервисные, дубли) и источники отчетов (CMDB, AD, гипервизор, консоль продукта).

После этого сравните два сценария: "по пользователям/устройствам" и "по ресурсам". Если доступ нужен 30 сотрудникам, а сервер мощный и с запасом, пользовательская модель часто дешевле. Если пользователей сотни, но нагрузка стабильна и ограничена, выгоднее вариант по ядрам или по хостам.

Пример: организация обновляет серверы и ставит более мощные CPU. Если лицензия по ядрам, стоимость может вырасти без роста функций. Иногда помогает перенести сервис на отдельные узлы с меньшим числом ядер или четко выделить лицензируемый пул. При подборе железа под такие ограничения полезно заранее согласовать конфигурацию с интегратором и производителем, например при поставках серверов уровня GSE S200 Series.

Закрепите выбранный подход в коротком документе: какая метрика, какие источники данных, какие лимиты настроены, кто согласует изменения. Иначе при расширении инфраструктуры экономия исчезнет за один квартал.

Сценарий 4: отказ от неиспользуемых опций и модулей

Частая причина лишних затрат - платные опции и модули, которые когда-то подключили "на всякий случай", а потом забыли. Со временем они начинают жить как подписка по умолчанию, и вы платите за функции, которые не участвуют ни в одном процессе.

Соберите единый список всего, что входит в договор, и отдельно - что реально активировано в системе. Важно фиксировать не только "куплено", но и "включено": иногда функции активны по умолчанию, хотя команда ими не пользуется.

Чтобы найти кандидатов на отключение, ответьте на несколько вопросов. Какие модули не использовались последние 60-90 дней (по логам, отчетам или статистике)? Какие опции дублируют другие инструменты, уже принятые в компании? Что включено по умолчанию, но не требуется политиками и регламентами? Есть ли функции, которые использует 1-2 человека без понятного эффекта для бизнеса? Какие возможности были нужны только для проекта, который уже завершен?

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

Выводите такие вещи поэтапно: сначала запрет на новые подключения и настройки, затем тестовый период с наблюдением, и только потом полное отключение и корректировка документации. Так отказ от неиспользуемых опций дает экономию на лицензиях без потери функций.

Пример: в организации закупили расширенный модуль отчетности и отдельный аддон мониторинга, но команда уже использовала встроенные отчеты и корпоративный мониторинг. После согласования модуль вывели из эксплуатации, оставив только критичные отчеты. Экономия появилась сразу, а пользователи почти ничего не заметили.

Сценарий 5: оптимизация резервирования, теста и DR без переплат

В резервировании и DR (аварийном восстановлении) деньги часто уходят не на защиту, а на привычку держать все включенным и лицензированным как продакшен. При этом бизнесу обычно важен не "второй продакшен", а понятные сроки восстановления и приемлемая потеря данных.

Сначала разделите системы по критичности. Для части сервисов нужна высокая доступность (почти без простоя), а для остальных достаточно резерва с ручным запуском.

Проверьте, как поставщик считает лицензии для failover, резервных узлов и DR-площадки. Часто правила позволяют иметь "холодный" или "тёплый" резерв с меньшими требованиями, но только если соблюдены условия: как часто запускается резерв, сколько времени работает, где хранится копия.

Быстро помогает короткий набор проверок:

• Какие RTO и RPO реально нужны бизнесу для каждой группы систем.
• Должен ли DR-сайт работать постоянно или достаточно включения по событию.
• Можно ли выделить отдельную тестовую и учебную среду без продакшен-лицензий.
• Какие стенды включены 24/7 "на всякий случай" и когда их последний раз использовали.
• Кто отвечает за документ "что считаем продакшеном", чтобы потом не было споров на аудите.

Отдельная частая переплата - тест и обучение. Если тестовые среды живут годами и на них крутятся те же опции, что и в бою, вы платите как за реальную нагрузку. Лучше согласовать график: когда стенд нужен, а когда его можно выключать, и какие функции там действительно необходимы.

Пример: организация держала DR-серверы включенными круглосуточно, хотя по регламенту допускался простой до 8 часов. После пересмотра требований DR перевели в "тёплый" режим, а часть тестовых машин стали включать только на время релизов. Железо осталось тем же (например, на типовых серверах уровня GSE S200), а лицензируемый объем заметно сократился.

Пример из практики: как организация сократила лицензии без боли

Средняя региональная организация (около 600 сотрудников) подошла к продлению ПО и увидела, что счета растут каждый год, хотя новые функции почти не появляются. Инфраструктура развивалась "как получится": под каждый проект ставили отдельный сервер, а права пользователей выдавали "с запасом", чтобы не мешать работе.

Исходно у них было 18 разрозненных физических серверов, несколько тестовых стендов, которые давно стали "полубоевыми", и смешанные роли: одни и те же люди числились и админами, и разработчиками, и "расширенными пользователями". В итоге лицензии считались по максимальным метрикам, а часть опций была включена просто потому, что когда-то пригодилась одному отделу.

Сначала провели инвентаризацию: какие системы реально нужны круглосуточно, какие можно переводить в режим по требованию, а где достаточно урезанных прав. Затем объединили нагрузки и перенесли сервисы на меньшее число хостов, оставив резерв по производительности. В таких проектах часто обновляют узлы на современные стойковые серверы, но решает не "железо", а порядок в ролях и метриках.

Самый заметный эффект дал пересчет. Они разделили роли и убрали "универсальные" учетные записи, пересчитали метрики лицензирования по фактическим ядрам, пользователям и устройствам (где это применимо), отделили тест от продакшена и закрепили правила запуска тестовых сред, а также отключили неиспользуемые модули и опции, оставив только нужные командам.

Результат: минус 25-35% лицензий при тех же функциях и прежнем SLA. Поддержка не получила вал обращений, потому что изменения делали поэтапно и заранее согласовали, кто и что реально должен делать в системе.

Чтобы экономия не исчезла через 3 месяца, они закрепили это документами: матрица ролей и прав доступа (кто, зачем и на какой срок), реестр лицензий и привязка к владельцам сервисов, правила для теста, пилотов и DR (когда включаем и кто согласует), перечень разрешенных опций и порядок запроса новых, а также календарь квартального пересмотра: роли, ядра, активные пользователи, лишние среды.

Типичные ошибки и ловушки, которые съедают экономию

Самая частая причина провала - попытка сделать экономию на лицензиях без потери функций "на глаз". Кажется, что модуль не нужен, серверов слишком много, а пользователей можно урезать. А потом выясняется, что часть функций завязана на редкие, но критичные сценарии, и откат стоит дороже, чем продление.

Ошибки, которые встречаются чаще всего

Обычно деньги "утекают" не из-за одной большой проблемы, а из-за нескольких мелких, которые никто не довел до конца:

• Решения принимают без подтвержденных данных об использовании (по отчетам, логам, мониторингу, заявкам).
• Консолидируют серверы и виртуальные машины, не проверив правила лицензирования для кластеров и миграций.
• Отключают опции, которые почти не используются, но нужны в пиковые периоды (закрытие месяца, отчетность, сезонные нагрузки).
• Не чистят "мертвые" учетные записи и сервисных пользователей, и за них платят годами.
• Меняют права, роли и схемы доступа, но не фиксируют это документально, и через полгода все снова разрастается.

Простой пример: в организации отключили модуль, потому что "им пользуются два человека". Но эти два человека запускали процедуру раз в квартал, и без нее останавливались согласования. В итоге модуль вернули в спешке, а поставщик выставил счет за срочное восстановление поддержки.

Как не потерять экономию через 3 месяца

Рабочее правило простое: сначала измеряем, потом меняем. Перед сокращением проверьте три вещи: кто использует, когда использует и что будет, если убрать.

Если вы одновременно обновляете инфраструктуру, удобно связать оптимизацию с планом по серверам и поддержке. Например, при поставке новых серверов для виртуализации (в том числе локального производства, как у GSE.kz) проще заранее продумать размещение ролей и закрепить лицензирование под выбранную архитектуру.

И оформляйте изменения. Короткий документ с датой, причиной, владельцем и правилами возврата экономит время и защищает от хаоса при росте команды.

Короткий чеклист перед тем, как продлевать лицензии

Продление лицензий часто делают по инерции: берут прошлогодние цифры и добавляют "про запас". Чтобы получить экономию на лицензиях без потери функций, лучше остановиться на 1-2 недели и пройтись по проверкам.

Соберите в одном месте базовую картину. Если в компании нет "единого источника правды", спор о цифрах съест все время, и вы все равно купите лишнее:

• Есть актуальная таблица по каждому продукту: метрика (ядра, пользователь, устройство), количество, срок, ответственный владелец.
• Понятно, где стоит софт: прод, тест, резерв, филиалы, временные стенды.
• По пользователям есть список ролей и групп, а не просто "все сотрудники".
• Отдельно отмечены опции и модули, которые включены, но не используются.
• Есть черновик расчета: сколько платим сейчас и сколько будет после изменений.

Дальше проверьте процессы, а не только цифры. Экономия не удержится, если доступы не отзываются, а тестовые среды тихо превращаются в прод:

• Работает отзыв доступа: сотрудник ушел или сменил роль, права снимаются по заявке или автоматически.
• Тест и резерв отделены правилами: кто имеет доступ, какие лимиты, что считается failover и на сколько времени.
• Консолидация оценена по нагрузке и лицензированию, а не "на глаз" (CPU, память, пики, рост на 12 месяцев).
• Лишние опции отключены и согласованы с владельцами процессов, чтобы не "сломать" отчет или интеграцию.
• Экономия посчитана дважды: до закупки (план) и после внедрения (факт по счетам и использованию).

Мини-сценарий для самопроверки: если вы планируете обновить серверы и уплотнить виртуалки, сначала посчитайте, как изменится лицензирование по ядрам. Иногда более мощные узлы дают меньшую стоимость владения, но только если вы заранее знаете, какие роли и модули реально нужны. В проектах по модернизации инфраструктуры это проще делать с командой, которая отвечает и за железо, и за интеграцию, и за поддержку 24/7.

Если после чеклиста остались "серые зоны", продлевать рано. Сначала закройте спорные места, иначе переплата просто переедет в новый контракт.

Следующие шаги: как закрепить результат на 90 дней

Экономия на лицензиях без потери функций держится только тогда, когда у нее есть владелец и регулярный процесс. Начните не со всех сценариев сразу, а с 1-2, где эффект быстрый и риск минимальный. Часто это пересмотр ролей пользователей и отказ от неиспользуемых опций.

Соберите план на 90 дней и заранее договоритесь, кто принимает решения: ИТ, безопасность, финансы и владельцы систем.

План на 90 дней

• Дни 1-14: короткий аудит и выбор 1-2 сценариев (что покупаем, что реально используется, где переплата по метрикам).
• Дни 15-45: внедрение изменений (права и роли, отключение опций, корректировка метрик и договоров, согласование с безопасностью).
• Дни 46-75: проверка последствий (не сломались ли процессы, хватает ли прав, нет ли роста обращений в поддержку).
• Дни 76-90: фиксация правил (кто и как заказывает доступ, как считаем метрики, что проверяем перед продлением).

Если у вас планируется консолидация серверов или обновление инфраструктуры, сверьте метрики заранее. Частая ошибка - купить новые серверы и только потом понять, что лицензирование по ядрам, сокетам или хостам стало дороже. При переносе нескольких приложений на более мощный хост заранее посчитайте, как изменится требование по лицензиям, и выберите конфигурацию, которая не создает лишних "лицензионных ядер".

Что закрепить как правило

• У одного человека есть роль владельца лицензий и календарь пересмотра (например, раз в месяц).
• Любой новый доступ оформляется через выбранную роль, а не "как попросили".
• Раз в квартал проверяются неиспользуемые опции и тестовые среды, чтобы они не превращались в постоянные.
• Перед закупкой серверов или миграцией сверяются метрики лицензирования и план размещения.

Если ресурсов не хватает, подключайте системного интегратора. Иногда удобно, когда поставка серверов, расчет метрик и дальнейшая поддержка ведутся одним планом. Например, GSE.kz (gse.kz) совмещает производство серверов и системную интеграцию, а также обеспечивает круглосуточную техническую поддержку через сервисную сеть по Казахстану.