Сервер дешевле рынка: сколько бизнес потеряет через три года

Бюджеты на ИТ сокращаются, оборудование дорожает, а ошибки в инфраструктурных проектах становятся заметно дороже. CIO и CFO приходится решать, где можно сократить расходы, а где экономия приведет к простою, повторной закупке и проблемам с поддержкой. В рубрике "Точка зрения" генеральный директор компании "Байт" Константин Хабаров разбирает, как считать стоимость серверной инфраструктуры на горизонте пяти лет и на чем заказчики чаще всего теряют деньги.

Константин Анатольевич, начнём с главного. Почему закупочная цена сервера - это вообще не полная цена решения? Какие расходы заказчики чаще всего не учитывают в коммерческих предложениях? И можно ли оценить их на горизонте пяти лет?

Потому что ценник на сервер - это цена коробки. Не цена работающей системы. Как с машиной: купить автомобиль можно один раз, а потом платить за топливо, обслуживание, резину и ремонт. За пять лет к цене железа добавляются сервис и запчасти — обычно 8–15% стоимости оборудования в год в зависимости от SLA. Добавляются энергия и охлаждение: для круглосуточной нагрузки это часто еще 10–25% цены железа за весь срок. Добавляются лицензии, резервное копирование, администрирование и миграции. Самая неприятная статья - простой. Один отказ критичного узла способен съесть всю первоначальную скидку за несколько часов. Короче, дешевый сервер - это не выгодная сделка, пока вы не посчитали весь маршрут на пять лет.

Давайте перейдем к цифрам. Если рассмотреть типовую серверную конфигурацию (два процессора, 256 ГБ RAM и дисковую подсистему), как на горизонте пяти лет обычно распределяются расходы? Какая часть приходится на сервис, запасные части, электричество, лицензии и резервное копирование? Где заказчики чаще всего недооценивают бюджет?

Возьмем не прайс-лист, а модель расчета. Пусть цена сервера с дисковой подсистемой - 100 условных единиц. За пять лет сервис и запасные части добавят 35-60 единиц, если нужна нормальная реакция на инцидент, а не ожидание деталей неделями. Электричество и охлаждение - еще 10–25 единиц: цифра зависит от загрузки, тарифа и инженерии площадки. Лицензии на ОС, виртуализацию, мониторинг и резервное копирование - от 20 до 70 единиц. Бэкапное хранение и восстановление - еще 15-40 единиц. Администрирование, внедрение и миграции могут дать 20–50 единиц. Итого покупка железа часто занимает 35-50% пятилетнего TCO. Самая большая дыра обычно не в розетке. Ее бюджет съело ПО, поддержка и работа людей. Как в ремонте: плитка видна сразу, а дороже всего часто оказываются электрика, трубы и переделки.

Где грань, когда резервирование - умная страховка, а когда - просто склад пыльных коробок, которые ждут своего часа в углу серверной? Как отличить одно от другого на этапе проектирования?

Резервирование - это страховка для критичных сервисов. Но, как и любая страховка, оно должно соответствовать реальному риску и цене возможного ущерба. Если час остановки ERP, производства или онлайн-продаж стоит дороже второго блока питания, дополнительного диска или узла кластера, страховка оправдана. Если система может спокойно простоять день, покупать полный дубль всего контура - это склад коробок. Как с аптечкой в машине: бинт и огнетушитель нужны всем, а реанимобиль в багажнике - нет. На этапе проекта надо разложить сервисы по критичности, определить RTO и RPO, посчитать ущерб и только потом выбирать N+1, кластер или холодный резерв. Стоп, не покупайте резерв "на всякий случай". Покупайте его под конкретный сценарий отказа.

Расскажите случай из практики, когда совместимость подвела. Привезли, а оно не встало в стойку, не подружилось с СХД, не завелось с правильной версией гипервизора. Кто в итоге платил за этот цирк - вы, заказчик или вендор?

