AI в эксплуатации: что помогает, что нет, границы и риски

Хронометраж: занятие 60 минут — теория 30 минут, практика 30 минут. Домашняя работа: 1–2 часа.

Кратко о чём урок: Где LLM реально ускоряет работу инженера эксплуатации, а где создаёт ложную уверенность. Обзор: ассистент против автоматизации, детерминизм против вероятностного ответа, что нельзя доверять модели и почему человек остаётся в контуре принятия решений.

---

1. Что изучаем

• отличать LLM-ассистента от автоматизации и понимать, почему это разные инструменты;
• называть задачи эксплуатации, где LLM ускоряет работу, и задачи, где он опасен;
• объяснять, почему вывод модели проверяется фактами из системы, а не принимается на веру;
• формулировать роль человека в контуре (human-in-the-loop) и что никогда не отдаётся модели на автомат;
• переносить дисциплину проверки всего курса на работу с ассистентом.

2. Зачем это нужно и где применяется

LLM-ассистент уже стоит на столе у инженера эксплуатации: им суммируют шумный журнал, объясняют незнакомый алерт, набрасывают статус для команды. Пользы от него много, но ровно там, где инженер не понимает его природы, начинаются аварии нового вида: команда, уверенно предложенная моделью и выполненная не глядя; «факт» о версии или флаге, которого не существует; решение об откате, принятое по красивому, но выдуманному объяснению. Всё это — не отказ инструмента, а неверное представление о том, что он делает. Этот вводный урок проводит границу: где ассистент экономит время, где создаёт ложную уверенность, и почему в контуре решений остаётся человек. Дальше блок разбирает конкретные применения — логи и алерты (21.03), дежурство (21.04), расследование (21.05), постмортем (21.06) — и каждый раз возвращается к этой границе.

3. Теория (30 минут)

Ассистент против автоматизации: два разных инструмента

Весь курс до этого блока строил автоматизацию: скрипт, плейбук Ansible, конфигурацию Terraform, пайплайн. У автоматизации есть свойство, на котором держится вся эксплуатация, — детерминизм: один и тот же вход даёт один и тот же результат, его можно проверить один раз и потом ему доверять, он идемпотентен (блок про Ansible) и воспроизводим (блок про CI/CD). Terraform, применённый дважды, даёт то же состояние; тест, прошедший на коммите, пройдёт снова.

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

Галлюцинации: ошибка, похожая на правильный ответ

Ключевое свойство, которое надо знать до первого использования, — модель может уверенно выдать неверное. Документация Anthropic называет это прямо: «Even the most advanced language models, like Claude, can sometimes generate text that is factually incorrect or inconsistent with the given context. This phenomenon, known as "hallucination"...» И там же честная оговорка про любые приёмы снижения: «while these techniques significantly reduce hallucinations, they don't eliminate them entirely. Always validate critical information, especially for high-stakes decisions».

Для инженера это не абстракция, а знакомый класс ошибки. Весь курс повторял правило «не выдумывать факты, флаги, цифры и ссылки» и ловил случаи, когда неверный результат выглядел как правильный: код возврата после конвейера, дававший «0» при упавшей команде; ответ 200 от сервиса, который на самом деле не отдавал нужного; «сертификат без SAN отвергнут», оказавшееся неверным. Галлюцинация LLM — тот же класс: ответ синтаксически безупречен, звучит уверенно и может быть ложным. Модель напишет несуществующий флаг команды так же гладко, как существующий; сошлётся на страницу документации, которой нет; назовёт версию, в которой «появилась» функция, наугад. И признаков «я не уверена» в тексте по умолчанию не будет — уверенный тон не связан с правильностью.

Отсюда прямое следствие: факт от модели — это гипотеза, а не факт, пока он не подтверждён источником. Ровно та же дисциплина, что весь курс: команда и вывод проверяются запуском, версии — первоисточником, ссылки — кодом ответа. С ассистентом это правило не ослабевает, а становится главным.

Где LLM реально помогает

Признав природу инструмента, легко увидеть, где он ускоряет работу, — это задачи, где ошибка дёшева, а результат проверяем, и где ценность в скорости формулирования, а не в авторитетности факта:

• Суммаризация шума. Тысяча строк журнала, длинный тред переписки по инциденту, простыня вывода — модель сжимает это до «вот что здесь по сути». Проверка дешёвая: сводку сверяют с исходником, и она лишь направляет внимание, а не заменяет чтение (21.03).
• Объяснение незнакомого. Непонятный алерт, чужое сообщение об ошибке, аббревиатура в дашборде — модель быстро даёт версию «что это значит», с которой инженер идёт проверять систему. Быстрее, чем искать с нуля (21.03, 21.04).
• Черновики текста. Обновление статуса для команды и пользователей, каркас постмортема, формулировка шага runbook — модель даёт болванку, которую человек правит. Экономит не понимание, а время на набор (21.04, 21.06).
• Генерация гипотез. При расследовании — список «что могло вызвать это» как отправная точка, каждую гипотезу дальше проверяют измерением (21.05).

Общее у всех четырёх: модель работает как фильтр и черновик, ускоряя рутину, а решение и проверку оставляет человеку. Это и есть выгодная роль.

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

Где LLM создаёт ложную уверенность

И зеркальный список — задачи, где тот же инструмент опасен, потому что цена ошибки высока, а неверный ответ неотличим от верного:

• Авторитетные факты. Точная версия, флаг команды, число, имя параметра, ссылка — здесь галлюцинация особенно коварна, потому что её не видно. Такие вещи берут из первоисточника, а не из ответа модели.
• Выполнение команд вслепую. «Дай команду, которая это чинит» с немедленным запуском — прямой путь к аварии: модель может предложить разрушительное или просто неверное действие уверенным тоном. Команду от модели читают, понимают и проверяют, как чужой pull request, а на проде — тем более.
• Решения с высокой ценой. Откатывать ли релиз, масштабировать ли, объявлять ли инцидент — это решения человека по фактам из системы, а не по объяснению модели. Модель может помочь их подготовить (собрать сигналы, набросать гипотезы), но не принять.

Различие между двумя списками — не в теме, а в цене ошибки и проверяемости. Одна и та же задача может быть безопасной как черновик и опасной как исполнение: «объясни этот алерт» — полезно; «и сразу выполни, что предложишь» — опасно.

Человек в контуре: почему он остаётся

Отсюда принцип, на котором держится весь блок, — human-in-the-loop: человек остаётся в контуре принятия решений, а модель занимает место помощника перед ним. Это не осторожность ради осторожности, а следствие природы инструмента: раз ответ вероятностный и может быть ложным без внешнего признака, между ним и действием обязателен шаг проверки человеком. Документация про снижение галлюцинаций формулирует то же практически: разрешать модели говорить «я не знаю», требовать обоснования цитатами и проверять каждое утверждение — «have it cite quotes and sources for each of its claims... If it can't find a quote, it must retract the claim». Проверяющая инстанция — не сама модель, а система: логи, метрики, документация, факт запуска. Модель — фильтр перед человеком, источник правды — система за человеком.

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

AI не заменяет то, что вы построили, — он ускоряет работу с этим

Важно снять завышенное ожидание: ассистент не отменяет ни одной инженерной практики курса, он лишь помогает ими быстрее пользоваться. Наблюдаемость (блок про метрики, логи, трейсы) остаётся источником правды: модель суммирует логи, но сами логи собирает ваш стек, и проверяет вывод модели именно он. SLO и бюджет ошибок (16.10) остаются мерой того, плохо ли сейчас, — модель не решает, нарушен ли SLO, это считает запрос по метрикам. Runbook (блок про SRE) остаётся записанной процедурой — модель подскажет нужный шаг, но шаг должен существовать и быть верным, иначе она подскажет правдоподобный несуществующий. Постмортем (21.06) остаётся организационным документом с причинно-следственными связями, которые проверяет человек.

Иначе говоря, LLM — это ускоритель поверх зрелой эксплуатации, а не замена её незрелости. На кластере без наблюдаемости ассистенту нечего суммировать и нечем проверять его ответ; без SLO он не с чем сравнить; без runbook ему не на что опереться. Поэтому этот блок стоит после блоков про наблюдаемость, SRE и безопасность, а не вместо них: ассистент усиливает того, у кого уже есть приборы и процедуры, и ничем не помогает тому, у кого их нет, — зато легко даёт ему ложную уверенность. Первый практический вывод для команды: внедрять ассистента имеет смысл там, где вывод модели есть чем проверить; там, где проверять нечем, он не ускоряет, а маскирует пробел.

