Сравнение моделей лицензирования: per user, device, core, server

Зачем разбираться в моделях лицензирования

Сравнение моделей лицензирования важно не только для бухгалтерии. Оно определяет, за что именно вы платите: право для человека (per user), для устройства (per device), для сервера (per server) или за вычислительную мощность по ядрам (per core). Ошибка здесь обычно заканчивается переплатой или спором на проверке.

Одна и та же система может стоить по-разному в зависимости от того, как вы ей пользуетесь. Простой пример: в офисе 30 сотрудников работают посменно за 10 общих ПК. При per user вы платите за 30, при per device - за 10. А если речь о серверной части с виртуальными машинами и растущей нагрузкой, per core часто оказывается честнее, чем per server: цена привязана к мощности и не прячется в условиях про сокеты, лимиты по виртуализации и другие оговорки.

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

Начните с простых вопросов: сколько у вас реальных пользователей (и сколько из них работают удаленно или с нескольких устройств), сколько устройств дают доступ (есть ли сменные рабочие места), сколько серверов и где они находятся (физические, виртуальные, разные площадки), какие CPU стоят на серверах и сколько ядер реально задействовано. И обязательно прикиньте рост на 6-12 месяцев: люди, устройства, ядра.

Выбор "на глаз" особенно опасен при росте компании и удаленной работе. Сегодня сотрудник за одним офисным ПК кажется "одним устройством", а завтра у него появляется ноутбук, домашний ПК и доступ через терминал. Тогда per device неожиданно раздувается, а per user, наоборот, становится понятнее и проще для учета. На серверной стороне бывает наоборот: добавили узлы в кластер или увеличили число ядер - и условия per server перестали быть выгодными.

Когда вы заранее понимаете свою схему доступа и нагрузку, лицензирование превращается из загадки в обычный расчет.

Короткие определения: per user, per device, per core, per server

Держите в голове один принцип: вы платите либо за "кто пользуется", либо за "с чего пользуется", либо за "сколько мощности", либо за "сколько серверов". Меняется только единица учета.

Per user (на пользователя)

Лицензия привязывается к человеку (сотруднику, учетной записи). Обычно это удобно, когда один и тот же человек работает с разных устройств: офисный ПК, ноутбук, телефон, домашний компьютер. Важно уточнить, как именно считается пользователь: по имени (named user) или по одновременным сессиям (concurrent user).

Per device (на устройство)

Лицензия привязывается к конкретному устройству: рабочему месту, терминалу, кассе, планшету в палате, тонкому клиенту. Хороший ориентир: если устройство общее и за ним по очереди работают разные люди, per device часто проще считать.

Per core (на ядро)

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

Per server (на сервер)

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

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

Мини-пример: если 30 сотрудников работают по сменам за 10 кассами, per user означает 30 лицензий, а per device - 10. При per core стоимость не меняется от числа касс, но зависит от конфигурации сервера.

Когда выбирать per user: типовые ситуации и примеры

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

Чаще всего per user выигрывает, если:

• у сотрудника 2-3 устройства (рабочий ПК, ноутбук, телефон);
• есть удаленка или гибридный график;
• пользователи закреплены поименно, и учет ведется аккуратно (AD/SSO, корпоративная почта);
• важно не ограничивать сценарии: "зашел с другого устройства и продолжил работу".

Пример: менеджер проекта работает на офисном ПК, вечером проверяет задачи с домашнего ноутбука, а днем согласует документы с телефона. В модели per device пришлось бы лицензировать несколько устройств, а per user покрывает одного человека.

Есть нюанс со сменными командами. Если за одним ПК по графику работает несколько людей (стойка регистрации, операторская, учебный класс), per user часто становится дороже, потому что вы платите за каждого сотрудника. В таких местах чаще логичнее per device.

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

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

Когда выбирать per device: рабочие места и сменные команды

Модель per device выгодна там, где одним и тем же компьютером пользуются разные люди. Вы платите за точку доступа, а не за каждого сотрудника. Это хорошо ложится на сменную работу и общие рабочие места.

Типичные примеры: рецепция, учебный класс, лаборатория, операторская с 2-3 сменами, колл-центр с посадочными местами. Простой ориентир: если людей больше, чем устройств (и они меняются по расписанию), per device почти всегда понятнее, чем per user.

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

