[Перевод] LLM вместо «прочитаем потом»: анализ постмортемов и паттерны инцидентов

Ваши инциденты содержат основу для самых стратегических улучшений инфраструктуры — если вы умеете правильно их «слушать».

В Zalando группа коллег, отвечающих за хранилища данных в нашем Tech Radar, решила исследовать вопрос:

«А что, если каждый отказ системы мог бы делать всю нашу инфраструктуру умнее?»

Дальше мы подошли к теме с позиции Site Reliability Engineering (SRE), чтобы извлекать из сбоев и постмортемов действительно ценное знание. Для нас ключевой элемент SRE — это контур обратной связи, в котором развиваются системы, команды и инвестиции. До сих пор наш традиционный подход к этому контуру опирался на человеческий разбор последствий инцидента, анализ первопричин (RCA) и корректирующие меры, которые внедряются, чтобы предотвратить повторение. Для оперативного, «реактивного» обучения это работает хорошо, но для ретроспективного анализа инцидентов за годы на масштабе компании — уже плохо подходит.

С ростом популярности LLM мы увидели возможность. Могут ли LLM находить закономерности, выявлять системные проблемы и даже предлагать превентивные меры, анализируя наши постмортемы в большом масштабе? Можно ли превратить прошлые выводы в динамически обновляемые наборы данных? Мы решили проверить эту гипотезу сначала на технологиях хранилищ данных, прежде чем масштабировать подход дальше.

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

• Как превращать постмортемы в предиктивные сигналы для более надёжного будущего;

• Как настроить ИИ так, чтобы он «читал между строк» и помогал тем, кто принимает решения;

• Практические советы по автоматизации анализа постмортемов.

Наш опыт показывает, что описанная автоматизация — это больше, чем лайфхак для повышения продуктивности, даже при том, что мы всё ещё продолжаем внедрять её и выжимать из неё пользу. Это стратегический рычаг для инженерных команд.

Традиционная проблема постмортемов

Многие компании унаследовали культуру постмортемов из книги Google «Site Reliability Engineering», в частности из главы «Postmortem Culture: Learning from Failure». Культура постмортемов в нашей команде во многом похожа. После того как устранены факторы, негативно влияющие на бизнес-операции, команда, отвечающая за инцидент, приступает к анализу первопричин и внедрению превентивных мер. В разборе участвуют не только команды, напрямую ответственные за затронутые приложения, но и стейкхолдеры, а также смежные команды. Инцидент считается закрытым только тогда, когда инженерное руководство (вплоть до VP Engineering — в зависимости от влияния и серьёзности) подтверждает достаточный прогресс по внедрению превентивных мер и утверждает постмортем. Выводы по таким инцидентам распространяются «снизу вверх» через еженедельные операционные обзоры и «по горизонтали» через инженерные сообщества. Это превращает каждый инцидент в возможность обучения для всей компании. Со временем у нас накопился богатый внутренний датасет: тысячи архивных документов постмортемов — настоящая золотая жила технических и организационных знаний.

Даже при такой культуре обучения есть ограничения:

• Постмортемы сильно различаются по глубине и ясности. Сравнивать их и извлекать закономерности часто ощущается как попытка сравнивать несопоставимые вещи;

• Анализ первопричин отражает допущения команды, а тонкие сопутствующие факторы нередко остаются «между строк»;

• Связывать инциденты между разными командами — это огромная когнитивная нагрузка и, по сути, неформальный нетворкинг. Чтобы смотреть на картину целиком на уровне компании, всё ещё нужна добрая воля конкретных людей и эффективные связи.

Когда обучение надёжности системы зависит исключительно от человеческих усилий, масштаб становится врагом. Вдумчиво прочитать один постмортем занимает примерно 15–20 минут (выделенный ревьюер способен разобрать около четырёх постмортемов в час при условии непрерывной концентрации). А теперь умножьте это на тысячи документов. Внезапно стратегические вопросы вроде «Почему хранилища данных чаще всего дают сбои на масштабе?» становится невозможно быстро закрыть — или хотя бы закрыть без чрезмерной когнитивной нагрузки. Даже если взять ограниченную область, связанную только с хранилищами данных, это потребовало от нас значительных временных затрат.