Типовой сценарий выглядит так. Заказчик выбирает сервер по спецификации и цене, а проверку связки с действующей СХД, гипервизором и резервным копированием оставляет "на потом". Приехали серверы, поставили в стойку, а нужная версия драйвера не поддерживает контроллер; часть функций виртуализации не взлетела. Начинается цирк: смена прошивок, поиск совместимой версии, дополнительные лицензии, перенос окна работ. Как на стройке, где окна привезли после того, как уже поставили коробку дома: формально все материалы есть, а закрыть контур нельзя. Платит тот, у кого не закреплена ответственность в договоре. Если поставщик продал только коробки - чаще платит заказчик. Если поставщик отвечает за работоспособность согласованной конфигурации, он устраняет проблему за свой счет. Поэтому проверьте матрицу совместимости и проведите пилот до закупки.

Сейчас все переходят на российское железо и софт. Это помогает сэкономить или, наоборот, добавляет скрытых расходов? Насколько реально собрать аналог "западного" сервера на отечественных компонентах и не пролететь с поддержкой?

Российское железо и софт не делают проект автоматически дешевле. Они меняют структуру риска. Как при ремонте квартиры: отечественная плитка может стоить разумно, но если к ней нет клея, затирки и мастера, экономия закончится переделкой. Серверная платформа сама по себе не работает. Нужна проверенная связка: сервер, СХД, ОС, гипервизор, средства резервного копирования, мониторинг и ИБ. Ключевой риск - фрагментация. Формально каждый продукт может быть в реестре, а вместе они встают колом. Собрать рабочий аналог западной платформы реально. Но его нельзя собирать по принципу "взяли самое дешевое в каждой строке спецификации". Нужны стендовые испытания, зафиксированные версии ПО, понятный порядок обновлений и единый ответственный за поддержку. Если этого нет, вы покупаете не импортозамещение, а геморрой на пять лет. Экономия появляется там, где поставщик отвечает за весь согласованный контур, а заказчик заранее понимает, кто и за сколько часов восстановит сервис.

CIO сегодня каждый день слышит: "айтишку надо в облако". Когда облако действительно дешевле своего сервера, а когда - это маркетинг, который влетает в копейку через три года аренды? Назовите критерий, по которому принимать решение.

Облако выгодно, когда нагрузка скачет, проект короткий или бизнесу нужна скорость запуска. Как такси: на пару поездок оно дешевле личной машины, страховки и гаража. Но если вы ездите по одному маршруту каждый день и круглосуточно, аренда начинает съедать бюджет. Для постоянной предсказуемой нагрузки собственная инфраструктура часто выгоднее на горизонте трех-пяти лет. Критерий простой: посчитайте базовую нагрузку, которую вы используете не меньше 70% времени, и стоимость ее аренды за 36–60 месяцев. Потом сравните с TCO своего контура, включая электричество, сервис, ПО, людей и резервирование. Не сравнивайте месячный счет за облако с ценой сервера. Это как сравнить стоимость ночи в гостинице с ценой квартиры. Отдельно считайте трафик, хранение, резервные копии и плату за исходящие данные - на них часто прокалываются. Облако не маркетинг и не религия. Это инструмент. Для переменной нагрузки - хороший. Для постоянно работающего тяжелого контура без расчета - дорогой.

Казалось бы, купил сервер - поставил. Но у вас в списке рисков - "дефицит кадров". При чём здесь железо, если его можно обслуживать удаленно?

