Как ИИ влияет на site reliability engineering (SRE)
Инженеры по надежности сайтов, или site reliability engineers (SRE), решают сложные проблемы с производительностью и надежностью. При этом их основная задача — давать devops-командам операционные инсайты и предлагать улучшения внедрения, которые повышают производительность бизнес-систем, безопасность и общую устойчивость.
Google представила свой SRE playbook в 2003 году, но на то, чтобы роль, инструменты и методы стали массовыми, ушло время. Сначала observability для cloud-native-приложений и отдельные SRE-позиции начали внедрять стартапы. По мере того как инструменты зрелели и обязанности SRE становились более четкими, крупные предприятия стали назначать SRE связующим звеном между devops и IT ops-командами, чтобы повышать устойчивость более широкого круга приложений, API и data pipelines.
SRE — это карьерный путь для разносторонних инженеров с сильным исследовательским мышлением, развитыми навыками анализа данных и умением работать под давлением. Эта роль стала критически важной по мере того, как технологии стали миссионно важными для предприятий, и она становится все более востребованной в эпоху genAI, поскольку все больше компаний внедряют AI agents.
Но критическая необходимость в устойчивости и возросшая технологическая сложность создают для SRE новые вызовы. Согласно отчету 2026 State of Production Reliability and AI Adoption, 44% респондентов за последний год сталкивались с outage, связанным с проигнорированными или подавленными alert-уведомлениями, а 35% сообщили, что их инженеры иногда игнорируют или отклоняют alert из-за alert fatigue. Более 70% получаемых alert, по мнению 57% организаций, не являются actionable.
Так делает ли ИИ роль SRE проще и помогает ли бизнесу запускать более надежные технологические операции? С другой стороны, ИИ сам же повышает сложность: компании разворачивают genAI-инструменты и AI agents во все большем числе бизнес-функций и стремятся автоматизировать больше решений в операционной деятельности.
AIops и agentic ops помогают SRE
За последнее десятилетие обязанности SRE несколько упростились благодаря улучшениям в monitoring platforms, практиках observability, инструментах централизованного сбора operational data и применению ИИ в IT operations (AIops). Но в разгар устранения outage или проблемы с производительностью непросто точно определить, какая система стала источником сбоя, а какие downstream-системы были затронуты.
Согласно Komodore 2025 Enterprise Kubernetes Report, 79% production incidents возникают из-за недавних изменений в системе, включая deployments и изменения в compute environments. Но остальные 21% incidents вызваны причинами, не зависящими от бизнеса, включая network failures, изменения у третьих сторон и сбои cloud provider.
«SRE, использующие возможности ИИ, добиваются успеха или терпят неудачу в тот момент, когда incident разворачивается и инженеры решают, что исследовать дальше», — говорит Itiel Shwartz, CTO в Komodor. «Если система упрощает обнаружение root cause, связывает сигналы с недавними изменениями и объясняет свою логику так, что инженеры это узнают, она заслуживает доверия. Если же она добавляет неопределенность или требует дополнительной проверки, ее отодвигают в сторону, независимо от того, насколько уникальна лежащая в основе модель. Менее очевидно то, что нужно, чтобы ИИ для SRE работал в production, и насколько эта реальность отличается от прототипов, демо и ранних внутренних сборок».
AIops — не новая возможность, особенно когда речь идет об использовании machine learning для корреляции logs, metrics и traces между monitoring и alerting-системами. IT service management и SRE уже применяют AIops, чтобы сокращать mean time to resolve incidents и эффективно выполнять root cause analysis (RCA). Agentic ops — следующий этап genAI-операционных возможностей, включая инструменты для мониторинга AI agents, управления их правами доступа и обнаружения drift точности AI model.
«ИИ полезен во время крупных incidents, потому что он может собрать большой объем контекста в несколько понятных предложений, а именно это нужно SRE в моменте», — предполагает Shani Shoham, chief revenue officer в OpenObserve. «Сложность архитектуры и разнообразие инструментов делают это проще для ИИ, чем для человека, но до автономного устранения проблем еще далеко».
Влияние ИИ на людей и burnout
Бизнес-потребность поддерживать системы в рабочем состоянии, защищенными и производительными — это круглосуточная стрессовая ответственность. Согласно The SRE Report 2025 от Catchpoint, 36% SRE часто или всегда испытывают повышенный стресс во время инцидента, а 28% сказали, что стресс сохраняется даже после его устранения. Возможности ИИ могут стать переломным фактором, помогая SRE избежать burnout и снизить стресс.
«ИИ может улучшить RCA, принимая во внимание куда больший контекст инцидента, чем способен удержать один инженер в 3 часа ночи, и анализируя traces, logs, metrics, deploys, config changes, alerts, ownership и недавнее поведение в production», — говорит Noam Levy, founding engineer и field CTO в Groundcover. «Помимо попытки провести полный RCA, его немедленная ценность — в том, чтобы выделить действительно важные сигналы, восстановить понятную хронологию причин и следствий и помочь инженерам отделить корреляцию от вероятной причинности. После внедрения исправления агенты также могут проверить remediation, сравнив поведение до и после, но это зависит от широкого доступа к богатым, коррелированным production-сигналам и cost model, который не мешает внедрению или экспериментам».
ИИ не только ускоряет устранение incidents и снижает стресс, но и может освобождать время SRE для proactive work и создавать карьерный путь для junior developers в роли SRE. Quais Taraki, CTO в EDB Postgres AI, добавляет: «ИИ снижает toil за счет автоматизации повторяющихся задач и ускоряет устранение incidents через copilots, которые сопоставляют сигналы across distributed systems, позволяя SRE сосредоточиться на стратегиях устойчивости, таких как chaos engineering и failure analysis».
ИИ может оказывать долгосрочное операционное влияние, особенно для организаций, которые хотят внедрять более mission-critical технологии и ИИ-возможности. Два долгосрочных преимущества ИИ для SRE — сокращение числа bridge calls, необходимых для incident response, и уменьшение числа инженеров, требуемых в «war rooms» для координации root cause analyses.
«Когда что-то идет не так, ИИ, который направляет SRE, может провести полный анализ, добраться до root cause и выполнить remediation», — говорит Spiros Xanthos, основатель и CEO Resolve AI. «ИИ также помогает избегать многих escalations, а когда они нужны, он направляет их к нужным людям из network, infrastructure и application teams. ИИ для SRE централизует operational intelligence, делает явным tribal knowledge и может помогать более junior developers».
Надежность AI agents
Хотя возможности ИИ в целом помогают SRE улучшать надежность систем, рост AI code generators, vibe coding и spec-driven development увеличивает их нагрузку. По данным одного исследования, 41% всего мирового кода теперь создается ИИ, а Gartner прогнозирует, что к 2028 году 40% нового enterprise production software будет создаваться с помощью техник vibe coding.
Но рост скорости разработки создает новые проблемы для SRE: по данным CodeRabbit, в AI pull requests в 1,4 раза больше critical issues и в 1,7 раза больше major issues. «AI-assisted development создала беспрецедентную скорость попадания кода в production, расширяя поверхность атаки, число edge cases и частоту отказов быстрее, чем традиционные SRE-практики могут это поглотить», — говорит Vinod Jayaraman, сооснователь и CTO NeuBird AI. «Скорость выпуска решений давно опередила скорость понимания того, что ломается в production. Чтобы замкнуть этот цикл, SRE нужны enterprise agents, которые могут собирать точный диагностический контекст, включая correlated traces, service dependencies и anomaly timelines, и превращать его в пригодный для действий ввод для инженеров и AI coding tools, отвечающих за исправление».
Растущее число AI agents, разворачиваемых в production, создает новые вызовы. AI agents — это не просто code; у них несколько точек отказа. Они построены на основе language models, подключаются к proprietary sources за контекстом и интегрируются с Model Context Protocol servers, чтобы поддерживать более сложные workflows. Изменения происходят непрерывно и не являются deployment events, поэтому задача SRE по выявлению источника ухудшения производительности и accuracy drift далеко не тривиальна.
«Традиционный SRE был создан для систем, которые отказывают воспроизводимым образом, но agents отказывают иначе и drift при обновлении со стороны model provider, а поведение меняется тихо, без baseline для сравнения», — говорит Mohammed Aboul-Magd, вице-президент по продукту в SandboxAQ. «Большинство организаций не могут ответить даже на базовые вопросы: сколько agents запущено, к чему у них есть доступ и продолжают ли они делать то, для чего были созданы».
«Каждый раз, когда уходит senior engineer, он уносит с собой годы изученных failure patterns, и следующий outage начинается с нуля», — добавляет Ronak Desai, сооснователь и CEO Ciroos. «Использование ИИ для накопления operational memory меняет это, и каждый инцидент, который ваша система решает, ИИ запоминает».
SRE должны взять на себя лидерскую роль в формировании emerging best practices, включая определение стандартов non-functional acceptance criteria для AI agents, observability practices и release-readiness criteria. SRE также должны обновить свои service-level objectives (SLO) и определить error budgets для AI agents в production.
Ryan Downing, вице-президент и CIO enterprise business solutions в Principal Financial Group, говорит: «Стандартные SLO и error budgets дают командам рамки, а ИИ помогает интерпретировать telemetry относительно этих целей, снижая шум, чтобы инженеры быстрее доходили до реальной проблемы и автоматизировали часть remediation до того, как это затронет клиентов».
ИИ повышает бизнес-значимость SRE
Более заметный сдвиг в site reliability engineering — это расширение его бизнес-области. IT-руководители сосредоточены на uptime, производительности и устранении проблем, а также на понимании их последствий. Руководители бизнеса будут ожидать от IT и SRE выявления, определения root cause и исправления более широкого класса проблем, включая rogue AI agents и последствия быстрого развертывания новых agentic capabilities.
«AI agents ставят перед SRE категории проблем, которые им раньше не приходилось решать, а именно сбои, определяемые в бизнес-терминах, а не в технических», — говорит Blake Sherwood, distinguished technologist по AI и platform strategy в Smarsh. «Традиционная reliability engineering строится вокруг latency, errors и crashes, но agents теперь дают сбои из-за пропущенных compliance steps или результатов, которые технически выглядели нормально, но контекстно были неверными. Большинство SRE-команд пока не настроены на это».
Вопрос в том, смогут ли SRE с AI-augmented tools успевать за скоростью, сложностью и бизнес-неотложностью внедрения новых AI business capabilities.
Материал — перевод статьи с английского.