В результате мы рискуем:

• Пропускать системные сигналы, которые могли бы подсказать, куда инвестировать в инфраструктуру;

• Реагировать на симптомы вместо того, чтобы устранять первопричины;

• Откладывать решения из-за нехватки целостной картины на стыке доменов.

Это «бутылочное горлышко» по пропускной способности привело нас к очевидному выводу: чтобы извлечь стратегическую ценность из нашего корпуса постмортемов, нам нужны скорость и эффективность. Конкретно — инструменты на базе ИИ, которые умеют читать, интерпретировать и синтезировать текст в большом масштабе.

Наша гипотеза была простой: LLM могут превратить гору документов, написанных людьми, в динамический датасет для принятия решений. Результаты, которые мы разберём дальше, оказались ещё более многообещающими, чем мы ожидали. Это снизило для нас когнитивную нагрузку: контекст стал компактнее, а паттерны в большом массиве постмортемов начали находиться быстро.

Внедрение ИИ: автоматизация анализа постмортемов

Мы сфокусировались исключительно на наших хранилищах данных: Postgres, AWS DynamoDB, AWS S3, AWS ElastiCache и Elasticsearch. По каждому из них у нас был вопрос: «Почему это хранилище данных снова и снова даёт сбои на масштабе?» — и желание получать ответ сразу.

Google NotebookLM выглядел естественным выбором в качестве инструментария для анализа постмортемов. Он отлично справлялся с тем, чтобы делать короткую выжимку из тысяч документов. Блокноты (Notebooks) повысили продуктивность в три раза: прочитать сводку и сделать выводы о первопричинах занимает около 5 минут. Но на нашем масштабе это всё равно медленно: разбор сводок занимает недели даже у выделенной команды экспертов, и всё равно не позволяет быстро отвечать на вопросы.

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

Чтобы решить проблему, мы спроектировали многоэтапный LLM-пайплайн вместо того, чтобы использовать топовые модели с огромными контекстными окнами. Это осознанный компромисс в пользу простоты и надёжности. Да, большие окна контекста позволяют модели «проглотить» больше текста, но мы заметили эффект «потерялся в середине»: детали из середины длинного ввода часто пропускаются или искажаются. Кроме того, большой контекст не гарантирует идеальной памяти и может увеличивать задержки, потребление памяти и стоимость. Наш пайплайн — это цепочка из нескольких моделей, где каждая стадия строго специализируется на одной цели.

В итоге конвейер просеивает высокоэнтропийную информацию и сводит её к лаконичным причинам отказов. Функциональный паттерн «map-fold» — ключевой строительный блок этого конвейера. Большой набор документов независимо обрабатывается языковой моделью, чтобы извлечь релевантные сведения (фаза «map»). Затем эти результаты агрегируются либо ещё одним вызовом LLM, либо детерминированной функцией в обобщённую сводку более высокого уровня (фаза «reduce» или «fold»). Такая модульная архитектура поддерживает композицию задач — например, суммаризацию, классификацию или извлечение знаний. На входе конвейера — тысячи документов постмортемов, на выходе — одностраничный отчёт, описывающий тренды и паттерны инцидентов в выбранном фокусе. Для каждого этапа мы подключали человеческую экспертизу: проверку, разметку и контроль качества, чтобы соблюсти требования к точности.

Суммаризация

Этот этап предназначен для того, чтобы превращать «сложные» отчёты об инцидентах в понятные сводки. Шаг, рассчитанный и на людей, и на машины, помогает заинтересованным сторонам быстро и точно понимать ключевые аспекты каждого инцидента без необходимости продираться через большие объёмы контекста.

Используя узко сфокусированный промпт, мы применяли техники промпт-инжиниринга Turn, Expression, Level of Details, Role (TELeR). LLM обрабатывает каждый документ постмортема и извлекает только самое существенное по пяти базовым измерениям:

• Issue Summary — краткое описание того, что произошло;

• Root Causes — чёткое выявление первопричин: технических или процессных;

• Impact — фактическое описание того, какие системы, сервисы или пользователи были затронуты и каким образом;

• Resolution — шаги, предпринятые для устранения инцидента;

