Александр Кротов: Управление сложной инфраструктурой в 2026 году

Александр, расскажите, как вы пришли к созданию инфраструктуры для AI-сервисов и что привлекло вас именно в backend-инженерии?

Backend и работа над инфраструктурой сложных сервисов всегда привлекали меня, потому что позволяют создавать масштабные проекты, которые влияют на продукт в целом. А AI — одна из самых перспективных современных технологий, которая бурно развивается и применяется практически везде. Поэтому когда я присоединился к Яндексу, и мне нужно было выбрать команду, я решил погрузиться в создание инфраструктуры для AI-сервисов. Меня привлекли возможности роста в этой сфере и перспективный проект. Не могу сказать, что задачи по разработке инфраструктуры очень разнообразны — в основном, это стандартные процессы конвертации структур друг в друга и передача данных по сети. Но в сумме получается масштабная платформа, где можно применить свое видение — и соответственно, работать с таким проектом очень интересно.

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

Мой главный подход — максимальный self service. Когда система только разрабатывается, в ней возникает много путаницы — потому что единый инструментарий еще не создан. Чтобы такого не повторялось, я сразу разрабатываю инструменты для быстрого выполнения повторяющихся задач. Например, с их помощью клиенты инфраструктуры могут сами обновить модель или скопировать сервис для тестирования новых функций — без обращения к разработчикам. Сейчас у нас есть общий репозиторий с IaC-описаниями сервисов, инструкция по типовым операциям и множество тестов, которые проверяют корректность внесенных изменений. В будущем мы планируем создать визуальные инструменты с подсказками, пользоваться которыми будет еще проще. Но уже сейчас клиенты выполняют простые операции сами — это и быстрее, и освобождает нам время для более сложных задач.

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

Действительно, баланс между обновлениями инфраструктуры и поддержкой очень важен. Но в этом плане нам повезло — у большинства небольших потребителей требования одинаковые, а для нескольких крупных клиентов можно персонализировать продукт. При этом, персонализация должна быть аккуратной, чтобы не создавать рисков для инфраструктуры. Мы внедряем изменения через Feature Flags — это IF-блоки, которые запускают куски кода при выполнении определенного условия. Для пользователей ничего не меняется, пока они не станут использовать новые функции — а мы при этом следим, что включение этих функций не повлияет на существующую инфраструктуру.

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

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

У вас большой опыт внедрения автоматизации и подхода Infrastructure as Code. Какие принципы и практики IaC вы считаете наиболее важными для надежной и безопасной работы крупной инфраструктуры?

Главные принципы: единая точка правды и однотипность. Если внести нешаблонные изменения в любой сервис, то появляются вопросы: "Зачем это было сделано, и важно ли это сохранить? Не сломает ли массовое обновление инфраструктуры этот сервис?". За этим приходится следить и устанавливать строгие ограничения доступа для продуктовых команд, чтобы они случайно не сломали сервис. Иначе это усложняет работу нам и создает риск для них. Мы стараемся строить систему так, чтобы принципы однотипности и единой точки правды гарантировались самой архитектурой. Например, для создания нового сервиса можно копировать объемные IaC файлы, полностью описывающие инфраструктуру, изменяя там несколько полей — при этом среды перестают быть однотипными, и растет риск расхождений. Вместо этого мы используем единый IaC-шаблон для каждого сервиса, который берет нужные настройки из отдельного файла и инстанцируется только при запуске релизных процессов. Таким образом, ручные изменения архитектуры исключены, чтобы не допустить ошибок из-за человеческого фактора. Дополнительно у нас есть проверки при запуске пайплайнов — если какой-либо сервис был изменен, то последние действия должны быть сделаны этой же автоматической системой, а не вручную. Для проверки больших изменений в общих шаблонах у нас есть ручной инструмент, который подходит для валидации всех наших сервисов разом — но его мы применяем крайне редко. Наша основная цель — полностью исключить ручное вмешательство в сервисы, чтобы не допустить ошибок. При этом часто клиентам нужно оперативно внести изменения, и делать это через автоматические инструменты, как им кажется, дольше, чем править руками. Поэтому наша задача — максимально обеспечить клиентов инструментарием, который позволит быстро реагировать на инциденты, без необходимости ручных правок.

Давайте немного отвлечемся от вашей основной деятельности и перейдем к сайд-проектам. В прошлом году вы разработали робота для сборки кубика Рубика, который побил мировой рекорд в 0,203 секунды. Какие принципы и методы из работы с AI-инфраструктурой помогли вам при проектировании робота, и что общего между масштабированием сотен сервисов и управлением скоростным механизмом?

Сходство между этими проектами скорее идеологическое, чем практическое. И при управлении сотнями сервисов, и при разработке робототехники возникают процессы, которые нужно оптимизировать, чтобы не тратить лишнее время. Поэтому на первый план выходят навыки профилирования — чтобы найти «узкие» места, которые тормозят систему. Расскажу, как я выявил неожиданное «узкое» место в своем роботе-спидкубере. Он работает так: сканирует кубик с помощью камер, планирует свои действия и собирает кубик, используя шесть моторов, которые одновременно поворачивают грани. Чтобы ускорить процесс, робот использует возможность резки углов — это популярная у людей техника начинать проворачивать грань, даже если предыдущий поворот соседней грани не был завершен до конца. В процессе система постоянно опрашивает сервоприводы (двигатель с отдельной платой управления), следит за вращением и ждет нужного момента, чтобы дать команду для поворота следующей грани. Проведя профилирование, я выяснил, что узкое место — это одновременный опрос нескольких сервоприводов, а они опрашивались с самого начала вращения грани и до конца. Но так как роботу важнее конец вращения, чем начало, можно первые 5 миллисекунд вращать грань без обратной связи — так можно освободить пропускную способность для более точного опроса других граней, которые как раз заканчивают вращение.

Вы одновременно развиваете разные сферы — backend, AI и робототехнику — поэтому в заключение хочу спросить у вас о перспективе на ближайшие 5–10 лет: по вашему мнению, где появятся самые неожиданные и интересные возможности для инженеров, которые работают на стыке инфраструктуры и интеллекта?

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