Как ИИ может улучшить site reliability engineering
По данным Cursor Developer Habits Report, 1% активных пользователей ИИ уже создают в 46 раз больше написанных ИИ строк кода в день, чем медианный активный пользователь. Узкое место сегодня — не написание ПО, а понимание того, что происходит после выкладки.
Каждый новый сервис, зависимость, feature flag, сгенерированная абстракция и путь деплоя увеличивают число способов, которыми production-система может отказать. ИИ сократил время, нужное для создания этой сложности, но не сократил время, нужное для ее понимания.
В итоге production-среда меняется быстрее, чем инженеры успевают заново собрать ее ментальную модель. В этой ситуации ИИ может помочь, потому что большинство практик отладки были придуманы для более медленного мира.
Отладка вчера и сегодня
Десятилетиями отладка была в основном пространственной задачей. Сбой в Service A относился к команде, которая владела Service A. Эта команда знала историю деплоев, особенности эксплуатации, полезные запросы к логам и странные поведения, которые так и не попали в runbook. Реакция на инциденты исходила из того же предположения: команды владели сервисами, runbook были привязаны к этим сервисам, а дежурства on-call повторяли организационные границы.
Эта модель по-прежнему работает, когда сбои остаются локальными. Если деплой вызывает утечку памяти или неверная конфигурация приводит к падению сервиса, симптом и причина обычно находятся в одном месте. Владеющая команда может разобраться, найти проблему и восстановить сервис. Но таких инцидентов становится все меньше среди всех production-сбоев.
Сгенерированный ИИ код сам по себе не менее надежен, чем написанный человеком. Изменились объем и скорость. Команды теперь могут вносить больше кода, затрагивать больше систем одновременно и быстрее развивать архитектуры, чем раньше. По мере того как системы становятся более взаимосвязанными, сбои все чаще проявляются не там, где возникают.
Инцидент одного перехода локален: сервис, который испытывает сбой, одновременно и является его источником. Расследование остается внутри границ одной команды.
Инцидент с несколькими переходами выглядит иначе. API checkout начинает отвечать с таймаутами. Внутри checkout ничего явно не сломано. Латентность нормальная. Уровень ошибок низкий. Реальная проблема — consumer очереди молча отбрасывает сообщения, потому что изменение схемы, развернутое двумя днями ранее, было лишь частично обратно совместимым. Команда очереди видит нормальную пропускную способность. Команда data platform не получает page, потому что в ее сервисе не нарушен ни один порог алерта. Каждая команда права в рамках своей системы, но никто не может объяснить, почему клиенты не могут завершить покупку.
Проблема не в нехватке данных. Современные production-системы производят больше telemetry, чем любой человек может использовать во время инцидента. Проблема в том, чтобы понять, какие данные важны, какие сигналы случайны и как разрозненные подсказки складываются в причинную цепочку.
Роль ИИ в production ops
Это меняет роль, которую должен играть ИИ. Его не стоит воспринимать как волшебного on-call-инженера. Frontier model не знает вашу архитектуру. Он не помнит прошлые инциденты. Он не знает, какие dashboards врут, какие сервисы падают вместе, что изменилось на прошлой неделе и какие зависимости важнее всего. Сам по себе он рассуждает в вакууме.
Полезная версия ИИ в production более конкретна. Он может собрать контекст, проверить гипотезы, проследить зависимости, сравнить текущий инцидент с прошлыми и отбросить объяснения, которые не совпадают по времени или blast radius. Он может делать работу, которая сейчас съедает первые 20 минут инцидента: собирать evidence, проверять недавние изменения, строить карту зависимостей и сужать пространство поиска.
Решения, требующие суждения, по-прежнему принимают люди. Они решают, достаточно ли сильны доказательства для действия, стоит ли риск rollback, нужно ли будить другую команду и является ли самым безопасным шагом mitigation или более глубокое расследование. Но им не нужно тратить половину инцидента на восстановление системы, которой организация и так уже управляет.
В этом и состоит более крупный сдвиг в производительности.
Если ИИ возьмет на себя большую часть troubleshooting tax, инженеры смогут сосредоточиться на работе, которая действительно накапливает эффект. Они смогут упрощать хрупкие архитектуры. Улучшать instrumentation в тех местах, где инциденты регулярно «уходят в темноту». Проектировать более безопасные degradation paths, более точные alerts, лучшие rollback patterns и evals, которые ловят semantic failures до того, как их увидят клиенты. Они смогут возвращать знания о production обратно в разработку, чтобы code assistants и процессы review понимали, какие сервисы рискованные, какие шаблоны уже приводили к outages и какие зависимости требуют особого внимания.
Именно на такую работу у инженеров обычно не хватает времени, потому что они снова и снова застревают в разборе одних и тех же классов инцидентов.
Дать инженерам заниматься инженерией
Цель не в том, чтобы убрать инженеров из production. Цель в том, чтобы перестать тратить их суждение на работу, которую система должна была делать сама. ИИ должен сокращать инциденты, но это лишь первичный эффект. Более важный эффект — дать senior engineer больше времени на предотвращение будущих инцидентов, а не втягивать их в каждый запутанный случай.
По мере того как ИИ ускоряет создание ПО, с другой стороны production operations нужен такой же ускоритель. Не просто более быстрая отладка. Лучшая распределенность человеческого внимания.
АИ-лавину кода не получится сдержать, заставляя инженеров бесконечно разбирать инциденты на машинной скорости. Ее сдержат, если сделать production-системы более понятными, более устойчивыми и менее зависимыми от того, какой именно эксперт случайно не спит.
—
New Tech Forum предоставляет площадку для технологических лидеров, включая вендоров и других внешних авторов, чтобы подробно обсуждать новые корпоративные технологии. Отбор материалов субъективен и основан на выборе технологий, которые редакция считает важными и наиболее интересными для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы к публикации и оставляет за собой право редактировать весь присланный контент. Все запросы направляйте на doug_dineley@foundryco.com.
Материал — перевод статьи с английского.