• Preventive Actions — запланированные или уже внедрённые меры, предотвращающие повторение.

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

Ниже — цензурированный пример сводки, которую генерировали LLM:

Краткое описание: [DATE], в промежутке между [TIME] и [TIME], развёртывание обновления библиотеки привело к инциденту уровня SEV2 длительностью [DURATION], затронувшему несколько сервисов. При развёртывании была обновлена AWS SDK с версии 2.20.162 до 2.30.20,что вызвало всплеск 5xx-ошибок и деградацию функциональности на страницах [PAGE A], [PAGE B], [PAGE C] и [PAGE D]. Первопричины: Основной первопричиной стало отсутствие зависимости [CLASS], вызванное несовместимостью версий между обновлённой AWS SDK (2.30.20) и общей [LIBRARY]... Среди вторичных причин — недостаточные интеграционные тесты, которые могли бы выявить проблемы подключения к DynamoDB, а также неполные практики развёртывания, когда PR накапливались до того, как изменения полностью раскатывались. Влияние: — Клиенты: [NUM_CUSTOMERS] получили некорректную [PAGE A]; [NUM_CUSTOMERS] клиентов не смогли открыть [PAGE B]; клиенты видели неперсонализированную [PAGE C]; а [PAGE D] была недоступна — Бизнес: потери примерно на [GMV] — Рынки: все [MARKETS] для [PAGE B] — Партнёры: [PAGE D] была недоступна во время инцидента Устранение: Инцидент устранили откатом проблемного развёртывания. Обнаружение произошло по алерту P5 в [TIME], затем сработал алерт P3 в [TIME] (высокий уровень 5xx-ошибок). Первопричину определили в [TIME], откат инициировали в [TIME], полное восстановление — к [TIME]. Превентивные меры: — Немедленные: откатили развёртывание, сократили задержку срабатывания алертов, зафиксировали версию AWS SDK на 2.20 — Дальнейшие: внедрить автоматизированные e2e-тесты для DynamoDB, обновить версию AWS SDK в общей библиотеке, ...

Классификация

На этом этапе мы системно определяем, повлияли ли конкретные технологии хранилищ данных напрямую на инцидент. Процесс устроен так: модель получает сводку постмортема вместе со списком интересующих технологий. LLM в промпте просили возвращать только названия технологий, для которых подтверждена прямая связь, либо «None», если такой связи нет:

• Найти любые упоминания этих технологий в документе;

• Проверить, что упоминание явно связано с первопричиной или влиянием инцидента.

• Ошибки поверхностной атрибуции (Surface Attribution Error) стали препятствием для нашего решения. Нам пришлось жёстко запретить выводы «по догадке» и любые предположения, чтобы отмечались только связи, прямо сформулированные в тексте. Дополнительно в промпт включены негативные примеры.

Реализованный классификатор надёжно определяет «причастность» технологии, что даёт нам возможность масштабировать анализ на все технологии в Zalando Tech Radar.

Анализатор

Самая важная часть анализа инцидента — извлечь короткий дайджест на 3–5 предложений, который подсвечивает: (а) первопричину или отказное состояние, связанное с технологией; (б) роль, которую она сыграла в общем сценарии отказа; (в) любые сопутствующие факторы или взаимодействия, усиливающие проблему. Выход формируется с расчётом на техническую аудиторию: он должен быть точным и читабельным без доступа к полному постмортему, так чтобы на понимание ключевых аспектов каждого инцидента уходило всего 30–60 секунд.

Ниже — цензурированный пример дайджеста, который генерировали LLM:

DynamoDB внесла вклад в этот инцидент как затронутое хранилище данных, но не была первопричиной отказа. Первопричиной стала несовместимость версий между обновлённой AWS SDK (2.30.20) и более старым модулем поддержки DynamoDB (2.17.279), который по-прежнему зависел от класса, удалённого в новой версии SDK. Этот конфликт зависимостей привёл к тому, что все операции записи в DynamoDB падали с NoClassDefFoundError, а затем по цепочке затронули несколько [SERVICES], которые использовали DynamoDB для хранения [DATA]. Сама DynamoDB работала нормально — проблема целиком была в том, что после обновления SDK приложение не могло корректно подключаться к DynamoDB и взаимодействовать с ней.

