Kris Beevers, CEO та співзасновник Netbox Labs — серія інтерв’ю

Kris Beevers, CEO та співзасновник NetBox Labs — технологічний підприємець і ветеран інфраструктурного програмного забезпечення з більш ніж двадцятилітнім досвідом створення компаній та платформ, орієнтованих на мережі, хмарну інфраструктуру та автоматизацію. До того, як очолити NetBox Labs, Beevers у 2013 році співавтворив NS1 і майже десять років був її CEO, перетворивши компанію на провідного постачальника технологій автоматизації мереж і управління трафіком додатків, перш ніж її придбала IBM у 2023 році. У рамках цієї угоди NetBox Labs вийшов з NS1 як незалежна компанія, а IBM став інвестором. Раніше у своїй кар’єрі Beevers займав старші інженерні та архітектурні посади в Internap Network Services та Voxel, а також співавтворив SolidJoint Research.

NetBox Labs розробляє платформу інфраструктурного інтелекту, призначену для допомоги організаціям моделювати, експлуатувати, автоматизувати та керувати все більш складними мережами та ІТ‑інфраструктурою. Компанія є комерційним куратором NetBox — широко впровадженої open-source системи реєстру мереж і інфраструктури, яку використовують понад 10 000 організацій. Її платформа поєднує граф інфраструктури та джерело правди з операційним інтелектом, автоматизацією, оркестрацією за допомогою ШІ та можливостями управління, що дозволяє як інженерам, так і агентам ШІ безпечно взаємодіяти з інфраструктурою. NetBox Labs підтримує хмарні, самокеровані корпоративні, гібридні та air‑gapped розгортання, інтегруючись з інструментами, такими як Ansible, Terraform, Nornir та конвеєрами безперервної інтеграції та розгортання.

Ви у 2013 році співавтворили NS1 і майже десять років будували компанію до її придбання IBM, після чого NetBox Labs виник як незалежна компанія. Які уроки, отримані під час створення NS1, вплинули на те, чому ви заснували NetBox Labs, і як змінився інфраструктурний виклик, який ви намагаєтеся вирішити, у еру ШІ?

Одне, чого я навчився, будуючи NS1, — це те, що інфраструктурні проблеми рідко залишаються чітко обмеженими. DNS був нашою частиною стеку, але наші клієнти працювали в надзвичайно складних середовищах, де мережі, дата‑центри, додатки та автоматизація взаємозалежні. Чим більше часу я проводив з цими командами, тим ясніше ставало, що розуміння самої інфраструктури — це набагато більша проблема.

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

Що змінилося з появою ШІ, так це в основному темп і масштаб. Команди інфраструктури просять створювати величезні середовища надзвичайно швидко, у той час як базова технологія змінюється так само швидко. Одночасно ми починаємо автоматизувати більше операцій інфраструктури, що відкриває захоплююче майбутнє. Коли ШІ застосовується до інфраструктури, ІТ‑команди розуміють, що їм потрібні якісні дані в реальному часі про свою інфраструктуру для автоматизації, і вони мають знати, яким має бути запланований стан, щоб ШІ міг допомогти виявити, коли операційна інфраструктура відхиляється від плану.

Отже, урок з NS1 досі актуальний. Перш ніж ефективно автоматизувати інфраструктуру, її треба зрозуміти. ШІ лише підвищує терміновість правильного розуміння.

Протягом більшої частини минулого десятиліття хмарні обчислення дозволяли розробникам і командам інфраструктури абстрагувати фізичне обладнання, що стоїть під їхніми застосунками. Чому ШІ змінює цю тенденцію і змушує DevOps, Site Reliability Engineering (SRE) та мережевих інженерів знову задуматися про живлення, охолодження, стійки, кабелі та фізичне мережеве обладнання?

Хмари навчили багатьох з нас розглядати інфраструктуру як практично безмежну. Ви запитували обчислювальні ресурси, і вони з’являлися. Вам не обов’язково треба було турбуватись, де знаходиться сервер, як його живлять, як його охолоджують чи як усі фізичні компоненти під ним збираються разом.

Інфраструктура ШІ дійсно не дозволяє цього робити.

Коли ви створюєте такі середовища, ви починаєте з досить фізичних питань. Скільки землі у мене є? Скільки електроенергії я можу отримати? Який тип охолодження я можу забезпечити? Далі ви переходите до стійок, GPU‑серверів, комутаторів, волоконно‑оптичного кабелю і, зрештою, до логічного рівня — IP‑адрес, конфігурацій та програмного забезпечення.

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

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

Дата‑центри ШІ все частіше обговорюються у гіговаттових масштабах. Що фундаментально змінюється в експлуатації, коли інфраструктура переходить від традиційних корпоративних або хмарних середовищ до об’єктів, спроектованих навколо величезних кластерів GPU?

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

