TCO миграции на open source: честный шаблон расчета

Зачем считать TCO перед миграцией

Считать только цену лицензий - почти всегда ошибка. Лицензии заметны в бюджете, но основные деньги часто уходят в другое: время команды, простои, поддержку, доработки, инфраструктуру и риски. Поэтому TCO миграции на open source лучше оценить заранее, чтобы решение было не «дешевле на бумаге», а выгоднее и спокойнее в эксплуатации.

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

Чаще всего сравнивают не один продукт, а целый набор решений, которые влияют друг на друга: ОС для серверов и рабочих мест, офис и почта, СУБД и прикладные сервисы, виртуализация и управление, резервное копирование и мониторинг.

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

Если часть затрат завязана на оборудование и поддержку на месте, TCO помогает «свести» в одну картину ИТ и финансы. При обновлении парка серверов или рабочих станций учитывайте не только цену покупки, но и доступность сервиса, сроки поставки, гарантийную поддержку и требования к локальному содержанию при закупках. В Казахстане это особенно заметно, когда инфраструктура строится на оборудовании, которое производится и обслуживается внутри страны. Например, GSE.kz (gse.kz) выпускает компьютеры и серверы в Казахстане и как системный интегратор берет на себя поддержку и инфраструктурные задачи.

Границы расчета и допущения

Чтобы TCO миграции на open source был честным, сначала договоритесь о границах. Иначе расчет превращается в спор: кто-то добавит все риски, а кто-то «забудет» половину затрат.

Опишите проект простыми словами: какие системы мигрируем, сколько пользователей затрагиваем, где это работает (офис, филиалы, дата-центр), какие требования по безопасности и доступности. Например, «300 офисных пользователей и 40 серверных VM для бухгалтерии и документооборота» - это один контур, а аналитическая платформа и тестовые стенды - другой.

Дальше зафиксируйте, что точно считаем: какие окружения (prod/test/dev), категории пользователей (обычные, админы, подрядчики), интеграции (AD, почта, бэкап, мониторинг), требуемый SLA и окна работ, а также горизонт (обычно 3-5 лет).

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

Выберите единицы учета и используйте их везде: пользователь, сервер, VM, ядро CPU, стойка, терабайт. Важно, чтобы open source и коммерческий вариант считались в одинаковых единицах.

И последнее - допущения. Зафиксируйте рост нагрузки (например, +15% в год), инфляцию и курс, сроки проекта, режим поддержки (5x8 или 24/7). Если планируете опираться на интегратора и сервисную сеть, отдельно запишите, что входит в поддержку: время реакции, восстановление, обновления, выезды.

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

Сначала посчитайте «цену без изменений»: сколько вы заплатите, если просто продлите коммерческие лицензии и продолжите работать как сейчас. Это базовая линия. Если она неточная, любое сравнение будет спорным.

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

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

Отдельно разложите сопровождение: что покупаете у вендора, а что у партнера. В строках должны быть понятные вещи: уровень поддержки (часы, 24/7 или 8/5), целевые времена реакции, обновления и патчи, помощь при инцидентах и при обновлениях. Простая проверка: если убрать поддержку, сможете ли вы безопасно оставаться на текущей версии?

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

Статьи TCO: из чего складывается итоговая сумма

Чтобы итог не «плавал», разложите расходы по корзинам. Удобно держать две оси: CAPEX (разовые вложения) и OPEX (регулярные расходы), а также прямые и косвенные затраты.

CAPEX обычно уходит в закупки: серверы, СХД, сеть, иногда лицензии на гипервизор или бэкап, если они остаются коммерческими. OPEX - это люди, поддержка, подписки на обновления, площадка, электричество, связь, расходники и сервисные контракты.

Сразу разделяйте разовые и регулярные суммы. Главные деньги часто прячутся не в покупке, а в 12-36 месяцах эксплуатации. Можно сэкономить на лицензиях, но заметно увеличить затраты на администрирование, обучение и поддержку в первые месяцы.

В таблицу обычно попадают пять крупных блоков:

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

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

Отдельно договоритесь о правилах учета «мелочей», которые в сумме дают заметный хвост: НДС (если применимо), доставка, таможенные расходы, расширенная гарантия, сервисные контракты, запасные части. При замене серверов цена «железа» может выглядеть одинаково, но итог меняется, если включить доставку, гарантию 3-5 лет и условия ремонта. Для Казахстана это особенно заметно при сравнении локальной поставки и длинной цепочки поставок. Если у поставщика есть сервисная сеть и понятные сроки восстановления, снижаются риски простоев, а вместе с ними и скрытая часть TCO.

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