Этот этап добавляет важную интерпретирующую ценность: он превращает «сырые» данные об инцидентах в производный датасет о технологических отказах, пригодный для дальнейшей обработки — людьми, LLM или другими методами. Например, благодаря ему мы смогли выявить общие паттерны инцидентов, связанных с хранилищами данных, за эти годы.

Паттерны

Настоящая ценность проявляется в одностраничном описании межинцидентного анализа, которое позволяет инженерному руководству целостно увидеть повторяющиеся паттерны, режимы отказов и сопутствующие факторы.

Мы подаём весь набор дайджестов инцидентов в LLM одним промптом. Внутри промпта мы явно запрещаем выводы «по догадке», повторы и добавление любой информации, не опирающейся на исходные данные. Это гарантирует, что итог будет одновременно точным и пригодным к действию. На выходе — краткий список общих тем отказов, повторяющихся в разных инцидентах.

Ниже — цензурированный пример паттернов отказов в отчёте LLM:

Ёмкость DynamoDB и троттлинг: в нескольких инцидентах возникали проблемы с ёмкостью DynamoDB, что приводило к троттлингу, росту задержек и сбоям сервисов. Недостаточное тестирование и масштабирование: нехватка достаточных нагрузочных тестов перед развёртыванием и недостаточное автоматическое масштабирование способствовали инцидентам. Ошибки логики приложения: баги в логике приложения, например создание дубликатов данных или неэффективные алгоритмы, приводили к перегрузке базы данных и деградации сервисов. Пробелы в мониторинге и алертинге: недостаточный мониторинг, а также слишком чувствительные или, наоборот, слишком «глухие» пороги срабатывания алертов были факторами в части инцидентов.

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

Человеческая проверка

Хотя цель нашего решения — уменьшить участие человека, человеческая проверка остаётся необходимой. Во время разработки конвейера мы проводили 100% ручную проверку пакетов результата. Это включало анализ сгенерированных дайджестов постмортемов и сравнение их с оригинальными постмортемами. Сама проверка сводилась к разметке: коллеги ставили «плюс» или «минус» результатам. Такой контур обратной связи от людей помогал нам уточнять промпты и выбирать оптимальные модели для каждого этапа. По мере взросления системы мы ослабили ручную проверку до 10–20% случайно выбранных сводок из каждого пакета результатов. Мы по-прежнему привлекаем человеческую экспертизу для вычитки финального отчёта и редакторской правки сводок и паттернов инцидентов.

Два года данных: ключевые выводы

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

Инциденты с AWS S3:
стабильно были связаны с ошибками конфигурации в артефактах развёртывания, из-за которых приложения не могли получить доступ к бакетам S3. Чаще всего это происходило из-за ручных ошибок или непроверенных изменений. Этот вывод напрямую привёл к решению внедрить автоматическую валидацию изменений для инфраструктуры как кода, что позволило «отсечь» 25% последующих инцидентов, связанных с хранилищами данных, и продемонстрировало очевидную окупаемость инвестиций.

Инциденты с AWS ElastiCache:
устойчивый тренд — загрузка CPU на уровне 80%, которая приводила к росту задержек на пиках трафика. Этот инсайт, полученный с помощью ИИ, подтолкнул нас сформировать стратегическое направление по планированию ёмкости, выбору типов инстансов и управлению трафиком для AWS ElastiCache.

За два года анализа инцидентов мы сформировали целостное понимание паттернов отказов в наших хранилищах данных. На данный момент самые частые повторяющиеся паттерны такие:

• отсутствие автоматической валидации изменений в конфигурации и в инфраструктуре как коде, а также слабая прозрачность изменений и их последствий;

• непоследовательные или «точечные» практики управления изменениями, включая ручные вмешательства;

• отсутствие progressive delivery для хранилищ данных (например canary или blue-green);

• недооценка характера и динамики трафика;

• неспособность масштабироваться заранее под рост спроса или запаздывающая реакция автоскейлинга;

• бутылочные горлышки из-за ограничений по памяти, CPU или IOPS.

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

