01

Как образуется долгЯк утворюється боргHow the debt forms

Планка выросла, парк остался

Планка зросла, парк залишився

The bar rose, the estate stayed

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

Майже кожна нова вимога перетворилася на постійний рядок витрат, а не на разовий проєкт.

Almost every new requirement became a permanent cost line rather than a one-off project.

Начну с того, почему долг вообще образуется, хотя никто не совершает ошибок.

Почну з того, чому борг взагалі утворюється, хоча ніхто не робить помилок.

Let me start with why the debt forms at all, even though nobody makes any mistakes.

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

Подивіться на вимоги 2020 року. Периметр закривався міжмережевим екраном без глибокої інспекції трафіку, і цього вистачало всім. Другий майданчик був побажанням, а не зобов’язанням. Незмінні резервні копії були екзотикою, про яку розповідали на конференціях. Об’єктне сховище всередині компанії майже не траплялося. Віртуалізація була одна, у дешевій редакції і з безстроковою ліцензією, і питання «а що як» нікому не спадало на думку. Прискорювачів у бюджеті не було взагалі, бо задач під них не було.

Look at the requirements of 2020. The perimeter was covered by a firewall without deep traffic inspection, and that was enough for everyone. A second site was a wish rather than an obligation. Immutable backups were an exotic topic discussed at conferences. Object storage inside a company was almost unheard of. There was one virtualisation platform, in a cheap edition with a perpetual licence, and the question “what if” occurred to nobody. Accelerators were not in the budget at all, because there was nothing to run on them.

Теперь посмотрите на требования 2026 года. Периметр — с инспекцией и контролем приложений. Две площадки — обязательство, причём с доказательством работоспособности переключения. Неизменяемые копии — пункт в техническом задании. Объектное хранилище — рабочий инструмент, на него уже пишут архивы и резервные копии. Виртуализация — подписка, срок которой надо совмещать со сроком жизни версии. Ускорители — отдельная строка бюджета, под которую надо найти киловатты.

Тепер подивіться на вимоги 2026 року. Периметр — з інспекцією і контролем застосунків. Два майданчики — зобов’язання, причому з доказом працездатності перемикання. Незмінні копії — пункт у технічному завданні. Об’єктне сховище — робочий інструмент, на нього вже пишуть архіви й резервні копії. Віртуалізація — підписка, строк якої треба суміщати зі строком життя версії. Прискорювачі — окремий рядок бюджету, під який треба знайти кіловати.

Now look at the requirements of 2026. The perimeter comes with inspection and application control. Two sites are an obligation, with proof that failover works. Immutable copies are a line in the specification. Object storage is a working tool, already holding archives and backups. Virtualisation is a subscription whose term has to be aligned with the lifetime of the version. Accelerators are a budget line of their own, for which kilowatts have to be found.

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

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

The most important thing in this picture is not that there are more requirements. What matters is that almost every one of them became a permanent cost line rather than a one-off project. A second site is not a purchase; it is a second site for good: power, links, licences, people, procedures. A subscription is a payment that does not end. Immutable copies are capacity that cannot be reused along the way.

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

Звідси робоче визначення, яким я далі користуюся. Інфраструктурний борг — це різниця між тим, що парк уміє сьогодні, і тим, що від нього сьогодні вимагають. Відсотки за цим боргом платяться не грошима, а обмеженнями: що більший розрив, то менше у вас лишається допустимих наступних кроків. А інфраструктурний дефолт — це момент, коли допустимих кроків не залишилося жодного, і єдиний доступний варіант — замінити все цілком, одразу й дорого.

Hence the working definition I use from here on. Infrastructure debt is the difference between what the estate can do today and what is demanded of it today. The interest on that debt is paid not in money but in constraints: the wider the gap, the fewer acceptable next steps you have left. And infrastructure default is the moment when no acceptable step remains and the only available option is to replace everything, all at once and expensively.

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

І одразу застереження, без якого далі буде незрозуміло. Борг сам по собі не порок. Будь-яка інфраструктура його має, бо вимоги змінюються швидше, ніж амортизується залізо. Питання лише в тому, чи знаєте ви свій борг, чи записаний він і чи закладений у план.

And one caveat straight away, without which the rest will not make sense. Debt in itself is no vice. Every infrastructure has it, because requirements change faster than hardware depreciates. The only question is whether you know your debt, whether it is written down and whether it is in the plan.

02

Состояние первоеСтан першийState one

Аванс: заплатить до того, как понадобится

Аванс: заплатити до того, як знадобиться

Paying in advance: before you need it

Выход из аренды заставил строить сразу и целиком. Каждый шестой узел парка не несёт прикладной нагрузки — и это осознанно.

Вихід з оренди змусив будувати одразу і цілком. Кожен шостий вузол парку не несе прикладного навантаження — і це усвідомлено.

Leaving a rented platform forced them to build it all at once. Every sixth node in the estate carries no application load — deliberately.

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

Перший замовник виходив з орендованої хмари на власне залізо. Рішення ухвалювалося один раз і цілком, тому й парк побудований один раз і цілком: три майданчики, більше 40 робочих вузлів і окремо по 3 вузли кластера управління на кожному.

The first customer was moving off a rented cloud onto their own hardware. The decision was taken once and in full, so the estate was built once and in full: three sites, more than 40 working nodes, and a separate three-node management cluster on each.

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

Ось ці вузли управління — найпоказовіша частина всього випуску. Кожен шостий вузол парку не несе жодної прикладної віртуальної машини. Він існує заради того, щоб майданчиком можна було керувати окремо від решти: обслуговувати, оновлювати, вимикати, не залежачи від сусідів. У борговому сценарії на цьому економлять передусім — управління підселяють до продуктивного навантаження, бо так дешевше на старті, — і потім роками не можуть вивести майданчик в обслуговування, не зачепивши продуктив.

Those management nodes are the most telling part of this whole issue. Every sixth node in the estate carries not a single application virtual machine. It exists so that the site can be managed independently of the others: serviced, updated, shut down without depending on its neighbours. In a debt scenario this is the first thing people economise on — management is co-located with production because it is cheaper at the start — and then for years they cannot take a site out for maintenance without touching production.

Второе, за что здесь заплачено вперёд, — незанятый запас. Нагрузка по трём площадкам распределена примерно как 65–17–17: одна работает, две почти пустые по построению. При этом около 71% затрат на электричество фиксированы и не зависят от того, есть ли на узле нагрузка. То есть аванс платится не только капиталом при закупке, но и каждый месяц в счёте за электричество.