Пошаговый шаблон расчета: как заполнить таблицу

Начните с одной таблицы и одинаковых правил для всех сценариев: один файл, один горизонт (обычно 3-5 лет), одинаковые статьи затрат.

1. Зафиксируйте, как система работает сейчас: доступность, время реакции, окна обслуживания, сколько заявок в месяц, сколько времени команда тратит на поддержку.

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

3. Разнесите деньги по годам: разовые (переезд, внедрение) - в Год 0; регулярные (поддержка, подписки, электричество) - по годам.

4. Добавьте резерв и проверьте чувствительность: что будет, если обучение займет на 2 месяца больше, а инцидентов станет на 20% больше.

5. Сравнивайте сценарии только при одинаковых условиях: одинаковый сервис, одинаковый объем работ, одинаковые допущения.

Если для надежности вы добавляете 2 узла в open source сценарии, это должно появиться и в «серверы», и в «поддержка». И наоборот: если при продлении лицензий вы все равно обновляете парк серверов, эти затраты должны быть в таблице, иначе цифры будут «красивыми», но бесполезными.

Серверы и вычисления: закупка, размещение, амортизация

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

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

Для расчета мощности заложите текущую нагрузку плюс запас: пик, рост на 12-24 месяца и резерв на отказ одного узла, если у вас кластер.

В расчет по вычислениям обычно включают закупку (серверы, сеть, монтаж), размещение (стойки, электричество, охлаждение или услуги ЦОДа), эксплуатацию (апгрейды, расходники, запасные части, продление гарантии), амортизацию (3-5 лет) и рост под новые сервисы и тестовые среды.

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

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

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

Хранение, резервное копирование и восстановление

Хранение в TCO часто занижают, потому что считают только «полезные» данные. На деле вы платите за рабочие файлы, архив, логи, временные данные, snapshots и сами бэкапы, плюс за запас под рост.

Сначала посчитайте, сколько вы храните реально и где именно. Удобно разделить на три части: рабочий массив (быстро), емкостной архив (дешевле, но медленнее) и «тень» в виде копий и ретенции.

Типы хранилищ и почему цена отличается

Производительное хранилище дороже не из-за «бренда», а из-за требований: низкая задержка, больше IOPS, чаще SSD, больше контроллеров и сетевых портов. Емкостное хранилище дешевле, но оно не спасет, если базы данных и виртуальные машины будут ждать диски.

Для таблицы достаточно разнести объемы по классам и указать цену за 1 ТБ в каждом классе, включая полки, диски, контроллеры и сеть.

Бэкапы, DR и цена RPO/RTO

Бэкап - это не только софт. Учитывайте носители, окно резервного копирования (нагрузка ночью или в выходные), хранение копий на другой площадке и регулярные тесты восстановления. Чем меньше RPO/RTO, тем больше копий, каналов и автоматизации потребуется.

Чтобы не ошибиться, соберите пять цифр: текущий объем данных по категориям, рост данных в год, политика ретенции, целевые RPO/RTO и частота тестового восстановления.

Пример: при 100 ТБ рабочих данных и 60 днях ретенции ежедневных копий итоговый объем под бэкапы легко становится в 2-4 раза больше «полезного» массива. Это и есть честная база для сравнения.

Поддержка и эксплуатация: люди, процессы, SLA

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

Сначала выберите модель поддержки. «Только своя команда» дает контроль, но требует компетенций и дежурств. Подрядчик снимает часть нагрузки, но добавляет ежемесячные платежи и зависимость от SLA. Смешанная модель чаще всего реалистичнее: внутренняя команда закрывает рутину и архитектуру, внешний партнер - сложные инциденты и 24/7.

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

SLA меняет бюджет сильнее, чем кажется. Разница между 8x5 и 24x7 - это не «еще один человек», а дежурства, эскалации и более строгие показатели восстановления.

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

Практический пример: если два системных администратора ведут платформу «между делом», миграция легко добавит 10-15 часов в неделю на патчи, алерты и инциденты. При переходе на 24x7 это превращается в дежурства и необходимость резервной смены. Если поддержки 24/7 нет внутри, ее можно закрывать внешним сервисом - и стоимость такого SLA должна попасть в TCO отдельной строкой.

Обучение и управление изменениями

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

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

