Фотография
нажмите — покажем
нажмите — покажем
💫Экономия от миграции в облако (Total Migration Cost Savings)
Экономия от миграции даёт простой и понятный ответ на главный вопрос любой трансформации: снижает ли облако итоговые расходы или перенос создаёт дополнительные издержки.
Метод учитывает не только стоимость инфраструктуры, но и общие операционные затраты на поддержку, что особенно важно для реальной оценки эффективности.
Как считается
Мы сравниваем две группы расходов:
🟣 фактические затраты на текущую инфраструктуру: дата-центр, приватное облако или существующий публичный облачный провайдер.
🟣 расходы на целевую архитектуру: инфраструктура выбранного публичного облака и общие затраты на эксплуатацию в новой среде.
Формула:
(Текущие инфраструктурные затраты – затраты на целевую облачную платформу) + (общие операционные затраты на инструменты и команду в текущей инфраструктуре – аналогичные затраты в целевой архитектуре).
Проще: сколько платим сегодня, сколько будем платить после миграции, плюс разница в стоимости сопровождения.
Что учитываем в расчётах
🟢отчёты по потреблению и стоимости инфраструктуры в дата-центре или приватном облаке
🟢 калькуляторы стоимости публичных облаков
🟢 собственные оценки общих расходов на инструменты, поддержку и участие команды
Что даёт этот анализ
Компания получает прозрачную картину экономического эффекта от миграции, без предположений и маркетинговых ожиданий.
Формула помогает понять, когда миграция действительно снижает затраты, а когда требует пересмотра архитектуры, объёмов или выбранной цели.
Источник: FinOps Foundation.
#считаем_finops
☁️ Подписаться
В Подход здравый и действительно часто используется для первичного обоснования экономической целесообразности миграции в облако. Он хорошо отвечает на вопрос "Становится ли инфраструктура дешевле?". В нашей практике, однако, мы обычно используем фреймворк Forrester TEI (Total Economic Impact). Он позволяет оценивать не только сокращение затрат, но и совокупный экономический эффект от инвестиций в миграцию: влияние на выручку и маржинальность за счет ускорения time-to-market, снижения операционных рисков, повышения масштабируемости и использования managed-сервисов. Такой подход позволяет обосновывать целесообразность миграции даже в случаях, когда прямые инфраструктурные затраты в облаке выше текущих, но сама миграция является драйвером для достижения стратегических целей Заказчика и роста финансовых показателей.Д Всем привет! А у кого-то есть практический опыт в расчете экономии и потом сравнении по итогам миграции? У нас есть сейчас одна такая задачка. Мы вроде расчеты провели, но не могу отделаться от ощущения "Всё равно всё пойдет совсем не так". Кажется, что вообще стартовать миграцию без расчетов — выстрел себе в ноги (как минимум в выделении ресурсов). Но насколько стоит доверять? Может есть какие-нить мысли?A Обязательно пойдёт не так точность оценки зависит от опыта команды заказчика (внезапно, да?), сложности инфраструктуры, количестве операций напильником Я бы делал так: "прикинули на листочке, умножили сроки на три, провели пилот, скорректировали сроки, провели первую итерацию - скорректировали сроки"A
Е Как говорится, гладко было на бумаге, да забыли про овраги 😃 Калькуляторы и внутренние оценки редко отражают фактические расходы после запуска. Помимо базовой стоимости инфраструктуры в зависимости от провайдера всплывают затраты на трафик, хранение данных, резервное копирование, техническую поддержку, отказоустойчивость и сопутствующие сервисы. В свою очередь сотрудники склонны недооценивать затраты на миграцию и дальнейшую поддержку новой среды. Я считаю что очень важно учитывать, что облако не является выгодным автоматически — без внедрения finops практик оно легко становится источником неожиданных затрат, черной дырой для денег 💸 и причиной выпадения последних волос у вашего CFO👨🦲 На мой взгляд решение о миграции это не вопрос одной формулы, а взвешенный комплексный подход, где важны не только расходы, но и цели, понимание рисков и реальных преимуществ облака: гибкости, масштабируемости, скорости изменений и устойчивости инфраструктуры.A Д Какой коэффициент "менеджерской накрутки" стоит применять? Например, в разработке ПО, фронт говорит: "Я сделаю эту форму за 3 часа". Ты у себя пишешь: "Закладываем 6 на недетально вычитанные требований, риски и еще сюда же закинем время на смоук", в зависимости от размера задачи этот Кэф может быть Х3.
От себя бы добавила, что стоит особенно внимательно оценить следующие риски:
- так называемый "double-bubble" - период времени, когда поддерживаются обе инфраструктуры (и новая, и старая). Этот период может быть затянут, если слишком рано приступить к миграции, либо сотрудники не успели пройти необходимое обучение и т.д.
- К слову об обучении - не стоит недооценивать расходы на подготовку персонала к миграции. Надо учесть, что может появиться необходимость в дополнительных специалистах. А также сам процесс переподготовки существующих сотрудников нередко занимает больше времени, чем планировалось.
- Расходы на целевую архитектуру: значимо не только приблизиться к эквиваленту уже имеющейся архитектуры, только в облаке, но и здесь необходимо сразу подумать о рисках. На первых порах могут быть совершены ошибки в настройке сервисов, выборе не тех резерваций и т.д., что сопряжено с существенными расходами. То есть мы топорно не сравниваем 2 возможные архитектуры между собой, а понимаем, что на деле все будет иначе. После этого нужно стремиться не просто к эквиваленту, а к оптимальной новой инфраструктуре. Но это уже совсем другой разговор, и, конечно же, это не решить одной формулой.
Ссылка
нажмите — покажем
нажмите — покажем
Привет!
Как раз сейчас занимаюсь изучением смежного вопроса (для своего железа). При попытке посчитать стоимость онпрем инфры есть проблема с расчетом по компонентам (ресурсам). Когда вы разместили свой сервер на мощностях провайдера: как поделить условные 500К за колокейшн по ресурсам/компонентам CPU, RAM и диск, к примеру).
Я сталкиваюсь с двумя мнениями:
1) Супер-дотошный. Когда "аллокация" ранее была проведена на всех уровнях. Когда в ТСО попадает всё по "конституции": ФОТ, ПО, амортстоимость (тут итого за сервак флэйвором или покомпонентно), трафик, э/э, ТП и пр. Тут можно рассчитать пропорции распределения "неизвестного" в долях по известному.
2) В среднем по рынку. Когда хочется сделать уже хоть что-то. Снять низковисящие фрукты. Нет времени на детальные расчеты (так еще и финансы могут быть к этому не готовы). Поэтому берут "средние" показатели с рынка. Условно, все "шеренные ресурсы" распределяются пропорционально кол-ву компонентов (например, 50% на процессор, 30 на память, 20 на диск).
Во втором сценарии, несомненно, скрытые издержки могут быть повсюду) Но у него есть несколько неоспоримых плюсов.
Точных методик, особенно для РФ рынка, полагаю нет. Калькуляторов не встречал тем более. Наверное можно отталкиваться от "вечной классики" — https://usermanual.wiki/vmware/cbmug250.84765594.pdf
Добрый вечер.
Про общепризнанный не знаю. Сам использовал разную развесовку в зависимости от цен на комплектующие, требования к масштабированию и пожеланий финансистов.
Так как диски у нас обычно на отдельных СХД, то в рамках compute хоста делил косты между CPU и RAM как 40/60%. А дальше если это было необходимо для ФЭМ, вносил корректировки.
Думаю, с учётом текущего роста цен на память, эта пропорция будет сдвигаться в сторону RAM.
Д При этом, кажется, основные игроки кто хотели мигрировать в онпрем уже понесли основные затраты на закупку железа. А как вы со своей стороны проводите корректировку пропорции? Условно, вы сразу на все объекты распространяете условия, или делаете "несколько тарифов" в зависимости от типа оборудования? И такое уточнение, делили ли еще общие затраты в привязке к такому compute хосту? Например, общие косты на обслуживающих инженеров, делили условно по кол-ву элементов в вашей модели (например, по кол-во юнитов во всех стойках) или также на уровне ресурсов (а если так, то пропорцию ту же использовали)?
Всем привет! В Москве пройдёт ITAMday 2026 — конференция по управлению ИТ-активами.
15 октября 2026 года в Москве, на площадке ИТ-экосистемы «Лукоморье» (БЦ «Академик»), состоится ITAMday — XI ежегодная конференция ассоциации itSMF России по управлению ИТ-активами. Ожидается более 350 участников: руководители ИТ-подразделений, специалисты по управлению активами и лицензиями, FinOps-практики, финансисты и юристы.
Тема года — «Экономная эволюция»: объекты учёта в компаниях стремительно меняются — от серверов и лицензий к облачным ресурсам и токенам ИИ-моделей, — а дисциплина учёта и контроля должна оставаться прежней. Конференция предложит практический взгляд на то, как считать и оптимизировать расходы на активы, которых ещё несколько лет назад просто не существовало.
Приглашаю вас выступить с докладом.
Регистрация открыта на сайте itamday2026.itsmfcon.ru