Друге, за що тут заплачено наперед, — незайнятий запас. Навантаження по трьох майданчиках розподілене приблизно як 65–17–17: один працює, два майже порожні за побудовою. При цьому близько 71% витрат на електрику фіксовані й не залежать від того, чи є на вузлі навантаження. Тобто аванс платиться не лише капіталом при закупівлі, а й щомісяця в рахунку за електрику.

The second thing paid for in advance here is unused headroom. The load across the three sites is split roughly 65–17–17: one works, two are nearly empty by design. And about 71% of the electricity cost is fixed and does not depend on whether a node carries any load. So the advance is paid not only in capital at the purchase, but every month on the electricity bill.

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

Третє спостереження — про фізику. Один із кластерів, а це півтора десятка вузлів, довелося рознести на дві стійки, і не тому, що не вистачило юнітів, а тому що не вистачило вводу. Це та сама межа, яка в занедбаних випадках виглядає як «розширення не проходить»: просто тут у неї уперлися на вході, коли ще можна було спроєктувати, а не на п’ятий рік, коли вже не можна.

The third observation is about physics. One of the clusters, some fifteen nodes, had to be split across two racks — not because there were not enough rack units but because there was not enough feed. It is the same limit that in neglected cases shows up as “the expansion will not fit”: here they simply ran into it at the outset, when it could still be designed around, rather than in year five, when it could not.

У аванса есть собственный сценарий отказа, и я бы не стал делать вид, что его нет. Если рост не придёт в расчётные сроки, площадка с загрузкой 17% будет стоить денег каждый месяц, а к четвёртому-пятому году парк начнёт устаревать, так и не дойдя до проектной нагрузки. Аванс оправдан ровно настолько, насколько обоснован прогноз, под который он сделан.

В авансу є власний сценарій відмови, і я б не став удавати, що його немає. Якщо зростання не прийде в розрахункові строки, майданчик із завантаженням 17% коштуватиме грошей щомісяця, а до четвертого-п’ятого року парк почне старіти, так і не дійшовши до проєктного навантаження. Аванс виправданий рівно настільки, наскільки обґрунтований прогноз, під який він зроблений.

Paying in advance has its own failure scenario, and I would not pretend otherwise. If the growth does not arrive on schedule, a site running at 17% costs money every month, and by year four or five the estate starts ageing without ever reaching its design load. The advance is justified exactly to the extent that the forecast behind it is.

Но у этого заказчика есть и ответ на такой упрёк. Параллельно построена независимая адресация с мультихомингом по BGP, и это меняет саму схему работы площадок: нагрузку планируется расселить по всем трём ровным слоем, чтобы ни одна не была основной, а все три — равновесными. Тогда распределение 65–17–17 перестаёт быть картиной «одна работает, две ждут» и становится переходным состоянием. Это, кстати, лучший ответ на вопрос, зачем платить за незанятый запас: за него платят не ради страховки, а ради того, чтобы площадки стали взаимозаменяемыми.

Але в цього замовника є і відповідь на такий докір. Паралельно побудована незалежна адресація з мультихомінгом по BGP, і це змінює саму схему роботи майданчиків: навантаження планується розселити по всіх трьох рівним шаром, щоб жоден не був основним, а всі три — рівноважними. Тоді розподіл 65–17–17 перестає бути картиною «один працює, два чекають» і стає перехідним станом. Це, до речі, найкраща відповідь на питання, навіщо платити за незайнятий запас: за нього платять не заради страховки, а заради того, щоб майданчики стали взаємозамінними.

But this customer has an answer to that reproach. In parallel they built independent addressing with BGP multihoming, and that changes how the sites work: the load is to be spread evenly across all three so that none is the primary and all three are equal. The 65–17–17 split then stops being a picture of “one works, two wait” and becomes a transitional state. That, incidentally, is the best answer to the question of why one would pay for idle headroom: it is paid for not as insurance but to make the sites interchangeable.

03

Состояние второеСтан другийState two

Рост под прогноз: расширение с обоснованием

Зростання під прогноз: розширення з обґрунтуванням

Growth against a forecast: expansion with a rationale

Резерв, который принимает половину нагрузки, превращается в тыкву ровно тогда, когда он нужен.

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

A standby that takes half the load turns into a pumpkin at exactly the moment it is needed.

Второй случай — компания с быстро растущей клиентской базой. Порядок величин такой: несколько сотен тысяч клиентов летом 2026 и примерно пятикратный рост за полтора года по плану. При таком прогнозе спорить про «а нужно ли расширяться» бессмысленно, спор идёт только про то, как именно.

Другий випадок — компанія зі швидко зростаючою клієнтською базою. Порядок величин такий: кілька сотень тисяч клієнтів улітку 2026 і приблизно п’ятикратне зростання за півтора року за планом. За такого прогнозу сперечатися про «а чи потрібно розширюватися» безглуздо, суперечка йде лише про те, як саме.

The second case is a company with a fast-growing customer base. The orders of magnitude: a few hundred thousand customers in the summer of 2026, and a planned fivefold growth over eighteen months. With a forecast like that, arguing about whether to expand is pointless; the argument is only about how.

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

Початково майданчики були несиметричними: основний ніс навантаження, резервний стояв гарячим резервом із завантаженням в одиниці відсотків. Розширення рахувалося не за принципом «добити основний», а до паритету — щоб резервний майданчик приймав усе навантаження основного, а не його половину. Це дорожче, і це правильно: резерв, який приймає половину, при справжній аварії перетворюється на гарбуз саме в той момент, коли він потрібен.

Originally the sites were asymmetric: the primary carried the load while the standby sat in hot standby at a few percent utilisation. The expansion was calculated not on the principle of “top up the primary” but to parity — so that the standby site would take the primary’s entire load rather than half of it. That costs more, and it is right: a standby that takes half turns into a pumpkin in a real outage at exactly the moment it is needed.

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

І ще одне рішення в цьому проєкті мені подобається, бо воно про борг, а не про специфікацію: ємність розбита на дві поставки — частина одразу, решта через кілька кварталів, під фактичне зростання, а не під красиву цифру в специфікації.

And one more decision in this project appeals to me, because it is about debt rather than specification: the capacity is split into two deliveries — part now, the rest a few quarters later, against actual growth rather than a pleasing figure in a document.

