У компаний появляется еще одна инженерная функция, которую пару лет назад многие бы приняли за шутку из чата в Slack: AI SRE. The New Stack пишет, что на фоне агентных инструментов разработки команды выпускают больше кода, чем раньше, а значит, быстрее накапливают и новый операционный долг: больше изменений, больше зависимостей, больше шансов, что инцидент прилетит не туда и не тогда, когда его ждали.
Сама постановка вопроса показательная. Авторы материала Nick Lucchesi и Alex Wilhelm предлагают компаниям не просто покупать очередной «умный» слой поверх мониторинга, а хотя бы попробовать собрать собственного AI SRE под свои процессы. Логика простая: если код теперь пишется и дорабатывается с помощью агентных помощников, то и разбирать последствия этого ускорения придется уже не только людям и не только классическим SRE-инструментам. Нужен слой, который умеет сопоставлять изменения в коде, телеметрию, сигналы из CI/CD, историю релизов и реальные симптомы в проде.
Важный нюанс в том, что речь не о замене SRE-команды на чат-бота с доступом к логам. Скорее о попытке создать внутреннего ассистента, который умеет делать черновую и самую нервную часть инцидент-менеджмента: быстро собирать контекст, сужать круг гипотез, поднимать связанные изменения, искать вероятную первопричину и предлагать следующий шаг. Для многих команд это уже выглядит логичным продолжением того, что произошло в разработке. Если AI помогает писать pull request, генерировать тесты и ускорять рефакторинг, то следом он неизбежно приходит туда, где этот ускоренный поток начинает ломаться, то есть в прод и в on-call.
Для русскоязычной IT-аудитории здесь особенно знакома сама боль. Почти в любой продуктовой компании скорость релизов давно воспринимается как конкурентное преимущество, но чем выше темп, тем короче окно на понимание, что именно пошло не так. Условно: вчера команда внесла три изменения, сегодня уже девять, завтра часть из них помогал писать агент в IDE, а послезавтра дежурный инженер пытается понять, какой именно коммит, конфиг или побочный эффект стал причиной деградации. И вот тут традиционный стек наблюдаемости начинает упираться в старую проблему: данных много, а ответа на вопрос «что сломалось первым» по-прежнему мало. AI SRE в этой картине выглядит не игрушкой для презентаций, а попыткой сократить путь от алерта до внятной версии причины.
Почему авторы делают акцент именно на «собственном» AI SRE, а не на готовом сервисе? Потому что инциденты редко укладываются в красивую универсальную схему. У каждой компании своя архитектура, свои зависимости, свои внутренние термины, свой ритм релизов и свой уровень хаоса в runbook-документации. Универсальная модель может помочь с паттернами, но реальные расследования почти всегда упираются в локальный контекст: кто что деплоил, какой сервис считается критичным, какие сигналы часто шумят, а какие действительно предвещают аварию. В этом смысле идея build-your-own звучит не как призыв срочно поднимать еще одну платформенную стройку, а как признание простого факта: operational knowledge плохо покупается в коробке.
При этом материал The New Stack не стоит читать как манифест «всем срочно нанять AI SRE-команду». Скорее это аккуратный сигнал рынку: вместе с агентной разработкой появляется новая зона ответственности. Если раньше узким местом был сам выпуск кода, теперь узким местом становится его эксплуатация, проверка гипотез и поиск причин сбоев. Для CTO и VP of Engineering это означает пересмотр бюджета и оргдизайна: часть инвестиций, которые еще вчера шли только в developer productivity, придется направлять в reliability automation. Для продактов это напоминание, что скорость поставки фич без эквивалентного роста устойчивости быстро превращается в платную подписку на хаос. Для HR в IT это еще и ранний индикатор новой гибридной компетенции на стыке SRE, platform engineering, observability и прикладного AI.
Есть и неприятная сторона этой истории. Как только компании начинают выпускать больше кода с помощью AI, соблазн закрыть последствия тем же AI становится почти автоматическим. Но если ассистент в разработке ошибся, баг можно поймать тестами или откатить релиз. Если ошибся AI-слой в разгар инцидента, цена выше: ложная первопричина, потеря времени команды, неверный rollback или пропущенный системный сбой. Поэтому идея AI SRE имеет смысл только там, где уже есть дисциплина вокруг телеметрии, change management, постмортемов и прав доступа. Иначе получится еще один «умный» интерфейс, который уверенно резюмирует то, чего сам не понимает.
Главный вывод из этого инфоповода довольно приземленный. Следующая гонка в инженерии, похоже, развернется не вокруг того, кто быстрее пишет код с агентами, а вокруг того, кто быстрее и точнее умеет разбираться в последствиях этого ускорения. Если эта гипотеза верна, то собственный AI SRE станет не модным ярлыком, а признаком зрелости: компания уже поняла, что в эпоху AI-кодинга выигрывает не та команда, которая чаще нажимает merge, а та, которая лучше остальных понимает, что именно она только что выпустила в прод.