CAPEX в ИТ: собственник покупает устойчивость

Инвестиционный бюджет на резервное копирование несколько лет подряд подавался наверх.

И несколько лет подряд его не защищали.

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

И в этом был главный разрыв.

ИТ говорило: «нам нужна копия».

Собственник слышал: «мы хотим потратить деньги на еще один технический контур».

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

Проблема не в том, что собственник не понимает ИТ.

Проблема в том, что ИТ само объясняет CAPEX так, будто покупает железо.

А в реальности покупают не железо.

Покупают время, за которое бизнес должен вернуться в рабочее состояние.

Почему «у нас будет копия» - слабый аргумент

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

Формулировка почти не менялась.

Нужно купить оборудование.

Нужно сделать резервную копию.

Будет отказоустойчивость.

На уровне ИТ это звучало логично. На уровне собственника - нет.

Потому что «будет копия» сама по себе не отвечает ни на один бизнес-вопрос.

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

Пока этих ответов нет, CAPEX выглядит как покупка дорогой коробки.

А собственник почти всегда будет резать дорогую коробку, если не видит за ней защищенный денежный поток.

Момент истины: backup был, восстановления не было

Я начал не с нового бюджета.

Я начал с проверки текущей реальности.

Резервное копирование формально было. Копии создавались. Отчеты выглядели приемлемо. Но при разборе обнаружилась базовая проблема: копии лежали в том же контуре, на тех же дисках и серверах, которые участвовали в основной работе.

То есть авария основного контура могла забрать с собой и рабочую систему, и резерв.

Для отчета backup был.

Для восстановления бизнеса - нет.

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

Для ИТ это инцидент.

Для бизнеса - минус день продаж.

И вот здесь важно перевести в деньги. Если брать рыночный ориентир по плотности продаж FMCG-сетей, супермаркет площадью 900-1000 кв. м может давать порядка 30-35 млн рублей выручки в месяц. Один день простоя - это до 1-1,2 млн рублей оборота под риском. Часть спроса вернется позже. Часть уйдет конкурентам. Но в момент аварии компания теряет управляемость продажами, остатками и учетом - и это само по себе стоит денег.

Пока мы обсуждали «систему резервного копирования», собственник видел расход. Когда мы начали обсуждать «день продаж, который компания теряет при полном разрушении контура», появился бизнес-смысл.

Проверка восстановлением ломает красивую теорию

Следующий шаг был неприятный, но обязательный.

Мы взяли копию, вынесенную за пределы основного контура, и начали считать не создание backup, а восстановление.

На бумаге все выглядело управляемо.

В реальности детальный план восстановления всего контура показал срок около двух недель.

Потом мы собрали тестовый контур и провели эксперименты. Задача была минимальная: поднять только то, что нужно для работы бизнеса - прием товара, отгрузку, продажи, оплату счетов и зарплаты.

В тестовом восстановлении на это ушло пять недель.

Формально данные были. Формально копии были. Но бизнес не покупает факт наличия копии.

Бизнесу нужно другое.

Чтобы касса работала.

Чтобы магазин мог продавать.

Чтобы склад мог принимать и отгружать.

Чтобы учет не превращался в ручную реконструкцию.

Чтобы финансовый контур понимал, что произошло с деньгами, товаром и обязательствами.

Именно поэтому ценность backup появляется не в момент создания копии.

Она появляется в момент проверенного восстановления.

Как я перевел бюджет с языка железа на язык бизнеса

После проверки стало понятно: защищать старый бюджет в прежнем виде бессмысленно.

Нужно было пересобрать саму логику разговора.

Я выделил критичные сервисы и контуры. Разделил их не по технической архитектуре, а по бизнес-влиянию.

Одно дело - сервис, без которого офису неудобно.

Другое - сервис, без которого магазин не продает.

Третье - система, без которой потом невозможно нормально восстановить учет, остатки, движение товара и финансовую картину.

После этого появились нормальные вопросы:

• Какой RTO нужен для критичных сервисов?
• Какой RPO допустим для данных?
• Какие сценарии аварии мы реально закрываем?
• Что восстанавливаем в первые часы?
• Что можно поднять в течение двух суток?
• Что допустимо восстановить позже?
• Где нужна собственная инфраструктура, а где можно использовать аренду оборудования?
• Какие копии должны физически уходить за пределы компании?