• Инцидент был вызван падением процесса AUTOVACUUM LAUNCHER из-за race condition, что, в свою очередь, оборвало все соединения в пуле подключений к базе PostgreSQL. Это падение было связано с известным багом PostgreSQL 12.

• Крупное обновление Postgres с версии 16 до 17 спровоцировало баг в логической репликации Postgres. Он проявляется, когда DDL-команды выполняются параллельно с большим количеством транзакций, что приводит к утечке памяти.

ИИ-анализ существенно сократил время разбора — с дней до часов — и обеспечил масштабируемость решения на несколько технологических областей. Он также выявил «скрытые горячие точки», например некорректную настройку пула подключений или circuit breaker’ов, которые приводили к каскадным отказам и раньше воспринимались как «стабильные» зоны.

Тупики: где ИИ не справился

Конвейер анализа инцидентов прошёл несколько итераций развития: мы пробовали разные модели и варианты хостинга. Сначала использовали open source модели, запущенные в LM Studio. Затем оценили несколько других моделей, и текущая версия работает на Claude Sonnet 4 в AWS Bedrock. Эта эволюция была продиктована в первую очередь требованиями комплаенса, а не технической необходимостью. Документы постмортемов содержат персональные данные (PII) дежурных инженеров, бизнес-метрики компании, потери GMV и т. п. Юридическое согласование было обязательным условием перед тем, как использовать LLM в облаке (например, AWS Bedrock). Во всех этих средах три ключевые проблемы, влияющие на конвейер и качество анализа, — это галлюцинации, ошибки поверхностной атрибуции и задержки.

Первые прототипы мы строили на небольших моделях — от 3B до 12B параметров. Мы наблюдали вероятность галлюцинаций до 40% на этапах суммаризации и анализа. Модель генерировала текст, который звучал правдоподобно, но был фактически неверным. По наблюдениям, маленькие модели однажды «сочинили» правдоподобную сводку про несуществующий инцидент с DynamoDB — лишь потому, что DynamoDB упоминалась в заголовке плейбука, на который ссылался постмортем. Чтобы справиться с этим, мы экспериментировали с разными стратегиями промптинга: подчёркивали строгие требования и максимально явно описывали ожидания на примерах. Затем мы проводили ручную проверку, пока эффект галлюцинаций не снизился до уровня ниже 15%. И уже при переходе на более крупную модель стало видно, насколько важной была работа по «закалке» промптов: галлюцинации стали практически незаметными. Это было критично для того, чтобы получить стратегические инсайты, о которых мы говорили выше.

Ошибки поверхностной атрибуции доминируют почти на каждом этапе конвейера. Модель принимает решения, опираясь на поверхностные признаки, а не на смысл или причинно-следственную связь. Она смещается к «ярким» ключевым словам, лежащим на поверхности, вместо того чтобы рассуждать по контексту и выделять реальный причинный фактор. Например, она может выдать хорошо структурированное и уверенно звучащее объяснение «вклада» AWS S3 в инцидент даже в ситуации, когда «S3» просто упомянута и причинной связи нет. Хотя мы применяли негативное промптирование, полностью проблему решить не удалось: даже с продвинутыми моделями вроде Claude Sonnet 4 мы всё равно наблюдаем примерно 10% таких ошибочных атрибуций.

Именно это стало главной причиной скепсиса и осторожности при принятии результатов, когда мы увидели первую версию отчёта. Мы добивались того, чтобы входы и выходы каждого этапа были читаемы человеком и поддавались ручной проверке. Так мы наращивали доверие и показывали роль ИИ как ассистента, способного давать качественный результат. Ключевую роль здесь сыграли дайджесты: они позволяли людям видеть все инциденты «в целом» и точно валидировать и править отчёты, которые генерировали LLM.