А теперь про то, чего в этом проекте не видно в железе. Лицензии на виртуализацию куплены в январе 2025 подпиской на 3 года, то есть оплачены до начала 2028. Срок общей поддержки той ветки платформы, которая развёрнута на площадках, заканчивается осенью 2027. То есть версия выйдет из поддержки раньше, чем кончится оплаченный срок, и переход на следующую ветку придётся делать внутри него — с обновлением железа там, где оно в список совместимости уже не попадает.

А тепер про те, чого в цьому проєкті не видно в залізі. Ліцензії на віртуалізацію куплені в січні 2025 підпискою на 3 роки, тобто оплачені до початку 2028. Строк загальної підтримки тієї гілки платформи, яка розгорнута на майданчиках, закінчується восени 2027. Тобто версія вийде з підтримки раніше, ніж закінчиться оплачений строк, і перехід на наступну гілку доведеться робити всередині нього — з оновленням заліза там, де воно до списку сумісності вже не потрапляє.

And now for what cannot be seen in the hardware. The virtualisation licences were bought in January 2025 as a three-year subscription, paid through to the start of 2028. General support for the platform branch deployed on the sites ends in the autumn of 2027. So the version leaves support before the paid term expires, and the move to the next branch will have to happen inside that term — with hardware upgrades wherever the existing kit no longer makes the compatibility list.

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

Це, до речі, відповідь на популярний аргумент «візьмемо редакцію простішу, вона дешевша». Дешева редакція перестає існувати швидше, ніж ви встигаєте на ній зекономити: молодші варіанти поступово виводяться з продажу, нові версії виходять лише у складі старших наборів, а підтримка поточної гілки закінчується за власним календарем, якому байдуже, коли ви купували. Строк життя вашої інфраструктури рахується не за датою закінчення договору, а за датою закінчення підтримки версії. Це різні дати, і друга зазвичай ближча.

That, incidentally, answers the popular argument of “let us take the simpler edition, it is cheaper”. A cheap edition stops existing faster than you can save on it: the lower tiers are gradually withdrawn from sale, new versions appear only inside the higher bundles, and support for the current branch ends on its own calendar, which does not care when you bought. The life of your infrastructure is measured not by the contract end date but by the version’s end-of-support date. They are different dates, and the second is usually the nearer one.

04

Состояние третьеСтан третійState three

Реструктуризация: долг, взятый осознанно

Реструктуризація: борг, узятий усвідомлено

Restructuring: debt taken deliberately

Объём данных вырос в 5 раз, бюджет не вырос. Разница между реструктуризацией и урезанием сметы — в том, записано ли решение.

Обсяг даних зріс у 5 разів, бюджет не зріс. Різниця між реструктуризацією і урізанням кошторису — у тому, чи записане рішення.

The data volume grew fivefold and the budget did not. The difference between restructuring and simply cutting the budget is whether the decision was written down.

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

Третій випадок — проєкт резервного копіювання, який під час підготовки довелося скорочувати. Обсяг даних, що захищаються, за час опрацювання зріс приблизно в 5 разів, а бюджет не зріс зовсім. Звичайна ситуація, і зазвичай вона закінчується тим, що ріжуть по живому: прибирають ліцензії, прибирають другий майданчик, прибирають стрічку.

The third case is a backup project that had to be cut back while it was being prepared. The volume of protected data grew roughly fivefold during the work, while the budget did not grow at all. An ordinary situation, and it usually ends with cuts to the bone: the licences go, the second site goes, the tape goes.

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

Тут зробили інакше. Ліцензії і сервери копіювання на обох майданчиках залишили за початковим завданням — тобто логіка рішення не постраждала. Скоротили інше: стрічкова бібліотека минулого покоління переїжджає на резервний майданчик замість нової закупівлі, наявний масив із дисками великої ємності підключається холодним шаром замість нового, комутатори фабрики не закуповуються, бо вільних портів на обох майданчиках достатньо.

Here they did it differently. The licences and backup servers on both sites were kept as originally specified — so the logic of the design was not damaged. What was cut was different: the previous-generation tape library moves to the standby site instead of a new purchase, the existing array with high-capacity drives is attached as the cold tier instead of a new one, and the fabric switches are not bought, because there are enough free ports on both sites.

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

Що це насправді означає. Замовник узяв борг свідомо: частина інфраструктури резервного копіювання тепер стоїть на обладнанні минулого покоління, у якого свій строк і свій ЗІП. Але цей борг порахований, записаний і підкріплений аргументом: основні системи вже реплікуються між майданчиками власними засобами, поза системою копіювання, тому відсутність швидкого шару на резервному майданчику не залишає діру, а створює обмеження за швидкістю відновлення, і це обмеження відоме заздалегідь.

What that actually means. The customer took on debt deliberately: part of the backup infrastructure now stands on previous-generation equipment with its own lifespan and its own spares. But this debt is calculated, written down and backed by an argument: the main systems already replicate between the sites by their own means, outside the backup system, so the absence of a fast tier on the standby site does not leave a hole but creates a constraint on restore speed — and that constraint is known in advance.

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

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

The difference between restructuring and an ordinary budget cut is exactly this: in one case you know what you paid with and can come back to it in a year; in the other, a year later you are surprised.

05

Состояние четвёртоеСтан четвертийState four

Отложенное решение: полторы сотни узлов без поддержки

Відкладене рішення: півтори сотні вузлів без підтримки

A deferred decision: a hundred and fifty nodes without support

Парк выглядит однородным в учёте и распадается на три группы в эксплуатации. Решение не принимается третий месяц.

Парк виглядає однорідним в обліку і розпадається на три групи в експлуатації. Рішення не ухвалюється третій місяць.

The estate looks uniform in the asset register and splits into three groups in operation. No decision has been taken for three months.

Четвёртый случай — самый неприятный, потому что в нём ничего не происходит. Парк закуплен в 2022 году: около 150 узлов одного поколения одной платформы, больше десяти позиций закупки. Несколько месяцев назад закончилась поддержка. Решение — продлевать или менять — не принято до сих пор.

Четвертий випадок — найнеприємніший, бо в ньому нічого не відбувається. Парк закуплений у 2022 році: близько 150 вузлів одного покоління однієї платформи, більше десяти позицій закупівлі. Кілька місяців тому закінчилася підтримка. Рішення — продовжувати чи міняти — не ухвалене досі.

The fourth case is the most unpleasant, because nothing in it is happening. The estate was bought in 2022: about 150 nodes of one generation on one platform, across more than ten purchase lines. Support ended several months ago. The decision — renew or replace — still has not been taken.

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

