ИИ разбирает инциденты, инженеры теряют связь со своими системами

Сентябрьский пост Сильвена Калаша 2026 года начинается с его собственной истории. Будучи SRE в LinkedIn в 2012 году, он спроектировал систему, которая должна была самовосстанавливаться и учиться на прошлых инцидентах; она осталась прототипом, потому что ИИ того времени на это не был способен. Инструменты, которые умеют это делать, теперь существуют: они разбирают алерты, формулируют гипотезы, запрашивают телеметрию, сопоставляют недавние deploy'и и применяют исправления. Они ему нравятся, их маркетинговое название "AI SRE" не нравится, и он опасается, что инженеры теряют связь со своими системами. Сейчас он работает в Rootly, компании по управлению инцидентами, и это важная деталь: описанное им решение - продукт его работодателя.

Аргумент

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

Он возводит эту мысль к статье Лизанны Бейнбридж 1983 года (bainbridge-ironies-of-automation; он называет её "The Ironies of Automation", в опубликованном заголовке артикля нет). Его пересказ совпадает с оригиналом: автоматизация сокращает возможность операторов практиковаться на рутинной работе, оставляя на них ответственность за нештатные ситуации, поэтому им требуется ещё больше навыков и больше подготовки, чем раньше.

Отсюда он делает прогноз, который стоит зафиксировать для последующей проверки: средний MTTR для большинства инцидентов снизится благодаря помощи ИИ, тогда как время решения сложных аварий резко взлетит из-за того, что инженеры потеряли контакт со своими системами. Никаких данных в подтверждение он пока не приводит.

Авиация как модель

Пилоты служат для него примером профессии, которая уже живёт в этих условиях. Автоматика пилотирует большую часть времени, а на пилотах остаётся ответственность за отказы двигателей, неверные показания приборов, прерванные взлёты и сваливание. Он приводит цифру: менее одного отказа двигателя в полёте на 100 000 лётных часов для современных газотурбинных двигателей. Это настолько редко, что пилот гражданской авиации может завершить карьеру, ни разу не столкнувшись с этим за пределами тренажёра. Когда такое всё же случается, реагировать нужно быстро и безошибочно, и его контрпример - рейс 235 TransAsia Airways: винт правого двигателя после взлёта автоматически перешёл во флюгерное положение, экипаж неверно определил проблему, самолёт свалился и разбился через 117 секунд после первого предупреждения. По правилам FAA, пишет он, командиры воздушных судов каждые шесть месяцев проходят повторное обучение или проверку квалификации, включая отказ двигателя на взлёте.

Решение

Rootly и Uptime Labs проводят реалистичные симуляции инцидентов. Инженер занимает место руководителя ликвидации аварии во время учебного сбоя в интернет-магазине, исследует проблему через инструменты observability и координирует действия в Slack с заинтересованными лицами, которых отыгрывает LLM, включая CEO и службу поддержки. На практике отрабатываются осмысление неполной информации, чёткая коммуникация, координация людей и управление ходом реагирования.

Он рассматривает очевидную альтернативу - просить агента объяснять шаги, сигналы и доказательства его диагноза - и отвергает её как полноценную замену: наблюдение за Сереной Уильямс может чему-то научить, но в теннис учатся играть на корте. Он подкрепляет это собственным прошлым опытом. Он более пяти лет строил школу разработки ПО вокруг обучения на практике, без преподавателей и с проектами вместо лекций; когда в Dropbox ему сказали, что нанятые выпускники слабы в поиске и устранении неполадок, он написал проекты, где студентам давали сломанную инфраструктуру для диагностики и починки.

Этот риск он называет долгом понимания (comprehension debt): растущий разрыв между тем, как работают системы команды, и тем, насколько хорошо дежурные их понимают. Рецепт - регулярный прямой контакт с системой, столкновение с незнакомыми сбоями, практика под давлением и отработанная координация при авариях уровня SEV0. Кабинетные учения (tabletop exercises) и chaos engineering - не новость, признаёт он, но сейчас они становятся ещё важнее.

Сопоставление с Бейнбридж

В посте взяты два решения из статьи - ручное управление и симуляции - но опущены другие, которые сделали бы аргументацию сильнее. Бейнбридж доказывала, что тренажёры не способны воспроизвести неизвестные неисправности, поэтому обучение должно учить общим стратегиям, а не конкретным реакциям. Это точное описание того, что тренирует роль руководителя инцидента, и повод предпочесть такие учения разбору вчерашних сбоев. Она также предупреждала, что автоматическое управление может маскировать сбой, компенсируя его до тех пор, пока исправить ситуацию станет уже невозможно. ИИ-дежурный, который в три часа ночи тихо глушит симптомы медленной деградации системы, - вполне правдоподобный программный аналог такой маскировки, и это лишь сильнее спрячет от глаз те сложные инциденты, о которых беспокоится автор.

Его "comprehension debt" - это командный аналог cognitive-debt, описывающего ту же эрозию в голове одного человека. Версия этого же аргумента для агентов-программистов - skill-atrophy-supervision-paradox; общий паттерн разобран в ironies-of-automation. История со школой разработки ставит его на одну сторону с идеями из dont-outsource-learning, где выход состоит в том, чтобы сохранять преодоление трудностей в процессе, а не читать чужие объяснения.