Годовая стоимость мейнфрейма в обоснованном бюджете

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

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

Универсальной честной ставки для мейнфрейма нет

Годовой бюджет нужно разделить на группы: каждая реагирует на свое событие. Цена ПО может зависеть от четырехчасового пика. Обслуживание оборудования останется неизменным до вывода машины. Расходы на людей изменятся только вместе с обязанностями и дежурствами. Внутреннее начисление за ЦОД может остаться даже после освобождения площади.

Как минимум разделите:

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

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

Первым результатом должен стать реестр контрактов, а не общая сумма. Для каждой строки укажите поставщика, продукт, срок, дату продления, метрику, минимум, текущую ступень, условие расторжения и источник доказательства. Назначьте владельца трактовки. Ячейка «ПО мейнфрейма» не скажет, какой счет уменьшится после переноса приложения.

MIPS оценивает мощность, но редко повторяет счет

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

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

Опасное сокращение выглядит так:

annual mainframe cost = total MIPS x assumed price per MIPS

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

Используйте MIPS для сверки. Если инвентаризация приписывает приложению половину системы, а отчеты из SMF показывают гораздо меньшую долю общего процессора, проверьте границу. Оценка могла включить базу и middleware из другой статьи, а замер мог пропустить batch с другим идентификатором. Такой спор полезен: он выявляет ответственность. Умножение двух сомнительных чисел только добавляет знак валюты к сомнению.

Счет по MSU зависит от замеров и договора

MSU, million service unit, измеряет мощность для некоторых цен на ПО IBM. Она ближе к расчету, чем MIPS, но сама по себе не имеет цены. Сумма зависит от продукта, модели, подходящей машины, договора, страны, обязательств и заявленного использования. Не доверяйте универсальной ставке за MSU.

Во многих схемах sub-capacity следят за скользящим средним за четыре часа, R4HA. Workload Manager записывает потребление, а Sub-Capacity Reporting Tool готовит данные для расчета подходящего ПО. Документация IBM по SCRT требует полных и корректных данных за период. Пропущенный интервал не доказывает бесплатную нагрузку: это дефект отчета.

На практике смешивают три величины:

• Мгновенный спрос показывает текущую ситуацию.
• Скользящее среднее сглаживает спрос в заданном окне.
• Расчетная величина применяет правила продукта и договора к заявленной мощности.

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

Постройте вклад в пик по исходным интервалам. Для продукта и LPAR запишите время месячного максимума, активные нагрузки, MSU, договорный минимум или ступень и следующую нижнюю границу. Проверьте удаление на всей серии. Не вычитайте среднее приложения из пика. Пики перемещаются.

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

Сверьте цепочку отчетности. Свяжите каждый central processor complex и LPAR с идентификаторами отчета, затем каждый оплачиваемый продукт с местами лицензирования и работы. Проверьте разработку, тест, восстановление и production. Отсутствующая в инвентаризации LPAR может влиять на счет; указанное приложение может не пользоваться продуктом.

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

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

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

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

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

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

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

Оборудование стоит больше суммы заказа

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

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

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

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

Дорогой специалист обычно выполняет несколько ролей

Нельзя просто сосчитать COBOL-разработчиков. Труднозаменимые люди ведут production control, JCL, scheduler, RACF, CICS или IMS, восстановление Db2, производительность, хранилища, релизы, инциденты и незаписанное знание. За одним именем могут скрываться пять функций.

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

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

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

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

Каждая строка счета нагрузки требует доказательства

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

Используйте таблицу такой формы:

cost_id,annual_cash,billing_driver,contract_floor,renewal_date,workload_share,removal_trigger,evidence
SW001,REDACTED,product_peak_msu,REDACTED,YYYY-MM-DD,measured,lower_tier_at_renewal,SCRT_report
HW004,REDACTED,fixed_lease,full_term,YYYY-MM-DD,shared,lease_end,signed_contract
LAB007,REDACTED,dedicated_effort,none,YYYY-MM-DD,time_study,role_reassigned,staffing_plan

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

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

Разницу показывает расчет:

run-rate allocation = annual cash x workload share
year-1 cash saving = annual cash x removable share x active fraction of year
net year-1 effect = year-1 cash saving - migration cash cost - overlap cost
steady-state saving = terminated and resized annual obligations

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

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

Договор исчезает после последней общей зависимости

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

Нанесите транзакции, задания, файлы, печать, процедуры базы, безопасность, скрипты, сверку и потребителей. Новый frontend при реестре в Db2 не убирает базу. Переписанный batch, который отправляет три задания JCL, не убирает scheduler.

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

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

CodeHero переписывает весь унаследованный код на Go, Rust и TypeScript и проверяет поведение через стенд паритета на записанном production-трафике. Работу можно завершить менее чем за 30 дней, но сроки уведомлений, хранение и общие зависимости по-прежнему определяют падение годовой суммы.

Часть расходов останется на новой платформе

Миграция меняет структуру, но не отменяет production engineering. Нужны вычисления, базы, хранилища, наблюдаемость, копии, безопасность, поддержка, инциденты, восстановление и знание правил. Ноль в этих строках означает агитацию, а не анализ.

Счета cloud требуют той же дисциплины. Разделите базовую и пиковую мощность, управляемую базу, сеть, хранение копий, non-production и поддержку. Не сравнивайте полную цену мейнфрейма с голой VM. Учтите параллельную работу и временное хранилище.

Одни обязанности дешевеют благодаря обычным инструментам и рынку труда, другие переезжают. RACF становится управлением доступом, SMF превращается в логи, метрики и трассировки, резерв Db2 заменяется резервом Postgres. Назначьте нового владельца контроля до удаления старого.

Запас производительности тоже остается. Новая система обязана выдержать наблюдаемые задержку, поток, закрытие и восстановление под реальным спросом. Размер определяют production-трассы и тесты, а не строки исходника. Современная архитектура сократит потери, но в бюджет входит доказанная мощность.

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

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

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

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

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

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

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

Решение опирается на устранимые деньги и дату выхода

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

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

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

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