Спочатку про те, що саме втрачено. Без чинного контракту втрачається вся сервісна підтримка заліза: не можна відкрити звернення, не можна отримати заміну комплектуючих. Не частина функцій, а все. При цьому вікно на постгарантійне обслуговування відкрите завжди, тобто двері не зачинилися — повернутися можна будь-якої миті, і це важлива деталь, бо вона перетворює ситуацію з безвихідної на відкладену.

First, what exactly has been lost. Without an active contract, all hardware service support is gone: you cannot open a case, you cannot get replacement parts. Not some functions — all of them. At the same time the window for post-warranty service is always open, so the door has not slammed shut: you can return at any moment, and that is an important detail, because it turns the situation from hopeless into merely deferred.

Теперь про состав, и это главное открытие этого случая. Парк выглядит однородным: одна платформа, один год, один вендор. В учёте это одна-две строки. В эксплуатации это три разные группы по назначению: около 90 узлов под одну платформу виртуализации, примерно 50 под другую и десяток обычных серверов под отдельные задачи. Причём почти половина всего парка приходится на одну-единственную позицию закупки.

Тепер про склад, і це головне відкриття цього випадку. Парк виглядає однорідним: одна платформа, один рік, один вендор. В обліку це один-два рядки. В експлуатації це три різні групи за призначенням: близько 90 вузлів під одну платформу віртуалізації, приблизно 50 під іншу і десяток звичайних серверів під окремі задачі. Причому майже половина всього парку припадає на одну-єдину позицію закупівлі.

Now the composition, and this is the main discovery of this case. The estate looks uniform: one platform, one year, one vendor. In the asset register it is one or two lines. In operation it is three different groups by purpose: about 90 nodes under one virtualisation platform, roughly 50 under another, and a dozen ordinary servers for separate tasks. And almost half the entire estate falls under a single purchase line.

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

Далі починається цікаве. Роль визначає обв’язку, а обв’язка визначає все інше. Вузли під гіперконвергентну платформу прив’язані до її списку сумісності: заміна накопичувача або мережевої карти вирішується не наявністю на складі, а тим, що платформа підтримує. Вузли другої групи прив’язані і до списку сумісності, і до ліцензійного календаря своєї платформи — на них сходяться одразу два борги. Звичайні сервери третьої групи прив’язані до життєвого циклу застосунків, які на них живуть, і ні до чого більше.

Then it gets interesting. The role determines the surrounding systems, and those determine everything else. Nodes under the hyperconverged platform are tied to its compatibility list: replacing a drive or a network card is decided not by what is in the warehouse but by what the platform supports. Nodes in the second group are tied both to a compatibility list and to their platform’s licensing calendar — two debts meet on them. The ordinary servers in the third group are tied to the life cycle of the applications running on them, and to nothing else.

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

Виходить, що у трьох груп різні строки заміни і різні тригери. І поки на парк дивляться як на півтори сотні вузлів, рішення виглядає непідйомним: одна велика сума проти маленького регулярного платежу за підтримку, а проміжного варіанта в голові немає. Якщо розкласти за групами — з’являються три окремі кроки з різними строками, і кожен із них рахується окремо. Починати при цьому логічно з найбільшої позиції: вона одна визначає половину відповіді.

So the three groups have different replacement dates and different triggers. And while the estate is viewed as a hundred and fifty nodes, the decision looks unaffordable: one large sum against a small recurring support payment, with no intermediate option in anyone’s mind. Break it into groups and three separate steps appear with different timings, each costed on its own. It makes sense to start with the largest line: on its own it determines half the answer.

Есть и второй слой, который в учёте не виден совсем. Узлы куплены разом, но вводились в работу не разом: развёртывание растянулось больше чем на 3 года, по мере надобности. Гарантия и поддержка при этом шли от даты поставки, то есть часть оплаченного срока была потрачена на оборудование, которое просто стояло и ждало своей задачи. Лицензии докупались по мере ввода узлов, и цикл лицензии был зафиксирован на год. Получается наложение: железо стареет от одной даты, лицензии живут от разных, а платформа за эти годы ушла вперёд по версиям, пока последние узлы только вводились.

Є і другий шар, який в обліку не видно зовсім. Вузли куплені разом, але вводилися в роботу не разом: розгортання розтягнулося більш ніж на 3 роки, у міру потреби. Гарантія і підтримка при цьому йшли від дати постачання, тобто частина оплаченого строку була витрачена на обладнання, яке просто стояло й чекало своєї задачі. Ліцензії докуповувалися в міру введення вузлів, і цикл ліцензії був зафіксований на рік. Виходить накладення: залізо старіє від однієї дати, ліцензії живуть від різних, а платформа за ці роки пішла вперед за версіями, поки останні вузли тільки вводилися.

There is a second layer that the asset register does not show at all. The nodes were bought together but were not brought into service together: the rollout stretched over more than three years, as needs arose. Warranty and support, however, ran from the delivery date, so part of the paid term was spent on equipment that simply stood waiting for a task. Licences were bought as nodes were commissioned, and the licence cycle was fixed at a year. The result is an overlay: the hardware ages from one date, the licences live from several, and over those years the platform moved ahead through versions while the last nodes were still being commissioned.

И ещё одно следствие, которое я бы запомнил отдельно. Весь парк куплен в один год, а значит вентиляторы, накопители и блоки питания вырабатывают ресурс синхронно. Отказы придут не равномерно по годам, а окном. Без действующего контракта это окно вы встречаете своим складом и своими руками.

І ще один наслідок, який я б запам’ятав окремо. Увесь парк куплений в один рік, а отже вентилятори, накопичувачі і блоки живлення виробляють ресурс синхронно. Відмови прийдуть не рівномірно за роками, а вікном. Без чинного контракту це вікно ви зустрічаєте своїм складом і своїми руками.

And one more consequence worth remembering separately. The whole estate was bought in one year, which means the fans, drives and power supplies wear out in step. Failures will not arrive evenly across the years but in a window. Without an active contract, you meet that window with your own spares and your own hands.

06

Состояние пятоеСтан п’ятийState five

Вынужденная лоскутность: когда каждый шаг был разумным

Вимушена клаптиковість: коли кожен крок був розумним

Forced patchwork: when every step was reasonable

Каждый шаг по отдельности был правильным. Сумма шагов дала конструкцию с действующим риском.

Кожен крок окремо був правильним. Сума кроків дала конструкцію з діючим ризиком.