Важно заранее договориться, что именно считается устройством. На практике в расчет обычно попадают офисные ПК и моноблоки, тонкие клиенты и терминальные станции, планшеты и мобильные рабочие места (если с них есть доступ), кассовые станции и POS-терминалы.

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

Главный риск per device - незаметный рост парка. Открыли дополнительное окно обслуживания, добавили кассу, поставили еще пару ПК в новом филиале - и расходы растут вместе с количеством устройств. Если выбираете эту модель, сразу закладывайте план расширения на 6-12 месяцев и назначайте ответственного, чтобы новые устройства не появлялись "в обход" лицензий.

Когда выбирать per core: серверы и виртуализация без сюрпризов

Per core чаще всего встречается у серверных продуктов, где цена привязана к вычислительной мощности. Это удобно, когда нагрузка зависит не от числа пользователей, а от того, сколько работы делает CPU: запросы к базе, расчеты, параллельные задачи. Тогда выбор модели сводится к вопросу, сколько физических ядер реально будет задействовано.

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

Проверьте:

• модель процессора (конкретный SKU);
• количество сокетов в сервере;
• количество физических ядер на сокет;
• включена ли гиперпоточность (ее нельзя путать с ядрами);
• план апгрейда CPU в ближайшие 12-24 месяца.

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

Per core обычно выигрывает в сценариях с постоянной высокой нагрузкой: базы данных и транзакционные системы, аналитика и отчетность, плотная виртуализация (много ВМ на одном хосте), рост нагрузки не через новых пользователей, а через объем данных.

Практический пример: вы ставите 2-сокетный сервер под БД и планируете рост. Сегодня хватает 16 ядер, через год нужен апгрейд до 32. При per core апгрейд CPU почти всегда автоматически повышает требования к лицензиям, поэтому бюджет на рост лучше считать заранее. Если вы закупаете серверы под такой контур (например, стойки уровня S200), фиксируйте конфигурацию и правила миграции ВМ до покупки - так меньше сюрпризов при масштабировании.

Когда выбирать per server: небольшие серверные контуры

Per server подходит там, где все просто и предсказуемо: 1-2 сервера на роль (файловый, печать, небольшая база, контроллер домена), мало изменений и редкие миграции. Тогда выбор модели сводится к вопросу, сколько именно серверов будет в контуре в ближайший год.

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

Когда per server выгоднее, чем per core

Per server часто выигрывает на небольших CPU (например, 1 сокет и немного ядер) и когда вы точно знаете, что серверов будет мало. Пример: у отдела один сервер приложений и один сервер базы, оба стабильны. Если лицензия считается "за сервер", рост нагрузки иногда можно закрыть апгрейдом железа (память, диски, иногда CPU) без покупки новых лицензий. Но только если правила действительно не привязаны к ядрам.

Резерв, тест и рост

Спросите про запасной сервер и тестовую среду. Иногда есть право на cold standby (резерв выключен), а иногда резерв считается как полноценный сервер. Чтобы не промахнуться, зафиксируйте на старте:

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

Главный риск per server - незаметное разрастание количества серверов при масштабировании приложения (новые VM под сервисы, отдельные узлы под очереди, кеш, мониторинг). Если вы ожидаете быстрый рост, per core или другая схема может быть спокойнее в долгую. Для небольших контуров на 1-2 сервера, наоборот, per server часто дает понятный бюджет и меньше неожиданностей.

Как выбрать модель за 5 шагов

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

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

2. Посчитайте пользователей и устройства по ролям. Отдельно посчитайте уникальных пользователей и отдельно - реальные точки доступа. Если один человек использует ноутбук, смартфон и домашний ПК, per user обычно понятнее. Если много людей работают по очереди за одним и тем же ПК или терминалом, чаще выигрывает per device.

3. Опишите серверную часть. Сколько серверов, какие процессоры и сколько ядер, есть ли виртуализация, сколько виртуальных машин планируется. Здесь легко ошибиться: при росте нагрузки per core обычно предсказуемее, чем попытки считать "по серверам", особенно если серверы мощные или вы часто меняете железо. Если вы закупаете стойки под проекты (например, на типовых rack-серверах класса S200), сразу фиксируйте число ядер и план расширения.

4. Оцените рост на 12-36 месяцев. Добавьте прогноз по штату, филиалам, новым сервисам и удаленной работе. Хорошая модель переживает рост без резкого скачка затрат из-за одного изменения (например, внезапно добавили смену или развернули новые VM).

