Споры про искусственный интеллект в SRE изменились.

Мы уже не гадаем, заменит ли агент дежурного инженера. Мы решаем, где именно провести черту его полномочий.

Сейчас тренд такой: агенту разрешают расследовать инцидент, но запрещают его чинить. И это логично, потому что граница проходит по цене ошибки.

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

Как выстроить эту границу на практике, чтобы не получить генератор галлюцинаций:
1. Настоящий режим только для чтения. Нужно следить, чтобы простое чтение данных агентом не запускало скрытые действия в базе или не блокировало процессы.
2. Жесткое вето со стороны. Если агент предлагает откатить релиз или добавить ресурсов, проверять это действие должен обычный, предсказуемый скрипт. Это правило должно жить в отдельном месте, куда у агента нет доступа на изменение.
3. Обратимость действий. Автоматизировать стоит только то, у чего есть четкий и быстрый откат. Перезапуск или масштабирование - это временное решение, а не настоящий фикс. Финальное решение и применение изменений в проде всегда остаются за человеком.

Даже самые радикальные сторонники автоматизации дежурств начинают с того, что дают агенту только чтение телеметрии и сравнивают его выводы с человеческими. Без фундамента в виде нормальных SLO и понятных метрик AI-агент не спасет, а просто будет быстрее ошибаться.

На каком этапе вы готовы доверить автомату реальное действие, а не просто анализ?

#sre #oncall #ai #observability #slo #incidentmanagement

Макс писал в деталях тут https://t.me/youngmaxnotes/131