Each step on its own was right. The sum of them produced a design with a live risk.

Пятый случай начинался лучше всех. В 2020 году — компактный гиперконвергентный кластер из 5 узлов, отдельное хранилище под резервные копии, ленточная библиотека. Нормальная архитектура своего времени, с правильно расставленными приоритетами.

П’ятий випадок починався найкраще. У 2020 році — компактний гіперконвергентний кластер із 5 вузлів, окреме сховище під резервні копії, стрічкова бібліотека. Нормальна архітектура свого часу, з правильно розставленими пріоритетами.

The fifth case started best of all. In 2020 there was a compact five-node hyperconverged cluster, separate storage for backups and a tape library. A sound architecture for its time, with the priorities in the right places.

Потом просело финансирование ИТ. Дальше каждый шаг делался из доступного, и каждый по отдельности был разумным. Понадобились ресурсы — собрали второй кластер, десяток серверов другого вендора на другой платформе виртуализации, потому что так выходило дешевле. Не хватило ёмкости — подключили к нему массив, хотя платформа рассчитана на локальные диски. Базы данных жили на отдельных серверах, купленных отдельно в третий раз и по третьему случаю.

Потім просіло фінансування ІТ. Далі кожен крок робився з доступного, і кожен окремо був розумним. Знадобилися ресурси — зібрали другий кластер, десяток серверів іншого вендора на іншій платформі віртуалізації, бо так виходило дешевше. Не вистачило ємності — підключили до нього масив, хоча платформа розрахована на локальні диски. Бази даних жили на окремих серверах, куплених окремо втретє і за третьої нагоди.

Then IT funding sagged. After that each step was made from what was available, and each on its own was reasonable. Resources were needed, so a second cluster was assembled — a dozen servers from another vendor on another virtualisation platform, because that worked out cheaper. Capacity ran short, so an array was attached to it, even though the platform is designed for local disks. The databases lived on separate servers, bought separately a third time on a third occasion.

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

Підсумок — три острови. Дві гіперконвергентні платформи у двох різних сегментах мережі плюс сервери баз даних. І зв’язок між сегментами йде не через один пристрій, а через каскад міжмережевих екранів, у якому немає резервування.

The result is three islands. Two hyperconverged platforms in two different network segments, plus the database servers. And the link between the segments runs not through one device but through a cascade of firewalls with no redundancy in it.

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

Ось це і є єдиний випадок із п’яти, де ризик не відкладений, а діючий. В усіх попередніх ідеться про «через рік упреться» або «на четвертий рік стане дорого». Тут відмова будь-якого пристрою в каскаді розриває зв’язок між сегментами просто сьогодні, а що довший каскад, то більше в ньому таких пристроїв. Причому це не наслідок чиєїсь некомпетентності: недубльований вузол з’явився рівно тому, що другий сегмент узагалі не планувався, він виник як вимушене рішення за грошима.

This is the one case of the five where the risk is not deferred but live. In all the previous ones it is “in a year it will hit a wall” or “by year four it will get expensive”. Here the failure of any device in the cascade severs the link between segments today, and the longer the cascade, the more such devices it contains. And this is not the result of anyone’s incompetence: the non-redundant node appeared precisely because the second segment was never planned at all; it arose as a forced decision about money.

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

І окремо — про дзеркальність із попереднім випадком. Там одна платформа під три ролі, тут три платформи під одну роль. Здається, що це протилежні помилки, але результат однаковий: парк, який неможливо ні розвинути одним ходом, ні замінити одним ходом. Уніфікація платформи — це не уніфікація парку, а різноманіття платформ — не гнучкість.

And separately, on the mirror image of the previous case. There, one platform in three roles; here, three platforms in one role. They look like opposite mistakes, but the result is the same: an estate that can neither be grown in one move nor replaced in one move. Unifying the platform is not unifying the estate, and a variety of platforms is not flexibility.

Унификация платформы — это не унификация парка, а разнообразие платформ — не гибкость.

Уніфікація платформи — це не уніфікація парку, а різноманіття платформ — не гнучкість.

Unifying the platform is not unifying the estate, and a variety of platforms is not flexibility.

07

Сетевой долгМережевий боргNetwork debt

Сеть отдаёт долг последней

Мережа віддає борг останньою

The network repays its debt last

Коммутатор просто работает — ровно до того дня, когда в него нужно воткнуть что-то новое.

Комутатор просто працює — рівно до того дня, коли в нього треба увіткнути щось нове.

A switch simply works — right up to the day you need to plug something new into it.

Про сеть в таких разговорах вспоминают в последнюю очередь, и это само по себе диагноз. Сервер устаревает заметно: у него кончается поддержка, он не проходит по списку совместимости, он шумит и греется. Коммутатор просто работает. Он работает десять лет, он работал вчера, он работает сегодня, и никаких поводов его трогать нет — ровно до того дня, когда в него нужно воткнуть что-то новое.

Про мережу в таких розмовах згадують в останню чергу, і це саме по собі діагноз. Сервер старіє помітно: у нього закінчується підтримка, він не проходить за списком сумісності, він шумить і гріється. Комутатор просто працює. Він працює десять років, він працював учора, він працює сьогодні, і жодних приводів його чіпати немає — рівно до того дня, коли в нього треба увіткнути щось нове.

Networking is the last thing remembered in such conversations, and that in itself is a diagnosis. A server ages visibly: its support runs out, it fails the compatibility list, it is noisy and it gets hot. A switch simply works. It has worked for ten years, it worked yesterday, it works today, and there is no reason to touch it — right up to the day you need to plug something new into it.

Смотрю на два ЦОД одного заказчика. Фабрика собрана из смеси оборудования: часть снята с продаж и поддержки производителем, часть — бюджетные коммутаторы, которые ставили как временное решение. Потолок фабрики — 10G. Периметр без межсетевого экрана нового поколения. Управление ручное, единой системы нет. Всё это годами никого не беспокоило, потому что сеть работала.

Дивлюся на два ЦОД одного замовника. Фабрика зібрана із суміші обладнання: частина знята з продажу і підтримки виробником, частина — бюджетні комутатори, які ставили як тимчасове рішення. Стеля фабрики — 10G. Периметр без міжмережевого екрана нового покоління. Управління ручне, єдиної системи немає. Усе це роками нікого не турбувало, бо мережа працювала.