Подумайте, що має відбутися, щоб запустити дата‑центр потужністю 300 мегават. Потрібно мати землю та електроенергію. Потім треба спроектувати приміщення та закупити стійки, GPU‑сервери, комутатори, оптоволокно, електричну інфраструктуру та охолоджувальне обладнання, часто у абсолютно різних постачальників, які по‑різному представляють свої продукти. Усе це обладнання має прибувати, бути прийнятим, встановленим у стійки, підключеним кабелями, налаштованим, протестованим і в кінцевому підсумку переданим для навчання або інференції.

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

Тож навіть незначні неефективності швидко наростають. Нещодавно я спілкувався з одним із найбільших у світі виробників волоконно‑оптичних кабелів, і вони сказали, що однією з їхніх найбільших бізнес‑проблем є повернення товару, бо клієнти замовляють неправильні довжини кабелів. Це звучить майже тривіально, доки ви не замовляєте сотні тисяч кабелів.

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

Ви сказали, що фактично не існує встановленого посібника чи кадрового потоку для управління інфраструктурою такого масштабу. Які навички зараз найважче знайти і де, на вашу думку, виникнуть найбільші дефіцити талантів у міру розширення AI‑інфраструктури?

Ймовірно, у світі зараз лише кілька сотень людей, які дійсно знають, як будувати таку інфраструктуру з такою швидкістю та масштабом. І більшість з них досить зайняті, фактично займаючись цим.

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

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

Люди, які можуть перетинати деякі з цих меж, будуть надзвичайно цінними. Але я не думаю, що ми вже визначили, якими саме будуть усі ці ролі. Модель талантів будується паралельно з інфраструктурою.

У міру розмивання меж між програмним забезпеченням, мережами, приміщеннями, енергією та інженерією дата‑центрів, які нові технічні ролі або гібридні навички, на вашу думку, з’являться?

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

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

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

AI‑агенти починають діагностувати проблеми, генерувати конфігурації та автоматизувати частини операцій інфраструктури. Які обов’язки, на вашу думку, AI реалістично перейме у інженерів інфраструктури, а які стануть ще більш залежними від глибокої людської експертизи?

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

Люди стають більш важливими, коли відповідь не очевидна.

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

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

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

NetBox Labs стверджує, що системи ШІ, які керують інфраструктурою, потребують авторитетної моделі пристроїв, з’єднань, залежностей та інших фізичних і логічних зв’язків. Чому такий контекст інфраструктури настільки важливий, коли ми переходимо від ШІ‑асистентів, які лише дають рекомендації, до агентів, які можуть реально виконувати дії?

Головна різниця полягає в тому, що коли агент може діяти, помилка має реальні наслідки.

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

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

Саме це є фундаментом, над яким ми роками будували NetBox Labs, надаючи командам точну модель як фізичної, так і логічної інфраструктури, а також намір, який стоїть за її функціонуванням.

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

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

У вашому нещодавня стаття CIO, «Чому я, CEO, особисто формую нашу стратегію ШІ», ви стверджували, що ШІ надто важливий, щоб керівники компаній просто делегували його, і описували особисте прототипування інструментами ШІ. Як практичний досвід роботи з цими системами змінив ваше розуміння того, що ШІ може реалістично автоматизувати в операціях інфраструктури?

Практичний досвід робить вас значно менш зацікавленим у теоретичних розмовах.

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

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

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

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

Оскільки AI‑дата‑центри все більше обмежуються доступністю електроенергії та вимогами охолодження, чи може інженерія інфраструктури еволюціонувати від переважного управління обчислювальними ресурсами до активного координації навантажень з енергією та фізичною місткістю?

Так, і ми вже це бачимо. У нас є внутрішня фраза «турбіни на стоянці», яка виникла під час реальної розмови з однією з команд, що будують гіпермасштабну AI‑інфраструктуру. Вони підключали інфраструктуру так швидко, що мережа не встигала, тому буквально купували турбіни і ставили їх на стоянці, щоб отримати достатньо енергії.

Саме в такому середовищі працюють ці команди. Коли електроенергія стає однією з головних обмежень, треба значно розумніше використовувати наявні ресурси. Відповідь на попит (demand‑side response), коли оператори активно координують AI‑навантаження у відповідь на зміни в електричній мережі, вже відбувається і стає все важливішою можливістю для команд, що керують енергоємною інфраструктурою.

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

Дивлячись у майбутнє, чи вважаєте ви, що головним вузьким місцем масштабування ШІ в кінцевому підсумку будуть GPU та розробка моделей, чи ж значно ширша проблема — пошук достатньої кількості енергії, фізичної інфраструктури, мережевих можливостей, автоматизації та кваліфікованих інженерів для управління всім цим?

Я не думаю, що буде лише одне вузьке місце.

Створення AI‑інфраструктури з тією швидкістю та масштабом, які сьогодні вимагає ринок, по суті є задачею задоволення обмежень. У будь‑який момент щось одне є головним обмеженням.

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

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

Тому я не ставив би ставку на один постійний вузький місце. Я вважаю, що більш важлива здатність — це вміння адаптуватися, коли обмеження змінюються.

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

Дякуємо за чудове інтерв’ю, читачі, які хочуть дізнатися більше, повинні відвідати NetBox Labs.