Цена простоя: как планировать ИT-инфраструктуру без аварийного бюджета

ИT-инфраструктура редко становится предметом большого управленческого разговора, пока она работает. Серверы обслуживаются, системы хранения отдают данные, сеть выдерживает нагрузку, пользователи получают доступ к сервисам. Для бизнеса это нормальное состояние, а не повод обсуждать архитектуру, резервирование или жизненный цикл оборудования. Отношение меняется в момент, когда технический сбой превращается в финансовую проблему. Клиент не может войти в личный кабинет, не проходит платёж, останавливается отгрузка, внутренний сервис перестаёт поддерживать операционный процесс. Тогда инфраструктуру начинают видеть не как вспомогательную функцию, а как часть бизнес-модели. В этом и есть развилка. Компания либо заранее считает цену риска и вкладывается в предотвращение проблем, либо экономит до тех пор, пока не приходится платить за последствия. Второй вариант почти всегда обходится дороже.

Директор сервисного департамента компании «ГИГАНТ Компьютерные системы» Владимир Кудряшов
Фото: «ГИГАНТ Компьютерные системы»

ИT-директор должен понимать не «всё ли в порядке», а сколько стоит час простоя конкретного сервиса. Считается это по довольно простой рамке: выручка или оборот процесса за час, умноженные на долю операций, которые встанут, плюс штрафы по SLA, плюс стоимость аварийного режима — срочная логистика запчастей, сверхурочная работа команды, привлечение подрядчика вне регламента. Когда стоимость простоя раскладывают так, для бизнеса с непрерывными операциями — скажем, круглосуточной отгрузкой или онлайн-обслуживанием клиентов — нередко выясняется неприятное: несколько часов недоступности ключевой системы обходятся дороже, чем годовой контракт на резервирование, который до этого считали «дорогим».

Дальше та же логика разворачивается в план восстановления. Какие сервисы встанут первыми, какой у них целевой RTO (время восстановления) и RPO (допустимая потеря данных), кто именно устраняет инцидент, доступны ли запчасти, подрядчики и поддержка вендора в нужный срок. Если на эти вопросы нет ответа в деньгах и в часах, разговор неизбежно скатывается к техническим аргументам: «надо обновить», «усилить резерв», «заменить СХД». Для бизнеса это выглядит как техническая заявка на новый бюджет.

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

Почему компании начинают действовать слишком поздно

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

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

Это слабое место многих компаний: они начинают планировать не тогда, когда видят проблему на горизонте планирования, а тогда, когда она уже пришла в повестку. И самый показательный пример того, как «требование регулятора» из абстракции превращается в календарный срок, — это история с вендорозависимостью.

Зависимость от одного вендора стала измеримым риском

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

Для значительной части наших заказчиков к рыночной неопределенности добавились требования регуляторов, и здесь срок уже не «когда-нибудь», а календарный. С 1 января 2025 года для органов государственной власти и заказчиков действует запрет на использование иностранного ПО на принадлежащих им значимых объектах КИИ, если иное не установлено федеральным законом. Отдельно действует запрет на применение средств защиты информации из недружественных стран.

Поблажек регуляторы больше не делают: нарушения в области безопасности КИИ уже не только технологический и управленческий риск, но и административная ответственность. По статье 13.12.1 КоАП штрафы для юридических лиц по отдельным составам могут достигать 500 тыс. рублей. Для доверенных программно-аппаратных комплексов на значимых объектах КИИ переходный период установлен до 1 января 2030 года, но это не отменяет главного: новые закупки и перестройку стека нужно планировать уже сейчас. Дедлайн назначен не ИT-службой, а государством.

Отсюда практический вывод: устойчивость не должна держаться на одном поставщике, подрядчике или инженере, который «всё знает». Мы в «ГИГАНТЕ» прошли этот путь не только как интегратор, но и как производитель — наши рабочие станции и моноблоки включены в Реестр Минпромторга, и мы видим спрос на замену импортного парка изнутри. Поэтому в проектах мы закладываем технологическую независимость в саму архитектуру: совместимость с российскими ОС из реестра Минцифры, документированную модель эксплуатации и расчет жизненного цикла, в котором замена компонента не означает перестройку половины контура.