Формат обучения лучше смешивать. Внешний курс дает базу и общий язык. Внутренние тренинги переводят знания на ваши правила. Наставничество в первые недели снижает количество ошибок. Сертификация нужна не всегда, но полезна там, где есть требования к компетенциям или высокий риск простоев.

Потерю продуктивности считайте честно. Возьмите 1-2 типовые роли (например, бухгалтер и оператор колл-центра), оцените, сколько задач они делают сейчас, и заложите снижение на период привыкания. Практичный ориентир: 10-20% падения в первые 2-4 недели после переключения, затем постепенное восстановление.

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

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

Простои и риски: как честно заложить резерв

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

Простои бывают плановыми (ночь, выходные), «полупростоями» (все работает, но медленно или с урезанными функциями) и авариями (неудачный релиз, проблемы совместимости, сбой хранилища, откат).

Как посчитать стоимость часа простоя

Проще считать по подразделениям: «час простоя» для бухгалтерии и для контакт-центра стоит по-разному.

Рабочая формула такая: стоимость часа = (потерянная выручка или штрафы) + (оплата простоя сотрудников) + (потери из-за срыва процессов) + (внеплановая работа ИТ и подрядчиков).

Считайте отдельно критичные сервисы и «офисные» системы, затем суммируйте ожидаемые простои.

Резерв по времени и бюджету

Резерв нужен на то, что сложно предсказать: доработки интеграций, неожиданные баги, повторные миграции данных. Практично закладывать +15-30% по срокам на первые волны миграции и +10-25% по бюджету на непредвиденные задачи и усиление поддержки. Отдельно держите резерв на откат: время, лицензии на период параллельной работы, дополнительные мощности.

Юридические и регуляторные риски тоже имеют цену. Проверьте требования к данным (где хранятся, кто имеет доступ, как ведутся журналы), к доступности (внутренние SLA) и к поддержке (кто отвечает ночью и в выходные). Если требования строгие, заранее решите, кто обеспечивает 24/7 и как быстро поставляются запчасти и замены для серверов.

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

Частые ошибки при сравнении open source и коммерческих лицензий

Чаще всего «кривое» сравнение появляется потому, что сравнивают разные вещи. Например, продление подписки на 12 месяцев ставят рядом с суммой на 3-5 лет и делают выводы. Для TCO важно, чтобы горизонт, состав затрат и уровень сервиса были одинаковыми для обеих сторон.

Типовые ошибки:

• сравнивать разные сроки (год лицензий против нескольких лет владения);
• считать труд ИТ «бесплатным» (время админов, инженеров, поддержки и руководителя проекта должно становиться деньгами);
• забывать про совместимость и «мелочи» (интеграции, драйверы, печать, криптосредства, мониторинг, бэкапы, отчетность);
• завышать экономию на лицензиях и занижать поддержку (open source не значит «ноль затрат», особенно при SLA и 24/7);
• не фиксировать целевой уровень сервиса (тогда спорят не о цифрах, а о «качестве»).

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

Практический пример: организация переходит на open source и одновременно обновляет серверы. Если в коммерческом варианте вы учитываете только продление лицензий, а в open source добавляете покупку серверов и СХД, сравнение нечестное. Железо нужно учитывать одинаково в обоих сценариях, а менять в расчете только то, что реально зависит от выбора ПО.

Пример структуры расчета и следующие шаги

Представим выбор: продлить коммерческие лицензии или перейти на open source для 200 рабочих мест и 20 серверов. Задайте один горизонт (например, 3 года) и одну валюту, затем разложите оба варианта на одинаковые статьи.

Удобная структура, в которую подставляются ваши цифры:

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

Сравнивайте не «open source бесплатно», а «сколько стоит работать без сюрпризов». Часто решающим фактором оказывается не цена лицензии, а SLA, совместимость с критичными приложениями, сроки миграции и стоимость ошибок. Если для части рабочих мест нужен строго определенный софт, может понадобиться гибридная схема (часть остается как есть, часть переезжает), и это заметно меняет расчет.

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

Дальше обычно идут пилот на небольшой группе, уточнение спецификаций и план закупок, затем план поддержки на период миграции. Часть работ удобно отдавать системному интегратору: подбор серверов и рабочих станций, проектирование инфраструктуры, настройка и сопровождение. Если вам важно «единое окно» ответственности по SLA и круглосуточная поддержка, заранее фиксируйте в договоре состав услуг и метрики - и вносите эти суммы в TCO отдельными строками.