3.1. Примеры и варианты реализации

Одна задача — «встроить LLM-ассистента в работу эксплуатации» — в трёх средах. Здесь среды различаются не стендом, а тем, откуда берётся модель.

Среда	Как решается	Что нужно иметь
Локальный стенд	Локальная модель (Ollama и аналоги) — приватно, без внешних вызовов, но слабее и требует ресурсов	машина с достаточной памятью/GPU
VPS / bare-metal	Своя модель на своём железе либо вызовы внешнего API из своей сети	сервер под модель или доступ к API
Облако / SaaS	Облачный LLM API (платный, ключ) — сильные модели, плата за запрос, данные уходят провайдеру	ключ API, контроль приватности и стоимости

Локальный стенд. Модель на своей машине не отправляет данные наружу (плюс к приватности), но обычно слабее облачной и требует ресурсов. Подходит там, где нельзя выпускать данные из периметра.

VPS / bare-metal. Компромисс: своя модель на арендованном железе или вызовы API из своей сети с контролем, что уходит в запрос.

Облако / SaaS. Самые сильные модели за плату по запросу; главная забота — приватность (что нельзя класть в промпт) и стоимость (21.02). Выбор среды — это выбор между силой модели, приватностью и ценой, а не между стендами.

Что выбрать. Для чувствительных данных — локальная/своя модель; для сложных задач без секретов — облачный API с дисциплиной приватности и стоимости. В любом случае роль модели и проверка вывода одинаковы — они не зависят от того, где модель работает.

4. Практика на занятии (30 минут)

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

Шаг 1 (10 минут). Заполнить карту применимости.

• Что сделать: открыть заготовку ai-usage-map.md и для каждой перечисленной там задачи эксплуатации проставить три значения: уместен ли LLM и в какой роли (подсказка / черновик / фильтр — не исполнитель), чем проверяется его вывод (какой источник в системе), какой риск при слепом доверии.
• Зачем: перевести общий принцип «ассистент подсказывает, а не исполняет» в конкретный список своих задач, а не оставить его абстрактным лозунгом.
• Ожидаемый результат: заполненная таблица, где у задач «выполнить команду в проде» и «назвать точную версию» стоит «опасен / только с проверкой», а у «суммаризация журнала» и «черновик статуса для команды» — «уместен как черновик» с указанным способом проверки.
• Если не так: если в столбце «уместен» стоит одно и то же значение почти для всех строк или столбец «чем проверяется» пуст — разметка ничего не различает. Вернуться к разделу 3 и для каждой спорной строки спросить: цена ошибки высока или низка, ответ легко сверить с системой или нет.

Шаг 2 (10 минут). Сформулировать своё правило.

• Что сделать: свернуть заполненную таблицу в одно правило на 1–2 предложения: где ассистент ускоряет работу, где создаёт ложную уверенность, что в любом случае остаётся за человеком.
• Зачем: таблица разбирает случаи по отдельности, а правило нужно, чтобы с ходу относить к одной из категорий новую задачу, которой в таблице ещё нет.
• Ожидаемый результат: правило вида «черновик и фильтр — да, авторитетный факт и исполнение действия — только через проверку человеком», записанное своими словами, а не переписанное из текста урока.
• Если не так: если правило получилось общим («быть осторожнее с ИИ») и не помогает решить, к какой категории отнести конкретную задачу — оно бесполезно. Проверить его на одной строке из своей таблицы: правило должно однозначно сказать, уместен там LLM или нет.

Шаг 3 (10 минут). Разобрать рисковый промпт.

• Что сделать: взять промпт «вот ошибка из прода, дай команду, я сразу выполню», объяснить письменно, что в нём не так, и переписать его так, чтобы ассистент предлагал объяснение и варианты, а решение и запуск оставались за человеком.
• Зачем: увидеть живьём главный антипаттерн урока — LLM в контуре исполнения — и потренироваться убирать его формулировкой запроса, а не только знать о нём в теории.
• Ожидаемый результат: два текста рядом: исходный промпт с пометками, что именно в нём опасно (немедленное исполнение, высокая цена ошибки, отсутствие проверки), и переписанная версия, которая просит объяснение причины и список вариантов, а не готовую команду на запуск.
• Если не так: если переписанный промпт всё ещё сводится к «дай команду и я её выполню», только вежливее сформулированному, — антипаттерн не убран, а закамуфлирован. Проверить: в ответе на переписанный промпт не должно быть прямого пути от текста модели к действию без шага проверки человеком.
• Ответьте: что именно в исходном промпте делает возможную ошибку модели опасной, а не просто неудобной?

