Рейтинговые агентства оценивают не прибыль за последний квартал, а способность обслуживать обязательства. Компания может быть прибыльной и получить понижение, потому что структура её обязательств перестала сходиться с её возможностями. У инфраструктуры есть ровно такой же рейтинг, только его никто не считает и никто не публикует. Обязательства растут — регулятор, бизнес, рынок, — а способность их обслуживать определяется парком, купленным несколько лет назад под совсем другие требования.
Последние полтора года мы видим это почти в каждом проекте. Причём видим в пяти разных вариантах, и это не пять степеней запущенности, а пять разных состояний, в которых компания может находиться. Один заказчик заплатил вперёд. Второй расширяется под прогноз. Третий сознательно урезал проект и записал, чем платит. Четвёртый третий месяц не принимает решение. Пятый собрал инфраструктуру из того, на что хватало денег в каждый конкретный год. Ниже разбираем все пять — с цифрами, потому что без цифр это разговор про ощущения.
Все случаи обезличены до уровня региона. Названий, объёмов из схем и сумм здесь нет и не будет.
Как образуется долг
Планка выросла, парк остался
Почти каждое новое требование превратилось в постоянную строку расходов, а не в разовый проект.
Начнём с того, почему долг вообще образуется, хотя никто не совершает ошибок.
Посмотрите на требования 2020 года. Периметр закрывался межсетевым экраном без глубокой инспекции трафика, и этого хватало всем. Вторая площадка была пожеланием, а не обязательством: её планировали, о ней говорили, до неё доходили не всегда. Неизменяемые резервные копии были экзотикой, про которую рассказывали на конференциях. Объектное хранилище внутри компании почти не встречалось — S3 был словом из презентаций про публичное облако. Виртуализация была одна, в дешёвой редакции и с бессрочной лицензией, и вопрос «а что если» никому не приходил в голову. Ускорителей в бюджете не было вообще, потому что задач под них не было. Требования регулятора были мягче, а цена простоя — ниже.
Теперь посмотрите на требования 2026 года. Периметр — с инспекцией и контролем приложений. Две площадки — обязательство, причём с доказательством работоспособности переключения. Неизменяемые копии — пункт в техническом задании, а не пожелание. Объектное хранилище — рабочий инструмент, на него уже пишут архивы и резервные копии. Виртуализация — подписка, срок которой надо совмещать со сроком жизни версии. Ускорители — отдельная строка бюджета, под которую надо найти киловатты. Регуляторные требования жёстче, цена простоя выше.
Самое важное в этой картинке — не то, что требований стало больше. Важно, что почти каждое из них превратилось в постоянную строку расходов, а не в разовый проект. Вторая площадка — это не закупка, это вторая площадка навсегда: питание, каналы, лицензии, люди, регламенты. Подписка — это платёж, который не кончается. Неизменяемые копии — это ёмкость, которую нельзя переиспользовать по ходу дела.
Отсюда рабочее определение, которым мы дальше пользуемся. Инфраструктурный долг — это разница между тем, что парк умеет сегодня, и тем, что от него сегодня требуют. Проценты по этому долгу платятся не деньгами, а ограничениями: чем больше разрыв, тем меньше у вас остаётся допустимых следующих шагов. А инфраструктурный дефолт — это момент, когда допустимых шагов не осталось ни одного, и единственный доступный вариант — заменить всё целиком, сразу и дорого.
И сразу оговорка, без которой дальше будет непонятно. Долг сам по себе не порок. Любая инфраструктура его имеет, потому что требования меняются быстрее, чем амортизируется железо. Вопрос только в том, знаете ли вы свой долг, записан ли он и заложен ли в план.
Пять состояний на шкале: аванс, рост под прогноз, реструктуризация, отложенное решение, вынужденная лоскутность. Дальше по одному разделу на каждое.
Состояние первое
Аванс: заплатить до того, как понадобится
Выход из аренды заставил строить сразу и целиком. Каждый шестой узел парка не несёт прикладной нагрузки — и это осознанно.
Первый заказчик выходил из арендованного облака на собственное железо. Решение принималось один раз и целиком, поэтому и парк построен один раз и целиком: три площадки, больше 40 рабочих узлов и отдельно по 3 узла кластера управления на каждой.
Вот эти узлы управления — самая показательная часть всего выпуска. Каждый шестой узел парка не несёт ни одной прикладной виртуальной машины. Он существует ради того, чтобы площадкой можно было управлять отдельно от остальных: обслуживать, обновлять, отключать, не завися от соседей. В долговом сценарии на этом экономят первым делом — управление подселяют к продуктивной нагрузке, потому что так дешевле на старте, — и потом годами не могут вывести площадку в обслуживание, не затронув продуктив.
Второе, за что здесь заплачено вперёд, — незанятый запас. Нагрузка по трём площадкам распределена примерно как 65-17-17: одна работает, две почти пустые по построению. При этом около 71% затрат на электричество фиксированы и не зависят от того, есть ли на узле нагрузка. То есть аванс платится не только капиталом при закупке, но и каждый месяц в счёте за электричество.
Третье наблюдение — про физику. Один из кластеров, а это полтора десятка узлов, пришлось разнести на две стойки, и не потому, что не хватило юнитов, а потому что не хватило ввода. Это тот же самый предел, который в запущенных случаях выглядит как «расширение не проходит»: просто здесь в него упёрлись на входе, когда ещё можно было спроектировать, а не на пятый год, когда уже нельзя.
У аванса есть собственный сценарий отказа, и мы бы не стали делать вид, что его нет. Если рост не придёт в расчётные сроки, площадка с загрузкой 17% будет стоить денег каждый месяц, а к четвёртому-пятому году парк начнёт устаревать, так и не дойдя до проектной нагрузки. Аванс оправдан ровно настолько, насколько обоснован прогноз, под который он сделан.
Но у этого заказчика есть и ответ на такой упрёк. Параллельно построена независимая адресация с мультихомингом по BGP, и это меняет саму схему работы площадок: нагрузку планируется расселить по всем трём ровным слоем, чтобы ни одна не была основной, а все три — равновесными. Тогда распределение 65-17-17 перестаёт быть картиной «одна работает, две ждут» и становится переходным состоянием. Это, кстати, лучший ответ на вопрос, зачем платить за незанятый запас: за него платят не ради страховки, а ради того, чтобы площадки стали взаимозаменяемыми.
Состояние второе
Рост под прогноз: расширение с обоснованием
Резерв, который принимает половину нагрузки, превращается в тыкву ровно тогда, когда он нужен.
Второй случай — компания с быстро растущей клиентской базой. Порядок величин такой: несколько сотен тысяч клиентов летом 2026 и примерно пятикратный рост за полтора года по плану. При таком прогнозе спорить про «а нужно ли расширяться» бессмысленно, спор идёт только про то, как именно.
Исходно площадки были несимметричными: основная несла нагрузку, резервная стояла горячим резервом с загрузкой в единицы процентов. Расширение считалось не по принципу «добить основную», а до паритета — чтобы резервная площадка принимала всю нагрузку основной, а не её половину. Это дороже, и это правильно: резерв, который принимает половину, при настоящей аварии превращается в тыкву ровно в тот момент, когда он нужен.
И ещё одно решение в этом проекте нам нравится, потому что оно про долг, а не про спецификацию: ёмкость разбита на две поставки — часть сразу, остаток через несколько кварталов, под фактический рост, а не под красивую цифру в спецификации.
А теперь про то, чего в этом проекте не видно в железе. Лицензии на виртуализацию куплены в январе 2025 подпиской на 3 года, то есть оплачены до начала 2028. Срок общей поддержки той ветки платформы, которая развёрнута на площадках, заканчивается осенью 2027. То есть версия выйдет из поддержки раньше, чем кончится оплаченный срок, и переход на следующую ветку придётся делать внутри него — с обновлением железа там, где оно в список совместимости уже не попадает.
Это, кстати, ответ на популярный аргумент «возьмём редакцию попроще, она дешевле». Дешёвая редакция перестаёт существовать быстрее, чем вы успеваете на ней сэкономить: младшие варианты постепенно выводятся из продажи, новые версии выходят только в составе старших наборов, а поддержка текущей ветки заканчивается по собственному календарю, которому всё равно, когда вы покупали. Срок жизни вашей инфраструктуры считается не по дате окончания договора, а по дате окончания поддержки версии. Это разные даты, и вторая обычно ближе.
Состояние третье
Реструктуризация: долг, взятый осознанно
Объём данных вырос в 5 раз, бюджет не вырос. Разница между реструктуризацией и урезанием сметы — в том, записано ли решение.
Третий случай — проект резервного копирования, который по ходу подготовки пришлось сокращать. Объём защищаемых данных за время проработки вырос примерно в 5 раз, а бюджет не вырос вовсе. Обычная ситуация, и обычно она заканчивается тем, что режут по живому: убирают лицензии, убирают вторую площадку, убирают ленту.
Здесь сделали иначе. Лицензии и серверы копирования на обеих площадках оставили по исходному заданию — то есть логика решения не пострадала. Сократили другое: ленточная библиотека прошлого поколения переезжает на резервную площадку вместо новой закупки, существующий массив с дисками большой ёмкости подключается холодным слоем вместо нового, коммутаторы фабрики не закупаются, потому что свободных портов на обеих площадках достаточно.
Что это на самом деле означает. Заказчик взял долг сознательно: часть инфраструктуры резервного копирования теперь стоит на оборудовании прошлого поколения, у которого свой срок и свой ЗИП. Но этот долг посчитан, записан и подкреплён аргументом: основные системы уже реплицируются между площадками своими средствами, вне системы копирования, поэтому отсутствие быстрого слоя на резервной площадке не оставляет дыру, а создаёт ограничение по скорости восстановления, и это ограничение известно заранее.
Разница между реструктуризацией и обычным урезанием сметы ровно в этом: в одном случае вы знаете, чем заплатили, и можете вернуться к этому через год, в другом — через год удивляетесь.
Состояние четвёртое
Отложенное решение: полторы сотни узлов без поддержки
Парк выглядит однородным в учёте и распадается на три группы в эксплуатации. Решение не принимается третий месяц.
Четвёртый случай — самый неприятный, потому что в нём ничего не происходит. Парк закуплен в 2022 году: около 150 узлов одного поколения одной платформы, больше десяти позиций закупки. Несколько месяцев назад закончилась поддержка. Решение — продлевать или менять — не принято до сих пор.
Сначала про то, что именно потеряно. Без действующего контракта теряется вся сервисная поддержка железа: нельзя открыть обращение, нельзя получить замену комплектующих. Не часть функций, а всё. При этом окно на постгарантийное обслуживание открыто всегда, то есть дверь не захлопнулась — вернуться можно в любой момент, и это важная деталь, потому что она превращает ситуацию из безвыходной в отложенную.
Теперь про состав, и это главное открытие этого случая. Парк выглядит однородным: одна платформа, один год, один вендор. В учёте это одна-две строки. В эксплуатации это три разные группы по назначению:
- около 90 узлов — аппаратные узлы под одну платформу виртуализации;
- примерно 50 узлов — аппаратные узлы под другую платформу виртуализации;
- десяток обычных серверов под отдельные задачи.
Причём почти половина всего парка приходится на одну-единственную позицию закупки.
Дальше начинается интересное. Роль определяет обвязку, а обвязка определяет всё остальное. Узлы под гиперконвергентную платформу привязаны к её списку совместимости: замена накопителя или сетевой карты решается не наличием на складе, а тем, что платформа поддерживает. Узлы второй группы привязаны и к списку совместимости, и к лицензионному календарю своей платформы — на них сходятся сразу два долга. Обычные серверы третьей группы привязаны к жизненному циклу приложений, которые на них живут, и ни к чему больше.
Получается, что у трёх групп разные сроки замены и разные триггеры. И пока на парк смотрят как на полторы сотни узлов, решение выглядит неподъёмным: одна большая сумма против маленького регулярного платежа за поддержку, а промежуточного варианта в голове нет. Если разложить по группам — появляются три отдельных шага с разными сроками, и каждый из них считается отдельно. Начинать при этом логично с самой крупной позиции: она одна определяет половину ответа.
Есть и второй слой, который в учёте не виден совсем. Узлы куплены разом, но вводились в работу не разом: развёртывание растянулось больше чем на 3 года, по мере надобности. Гарантия и поддержка при этом шли от даты поставки, то есть часть оплаченного срока была потрачена на оборудование, которое просто стояло и ждало своей задачи. Лицензии докупались по мере ввода узлов, и цикл лицензии был зафиксирован на год. Получается наложение: железо стареет от одной даты, лицензии живут от разных, а платформа за эти годы ушла вперёд по версиям, пока последние узлы только вводились.
И ещё одно следствие, которое мы бы запомнили отдельно. Весь парк куплен в один год, а значит вентиляторы, накопители и блоки питания вырабатывают ресурс синхронно. Отказы придут не равномерно по годам, а окном. Без действующего контракта это окно вы встречаете своим складом и своими руками.
Состояние пятое
Вынужденная лоскутность: когда каждый шаг был разумным
Каждый шаг по отдельности был правильным. Сумма шагов дала конструкцию с действующим риском.
Пятый случай начинался лучше всех. В 2020 году — компактный гиперконвергентный кластер из 5 узлов, отдельное хранилище под резервные копии, ленточная библиотека. Нормальная архитектура своего времени, с правильно расставленными приоритетами.
Потом просело финансирование ИТ. Дальше каждый шаг делался из доступного, и каждый по отдельности был разумным. Понадобились ресурсы — собрали второй кластер, десяток серверов другого вендора на другой платформе виртуализации, потому что так выходило дешевле. Не хватило ёмкости — подключили к нему массив, хотя платформа рассчитана на локальные диски. Базы данных жили на отдельных серверах, купленных отдельно в третий раз и по третьему случаю.
Итог — три острова. Две гиперконвергентные платформы в двух разных сегментах сети плюс серверы баз данных. И связь между сегментами идёт не через одно устройство, а через каскад межсетевых экранов, в котором нет резервирования.
Вот это и есть единственный случай из пяти, где риск не отложенный, а действующий. Во всех предыдущих речь про «через год упрётся» или «на четвёртый год станет дорого». Здесь отказ любого устройства в каскаде разрывает связь между сегментами прямо сегодня, а чем длиннее каскад, тем больше в нём таких устройств. Причём это не следствие чьей-то некомпетентности: недублированный узел появился ровно потому, что второй сегмент вообще не планировался, он возник как вынужденное решение по деньгам.
И отдельно — про зеркальность с предыдущим случаем. Там одна платформа под три роли, здесь три платформы под одну роль. Кажется, что это противоположные ошибки, но результат одинаковый: парк, который невозможно ни развить одним ходом, ни заменить одним ходом. Унификация платформы — это не унификация парка, а разнообразие платформ — не гибкость.
Унификация платформы — это не унификация парка, а разнообразие платформ — не гибкость.
Сетевой долг
Сеть отдаёт долг последней
Коммутатор просто работает — ровно до того дня, когда в него нужно воткнуть что-то новое.
Про сеть в таких разговорах вспоминают в последнюю очередь, и это само по себе диагноз. Сервер устаревает заметно: у него кончается поддержка, он не проходит по списку совместимости, он шумит и греется. Коммутатор просто работает. Он работает десять лет, он работал вчера, он работает сегодня, и никаких поводов его трогать нет — ровно до того дня, когда в него нужно воткнуть что-то новое.
Смотрим на два ЦОД одного заказчика. Фабрика собрана из смеси оборудования: часть снята с продаж и поддержки производителем, часть — бюджетные коммутаторы, которые ставили как временное решение. Потолок фабрики — 10G. Периметр без межсетевого экрана нового поколения. Управление ручное, единой системы нет. Всё это годами никого не беспокоило, потому что сеть работала.
А потом в том же году заказчик закупает серверы баз данных и сервер под ИИ, и у всех у них сетевые карты 25G. Втыкать их некуда. В этот момент сетевой долг из абстракции превращается в цифру: новый сервер стоит в стойке и работает вчетверо медленнее, чем мог бы, либо не работает вовсе, пока не заменена фабрика. Причём замена фабрики — это не докупка узла в кластер, это окно, в которое встаёт всё.
Второй пример мельче, но показательнее, потому что в нём считается риск, а не скорость. Офисная сеть, всё ядро — один 10G-коммутатор. Запасного такого же в маневровом фонде нет: фонд состоит из оборудования попроще, у которого и портов меньше, и межкоммутаторные линки вчетверо у́же. То есть при отказе ядра сеть восстановится, но в деградированном виде, и заранее это никем не посчитано.
У сетевого долга две особенности, из-за которых он опаснее серверного. Первая: сеть отдаёт долг последней, потому что её замена требует остановки всего, а не части. Вторая: сетевой долг обнаруживается не в отчёте, а в чужом проекте — когда серверная закупка уже сделана, деньги потрачены, а воткнуть железо оказывается некуда. Поэтому список сроков поддержки по фабрике и по периметру нужно вести ровно так же, как по серверам, и пересматривать его перед каждой серверной закупкой, а не после.
Метрики
Чем измерять долг
Возраст оборудования — плохая метрика. Мерить надо разрыв между тем, что парк умеет, и тем, что от него требуют.
Возраст оборудования — плохая метрика. Пятилетний узел, который делает ровно то, что от него требуют, долгов не создаёт. Трёхлетний, который не проходит по требованиям регулятора, создаёт. Мерить надо разрыв, а не годы.
Первое измерение — возрастная структура парка по потреблению, а не по количеству. У одного из заказчиков на площадке четыре стойки, больше 80 юнитов оборудования, около 25 kW в типовой работе. Из них серверы 2015 года дают больше половины всего потребления площадки. Ещё примерно 19% мощности приходится на сетевое оборудование, половина которого выпущена больше десяти лет назад. Это значит, что производственная база компании физически одиннадцатилетняя, а любой новый проект въезжает в остаток от неё.
Второе измерение — запас, посчитанный на отказ узла, а не на сегодняшний день. Смотрим на кластер из 9 узлов, 508 виртуальных машин. Сейчас: по процессорам 59,4%, по памяти 62,8%, по сырой ёмкости 55,7%. Выглядит спокойно. Пересчитываем то же самое на 8 узлов, то есть на отказ одного: 66,9%, 70,7% и 62,6%. Спокойствие заканчивается — запас по памяти в режиме N-1 остаётся меньше 30%, и упрётся кластер именно в память.
А теперь то, что превращает эту таблицу из наблюдения в срок. Кластер начал активно заполняться в марте. Вся эта загрузка набрана примерно за полгода, и при сохранении темпа расширение нужно не в следующем бюджетном цикле, а сейчас: пока оборудование пройдёт закупку, поставку и ввод, запаса на отказ узла уже не останется.
Кластер заполнился за полгода. При том же темпе расширение нужно не в следующем бюджетном цикле, а сейчас.
Третье измерение — симметрия площадок относительно прогноза нагрузки, а не относительно сегодняшнего дня. Вопрос простой: если основная площадка исчезнет в тот момент, когда клиентская база вырастет вдвое, резервная примет всё или половину?
Четвёртое измерение — календарь поддержки против горизонта планов. Дата окончания поддержки версии, дата окончания контракта на железо, срок подписки и срок амортизации — это четыре разные даты, и совпадают они редко. Разложите их на одной шкале, и станет видно, какой из них наступит первым.
Дефолт
От долга к техническому дефолту
Важен не размер разрыва, а число способов его закрыть. Каждое отложенное решение убирает один.
Теперь соберём всё на одной шкале. В день закупки долга нет: парк ровно соответствует требованиям, под которые покупался. Дальше требования начинают расти ступенями — новый регламент, новая система, новая планка по защите периметра, новая версия платформы. Возможности парка при этом не растут, а медленно снижаются: выходит из поддержки версия, заканчивается контракт на железо, исчерпывается ввод по питанию и порты в фабрике.
Долг начинается в точке, где эти две линии расходятся. Он ещё ничего не ломает и не виден в мониторинге — просто с этого момента у вас появляется разрыв, который нужно чем-то закрывать. Дальше важно не то, насколько разрыв велик, а сколько у вас остаётся способов его закрыть. Сначала их много: продлить поддержку, доложить узлы, перераспределить нагрузку, перенести часть на вторую площадку, отложить на квартал. Каждое пропущенное решение убирает один способ.
Технический дефолт — это состояние, в котором способов не осталось ни одного. Расширение не проходит по вводу, поддерживаемой версии для вашей ветки больше не продают, поддержку на железо надо восстанавливать через инспекцию, сеть не держит скорость нового оборудования, а восстановление не укладывается в норматив. Каждое из этих событий по отдельности решаемо, и именно поэтому каждое по отдельности откладывается. Вместе они складываются в ситуацию, где единственный доступный вариант — заменить всё сразу, целиком и на максимуме цены.
И это не гипотетическая точка в будущем. Мы видели её вживую: парк, доживший до момента, когда смена прикладного софта оказалась возможна только через полную выгрузку данных. Не миграция, не переезд, а перезаливка всего с нуля — потому что ни одного промежуточного пути к тому моменту уже не осталось.
Чек-лист
Что проверить у себя
Тринадцать вопросов, после которых становится видно, в каком состоянии находится ваш парк.
- Какие требования появились к вашей инфраструктуре за последние 5 лет и какие из них стали постоянной строкой расходов, а не разовым проектом.
- Сколько узлов вашего парка не несёт прикладной нагрузки и почему — это осознанный аванс или случайность.
- Какая доля потребления площадки приходится на оборудование старше 7 лет и отдельно на сетевое оборудование.
- Чему равна загрузка кластера при отказе одного узла и какой ресурс при этом заканчивается первым.
- С какой скоростью кластер заполнялся последние полгода и когда при этом темпе он упрётся в режим N-1.
- Примет ли резервная площадка всю нагрузку основной при прогнозной нагрузке через 2 года, а не при сегодняшней.
- Когда заканчивается общая поддержка версий платформ, которые у вас развёрнуты, и совпадает ли это со сроком ваших подписок.
- Есть ли действующий контракт на поддержку по каждой группе оборудования и что именно вы теряете там, где его нет.
- На сколько разных групп по назначению распадается ваш парк, если смотреть не на модель, а на то, чем определяется замена детали.
- Какая доля парка куплена в один год и когда ожидается синхронная выработка ресурса расходных компонентов.
- Какой потолок скорости у вашей фабрики и совпадает ли он с картами серверов, которые вы закупаете в этом году.
- Сколько у вас недублированных элементов на путях между сегментами и какие из них появились как вынужденное решение.
- Какие ваши сокращения сметы за последние 3 года записаны с обоснованием, а какие просто произошли.
Итог
Вместо вывода
Пять состояний из этого выпуска — не рейтинг заказчиков и не шкала от плохого к хорошему. Это пять способов обойтись с одной проблемой: требования растут быстрее, чем железо амортизируется. У каждого варианта своя цена и свой сценарий отказа. Плохих здесь по-настоящему два, и оба узнаются по одному признаку: никто не может сказать, чем именно компания заплатила.
Технический дефолт наступает не тогда, когда отказывает железо. Железо отказывает всегда, к этому есть ЗИП, резерв и регламент. Дефолт наступает тогда, когда перестают принимать решение — и однажды обнаруживают, что выбирать больше не из чего.
Хорошая новость в том, что инфраструктурный рейтинг, в отличие от финансового, считаете вы сами. Достаточно раз в год раскладывать парк по группам, а даты — по одной шкале. Если после этого у вас есть три посильных шага вместо одного непосильного, долг управляемый. Если шаг остался один и он неподъёмный — вы уже знаете, в каком вы состоянии. Хотите разобрать свой случай — пишите, разложим по тем же четырём измерениям.