I am looking at two data centres belonging to one customer. The fabric is assembled from a mixture of equipment: some of it withdrawn from sale and support by the manufacturer, some of it budget switches installed as a temporary measure. The fabric’s ceiling is 10G. The perimeter has no next-generation firewall. Management is manual, with no single system. None of it bothered anyone for years, because the network worked.

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

А потім того самого року замовник закуповує сервери баз даних і сервер під ШІ, і в усіх них мережеві карти 25G. Втикати їх нікуди. У цей момент мережевий борг з абстракції перетворюється на цифру: новий сервер стоїть у стійці і працює вчетверо повільніше, ніж міг би, або не працює зовсім, поки не замінена фабрика. Причому заміна фабрики — це не докупівля вузла в кластер, це вікно, в яке стає все.

And then in the same year the customer buys database servers and an AI server, and all of them have 25G network cards. There is nowhere to plug them in. At that moment the network debt turns from an abstraction into a number: the new server stands in the rack running four times slower than it could, or not running at all until the fabric is replaced. And replacing a fabric is not adding a node to a cluster; it is a maintenance window in which everything stops.

Второй пример мельче, но показательнее, потому что в нём считается риск, а не скорость. Офисная сеть, всё ядро — один 10G-коммутатор. Запасного такого же в маневровом фонде нет: фонд состоит из оборудования попроще, у которого и портов меньше, и межкоммутаторные линки вчетверо у́же. То есть при отказе ядра сеть восстановится, но в деградированном виде, и заранее это никем не посчитано.

Другий приклад дрібніший, але показовіший, бо в ньому рахується ризик, а не швидкість. Офісна мережа, усе ядро — один 10G-комутатор. Запасного такого самого в маневровому фонді немає: фонд складається з обладнання простішого, у якого і портів менше, і міжкомутаторні лінки вчетверо вужчі. Тобто при відмові ядра мережа відновиться, але в деградованому вигляді, і заздалегідь це ніким не пораховано.

The second example is smaller but more telling, because what is counted in it is risk rather than speed. An office network whose entire core is a single 10G switch. There is no identical spare in the standby pool: the pool consists of simpler equipment with fewer ports and inter-switch links four times narrower. So if the core fails the network will come back, but in a degraded form — and nobody has worked that out in advance.

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

У мережевого боргу дві особливості, через які він небезпечніший за серверний. Перша: мережа віддає борг останньою, бо її заміна вимагає зупинки всього, а не частини. Друга: мережевий борг виявляється не у звіті, а в чужому проєкті — коли серверна закупівля вже зроблена, гроші витрачені, а увіткнути залізо виявляється нікуди. Тому список строків підтримки за фабрикою і за периметром треба вести рівно так само, як за серверами, і переглядати його перед кожною серверною закупівлею, а не після.

Network debt has two features that make it more dangerous than server debt. First: the network repays last, because replacing it requires stopping everything rather than a part. Second: network debt is discovered not in a report but in somebody else’s project — when the server purchase has been made, the money spent, and there turns out to be nowhere to plug the hardware in. So the end-of-support list for the fabric and the perimeter has to be kept exactly as it is for servers, and reviewed before every server purchase rather than after.

08

МетрикиМетрикиMetrics

Чем измерять долг

Чим вимірювати борг

How to measure the debt

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

Вік обладнання — погана метрика. Міряти треба розрив між тим, що парк уміє, і тим, що від нього вимагають.

Equipment age is a poor metric. What should be measured is the gap between what the estate can do and what is demanded of it.

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

Вік обладнання — погана метрика. П’ятирічний вузол, який робить рівно те, що від нього вимагають, боргів не створює. Трирічний, який не проходить за вимогами регулятора, створює. Міряти треба розрив, а не роки.

Equipment age is a poor metric. A five-year-old node that does exactly what is asked of it creates no debt. A three-year-old one that fails the regulator’s requirements does. Measure the gap, not the years.

Первое измерение — возрастная структура парка по потреблению, а не по количеству. У одного из заказчиков на площадке четыре стойки, больше 80 юнитов оборудования, около 25 kW в типовой работе. Из них серверы 2015 года дают больше половины всего потребления площадки. Ещё примерно 19% мощности приходится на сетевое оборудование, половина которого выпущена больше десяти лет назад. Это значит, что производственная база компании физически одиннадцатилетняя, а любой новый проект въезжает в остаток от неё.

Перший вимір — вікова структура парку за споживанням, а не за кількістю. В одного із замовників на майданчику чотири стійки, більше 80 юнітів обладнання, близько 25 kW у типовій роботі. З них сервери 2015 року дають більше половини всього споживання майданчика. Ще приблизно 19% потужності припадає на мережеве обладнання, половина якого випущена понад десять років тому. Це означає, що виробнича база компанії фізично одинадцятирічна, а будь-який новий проєкт в’їжджає в залишок від неї.

The first dimension is the age structure of the estate by power draw rather than by unit count. At one customer’s site there are four racks, more than 80 rack units of equipment and about 25 kW in normal operation. Of that, 2015 servers account for more than half of the site’s entire draw. A further 19% or so goes on network equipment, half of which was made more than ten years ago. Which means the company’s production base is physically eleven years old, and any new project moves into what is left of it.

Второе измерение — запас, посчитанный на отказ узла, а не на сегодняшний день. Смотрю на кластер из 9 узлов, 508 виртуальных машин. Сейчас: по процессорам 59,4%, по памяти 62,8%, по сырой ёмкости 55,7%. Выглядит спокойно. Пересчитываю то же самое на 8 узлов, то есть на отказ одного: 66,9%, 70,7% и 62,6%. Спокойствие заканчивается — запас по памяти в режиме N-1 остаётся меньше 30%, и упрётся кластер именно в память.

Другий вимір — запас, порахований на відмову вузла, а не на сьогоднішній день. Дивлюся на кластер із 9 вузлів, 508 віртуальних машин. Зараз: за процесорами 59,4%, за пам’яттю 62,8%, за сирою ємністю 55,7%. Виглядає спокійно. Перераховую те саме на 8 вузлів, тобто на відмову одного: 66,9%, 70,7% і 62,6%. Спокій закінчується — запас за пам’яттю в режимі N-1 залишається менше 30%, і впреться кластер саме в пам’ять.

The second dimension is headroom calculated for the loss of a node rather than for today. I am looking at a cluster of 9 nodes running 508 virtual machines. Right now: 59.4% on processors, 62.8% on memory, 55.7% on raw capacity. It looks comfortable. Recalculate the same for 8 nodes, that is for the loss of one: 66.9%, 70.7% and 62.6%. The comfort ends — the memory headroom in N-1 mode is below 30%, and memory is exactly what the cluster will run into.

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

