Два предложения по платформе данных легко сравнить по стоимости вычислений и хранения. Сравнение становится сложнее, когда в одном варианте учтены инженеры сопровождения, а в другом они остались в бюджетах доменов; в одном заложено восстановление истории, а в другом — только успешный ежедневный запуск.
В результате самая дешёвая схема на презентации может оказаться просто схемой с наименьшим числом описанных обязательств.
Рассмотрим, как собрать модель стоимости до выбора продуктов и поставщиков. Предмет решения — аналитическая платформа для регулярной управленческой отчётности. Разберём три архитектурных варианта, посчитаем их на одинаковом горизонте и проверим, какие допущения меняют выбор. Все числа ниже учебные: они не являются тарифами, оценкой конкретной компании или обещанием экономии.
Сначала определить, какой сервис покупает бизнес
В учебной компании есть отчётность по продажам и платежам, несколько предметных команд и существующее хранилище. Руководство рассматривает обновление платформы, поскольку время подготовки новых витрин растёт, а сопровождение старых становится менее прозрачным.
Но «новая платформа» ещё не описывает требуемый результат. Зафиксируем условия, на которых будем сравнивать варианты:
ежедневный согласованный срез для управленческого решения, с заранее определённым временем готовности;
история заказов и платежей, позволяющая воспроизвести расчёт за закрытый период;
изолированная проверка новой версии витрины до выдачи потребителям;
разграничение доступа к чувствительным данным и журналирование выдачи;
восстановление после ошибки загрузки и исправление затронутой истории;
понятная поддержка: владелец продукта данных, техническая команда и маршрут эскалации.
Конкретные допустимые задержки, время восстановления, потеря данных и сроки хранения должны быть согласованы до расчёта. Они здесь не объявляются универсальными нормами.
Для антифрода с минимальной задержкой или интерактивного управления оборудованием эта модель потребует пересмотра. Их нельзя незаметно включить в тот же бюджет после выбора архитектуры для ежедневной отчётности.
Полезный первый результат работы CDO — перечень обязательств, которые имеют бизнес-владельца. Техническая команда оценивает способ их исполнения. Если никто не может объяснить, зачем хранить определённую историю или поддерживать определённую свежесть, стоимость этого требования пока нельзя считать согласованной.
Рабочая нагрузка должна быть видна в модели
Одного размера хранилища недостаточно. Две системы с одинаковым объёмом данных могут выполнять разную работу.
Для оценки нужны как минимум четыре профиля.
Поступление данных. Сколько источников подключается, как часто приходят изменения, есть ли повторы, поздние исправления и ограничения на чтение операционных систем. Отдельно рассматриваются обычный день и массовая повторная загрузка.
Преобразования. Какие наборы пересчитываются целиком, какие — по изменениям; где нужны тяжёлые соединения и пересчёт истории. Важно понимать зависимости: ускорение одного задания не поможет, если его входы готовы слишком поздно.
Потребление. Сколько одновременно активных запросов, какие разрезы используются, насколько допустимо кэширование, кто выгружает подробные данные. Количество зарегистрированных пользователей не равно одновременной нагрузке.
Эксплуатационные события. Подключение нового источника, изменение схемы, восстановление, удаление данных, выпуск новой версии продукта. Эти операции тоже потребляют труд и ресурсы, хотя их нет в обычном расписании отчётов.
Профили собираются из наблюдений и дополняются явно помеченными прогнозами. Если измерений нет, это отдельный риск оценки. Его полезнее ограничить пилотом, чем скрыть за одним «коэффициентом роста».
Три архитектуры, которые можно сравнивать
Для нашей задачи рассмотрим три варианта. Это логические решения; конкретный стек выбирается после проверки их выполнимости.
А. Развивать существующее хранилище. Сохранить основной контур хранения и выдачи, переработать критические преобразования, добавить управляемую публикацию версий и наблюдаемость. Предметные команды получают согласованный путь выпуска своих витрин.
Преимущество для оценки — меньше перемещаемых компонентов и уже известная эксплуатация. Ограничение — существующая система может не обеспечить нужную изоляцию нагрузок, расширение или восстановление. Это проверяется до признания варианта допустимым, а не компенсируется низкой ценой в расчёте.
Б. Отделить долговременное хранение от основных вычислительных нагрузок. Организовать общий слой данных и отдельные вычислительные контуры для подготовки и потребления, с явно спроектированной выдачей проверенных версий.
Такое разделение может позволить независимо подбирать ресурсы для разных нагрузок. Но само название архитектуры не доказывает ни экономию, ни удобство. Нужно оценить передачу данных, повторное чтение, служебные операции, метаданные, новые компетенции и стоимость интерфейсов между компонентами.
В. Оставить основной аналитический контур и выделить специализированный контур потребления. Например, отдельную систему для интерактивных запросов, питаемую опубликованными продуктами основной платформы.
Вариант имеет смысл проверять, если требования потребителей существенно отличаются от требований подготовки данных. Цена разделения — дополнительная копия, синхронизация, доступы и восстановление двух контуров. Ускорение выдачи не должно скрыть, что копия отстаёт или использует другую версию расчёта.
Во всех вариантах владельцы предметных продуктов и сквозных показателей остаются необходимы. Перенос таблиц не определяет, кто вправе менять методику и кто обязан исправлять исходные данные.
Считать одну и ту же границу расходов
Для каждого варианта разделим затраты на четыре части.
Регулярная эксплуатация: инфраструктура, лицензии, команды сопровождения и обязательные общие функции.
Переход: разработка, перенос, испытания, обучение и подготовка процедур.
Дополнительная параллельная работа: расходы сверх уже учтённого регулярного контура, пока обязательны два пути.
Завершение перехода: отключение старых заданий, перенос оставшихся потребителей, проверка доступов и удаление управляемых копий.
В категории труда важно не посчитать одного инженера дважды. Если сопровождение инцидентов входит в полную стоимость команды, не нужно второй раз добавлять её же часы отдельной строкой. Если общие инженеры распределены между продуктами, способ распределения должен быть одинаковым для всех вариантов.
И наоборот: если доменная команда пишет и поддерживает преобразования, эти затраты входят в стоимость платформенного решения независимо от того, кому подчиняется сотрудник.
Для горизонта из 36 месяцев используем простую модель:
TCO = 36 × регулярные месячные расходы + переход + дополнительные расходы параллельной работы + завершение перехода.
Для простоты регулярный целевой бюджет считается неизменным во все 36 месяцев, включая период перехода. Это плановое допущение для сравнения, а не помесячный прогноз фактических платежей. Параллельные расходы — только дополнительные затраты сверх этой базы, а работа по переходу не включена повторно в регулярное сопровождение.
Это недисконтированная модель ресурсов и бюджета, а не финансовая оценка инвестиционного проекта. Для решения, где существенны время платежей, валюта или условия финансирования, финансовая служба должна дополнить её соответствующей моделью. Смешивать годовую экономию ресурсов и текущую денежную выплату нельзя.
Учебный расчёт на одинаковом горизонте
Будем считать в условных единицах бюджета. Полная стоимость труда и инфраструктуры условна; сравнение показывает устройство модели, а не рыночные цены.
Вариант А. Регулярные расходы в месяц: инфраструктура 18, команда 45, общие функции 7. Итого 70. Переход — 180. Дополнительная параллельная работа — 30 в месяц на протяжении четырёх месяцев, то есть 120. Завершение — 40.
За 36 месяцев: 36 × 70 + 180 + 120 + 40 = 2 860.
Вариант Б. Инфраструктура 25, команда 36, общие функции 9. Регулярный итог также 70. Переход — 360. Дополнительная параллельная работа — 50 в месяц в течение шести месяцев, то есть 300. Завершение — 60.
Итого: 36 × 70 + 360 + 300 + 60 = 3 240.
Вариант В. Инфраструктура 22, команда 51, общие функции 12. Регулярный итог 85. Переход — 260. Дополнительная параллельная работа — 40 в месяц в течение пяти месяцев, то есть 200. Завершение — 80.
Итого: 36 × 85 + 260 + 200 + 80 = 3 600.
В этих допущениях вариант А требует меньше ресурсов. Но принимать решение ещё рано. Сначала надо убедиться, что он исполняет обязательства. Если он не обеспечивает требуемое восстановление или время выдачи данных, он не является более дешёвым способом получить тот же сервис.
В этом и состоит первая развилка: сравниваем стоимость допустимых решений, а не используем стоимость для оправдания недопустимого.
Какая гипотеза способна изменить выбор
В примере у А и Б одинаковые регулярные расходы. Разница разовых и переходных расходов — 380: у А это 340, у Б — 720.
Чтобы Б стал дешевле на горизонте 36 месяцев, он должен экономить больше 380 / 36, то есть примерно 10,56 условной единицы в месяц, при неизменных остальных допущениях.
Допустим, сторонники варианта Б ожидают, что команда будет стоить 27 вместо 36. Тогда месячный итог станет 61, экономия относительно А — 9. За 36 месяцев получится 324, чего недостаточно, чтобы покрыть дополнительные 380.
При стоимости команды 25 месячный итог Б составит 59. Экономия 11 за 36 месяцев даст 396. Общий итог Б — 2 844 против 2 860 у А. Разница всего 16: небольшая ошибка в допущениях способна изменить результат.
Это не основание спорить о двух единицах бюджета на презентации. Это указание, что нужно измерить на пилоте: какие операции исчезают, какие новые возникают, сколько времени требуется на поддержку и насколько прогнозируем этот труд.
Освободившееся время также не обязательно превращается в сокращение расходов. Команда может использовать его для новых продуктов, улучшения качества или снижения очереди. Это полезный эффект, но у него другая форма результата.
Параллельный контур — отдельный архитектурный риск
Вариант Б в учебной модели предусматривает шесть месяцев параллельной работы. Если срок удвоится, появятся ещё шесть месяцев по 50 — дополнительные 300. Итого станет 3 540 вместо 3 240, при неизменных остальных условиях.
Причина задержки может находиться вне технического переноса. Остался один потребитель со старым форматом. Не согласовано правило закрытого периода. История сверена по общим суммам, но не по ключам. Владелец опасается отключать привычный отчёт, потому что не проверен возврат после сбоя.
Поэтому длительность параллельной эксплуатации должна быть результатом плана зависимостей и приёмки. Её нельзя выбирать только из того, сколько бюджет позволяет держать два контура.
У каждого обязательного старого потребителя нужны владелец, способ перехода и критерий завершения. В учебном примере выключение старого пути возможно, когда:
согласованы определения показателей и объяснены значимые расхождения;
новый путь проверен на закрытии периода, поздних событиях и исправлении истории;
обязательные потребители переключены и подтвердили доступность своих операций;
выполнено упражнение по восстановлению и определены ограничения возврата;
назначен ответственный за отключение заданий, прав и управляемых копий.
Срок наблюдения определяется рисками и бизнес-циклом. Произвольное число дней без этих проверок не создаёт основания для отключения.
Качество и безопасность нельзя убрать из одной альтернативы
В модели иногда появляются предложения с почти одинаковой функциональностью и очень разной стоимостью. Прежде чем объяснять разницу эффективностью архитектуры, стоит проверить обязательства.
Есть ли в обоих вариантах проверка новой версии витрины до выдачи? Можно ли установить, какие входы использовались? Кто пересчитывает зависимые продукты после семантической ошибки? Учтены ли резервные копии и испытания восстановления, а не только сам механизм резервирования?
Для доступа проверяется весь путь до потребителя. Более узкая роль BI-модели не компенсирует прямое чтение тех же данных через другой интерфейс. Дополнительный контур потребления означает ещё одну поверхность применения правил и ещё одну копию, для которой нужны правила хранения и удаления.
Конкретные требования определяют владельцы данных и уполномоченные службы. В статье не предлагается единый срок хранения или универсальная схема соответствия требованиям.
Экономическая модель должна показывать стоимость выполнения принятой политики. Если часть требований пока исключена, исключение описывается вместе с владельцем риска. Иначе один вариант получает скрытое преимущество за счёт меньшего уровня защиты и обслуживания.
Инциденты: не подменять неизвестный риск точной суммой
Команда может оценить наблюдавшиеся затраты: часы расследования, повторное вычисление, ручные сверки. Для будущей архитектуры частота подобных событий часто неизвестна.
Вместо одной убедительной суммы полезно построить сценарии: обычная эксплуатация, существенный пересчёт истории, длительный отказ компонента. Для каждого описать действия, ресурсы, затронутые продукты и границы оценки.
Если регулярная команда уже включает дежурство, её стоимость не добавляется повторно. Но временные мощности для восстановления или работа внешнего подрядчика могут быть дополнительными затратами — если они действительно предусмотрены моделью.
Ущерб от неверного бизнес-решения рассматривается отдельно. Формула «ошибка может стоить очень дорого» не определяет ни вероятность, ни допустимый уровень риска. Эти оценки требуют участия владельца процесса, а не только инженера данных.
Что проверить на пилоте до утверждения бюджета
Пилот должен уменьшить неопределённость, которая способна изменить решение. Для нашего расчёта это стоимость сопровождения, перехода и длительность двух контуров.
Возьмём один сквозной продукт с репрезентативными зависимостями: заказы, платежи, управленческая витрина и реальные потребители. Только удобный набор данных может дать нерепрезентативную оценку.
Проверим обычную загрузку и выдачу, изменение предметного правила, повтор события, поздние данные и пересчёт истории. В безопасной среде воспроизведём отказ и восстановление. Запишем не только продолжительность задания, но и ручные операции, участие платформенной и доменных команд, дополнительную инфраструктуру и обращения потребителей.
Отдельно проверим выпуск второго продукта по тому же пути. Первый может держаться на ручной работе автора платформы; второй покажет, существует ли повторяемый механизм.
До начала пилота стоит определить решение по его результатам. Например: вариант Б принимается к следующей фазе только если выполняет обязательства, а наблюдаемые операции позволяют обосновать выбранный диапазон стоимости сопровождения. Если данных недостаточно, решение остаётся условным; неопределённость не исчезает после успешной демонстрации.
Как оформить решение для CDO и финансового руководителя
На рассмотрение выносится не только итоговая сумма, но и её происхождение:
требуемые результаты и обязательства перед бизнесом;
допустимые варианты архитектуры и причины исключения остальных;
одинаковая граница затрат и владелец каждой существенной статьи;
наблюдения, прогнозы и наиболее чувствительные допущения;
результаты пилота и оставшаяся неопределённость;
бюджет перехода и условие завершения параллельной работы;
критерии приёмки, остановки следующей фазы и восстановления.
Финансовый руководитель проверяет способ представления бюджета и денежных потоков. Владельцы продуктов подтверждают обязательства. Технические команды отвечают за оценки реализации и эксплуатации. CDO связывает эти части в решение и обеспечивает полномочия для выполнения принятых границ.
Утверждение бюджета не должно превращать гипотезы в факты. По ходу перехода модель обновляется: изменился объём, срок поддержки старого интерфейса или способ восстановления — пересматривается прогноз, а не только отчёт об освоении средств.
Итог выбора в учебном примере
При исходных допущениях развитие существующего хранилища дешевле двух других вариантов. У отдельного слоя хранения и вычислений появляется небольшое преимущество только после существенного изменения оценки команды, причём разница чувствительна к задержке миграции.
Практический вывод здесь не в победе конкретной архитектуры. До выбора стека удалось установить, какие условия должны быть доказаны: выполнение обязательств, стоимость поддержки и возможность завершить двойную эксплуатацию.
Когда эти условия сформулированы, сравнение продуктов становится предметным. Команда ищет способ исполнить определённый сервис и измеряет существенные затраты. Тогда TCO помогает выбрать архитектуру, а не служит приложением к уже выбранному стеку.