Крис Биверс, генеральный директор и соучредитель Netbox Labs — серия интервью

Kris Beevers, генеральный директор и соучредитель NetBox Labs — технологический предприниматель и ветеран инфраструктурного программного обеспечения с более чем двадцатилетним опытом создания компаний и платформ, ориентированных на сетевые технологии, облачную инфраструктуру и автоматизацию. До возглавления NetBox Labs Биверс соучредил NS1 в 2013 году и почти десятилетие был её генеральным директором, превратив компанию в заметного поставщика технологий сетевой автоматизации и управления трафиком приложений, прежде чем IBM приобрела её в 2023 году. В рамках этой сделки NetBox Labs отделилась от NS1 как независимая компания, а IBM стала инвестором. Ранее в своей карьере Биверс занимал старшие инженерные и архитектурные позиции в Internap Network Services и Voxel, а также соучредил SolidJoint Research.

NetBox Labs разрабатывает платформу инфраструктурного интеллекта, предназначенную для помощи организациям в моделировании, эксплуатации, автоматизации и управлении всё более сложными сетями и ИТ‑инфраструктурой. Компания является коммерческим хранителем NetBox — широко используемой открытой системы учёта сети и инфраструктуры, которой пользуются более 10 000 организаций. Её платформа сочетает граф инфраструктуры и источник правды с операционным интеллектом, автоматизацией, оркестрацией с поддержкой ИИ и возможностями управления, позволяя как инженерам, так и ИИ‑агентам безопасно взаимодействовать с инфраструктурой. NetBox Labs поддерживает облачные, самостоятельно управляемые корпоративные, гибридные и air‑gapped развертывания, интегрируясь с инструментами такими как Ansible, Terraform, Nornir и конвейерами непрерывной интеграции и доставки.

Вы соучредили NS1 в 2013 году и почти десятилетие строили компанию до её приобретения IBM, после чего NetBox Labs стала независимой компанией. Какие уроки, полученные при построении NS1, повлияли на то, почему вы основали NetBox Labs, и как изменилась проблема инфраструктуры, которую вы пытаетесь решить, в эпоху ИИ?

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

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

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

Итак, урок из NS1 по‑прежнему актуален. Прежде чем эффективно автоматизировать инфраструктуру, её необходимо понять. ИИ лишь делает правильность этого понимания гораздо более срочной задачей.

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

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

Инфраструктура ИИ действительно не позволяет делать это.

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

Все эти элементы зависят друг от друга. Вы не можете решить, сколько стоек развернуть, не понимая плотность мощности и охлаждения. Вы не можете рассматривать GPU независимо от сети, их соединяющей.

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

О центрах данных ИИ всё чаще говорят в масштабе гигаватт. Что фундаментально меняется в эксплуатации, когда инфраструктура переходит от обычных корпоративных или облачных сред к объектам, построенным вокруг огромных кластеров GPU?

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

Подумайте, что нужно сделать, чтобы запустить в эксплуатацию центр обработки данных мощностью 300 мегаватт. Требуются земля и электроэнергия. Затем необходимо спроектировать объект и закупить стойки, GPU‑серверы, коммутаторы, оптоволокно, энергетическую инфраструктуру и системы охлаждения, часто у совершенно разных поставщиков, использующих разные способы представления своей продукции. Всё это оборудование должно прибыть, быть принято, установлено в стойки, проложено кабелями, сконфигурировано, протестировано и, в конечном итоге, передано для обучения или вывода в продакшн.

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

Таким образом, небольшие неэффективности быстро накапливаются. Недавно я провёл время с одним из крупнейших в мире производителей оптоволоконных кабелей, и они сказали, что одной из их главных бизнес‑проблем являются возвраты, потому что клиенты заказывают кабели неправильной длины. Это звучит почти тривиально, пока вы не заказываете сотни тысяч кабелей.

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

Вы сказали, что фактически нет установленного руководства или кадрового пула для эксплуатации инфраструктуры такого масштаба. Какие навыки сейчас hardest to find, и где, по вашему мнению, появятся самые большие дефициты талантов по мере роста AI‑инфраструктуры?

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

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

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

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

По мере того как границы между программным обеспечением, сетями, объектами, энергией и инженерией дата‑центров стираются, какие новые технические роли или гибридные наборы навыков, по вашему мнению, появятся?

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

Вы уже не рассматриваете вычисления или сети изолированно. Электроснабжение, охлаждение, физический дизайн, цепочки поставок, сети и автоматизация должны работать вместе, чтобы вывести эти среды в онлайн и поддерживать их работу.

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

AI‑агенты начинают диагностировать проблемы, генерировать конфигурации и автоматизировать части эксплуатации инфраструктуры. Какие обязанности, по вашему мнению, AI реально возьмёт на себя от инженеров инфраструктуры, а какие станут ещё более зависимыми от глубоких человеческих экспертиз?

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

Там, где люди становятся более важными, — это когда ответ не очевиден.

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

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

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

NetBox Labs утверждает, что системы ИИ, управляющие инфраструктурой, нуждаются в авторитетной модели устройств, соединений, зависимостей и других физических и логических отношений. Почему такой контекст инфраструктуры так важен при переходе от ИИ‑ассистентов, которые дают рекомендации, к агентам, способным действительно выполнять действия?

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

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

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

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

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

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

В вашей недавней статье CIO, «Почему я, CEO, лично разрабатываю нашу стратегию ИИ», вы утверждали, что ИИ слишком важен, чтобы руководители компаний просто делегировали его, и описали личное прототипирование с помощью ИИ‑инструментов. Как практический опыт работы с этими системами изменил ваше представление о том, что ИИ может реально автоматизировать в операциях инфраструктуры?

Практический опыт делает вас гораздо менее заинтересованным в теоретических разговорах.

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

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

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

Меня интересует более базовый вопрос. Помогает ли это нам управлять инфраструктурой быстрее, надёжнее или эффективнее? Если да — отлично. Если нет, то не имеет значения, насколько сложен ИИ, стоящий за этим.

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

Да, и мы уже начинаем это видеть. У нас есть внутренний термин «турбины на парковке», который возник в реальном разговоре с одной из команд, строящих гипермасштабную ИИ‑инфраструктуру. Они вводили инфраструктуру так быстро, что сеть не успевала за ними, поэтому они буквально покупали турбины и ставили их на парковку, чтобы получить достаточно энергии.

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

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

Смотря в будущее, считаете ли вы, что главным узким местом масштабирования ИИ в конечном итоге будут GPU и разработка моделей, или же гораздо более широкая проблема — найти достаточно энергии, физической инфраструктуры, сетевых возможностей, автоматизации и квалифицированных инженеров для управления всем этим?

Я не думаю, что будет одно единственное узкое место.

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

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

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

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

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

Спасибо за отличное интервью, читатели, желающие узнать больше, должны посетить NetBox Labs.