Результаты сделанного выбора будут особенно заметны, если компания масштабируется, растет, а условия в отрасли претерпевают постоянные изменения. Понятно, что каждая покупка оборудования должна соответствовать долгосрочным целям компании и обеспечивать бесперебойную работу всех систем. Вместе с Алексеем Учакиным, директором по инфраструктуре в EdgeЦентр, IT World выяснял, как тратить деньги на оборудование так, чтобы инфраструктура работала 24/7, росла и развивалась, когда это нужно бизнесу.
Управление затратами: разница моделей
FinOps — культура управления затратами на облачную инфраструктуру. То есть в облачных сервисах у нас есть API-интерфейсы, JSON-файлы и удобные CSV-отчеты, позволяющие детально анализировать и контролировать потребление ресурсов. Провайдер предоставляет исчерпывающую информацию обо всех затратах, что упрощает финансовый учет и оптимизацию расходов.
В среде on-premise ситуация выглядит иначе.
● Модель требует значительных капитальных вложений (CapEx), развертывание оборудования занимает много времени, измеряемого неделями и даже месяцами.
● В отличие от облака, где тарификация может быть без фиксированной суммы в месяц, по фактически используемым ресурсам Pay-As-You-Go (PAYG), расчет затрат on-prem производится помесячно и с определённым коммитом, а контракты, как правило, годовые и с ограничениями на досрочное расторжение. Это затрудняет оперативное управление бюджетом.
● В расчеты затрат на капитальные расходы (CapEx) и операционные издержки (OpEx) не включают возможные переменные, например, энергопотребление во время пиковых нагрузок или перерасход трафика. При этом затраты на тот же трафик “сверх нормы” могут быть весьма значительны.
● Практически все счета приходят в pdf-файлах на почту бухгалтерии, что осложняет их машинную обработку.
Рис.1 Отличия в эксплуатции cloud и on-prem инфраструктуры
Все это делает процесс управления затратами в on-premise более трудоемким и менее прозрачным по сравнению с облачными средами. При этом сама инфраструктура остается востребованной в таких секторах, как банковский, промышленный, операторы CDN и облачные провайдеры.
При этом использование on-prem инфраструктуры не исключает возможности применения эффективных подходов FinOps, характерных для облачной среды, например, для создания внутренних, частных облаков для собственных команд разработки и других подразделений. Что же можно сделать для более правильного управления расходами?
Начать с актуализации данных
Сначала стоит обратиться к имеющимся учетным системам. Например, в компании могут быть Zabbix, Netbox или DCImanagement-система, где можно найти информацию о том, что в какой стойке стоит и какую конфигурацию имеет. На практике списки оборудования могут оказаться устаревшими: где-то могли провести апгрейд и забыть обновить документацию, где-то, напротив, демонтировали оборудование, а информация осталась. Расхождения накапливаются, реальное состояние инфраструктуры может существенно отличаться от того, что зафиксировано “на бумаге”.
Какие еще данные стоит актуализировать:
Соглашения об уровне обслуживания (SLA). После актуализации железа нужно обратить внимание на ДЦ, где это железо стоит. Какой у него SLA, что в него входит (а, главное, что не входит), каково время реакции дежурной смены? На деле SLA могут либо отсутствовать в договорах, либо не соблюдаться. Об отсутствии четких гарантий можно узнать лишь в критический момент, когда возникает необходимость срочного вмешательства.
Складские запасы. Следует помнить важный принцип: пока инженер в дата-центре не подошел к нужной коробке, не осмотрел ее и не извлек требуемую деталь, этот запас остается своего рода «квантовой неопределенностью». Даже если у вас есть запасные модули памяти, но дежурный инженер не может их оперативно найти, то запасы теряют ценность, особенно во время инцидента.
Рис.2 Слайд 21 из презентации EdgeЦентр
Анализ и оптимизация
После тщательного аудита можно приступать к дальнейшему анализу и оптимизации затрат. Идем к продуктовым командам и спрашиваем, а хватает ли им железа, соответствует ли конфигурация их потребностям. Возможно, используемые серверы избыточны по мощности и команды не используют весь потенциал, что приводит к неоправданным затратам. Или, наоборот, чего-то может не хватать. Оптимизация конфигураций под конкретные нужды каждой команды позволяет снизить издержки и одновременно повысить производительность.
Аналогичный подход можно использовать по отношению к управлению пиковыми нагрузками. Возможно, некоторые серверы у одной команды простаивают, а другим в это время не хватает мощностей. Потребность в ресурсах может изменяться в зависимости от сезонности, рекламных кампаний или специальных событий, таких как «черная пятница» или новогодние распродажи. Если команда работает на пределе возможностей оборудования, это может привести к деградации сервиса и потере доходов. Чтобы предотвратить подобные ситуации, необходимо предусмотреть резервные мощности для покрытия пиковых нагрузок. Одним из вариантов может быть временное перемещение части нагрузки в публичное облако, если такая возможность доступна и приемлема для компании.
Но не все организации готовы к такому решению. Альтернативный подход заключается в создании общего пула серверов, которые можно оперативно перераспределять между разными командами в зависимости от текущих потребностей. Поскольку пиковая нагрузка у разных проектов может приходиться на разные периоды (например, у одной части бизнеса “высокий сезон” в ноябре, а у другой — в июле), такой механизм позволит избегать покупки лишнего оборудования и эффективнее использовать имеющиеся ресурсы.
Бюджеты и потребности
Перед началом планирования бюджета на ближайший квартал или год нужно обсудить с продуктовыми командами их планы по развитию: насколько увеличатся потребности в ресурсах в ближайшие месяцы или год. Хорошо бы также оценить динамику роста за предыдущие периоды, чтобы понять реалистичность ожиданий. Если команда планирует нагрузку х3, но ранее не демонстрировала существенного роста, возможно ей стоит пересмотреть прогнозы.
Важно учитывать сроки, в которые команды ожидают увеличения нагрузки. Если они заявляют, что рост необходим немедленно («вчера»), это сигнал о проблемах с планированием. Если говорят, что достаточно будет через месяц, это также указывает на недостаточную проработанность, ведь за столь короткий срок практически невозможно доставить и установить новое оборудование, если оно еще не заказано.
Не забывайте, что рост проекта связан не только с увеличением вычислительных мощностей “под капотом” и увеличением количества серверов, но и с внутренними изменениями в коде или архитектуре продукта. Возможно, команде потребуется сначала провести рефакторинг или оптимизировать часть модулей, прежде чем планировать закупку новых серверов. В таком случае планирование выполняется с пометкой “nice to have” с последующим уточнением планов по месту.
После обсуждения с продуктовыми командами можно вернуться к своей инфраструктурной команде и оценить сопутствующие расходы. Определите, сколько места и электроэнергии потребуется для размещения новых серверов, проверьте состояние сети и наличие свободных портов. Возможно, придется приобрести дополнительное сетевое оборудование или расширить существующие линии связи. В on-premise ответственность за работоспособность оборудования ложится на инфраструктурную команду, поэтому убедитесь, что у вас есть достаточный запас запчастей под ремонт или предусмотрена вендорская поддержка (а лучше и то, и другое). Дополнительно создайте маневренный фонд для мелких апгрейдов, таких как добавление дисков или оперативной памяти, или даже пул резервных серверов для оперативного распределения ресурсов между командами (об этом мы говорили выше).
Реальные вызовы в модели on-premise
Реальность, с которой сталкивается любая организация, эксплуатирующая on-premise инфраструктуру, полна вызовов. Например, отсутствие свободных стоек в дата-центре может означать задержку расширения на полгода или больше, пока не появится возможность разместить новые серверы. Закупка оборудования может затягиваться на месяцы, а иногда и на годы. Цены на оборудование зависят от валютных курсов, глобальных событий и проблемам в цепочках поставок. Все это может привести к увеличению стоимости оборудования на 50% и более, что усложняет бюджетирование.
Есть и другие группы рисков:
Привязка к вендорам и платформам. Часто компании выбирают одного или нескольких основных поставщиков оборудования. Если вы используете только серверы Dell или HP или коммутаторы Cisco, то вы можете попасть в ситуацию, когда единственно нужный вам вариант стоит дорого и поставляется долго, или не поставляется больше вообще, хотя есть аналоги, например, AMD вместо Intel или Juniper вместо Cisco, с более низкой ценой и коротким сроком поставки.
Затраты на оборудование и эксплуатацию. Ошибка при заказе оборудования или неправильная архитектура могут привести к значительным дополнительным затратам. Например, если закупленное оборудование не соответствует задачам, для которых оно закупалось, его замена потребует времени и средств. Кроме того, эксплуатация on-premise инфраструктуры включает в себя скрытые затраты, такие как содержание склада запчастей, амортизация оборудования и зарплата обслуживающего персонала, которые не всегда учитываются при составлении финмодели проекта.
Проблемы с биллингом и документированием. Биллинг в on-premise среде часто основан на бумажных счетах или PDF-документах, что затрудняет автоматическую обработку и атрибутирование затрат. Распознавание позиций в счете и привязка их к конкретному оборудованию или услугам может потребовать участия человека, что увеличивает вероятность ошибок. Это особенно актуально для бухгалтерии, которая может испытывать трудности с интерпретацией общих формулировок в счетах.
Ограниченность контрактов и штрафы. Контракты с дата-центрами или провайдерами могут содержать условия, предусматривающие штрафы за досрочное расторжение, или требовать подачи заявления о расторжении за несколько месяцев. Это ограничивает гибкость компании в случае необходимости изменить условия сотрудничества или перейти на другую платформу.
Недостаточная емкость инфраструктуры. Подобно тому, как облачные провайдеры могут столкнуться с нехваткой ресурсов в определенном регионе, on-premise инфраструктура может страдать от недостатка емкости сети, нехватки свободных стоек или длительного срока поставки оборудования. Расширение требует значительных временных и финансовых затрат.
Рис.3 Риски, возникающие при эксплуатации cloud и on-prem инфраструктуры
Как минимизировать риски
Для эффективной работы с рисками необходимо разработать комплексный подход, учитывающий множество факторов.
● Для начала составьте список основных поставщиков, подробно изучите их возможности и ограничения. Например, для дата-центра важно знать, сколько у него свободных стоек, когда планируется ввод новых залов или кампусов и есть ли “свободное” электричество под рост нагрузки. Подготовьте альтернативные варианты на случай, если основной поставщик или партнер перестанет удовлетворять вашим требованиям.
● Регулярно отслеживайте средние сроки поставки оборудования и договаривайтесь с поставщиками о своевременном уведомлении в случае их увеличения. Это даст возможность корректировать планы и заранее информировать продуктовые команды о задержках с поставками.
● Договоритесь с поставщиком о “тёплом” складе - т.е. оборудовании, которое он будет закупать заранее и держать здесь локально, отгружая вам по мере необходимости. Так вы получите короткий срок поставки и экономию места на вашем складе без необходимости замораживать значительное количество денежных средств в авансовых платежах.
● Учитывайте временные затраты на внутренние процедуры согласования и оплаты. Процесс подписания контракта и перевода средств может занимать несколько недель.
● Регулярно проверяйте, насколько дата-центры и провайдеры выполняют условия соглашений об уровне обслуживания (SLA). Это особенно важно в условиях нестабильных рынков и изменчивых экономических реалий.
FinOps-пайплайн для on-premise инфраструктуры
В отличие от облачных решений, где цикл обратной связи относительно короток, в случае с собственным оборудованием он растягивается на недели, месяцы и даже годы. Тем не менее его можно разделить на значимые этапы.
Рис.4 Слайд 60 из презентации EdgeЦентр
Планирование (Planning). На этом этапе определяется, какие ресурсы необходимы для достижения целей бизнеса. Важно учесть будущие потребности продуктовых команд, ожидаемый рост нагрузки и технологические тренды. При планировании также учитываются риски, связанные с возможными задержками поставок и изменением рыночной конъюнктуры.
Закупки. (Procurement). После определения потребностей начинается процесс поиска и заказа необходимого оборудования. Это длительный этап, который может включать переговоры с поставщиками, заключение контрактов и ожидание доставки.
Эксплуатация (Operation & Maintenance). Включает настройку, тестирование и интеграцию новых устройств в существующую инфраструктуру. Этот этап может продолжаться годами, поскольку оборудование эксплуатируется длительное время.
Вывод из эксплуатации (Disposal). По окончании жизненного цикла оборудования возможны варианты: перевод в тестовый контур, списание или продажа Важно учитывать юридические и технические аспекты каждого из этих шагов, чтобы минимизировать риски и убытки.
Рис.5 Слайд 61 из презентации EdgeЦентр
Команды и инструменты для управления затратами
Управление затратами на on-premise инфраструктуру требует вовлечения различных отделов и использования специализированных инструментов.
● IT-команды отвечают за управление инфраструктурой и обеспечение ее надежного функционирования. Они используют системы управления дата-центром, чтобы отслеживать состояние оборудования, электроснабжения и охлаждения; базы данных, содержащие информацию о конфигурации оборудования; обеспечивают наблюдение за состоянием оборудования и предупреждают о потенциальных проблемах.
● Финансисты контролируют денежные потоки и ведут учет затрат. Основные их инструменты — это ERP-системы и Excel.
● Складские подразделения могут использовать системы управления складом, такие как 1C WMS.
● Для точной аналитики и отчетов могут использоваться системы бизнес-аналитики, такие как Power BI или Tableau.
● Координирующие роли: у продуктовых команд, которые запрашивают закупку оборудования; у сотрудников, ответственных за его приобретение; у юристов, которые следят за юридическим соответствием сделок.
Рис. 6 Слайд 74 из презентации EdgeЦентр
Выводы и рекомендации
Инфраструктура on-premise подвержена множеству рисков, связанных с поставщиками, техническими сбоями и юридическими нюансами. Задача — научиться распознавать и минимизировать эти риски. Их полное исключение невозможно, но правильное управление способно существенно облегчить жизнь бизнесу.
● Ключевым моментом в этом процессе является тесная коллаборация между всеми участниками процесса: и айтишниками, и юристами и др. И помните, что все подразделения должны работать с одними и теми же данными. Использование концепции единого источника истины (source of truth) поможет избежать конфликтов и разногласий между командами. Убедитесь, что данные из различных источников (ERP, DCI-менеджмент, складские системы) синхронизированы и согласованы.
● Даже если вы думаете, что никогда не занимались FinOps-практиками, вы наверняка уже следуете многим из них, например выстраивая процессы планирования, закупок и эксплуатации. Поэтому начать можно с малого шага, например, с аудита текущего состояния инфраструктуры или оптимизации существующих процессов.
● Вам нужен «FinOps-чемпион». Это должен быть сотрудник, обладающий глубокими знаниями в ИТ, и немного вокруг: финансах, юриспруденции, бухгалтерии - чтобы эффективно общаться со смежными командами. Его задача — методично собирать и обрабатывать данные, связывая различные департаменты в единый процесс.
● Развитие FinOps для on-premise инфраструктуры может рассматриваться как зрелый этап Capacity Management в компании. Он открывает путь к созданию внутренней инфраструктуры, которая функционирует подобно облачным решениям, позволяя эффективно управлять ресурсами и взаимодействовать как с внутренними, так и с внешними заказчиками.