Удаленно можно подключиться. Удаленно нельзя отменить физический отказ, ошибочную схему питания или конфликт прошивок. Сервер - это не чайник: воткнул в розетку и забыл. Это больше похоже на машину, где мотор, коробка, электроника и топливо должны работать вместе. Нужен человек, который понимает виртуализацию, сеть, хранение, резервное копирование и порядок восстановления. В дефиците не "руки", а инженеры, способные быстро локализовать проблему в стыке систем. Когда такого специалиста нет, инцидент растягивается: один подрядчик кивает на СХД, другой - на гипервизор, третий - на сеть. В итоге сервис встает колом, а бизнес теряет время и деньги, пока участники разбираются, где именно возникла проблема. Удаленная поддержка работает, если есть мониторинг, доступы, документация, запасные части и закрепленный уровень ответственности. Без этого удаленно вы получите только длинную переписку. Заказчику нужно либо держать компетенцию внутри, либо покупать ее как сервис. Третьего варианта нет.

Назовите три самые частые ошибки, которые совершают финансисты и ИТ-директора, когда считают стоимость владения. На чём они постоянно прокалываются?

Первая ошибка - сравнивают только цену закупки. Это как выбирать квартиру по цене входной двери, не глядя на коммунальные платежи и состояние дома. Вторая — не считают стоимость простоя. У ИТ-директора есть SLA, у финансового директора — выручка, но эти цифры часто не встречаются в одной таблице. Третья - считают инфраструктуру статичной. Через два года растет объем данных, появляются новые сервисы, меняются требования к ИБ, и первоначальная конфигурация становится тесной. Тогда докупают память, диски, лицензии и работы уже без конкуренции, в аварийном режиме. Добавлю четвертую: забывают про миграцию и вывод из эксплуатации. Переезд на новую платформу - это не перевозка шкафа. Нужны окна работ, тесты восстановления, резерв, время людей. Запомните: TCO - это не один итоговый столбец. Это сценарий, что вы будете делать, когда что-то сломали, выросли или изменили.

Компании сокращают инвестиционные программы. Как понять, что обновление инфраструктуры нельзя переносить?

Режим экономии - не повод менять серверы по календарю. Но он и не повод ждать, пока все сломается. Как с крышей: можно отложить косметический ремонт, но нельзя игнорировать течь над электрощитовой. Есть четыре стоп-сигнала. Первый - оборудование снято с поддержки или критичные детали недоступны в понятный срок. Второй - растет число инцидентов и время восстановления. Третий - мощности уже не хватает: сервисы деградируют, резервные копии не укладываются в окно, пользователи ждут. Четвертый - платформа не поддерживает требования ИБ или нужные версии ПО. В этих случаях перенос - не экономия, а перенос убытка на более дорогую дату. Не обязательно менять все. Разбейте проект: сначала критичный контур, затем узкие места, затем развитие. Проверьте, что старую систему можно безопасно продержать еще год, и только после этого режьте бюджет. Если не можете назвать срок поставки запчасти и время восстановления, у вас не инфраструктура, а лотерея.

А сами вы на этом обжигались? Расскажите случай, когда вы, Константин, как руководитель, приняли решение сэкономить на "железе", а потом переплатили в разы. Честно.

Личную историю придумывать не буду. Но есть отраслевой сценарий, который повторяется регулярно. Компания берет более дешевую конфигурацию без расширенной поддержки и без запаса по дискам, потому что разница в смете выглядит заметной. Это как купить машину без страховки, а потом попасть в аварию. Через год растет нагрузка, один из узлов выходит из строя, а совместимого компонента нет на складе. Начинаются срочная закупка, доставка, внеплановые работы, перенос сервисов ночью и риск потери данных. Первоначальная экономия исчезает за один инцидент. Хуже, если простаивает производство или клиентский сервис: тогда счет идет уже не за железо. Обожглись на этом многие. Вывод простой: экономить можно на избыточности, которую вы доказанно не используете. Экономить на поддержке критичного контура - это ставить бизнес на домкрат без страховочной опоры.

И последнее. Если всё, что вы сказали, сжать в одно короткое правило, которое можно повесить в кабинете CIO или выбить на табличке в серверной, то что это будет? Одна фраза. Или одна цифра.

Покупайте не сервер. Покупайте пять лет предсказуемой работы.