State of On-call 2025

В начале 2025 года на конференции SREcon25 Americas было представлено исследование состояния практики дежурств в организациях, в рамках которого были изучены десятки академических статей и отраслевых публикаций, а также проведен опрос среди практикующих инженеров.

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

Подробнее про основные выводы из исследования читайте в нашем обзоре.

#insights #report #sre

Как не сойти с ума, чиня прод – практические заметки SRE

Практические заметки SRE: принципы вместо героизма, DIS и graceful degradation, мониторинг по абсолюту и трендам, нагрузочные тесты и учения, GitOps, фичатогглы, процессы и психология дежурств. Как строить надёжную эксплуатацию и спокойно восстанавливаться из инцидентов.

https://jtprog.ru/sre-recipes-summary/

На написание этой статьи меня сподвигла книга “SRE. Рецепты выживания в продакшне для инженера по надежности” за авторством Натальи Савенковой.

#DevOps #SRE #Postmortem #Observability #incidentManagement #ChaosEngineering #post

Когда 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