Так CAPEX перестал быть строкой «на серверы».

Он стал картой последствий.

Формула стала простой

Для собственника расчет должен быть не техническим, а управленческим.

Не «столько стоит СХД».

Не «столько стоит ленточная библиотека».

Не «столько стоит лицензия».

А так:

Эффект = предотвращенная стоимость аварии - стоимость резервирования.

Стоимость аварии я раскладывал на понятные компоненты:

• потерянный оборот за время простоя
• ФОТ людей, которые не могут нормально работать
• стоимость аварийного восстановления
• срочные закупки по худшей цене
• работа подрядчиков в пожарном режиме
• штрафы и обязательства перед контрагентами
• ручное восстановление учета
• риск потери данных
• управленческая цена хаоса, когда никто не понимает, какая версия данных правильная

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

Это уже был другой разговор.

Не «дайте денег на ИТ».

А «вот сценарий аварии, вот цена простоя, вот варианты защиты, вот стоимость каждого варианта, вот остаточный риск».

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

Почему нельзя покупать «мерседес» и нельзя брать «рено логан»

После расчетов у нас было несколько вариантов.

Можно было сделать дорогой идеальный контур.

Можно было сделать минимальное решение, чтобы формально закрыть вопрос.

Оба варианта были плохими.

Первый перегружал инвестицию. Второй оставлял бизнес с иллюзией защиты.

Мне нужен был не «мерседес» и не «рено логан».

Нужна была «камри».

Достаточно надежно, чтобы закрыть реальные сценарии риска. Достаточно экономически обоснованно, чтобы собственник понимал, за что платит. Достаточно управляемо, чтобы команда могла не только купить оборудование, но и регулярно проверять восстановление.

В итоговой политике восстановления мы зафиксировали другую логику:

• критичные сервисы должны подниматься в коротком окне
• основной рабочий контур должен возвращаться не «когда получится», а в управляемый срок
• копии должны уходить за пределы основного контура
• для части сценариев нужно использовать отчуждаемое хранение
• проверка восстановления должна быть частью процесса, а не разовым упражнением перед защитой бюджета

Неожиданный финал

Когда я показал собственнику текущую картину, разговор изменился.

Он увидел не «инвестицию в миллионы».

Он увидел стоимость страховки от потери бизнеса в момент сбоя.

Итоговый согласованный бюджет оказался в 2,5 раза выше первоначального запроса.

Это важный управленческий момент.

Он согласовал не более дорогую версию ИТ-хотелки. Он согласовал меньший остаточный риск.

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

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

На бумаге мы покупали серверы, носители, лицензии и регламент.

По факту покупали время, за которое бизнес не падает в ручное восстановление.

Что изменилось после проекта

После пересборки подхода резервное копирование перестало быть технической процедурой «для ИТ».

Оно стало частью контура управляемости.

Критичные сервисы получили понятные целевые параметры восстановления. Доступность ключевых контуров была доведена до 99,9%. В отдельных контурах восстановление критичных сервисов стало занимать меньше часа.

Главное изменение было даже не в цифрах.

До проекта компания жила в логике: «у нас вроде бы есть backup».

После проекта появилась другая постановка: «мы знаем, что восстанавливаем, в каком порядке, за какое время и с каким допустимым уровнем потерь».

Это разные уровни зрелости.

Вывод

Есть компании, которые делают резервные копии.

И есть компании, которые пока не проверяли, смогут ли из них восстановиться.

Разница между ними видна не в отчете ИТ.

Она становится видна в день аварии.

Отказ от CAPEX не отменяет расход. Он переносит его в будущее. Только в будущем это уже не плановая инвестиция, а аварийная закупка, простой, ручное восстановление, потеря продаж и управленческий хаос.

Плановый CAPEX почти всегда выглядит дорогим до аварии.

После аварии дорогим выглядит уже отказ от него.

Собственник покупает не железо.

Он покупает устойчивость, скорость восстановления и управляемость в момент, когда бизнесу некогда разбираться, кто был прав в бюджетном комитете.

Если компания не знает, за сколько восстановит критичные сервисы, у нее нет настоящего контроля над непрерывностью бизнеса. Можно иметь отчеты. Можно иметь копии. Можно иметь красивые SLA в договоре с подрядчиком. Но если восстановление не проверено - бизнес покупает не устойчивость, а надежду.

А надежда плохо работает в момент инцидента.