5. Сравните 2-3 модели на одном наборе цифр. Сделайте таблицу: текущие значения и план на 1 и 3 года. Выбирайте вариант, который дает самый ровный итог по сценарию роста, а не самый дешевый "сегодня".

Мини-сценарий: в колл-центре 60 операторов в 3 смены и 25 рабочих мест - часто логика ведет к per device. А в команде продаж 40 человек с ноутбуками и телефоном у каждого обычно лучше ложится per user.

Частые ошибки и где обычно переплачивают

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

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

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

Сменность тоже часто переворачивает расчеты. На заводе 3 смены могут работать за одним ПК: per device выглядит выгоднее, чем per user. А в офисе наоборот: один сотрудник с ноутбуком и стационарным ПК может сделать per device дороже, чем per user.

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

Перед покупкой зафиксируйте на бумаге, что именно считается лицензируемой единицей:

• кто считается пользователем (человек, учетная запись, одновременная сессия);
• что считается устройством (ПК, тонкий клиент, терминал);
• как считаются ядра/процессоры (минимумы, округления, гиперпоточность);
• как учитывается виртуализация (хост, кластер, миграции);
• что происходит при росте (апгрейд, добавление серверов, временные доступы).

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

Примеры типовой нагрузки по отраслям

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

Поликлиника (регистратура, общие ПК, смены). Главный показатель - рабочие места (устройства), потому что за одним компьютером часто работают разные люди по графику. Чаще подходит per device: вы привязываете право использования к конкретным ПК, и сменность не превращается в доплаты.

Банк (часть сотрудников с ноутбуками, есть удаленный доступ). Главный показатель - пользователи, потому что один человек может подключаться с ноутбука, домашнего ПК и телефона. Чаще подходит per user, особенно если доступ нужен "лично сотруднику", а не конкретному рабочему месту.

Университет (компьютерные классы и преподаватели). Обычно два потока. Для классов главный показатель - количество компьютеров (per device). Для преподавателей и сотрудников, которые работают с личных ноутбуков и из дома, главный показатель - количество людей (per user). Часто получается смешанная схема, но с понятной логикой.

Предприятие (сервер с виртуальными машинами, рост нагрузки). Главный показатель - ядра/мощность, потому что число виртуальных машин и пользователей меняется, а ресурсы сервера растут. Чаще подходит per core: так меньше сюрпризов при добавлении VM или увеличении нагрузки на хост.

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

Быстрый чеклист перед покупкой лицензий

Перед закупкой соберите цифры на одной странице. Это снижает риск выбрать не ту модель и потом доплачивать при расширении или проверке.

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

Дальше посчитайте точки доступа: сколько устройств дают доступ к системе, включая общие ПК на стойке, терминалы, ноутбуки для выездных работ, резервные рабочие места и тестовые машины. Если есть сменные команды (2-3 смены на одном месте), это может резко поменять выбор между per user и per device.

Отдельно опишите серверный контур на ближайший год - не "как сейчас", а с учетом планов: сколько серверов добавится, какие CPU стоят (сокеты и ядра), появятся ли новые роли (БД, приложений, виртуализации). Для per core и per server эти детали влияют на стоимость сильнее всего.

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

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

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

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

Что делать дальше: зафиксировать правила и план роста

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

Соберите одну таблицу учета

Сведите факты в одну таблицу и обновляйте ее по расписанию (например, раз в месяц). В ней важны не только текущие цифры, но и ожидаемый рост на 6-12 месяцев. Это помогает быстро понять, что именно двигает счет - люди, устройства или вычислительная мощность.

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

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

Запас на рост без переплаты

Закладывайте резерв под реальные изменения: новые отделы, сезонные пики, добавление узлов, расширение CPU. Но не покупайте "в два раза больше на всякий случай". Проще заранее определить порог, при котором вы докупаете лицензии (например, при достижении 85-90% лимита).

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

На практике удобно связывать план лицензий с планом инфраструктуры. Если вы обновляете рабочие места и серверы, можно опереться на локального производителя и интегратора - например, GSE.kz (gse.kz), чтобы одновременно подобрать ПК L200, моноблоки M200 или серверы S200 и сразу закрепить единые правила учета лицензий и поддержки.