Когда AI ломает облако: кейс AWS и Kiro AI

Привет, %username%! Тут всплыла интересная история: у AWS в декабре было как минимум два инцидента, в которых ключевую роль сыграли их же собственные AI-инструменты — агент Kiro и другие dev-инструменты на базе AI.

Что произошло по факту?

  • В середине декабря один из AI-агентов (Kiro AI для разработчиков) получил доступ на внесение изменений и решил «delete and recreate environment» — фактически снес и пересоздал окружение, от которого зависел клиентский сервис для анализа стоимости использования AWS.
  • Это привело к 13-часовому инциденту для клиентов, пользующихся этим сервисом.
  • Источники внутри компании говорят, что было как минимум два подобных инцидента за последние месяцы, оба связаны с автономными AI-агентами, которым позволили действовать без человеческой проверки.
  • Официальный комментарий AWS: это не «ошибка AI», а «user error» — некорректно настроенные права доступа, которые позволили агенту делать слишком много.

На мой взгляд, тут несколько очень важных уроков для нас с тобой:

  • Автономный AI = ещё один супер-сильный и плохо предсказуемый оператор. Если ты даёшь агенту право менять инфраструктуру, он должен проходить те же уровни контроля, что и человек с prod-доступом (RBAC, approvals, change management, audit).
  • «Пусть AI сам всё починит» без guardrails быстро превращается в «AI сам всё сломал». Нужны чёткие ограничения: где агент только предлагает actions, а где ему можно выполнять действия автоматически — и при каких SLO/условиях.
  • Классические практики SRE никуда не делись: canary/gradual rollout даже для AI-автономии; принцип наименьших привилегий для агентов; чёткие runbook’и и контрольные точки, куда AI не может ступить без человека.
  • Коммуникация тоже важна: AWS публично минимизирует масштаб («очень ограниченное событие», один сервис в одном регионе Китая), но 13 часов даунтайма для клиентского сервиса — это совсем не мелочь с точки зрения пострадавших пользователей.

Если смотреть шире — это хороший звоночек для всех, кто сейчас встраивает AI в CI/CD, incident response, remediation и управление инфраструктурой. AI-агенты очень быстро превращаются из «умного помощника» в «root с руками, которые не устают» — и это может быть как благом, так и идеальным источником инцидентов.

Предлагаю обсудить:

  • Ходят ли AI-инструменты в твою prod-инфраструктуру сейчас? Что им разрешено: только советовать или уже что-то менять?
  • Как бы ты ограничивал агентные системы: отдельные роли, sandbox-окружения, обязательные human approval на destructive actions?
  • Считаешь ли ты честным называть такие кейсы «user error, not AI error», или это уже вопрос культуры ответственности и дизайна систем?

Делись опытом и идеями — особенно будет интересно почитать реальные истории, где AI уже помогает (или мешает) в эксплуатации.

@jtprogru_channel @jtprogru_chat

#SRE #DevOps #AI #AWS #Incidents #Automation #Reliability #OnCall #Observability