Ошибки поверхностной атрибуции часто идут рядом с переобучением, потому что и то и другое означает опору на поверхностные паттерны из прошлого, а не на более глубокие и надёжные сигналы. Универсальные LLM обучаются на публично доступных данных и с трудом выявляют новые паттерны отказов, которых раньше «не встречали», а также плохо справляются с проприетарными технологиями Zalando. Поскольку анализ хранилищ данных у нас был сфокусирован только на публичных технологиях, эффект переобучения был несущественным. Сейчас мы полагаемся на человеческую редакторскую работу над финальным отчётом, чтобы учесть новые режимы отказов, которые ИИ мог пропустить. Наглядный пример этой проблемы — неприемлемо низкое качество анализа инцидентов, связанных с внутренними технологиями Zalando (например, Skipper). Исправление этой и подобных ситуаций требует дообучения модели (fine-tuning).

Подход «fail fast» и быстрые итерации были для нас критически важны при разработке конвейера. Учитывая объём документов, мы пришли к выводу, что общее время обработки одного документа не должно превышать 120 секунд, иначе годовой прогон данных становится непрактично долгим. В первых релизах использовалась open source модель с 27B параметров — это был самый затратный по времени этап в конвейере: обычно он занимал 90–120 секунд, из-за чего у нас не оставалось «бюджета» на цепочку из нескольких стадий. Архитектура «map-fold», описанная выше, была запущена с несколькими моделями — 3B, 12B и 27B: на классификацию уходило примерно 20 секунд на документ, а на анализ — около 60 секунд на инцидент. Это позволило обрабатывать годовой массив данных менее чем за 24 часа. Самый свежий релиз, основанный на Claude Sonnet 4, обрабатывает каждый постмортем примерно за 30 секунд, открывая возможности для почти мгновенного анализа.

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

Надёжной точности при извлечении числовых данных из постмортемов — таких как потери GMV или EBIT, число затронутых клиентов и время восстановления — добиться не удалось. Поэтому для анализа инвестиционных возможностей мы опираемся на внутренний датасет инцидентов, который выступает надёжным «источником истины».

Выводы и рекомендации

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

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

• Эффективность многоэтапного пайплайна: многоэтапный LLM-пайплайн, где каждая стадия специализируется на одной задаче (суммаризация, классификация, анализ, паттерны), оказался более эффективным и надёжным, чем попытка использовать одну «топовую» LLM с большим окном контекста. Это помогло снизить эффект «потерялся в середине» и повысить точность.

• Human-in-the-loop критически важен: несмотря на автоматизацию, ручная проверка, экспертиза, разметка и контроль качества на каждом этапе, особенно на уровне «дайджестов», необходимы для доработки промптов, обеспечения точности, формирования доверия и учёта новых режимов отказов, которые ИИ может пропустить.

Дальше, развивая партнёрство SRE и ИИ, мы сформулировали такие выводы и рекомендации.

Выводы и рекомендации

Начинайте с малого и итеративно развивайте: стартуйте с узких сценариев и закладывайтесь на быстрые итерации.

Сделайте работу с промптами приоритетом: инвестируйте время в точные и «жёстко ограниченные» промпты, чтобы минимизировать галлюцинации и ошибки поверхностной атрибуции. Проектируйте решение так, чтобы оно легко эволюционировало, и поставляйте конвейеры вместе с эталонными («golden») датасетами для тестирования.

Проектируйте под человеческую проверяемость: делайте так, чтобы промежуточные результаты были читаемы человеком — это упрощает валидацию и повышает доверие.

Опыт Zalando показывает: если внедрять LLM без магии и держать человека в контуре, постмортемы перестают быть архивом «на потом» и превращаются в рабочий источник сигналов — по повторяющимся фейлам и точкам, куда реально стоит инвестировать в надёжность.

Если вы регулярно разбираете инциденты и думаете, куда вкладываться в надёжность, это уже зона ответственности CTO. На курсе «CTO / Технический директор» разбирают, как выстроить техстратегию, структуру и управление командой 100+ человек, чтобы решения не застревали между SRE, продуктом и бизнесом вовремя. Готовы к серьезному обучению? Пройдите вступительный тест.

Для знакомства с форматом обучения и экспертами приходите на бесплатные демо-уроки:

• 24 февраля 20:00. «Presale и оценка проектов: как CTO превращает неопределённость в надёжные планы». Записаться

• 11 марта 20:00. «Когда интеллект становится угрозой: управленческие риски в эпоху AI». Записаться

• 18 марта 20:00. «CTO как система: люди, процессы и IT для управления бизнесом». Записаться