А тепер те, що перетворює цю таблицю зі спостереження на строк. Кластер почав активно заповнюватися в березні. Усе це завантаження набране приблизно за півроку, і за збереження темпу розширення потрібне не в наступному бюджетному циклі, а зараз: поки обладнання пройде закупівлю, постачання і введення, запасу на відмову вузла вже не залишиться.

And now the thing that turns this table from an observation into a deadline. The cluster began filling up in earnest in March. All that load was accumulated in roughly six months, and at the same pace the expansion is needed not in the next budget cycle but now: by the time the equipment goes through procurement, delivery and commissioning, the headroom for a node failure will be gone.

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

Кластер заповнився за півроку. За того самого темпу розширення потрібне не в наступному бюджетному циклі, а зараз.

The cluster filled up in six months. At the same pace the expansion is needed now, not in the next budget cycle.

Третье измерение — симметрия площадок относительно прогноза нагрузки, а не относительно сегодняшнего дня. Вопрос простой: если основная площадка исчезнет в тот момент, когда клиентская база вырастет вдвое, резервная примет всё или половину?

Третій вимір — симетрія майданчиків відносно прогнозу навантаження, а не відносно сьогоднішнього дня. Питання просте: якщо основний майданчик зникне в той момент, коли клієнтська база зросте вдвічі, резервний прийме все чи половину?

The third dimension is the symmetry of the sites against the forecast load rather than against today. The question is simple: if the primary site disappears at the moment the customer base has doubled, will the standby take all of it or half?

Четвёртое измерение — календарь поддержки против горизонта планов. Дата окончания поддержки версии, дата окончания контракта на железо, срок подписки и срок амортизации — это четыре разные даты, и совпадают они редко. Разложите их на одной шкале, и станет видно, какой из них наступит первым.

Четвертий вимір — календар підтримки проти горизонту планів. Дата закінчення підтримки версії, дата закінчення контракту на залізо, строк підписки і строк амортизації — це чотири різні дати, і збігаються вони рідко. Розкладіть їх на одній шкалі, і стане видно, яка з них настане першою.

The fourth dimension is the support calendar against the planning horizon. The version’s end-of-support date, the hardware contract’s end date, the subscription term and the depreciation period are four different dates, and they rarely coincide. Lay them out on one timeline and it becomes clear which of them arrives first.

09

ДефолтДефолтDefault

От долга к техническому дефолту

Від боргу до технічного дефолту

From debt to technical default

Важен не размер разрыва, а число способов его закрыть. Каждое отложенное решение убирает один.

Важливий не розмір розриву, а кількість способів його закрити. Кожне відкладене рішення прибирає один.

What matters is not the size of the gap but the number of ways to close it. Every deferred decision removes one.

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

Тепер зберемо все на одній шкалі. У день закупівлі боргу немає: парк точно відповідає вимогам, під які купувався. Далі вимоги починають зростати сходинками — новий регламент, нова система, нова планка щодо захисту периметра, нова версія платформи. Можливості парку при цьому не зростають, а повільно знижуються: виходить із підтримки версія, закінчується контракт на залізо, вичерпується ввід за живленням і порти у фабриці.

Now let us put it all on one timeline. On the day of purchase there is no debt: the estate matches exactly the requirements it was bought for. Then the requirements start rising in steps — a new regulation, a new system, a new bar for perimeter protection, a new platform version. The estate’s capability, meanwhile, does not grow but slowly declines: a version leaves support, the hardware contract expires, the power feed and the fabric ports run out.

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

Борг починається в точці, де ці дві лінії розходяться. Він ще нічого не ламає і не видно його в моніторингу — просто з цього моменту у вас з’являється розрив, який треба чимось закривати. Далі важливо не те, наскільки розрив великий, а скільки у вас лишається способів його закрити. Спочатку їх багато: продовжити підтримку, докласти вузли, перерозподілити навантаження, перенести частину на другий майданчик, відкласти на квартал. Кожне пропущене рішення прибирає один спосіб.

The debt begins at the point where those two lines diverge. It breaks nothing yet and does not show up in monitoring — it is simply that from that moment you have a gap that has to be closed somehow. From then on, what matters is not how large the gap is but how many ways you have left to close it. At first there are many: renew support, add nodes, redistribute the load, move part of it to the second site, defer for a quarter. Every missed decision removes one of them.

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

Технічний дефолт — це стан, у якому способів не залишилося жодного. Розширення не проходить за вводом, підтримуваної версії для вашої гілки більше не продають, підтримку на залізо треба відновлювати через інспекцію, мережа не тримає швидкість нового обладнання, а відновлення не вкладається в норматив. Кожна з цих подій окремо вирішувана, і саме тому кожна окремо відкладається. Разом вони складаються в ситуацію, де єдиний доступний варіант — замінити все одразу, цілком і на максимумі ціни.

Technical default is the state in which no ways remain. The expansion does not fit the feed, a supported version for your branch is no longer sold, hardware support has to be reinstated through an inspection, the network will not carry the speed of the new equipment, and recovery does not meet its target. Each of these events is solvable on its own, and that is exactly why each of them, on its own, gets deferred. Together they add up to a situation where the only available option is to replace everything at once, in full and at peak price.

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

І це не гіпотетична точка в майбутньому. Я бачив її наживо: парк, що дожив до моменту, коли зміна прикладного софту виявилася можливою лише через повне вивантаження даних. Не міграція, не переїзд, а перезаливання всього з нуля — бо жодного проміжного шляху на той момент уже не залишилося.

And this is not a hypothetical point in the future. I have seen it in the flesh: an estate that reached the point where changing the application software was possible only through a complete data export. Not a migration, not a move, but reloading everything from scratch — because by then not a single intermediate path remained.

10

Чек-листЧек-листChecklist

Что проверить у себя

Що перевірити у себе

What to check in your own estate

Тринадцать вопросов, после которых становится видно, в каком состоянии находится ваш парк.

Тринадцять питань, після яких стає видно, в якому стані перебуває ваш парк.

Thirteen questions after which it becomes clear which state your estate is in.