Проверка результата. В карте разведены «дёшево и проверяемо» и «дорого и неотличимо»; сформулировано личное правило; рисковый промпт переписан с человеком в контуре.

5. Домашняя работа (1–2 часа)

Задание. Завести ai-usage-map.md под свои реальные задачи дежурства и эксплуатации (не абстрактные): выписать 8–10 задач, разметить каждую по применимости LLM, роли и способу проверки вывода, и вывести из таблицы одно правило для себя. Отдельно разобрать один рисковый промпт из своей практики (или предложенный) и переписать его безопасно.

Критерии приёмки.

• в ai-usage-map.md не меньше 8 задач, у каждой заполнены роль LLM и способ проверки вывода фактом из системы;
• хотя бы у двух задач честно стоит «опасен / только с проверкой» с объяснением цены ошибки;
• сформулировано личное правило, разделяющее ускорение и ложную уверенность;
• разобран рисковый промпт: что не так и как переписан с человеком в контуре.

Файлы для работы: blocks/21-ai-operations/examples/21.01-ai-ops-intro/ — заготовка карты применимости ai-usage-map.md.

6. Частые ошибки и подводные камни

• Доверять факту от модели без проверки. Симптом: в отчёт/команду попал несуществующий флаг или неверная версия. Причина: галлюцинация неотличима от верного ответа по тону. Что делать: авторитетные факты брать из первоисточника, ответ модели считать гипотезой.
• Ставить LLM в контур исполнения. Симптом: авто-команда по алерту сделала хуже. Причина: вероятностной модели дали право действовать без человека. Что делать: модель — подсказка человеку, исполнение — после проверки.
• Считать разные ответы багом. Симптом: тот же промпт дал два разных ответа, «инструмент сломан». Причина: LLM вероятностный по природе, это не автоматизация. Что делать: не полагаться на воспроизводимость ответа как на свойство; для важного — проверка и, где нужно, фиксация параметров (21.02).
• Путать «звучит уверенно» и «верно». Симптом: приняли гладкое объяснение как истину. Причина: уверенный тон не связан с правильностью. Что делать: спросить «чем проверю и что если неправда» до того, как действовать.
• Ждать от модели решения, а не подготовки. Симптом: решение об откате принято по объяснению модели. Причина: смешаны роли «подготовить» и «решить». Что делать: решение — за человеком по фактам системы; модель только собирает и формулирует.

7. Проверка усвоения

1. Чем LLM-ассистент отличается от автоматизации и почему одному можно доверить действие, а другому нет?
2. Что такое галлюцинация и почему она опаснее обычной ошибки инструмента?
3. К какому уже знакомому классу ошибок курса относится «уверенный, но неверный ответ»?
4. Назовите две задачи, где LLM уместен, и две, где он создаёт ложную уверенность. Что их различает?
5. Почему человек остаётся в контуре и что именно он проверяет?
6. Как переписать промпт «дай команду, я сразу выполню», чтобы он был безопасен?
7. Меняется ли роль модели от того, где она работает (локально/в облаке)?

8. Материалы

Минимум два варианта на выбор: официальная документация плюс книга/статья/видео.

• Anthropic, Reduce hallucinations — что такое галлюцинации, почему они не устраняются полностью и как проверять вывод (разрешать «не знаю», обоснование цитатами, проверка утверждений): https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations. Кому: чтобы понять природу ошибки модели и дисциплину проверки.
• Google SRE Workbook, Incident Response — как устроена реакция на инцидент, куда в неё встраивается помощник и где решения остаются за людьми: https://sre.google/workbook/incident-response/. Кому: для контекста эксплуатации, в который встраивается ассистент.
• OpenAI, Prompt engineering — как формулировать запрос, чтобы получать полезный и проверяемый ответ: https://platform.openai.com/docs/guides/prompt-engineering. Кому: практический старт по составлению промптов (детали — в 21.02).

---

← Предыдущий: 20.07. Планирование инфраструктурных проектов: оценка, декомпозиция, риски · Блок 21 · Следующий: 21.02. Настройка LLM-ассистента в работе инженера →