ИТ-инфраструктуру часто начинают обсуждать на уровне руководства только после сбоя.
Пока сервисы работают, серверы выдерживают нагрузку, данные доступны, а пользователи не жалуются, она остается техническим фоном. Но в момент аварии быстро становится бизнес-проблемой: клиент не может войти в личный кабинет, платеж не проходит, отгрузка останавливается, сотрудники теряют доступ к рабочим системам.
Для компании это не просто временная неисправность. Простой измеряется деньгами, сроками, штрафами, репутацией и потерянными операциями. Поэтому зрелость инфраструктуры определяется не количеством закупленного оборудования, а способностью заранее понимать, какие сервисы критичны, где отказ особенно дорог и какие меры дешевле аварийного восстановления.
Главная управленческая ошибка — считать инфраструктурные проекты только как закупку. Бизнес видит стоимость оборудования, лицензий, внедрения и поддержки, но не всегда оценивает цену простоя. В результате резервирование, модернизация или расширенный сервисный контракт выглядят дорогими до первой аварии. После нее часто выясняется, что несколько часов недоступности ключевой системы обходятся дороже профилактики, которую раньше откладывали.
«Бизнесу важно считать не абстрактное состояние ИТ-инфраструктуры, а стоимость часа простоя конкретного сервиса. В этот расчет должны входить не только прямые потери от остановки операций, но и штрафы по SLA, срочная логистика, сверхурочная работа команды, привлечение подрядчиков в аварийном режиме, перенос сроков по проектам и репутационные последствия. Пока эти параметры не переведены в деньги, модернизация выглядит как затратная инициатива ИТ-службы. Когда они посчитаны, становится видно, что плановые вложения часто дешевле одного серьезного отказа», — делится экспертизой Владимир Кудряшов, директор сервисного департамента компании «ГИГАНТ Компьютерные системы».
Когда такой расчет появляется, ИТ-проект перестает выглядеть как просьба на новый бюджет. Он становится управленческим решением: вот стоимость аварийного сценария, вот цена профилактики, вот риск задержки запуска сервиса, вот расходы на поддержку устаревшего решения. На этом языке бизнесу проще сравнивать не модели серверов или СХД, а последствия разных вариантов действий.
Чаще всего компании переходят к таким расчетам поздно. В идеальной модели инфраструктура развивается исходя из планов бизнеса, прогнозов роста и оценки рисков. В реальности толчком обычно становятся крупный сбой, регуляторный дедлайн или окончание поддержки оборудования и ПО. Пока сервисы работают, проблему можно отложить. Когда отказ уже грозит остановкой процесса или невыполнением требований, времени на спокойное планирование почти не остается.
После 2022 года к этому добавился фактор вендорозависимости. Раньше моновендорная архитектура казалась удобной: один поставщик, единая линейка, предсказуемая совместимость. Теперь зависимость от одного внешнего контура стала измеримым риском. Если поставщик уходит, прекращает поддержку или меняет условия, перестраивать приходится не один узел, а значительную часть стека. Гарантии теряют силу, обновления безопасности становятся недоступны, а критически важная деталь может ехать не несколько дней, а недели или месяцы.
«Многие компании долго воспринимали вендорозависимость как техническую особенность архитектуры, а не как бизнес-риск. Но если поставщик больше не поддерживает оборудование, не выпускает обновления или меняет условия сопровождения, проблема быстро выходит за пределы ИТ. Начинают расти сроки восстановления, дорожает сервис, усложняется закупка запасных частей, повышается зависимость от узкого круга специалистов. В такой ситуации инфраструктура вроде бы продолжает работать, но цена любого сбоя становится менее предсказуемой», — добавляет Владимир Кудряшов, директор сервисного департамента компании «ГИГАНТ Компьютерные системы».
Для части компаний к рыночной неопределенности добавились требования регуляторов. С 1 января 2025 года для органов государственной власти и ряда заказчиков действует запрет на использование иностранного ПО на принадлежащих им значимых объектах КИИ, если иное не установлено федеральным законом. Отдельно действует запрет на применение средств защиты информации из недружественных стран. За нарушения в области безопасности КИИ предусмотрена административная ответственность, а штрафы для юридических лиц по отдельным составам статьи 13.12.1 КоАП могут достигать 500 тыс. рублей.
Переходный период для доверенных программно-аппаратных комплексов на значимых объектах КИИ установлен до 1 января 2030 года, но это не отменяет необходимости планировать новые закупки заранее. В этой логике дедлайн задает уже не ИТ-служба, а государство. Чем сложнее контур, тем опаснее откладывать замену оборудования, ПО и средств защиты до последнего года.
Поэтому устойчивость не должна держаться на одном поставщике, подрядчике или инженере, который «все знает». В инфраструктурных проектах все большую роль играет технологическая независимость: совместимость с российскими ОС из реестра Минцифры, понятная модель эксплуатации, документированный жизненный цикл и архитектура, в которой замена одного компонента не требует перестраивать половину контура.
Еще одна причина аварийного бюджета — конфликт между стабильностью, безопасностью и развитием. Бизнес одновременно хочет, чтобы сервисы не падали, данные были защищены, а новые продукты запускались быстрее. Но эти цели тянут бюджет в разные стороны. У безопасности есть регуляторный аргумент. У развития есть заказчик внутри бизнеса. У стабильности такого сильного лоббиста часто нет, поэтому расходы на резерв, запасные части, поддержку и профилактику первыми попадают под сокращение.
В моменте такая экономия выглядит рационально. Но после сбоя становится видно, сколько стоили отложенные решения: простой, срочные поставки, переработки команды, невыполненные обязательства перед клиентами, репутационные потери. Проблема не в том, что бизнесу не нужна стабильность. Проблема в том, что ее цену начинают считать позже, чем цену новых сервисов или требований безопасности.
Корректный расчет должен идти не от цены закупки, а от совокупной стоимости владения. Инфраструктура не заканчивается в момент поставки оборудования. Дальше идут годы эксплуатации: обслуживание, обновления, расширение, интеграции, ремонт, обучение команды, вывод из эксплуатации. Поэтому сравнивать решения только по стартовой цене опасно. На горизонте 5–7 лет дешевый вариант может оказаться самым затратным, если запчасти становятся труднодоступными, поддержка дорожает, масштабирование требует дополнительных вложений, а любая доработка превращается в отдельный проект.
«Правильный вопрос — не сколько компания еще протянет на старом оборудовании, а сколько будет стоить следующий отказ и какой процесс он остановит. Если система формально работает, но восстановление после сбоя занимает все больше времени, поддержка дорожает, а запасные части приходится искать в авральном режиме, это уже не экономия. Это перенос расходов в будущее, причем в тот момент, когда у бизнеса будет меньше времени на выбор и больше потерь от простоя», — отмечает Владимир Кудряшов, директор сервисного департамента компании «ГИГАНТ Компьютерные системы».
Эта логика особенно важна для решений, которые формально еще работают, но уже становятся операционно опасными. Возраст оборудования сам по себе не является причиной модернизации. Критичнее другие признаки: система чаще ломается, восстановление занимает больше времени, поддержка старого решения приближается по стоимости к покупке нового, инфраструктура начинает тормозить запуск сервисов, а запчасти и квалифицированная поддержка становятся труднодоступными. В такой ситуации продолжать эксплуатацию не всегда значит экономить. Иногда это означает ждать момента, когда расходы придут уже в аварийном режиме.
Аудит инфраструктуры тоже должен быть не формальным отчетом, а инструментом для ответа на конкретный управленческий вопрос: менять оборудование сейчас или дожать еще год, усиливать резервирование или нет, перестраивать архитектуру под требования КИИ к определенному сроку, пересматривать договор поддержки или оставлять текущую модель. Для такого ответа нужны факты: срок жизни ключевого оборудования, статус поддержки вендора, уровень резервирования площадок, узкие места под пиковой нагрузкой, зависимость от отдельных специалистов, доступность запчастей и подрядчиков, статистика инцидентов за 12–24 месяца.
Именно статистика часто меняет разговор. Если за год произошло полтора-два десятка инцидентов, среднее восстановление занимает несколько часов, а два-три отказа реально останавливали бизнес-процесс, ИТ-директор получает не ощущение риска, а аргументы для бюджета. Тогда модернизация обсуждается не как «обновление железа», а как способ снизить конкретные потери.
«Аудит инфраструктуры должен отвечать на понятный для руководства вопрос: какие бизнес-процессы остановятся при отказе и сколько времени займет восстановление. Недостаточно увидеть, что оборудование устарело или система перегружена. Нужно связать техническое состояние с последствиями для продаж, производства, логистики, клиентского сервиса или выполнения обязательств. Тогда у собственника появляется не абстрактный отчет об ИТ-рисках, а основание для решения: что менять сейчас, что можно планировать на следующий бюджетный цикл, а где достаточно усилить поддержку», — заключает Владимир Кудряшов, директор сервисного департамента компании «ГИГАНТ Компьютерные системы».
При этом у компаний обычно нет дефицита технических данных. Мониторинг показывает загрузку процессоров, состояние дисков, свободное место, работу каналов и сервисов. Но не каждая метрика помогает принять управленческое решение. Зеленый дашборд не всегда означает устойчивость бизнеса, а высокая загрузка процессора важна не сама по себе, а как причина возможного сбоя: какой сервис замедлится, какой процесс остановится, какой SLA будет нарушен, какие расходы возникнут при отказе.
Поэтому стратегическое планирование инфраструктуры начинается не с выбора оборудования, а с проверки логики проекта. Что именно защищает модернизация: выручку, непрерывность процесса, выполнение требований, скорость запуска новых сервисов? Какой сбой она предотвращает и чем это подтверждено — статистикой инцидентов, сроками поддержки, стоимостью восстановления, зависимостью от поставщика или ограничениями текущей архитектуры?
Чем точнее собрана эта картина, тем сильнее позиция ИТ-директора в разговоре с руководством. Он приходит не с просьбой «обновить инфраструктуру», а с расчетом: вот цена аварии, вот стоимость профилактики, вот последствия отказа, вот горизонт владения. Для бизнеса это главный практический смысл инфраструктурного планирования — управлять стоимостью риска заранее, а не узнавать ее уже после простоя.