Стоимость владения IT-стеком: как считать изнутри

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

Что именно считать

Стоимость владения, или TCO (total cost of ownership)¹, — расходы на систему за выбранный период, а не цена покупки оборудования или сумма в кабинете облачного провайдера. Границы расчёта задайте заранее: например, один сервис вместе с базой данных, очередью, мониторингом и командой, которая его поддерживает.

В расчёт обычно входят четыре группы расходов:

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

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

Как стоимость возникает внутри стека

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

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

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

Постоянные и переменные расходы

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

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

Соберите расчёт без ложной точности

Сначала выберите период — обычно месяц для текущих расходов и год для сравнения решений с затратами на внедрение. Затем зафиксируйте, что считается результатом системы: активный пользователь, заказ, обработанная задача, запрос или другая измеримая единица. Без такого знаменателя два стека с разным объёмом работы сравнивать трудно.

1. Зафиксируйте границы. Перечислите сервисы и общие компоненты, которые входят в расчёт. Проверка: другой инженер может прочитать список и понять, что именно вы сравниваете.
2. Соберите прямые расходы. Возьмите счета провайдера и поставщиков за один и тот же период; отделите продакшен от тестовых сред, если это возможно. Проверка: сумма по категориям сверяется с исходными счетами, а расхождения объяснены.
3. Добавьте труд. Оцените время команды на эксплуатацию и поддержку по задачам или учёту времени. Умножайте его на внутреннюю стоимость часа, только если у компании есть согласованная методика расчёта. Проверка: видно, какие часы включены и как получена ставка.
4. Учтите резерв и сбои. Отдельно покажите свободную мощность, резервные копии, тестовые среды и работу по инцидентам. Проверка: в отчёте не смешаны фактически использованные ресурсы и запас на отказ или пик нагрузки.
5. Разделите общие расходы. Если мониторинг или платформа обслуживают несколько продуктов, выберите правило распределения: по числу узлов, объёму данных, запросам или другому измеряемому показателю. Проверка: сумма распределённых частей равна исходной общей сумме.
6. Посчитайте стоимость единицы результата. Разделите общую стоимость за период на число единиц работы за тот же период. Проверка: числитель и знаменатель относятся к одним границам системы и одинаковому временному окну.

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

Сравнивайте варианты по одинаковым условиям

Перед сравнением задайте одинаковые требования к нагрузке, доступности, сроку хранения данных и объёму поддержки. Иначе «дешевле» может означать, что один вариант просто не выполняет те же условия. Таблица ниже — не рейтинг технологий, а способ проверить, какие расходы легко пропустить в каждом сценарии.

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

Где расчёт ломается

Общие расходы распределяют произвольно

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

Стоимость людей считают дважды или не считают совсем

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

Экономию считают без цены риска

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

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

Что делать дальше

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

¹ TCO — совокупная стоимость владения: расходы на приобретение, работу, поддержку и изменения системы за выбранный период. Состав расчёта зависит от границ, которые вы задали.