Стабильность, безопасность и развитие тянут бюджет в разные стороны

Бизнес хочет сразу трёх вещей: чтобы сервисы не падали, данные и процессы были защищены, а новые продукты выходили быстро. В реальности эти цели конфликтуют. Стабильность требует осторожности. Безопасность требует контроля. Развитие требует изменений. А бюджет один.

У безопасности есть понятный аргумент — требование регулятора. У развития есть сильный внутренний заказчик: бизнес-подразделение, которое ждёт новый сервис, рост продаж или сокращение издержек. Стабильность защищать сложнее. У неё нет такого яркого лоббиста, поэтому расходы на резерв, запасные части, поддержку и профилактику первыми попадают под сокращение.

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

Главная ошибка — считать только закупку

Многие стратегические ошибки в инфраструктуре появляются не из-за плохих технологий, а из-за короткого горизонта планирования.

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

Поэтому корректное сравнение — это совокупная стоимость владения (TCO) за весь горизонт, обычно 5-7 лет. Именно на этой дистанции «выгодная» закупка нередко обгоняет «дорогую» — и решение, которое казалось экономией, оказывается самым затратным вариантом.

Технический долг становится проблемой, когда его переводят в деньги

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

Пока ИT говорит о техническом долге техническим языком, руководство реагирует слабо. Слова «система устарела», «растёт риск отказа», «нужно обновление» сами по себе редко пробивают бюджет.

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

Дожимать старое оборудование — не всегда экономия

Модернизация нужна не потому, что оборудование достигло определённого возраста. Граница проходит там, где дальнейшая эксплуатация становится экономически или операционно опасной.

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

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

Аудит должен отвечать на вопрос, а не создавать том отчёта

Самый слабый аудит начинается с фразы «нам нужен аудит». На выходе появляется толстый документ, который ложится в архив и ни на что не влияет. Нормальный аудит начинается с управленческого вопроса, для ответа на который не хватает фактов: менять оборудование сейчас или дожать ещё год; усиливать резерв или нет; перестраивать архитектуру под требования КИИ к конкретному сроку; пересматривать договор поддержки. Под такой вопрос аудит собирает не «состояние вообще», а основания для действия. В нашей практике в этот минимальный набор входит:

• срок жизни ключевого оборудования и официальный статус поддержки вендора (действует / End of Sale / End of Support);
• уровень резервирования критичных площадок по классификации Tier (Uptime Institute и сопоставимые отраслевые требования): Tier II и Tier III - это разная допустимая длительность простоя;
• узкие места под пиковой нагрузкой и их связь с конкретным сервисом и SLA;
• bus factor - зависимость от отдельных специалистов, без которых восстановление встанет;
• реальная доступность запчастей, подрядчиков и поддержки - не «в принципе», а в сроках;
• статистика инцидентов за 12-24 месяца: что чаще выходило из строя, как быстро восстанавливали, чьими силами, где возникали задержки.

Последний пункт ценнее всего, потому что переводит разговор из «кажется, система устаревает» в цифры. В типичной картине это выглядит так: за год полтора-два десятка инцидентов, среднее время восстановления - несколько часов, и из всей этой массы два-три отказа реально останавливали бизнес-процесс, а не просто срабатывали как предупреждение. Именно такие факты нужны ИT-директору в разговоре с бизнесом - не общая оценка «всё плохо» или «в целом работает», а данные, которые можно связать с риском, сроком и деньгами.

Метрик много, управленческих данных мало

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

Зелёный дашборд не всегда означает устойчивость бизнеса. Высокая загрузка процессора важна не сама по себе, а как причина будущего сбоя: какой сервис замедлится, какой процесс остановится, какой SLA будет нарушен, какие затраты возникнут при отказе. Мониторинг отвечает на вопрос, что происходит с системой. Для стратегического решения нужно понять, что это означает для компании.

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

Планирование начинается с неудобных вопросов

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

Чем точнее собрана эта картина, тем сильнее позиция ИT-директора. Он приходит к руководству не с просьбой «обновить железо», а с расчётом: вот цена аварийного сценария, вот стоимость профилактики, вот последствия отказа, вот горизонт владения.

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

Автор: Владимир Кудряшов, директор сервисного департамента компании «ГИГАНТ Компьютерные системы»