1. Какие требования появились к вашей инфраструктуре за последние 5 лет и какие из них стали постоянной строкой расходов, а не разовым проектом.
2. Сколько узлов вашего парка не несёт прикладной нагрузки и почему — это осознанный аванс или случайность.
3. Какая доля потребления площадки приходится на оборудование старше 7 лет и отдельно на сетевое оборудование.
4. Чему равна загрузка кластера при отказе одного узла и какой ресурс при этом заканчивается первым.
5. С какой скоростью кластер заполнялся последние полгода и когда при этом темпе он упрётся в режим N-1.
6. Примет ли резервная площадка всю нагрузку основной при прогнозной нагрузке через 2 года, а не при сегодняшней.
7. Когда заканчивается общая поддержка версий платформ, которые у вас развёрнуты, и совпадает ли это со сроком ваших подписок.
8. Есть ли действующий контракт на поддержку по каждой группе оборудования и что именно вы теряете там, где его нет.
9. На сколько разных групп по назначению распадается ваш парк, если смотреть не на модель, а на то, чем определяется замена детали.
10. Какая доля парка куплена в один год и когда ожидается синхронная выработка ресурса расходных компонентов.
11. Какой потолок скорости у вашей фабрики и совпадает ли он с картами серверов, которые вы закупаете в этом году.
12. Сколько у вас недублированных элементов на путях между сегментами и какие из них появились как вынужденное решение.
13. Какие ваши сокращения сметы за последние 3 года записаны с обоснованием, а какие просто произошли.

1. Які вимоги з’явилися до вашої інфраструктури за останні 5 років і які з них стали постійним рядком витрат, а не разовим проєктом.
2. Скільки вузлів вашого парку не несе прикладного навантаження і чому — це усвідомлений аванс чи випадковість.
3. Яка частка споживання майданчика припадає на обладнання старше 7 років і окремо на мережеве обладнання.
4. Чому дорівнює завантаження кластера при відмові одного вузла і який ресурс при цьому закінчується першим.
5. З якою швидкістю кластер заповнювався останні півроку і коли за цього темпу він упреться в режим N-1.
6. Чи прийме резервний майданчик усе навантаження основного за прогнозного навантаження через 2 роки, а не за сьогоднішнього.
7. Коли закінчується загальна підтримка версій платформ, які у вас розгорнуті, і чи збігається це зі строком ваших підписок.
8. Чи є чинний контракт на підтримку за кожною групою обладнання і що саме ви втрачаєте там, де його немає.
9. На скільки різних груп за призначенням розпадається ваш парк, якщо дивитися не на модель, а на те, чим визначається заміна деталі.
10. Яка частка парку куплена в один рік і коли очікується синхронне вироблення ресурсу витратних компонентів.
11. Яка стеля швидкості у вашої фабрики і чи збігається вона з картами серверів, які ви закуповуєте цього року.
12. Скільки у вас недубльованих елементів на шляхах між сегментами і які з них з’явилися як вимушене рішення.
13. Які ваші скорочення кошторису за останні 3 роки записані з обґрунтуванням, а які просто сталися.

1. What requirements have appeared for your infrastructure over the last five years, and which of them became a permanent cost line rather than a one-off project.
2. How many nodes in your estate carry no application load, and why — is it a deliberate advance or an accident.
3. What share of the site’s power draw comes from equipment older than seven years, and separately from network equipment.
4. What the cluster’s utilisation is with one node failed, and which resource runs out first.
5. How fast the cluster has been filling up over the last six months and when, at that pace, it hits the N-1 limit.
6. Whether the standby site will take the primary’s entire load at the forecast load two years out, not at today’s.
7. When general support ends for the platform versions you have deployed, and whether that matches the term of your subscriptions.
8. Whether there is an active support contract for each equipment group, and exactly what you lose where there is not.
9. How many different groups by purpose your estate splits into, if you look not at the model but at what determines a part replacement.
10. What share of the estate was bought in a single year, and when the wear-prone components are expected to reach end of life together.
11. What speed ceiling your fabric has, and whether it matches the network cards of the servers you are buying this year.
12. How many non-redundant elements sit on the paths between segments, and which of them appeared as a forced decision.
13. Which of your budget cuts over the last three years are written down with a rationale, and which simply happened.

11

ИтогПідсумокWrap-up

Вместо вывода

Замість висновку

In place of a conclusion

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

П’ять станів із цього випуску — не рейтинг замовників і не шкала від поганого до хорошого. Це п’ять способів обійтися з однією проблемою: вимоги зростають швидше, ніж залізо амортизується. У кожного варіанта своя ціна і свій сценарій відмови. Поганих тут по-справжньому два, і обидва впізнаються за однією ознакою: ніхто не може сказати, чим саме компанія заплатила.

The five states in this issue are not a ranking of customers or a scale from bad to good. They are five ways of dealing with one problem: requirements grow faster than hardware depreciates. Each variant has its own price and its own failure scenario. Two of them are genuinely bad, and both are recognised by one sign: nobody can say what exactly the company paid with.

Технический дефолт наступает не тогда, когда отказывает железо. Железо отказывает всегда, к этому есть ЗИП, резерв и регламент. Дефолт наступает тогда, когда перестают принимать решение — и однажды обнаруживают, что выбирать больше не из чего.

Технічний дефолт настає не тоді, коли відмовляє залізо. Залізо відмовляє завжди, до цього є ЗІП, резерв і регламент. Дефолт настає тоді, коли перестають ухвалювати рішення — і одного разу виявляють, що вибирати більше немає з чого.

Technical default does not arrive when hardware fails. Hardware always fails; there are spares, standby capacity and procedures for that. Default arrives when people stop making decisions — and one day discover there is nothing left to choose between.

Хорошая новость в том, что инфраструктурный рейтинг, в отличие от финансового, считаете вы сами. Достаточно раз в год раскладывать парк по группам, а даты — по одной шкале. Если после этого у вас есть три посильных шага вместо одного непосильного, долг управляемый. Если шаг остался один и он неподъёмный — вы уже знаете, в каком вы состоянии.

Хороша новина в тому, що інфраструктурний рейтинг, на відміну від фінансового, рахуєте ви самі. Достатньо раз на рік розкладати парк за групами, а дати — за однією шкалою. Якщо після цього у вас є три посильні кроки замість одного непосильного, борг керований. Якщо крок залишився один і він непідйомний — ви вже знаєте, в якому ви стані.

The good news is that the infrastructure rating, unlike the financial one, is calculated by you. It is enough to sort the estate into groups once a year and lay the dates out on one timeline. If after that you have three manageable steps instead of one unmanageable one, the debt is under control. If only one step is left and it is unaffordable, you already know which state you are in.