Thema: Прикладная часть 0. Лаборатория AgentClinic-production
Schwierigkeitsgrad: Средний (Mittel)
Geschätzte Lernzeit: 2–3 часа (теория + первичная настройка среды)
Voraussetzungen: Успешное завершение первого тома курса (создание базового приложения AgentClinic).
Понимание принципов работы с TypeScript, фреймворком Hono, SQLite и Vitest.
Базовые знания о концепциях CI/CD, ревью кода и написании спецификаций.
Установленный Python 3 для запуска учебных скриптов из второго тома.
Lernziele: Освоить методологию чтения второго тома как единой лабораторной ветки, развивающей один production-кейс.
Понять разницу между реальной инфраструктурой и учебными ролями (Kubernetes, Grafana) в рамках курса.
Настроить рабочее окружение: создать структуру каталогов capstone/ и успешно запустить первый smoke-прогон.
Научиться различать типы команд ([runnable], [project script], [conceptual interface]) и понимать, какие артефакты идут в зачет.
Сформулировать правила переноса проверяемых принципов из дополнительных кейсов (например, autoscale_200pct) в базовый (high_memory_usage).
Übersicht: Данный раздел является методической «нулевой» главой, подготавливающей почву для глубокого погружения в эксплуатационные сценарии (production-контур) приложения AgentClinic. В отличие от первого тома, где фокус был на разработке фич и маршрутов, второй том переключается на надежность, инцидент-менеджмент и качество спецификаций. Здесь закладывается концепция сквозного учебного кейса (high_memory_use), который пройдет красной нитью через все последующие лабораторные работы. Вы научитесь работать с пакетом доказательств (capstone/), не требуя при этом развертывания реальных тяжелых production-систем, а используя легковесные Python-скрипты для симуляции проверок.
Schlüsselkonzepte: Agentclinic-production: Учебная production-модель вашего приложения. В отличие от реального продакшена, термины вроде Kubernetes или Grafana используются здесь как абстракции (роли) для понимания того, откуда пришел сигнал и как действовать.
Сквозной кейс (high memory usage): Основной учебный инцидент (в сервисе appointments-api), на котором вы будете отрабатывать весь цикл: от алерта до нормализации и ревью. В capstone/ допускается только один основной кейс.
Стек исполнения: Продуктовый стек (TypeScript, Hono, SQLite) остается неизменным. Для симуляции production-проверок во втором томе добавляется слой скриптов на Python (stdlib) — это дешевый способ запускать тесты без инфраструктуры.
Пакет доказательств (capstone/): Итоговый каталог с артефактами, который вы будете собирать по мере прохождения тома. Включает генеалогию требований, спецификации, вердикты и ревью. Должен быть читаем без истории чата.
Карта переноса: Правило, по которому выводы из локальных инцидентов (node_not_ready, cdn_error_budget_burn и др.) конвертируются в абстрактные принципы (например, анти-Goodhart-инвариант) и переносятся в зачетный high_memory_usage.
Übungsaufgaben: Name: Инициализация зачетного пакета
Problem: Вам необходимо подготовить структуру каталогов для будущего пакета доказательств по выбранному инциденту.
Lösung: 1. Откройте терминал в корне проекта. 2. Выполните команду mkdir -p capstone. 3. Оставьте каталог пустым до прохождения следующих глав, либо создайте пустой README.md с указанием базового инцидента (например, high_memory_usage).
Komplexität: beginner
Name: Запуск smoke-тестирования учебной среды
Problem: Перед началом работы с главами 4–11 необходимо убедиться, что все локальные runnable-примеры работают корректно.
Lösung: 1. Найдите скрипт book2/examples/smoke_all.sh. 2. Запустите его через терминал командой bash book2/examples/smoke_all.sh. 3. Убедитесь, что скрипт отработал без ошибок и не оставил мусора в рабочем дереве (временные файлы создаются в изолированной копии).
Komplexität: intermediate
Name: Анализ карты переноса инцидентов
Problem: Определите, какой конкретный артефакт (принцип) вы должны вынести из анализа кейса cdn_error_budget_burn в ваш основной зачетный пакет по high_memory_usage.
Lösung: Согласно карте переноса, из cdn_error_budget_burn не нужно переносить сам новый сервис. Необходимо вынести пару KPI + guard-метрику (защитное правило против перекоса метрик, анти-Gudhart). Запишите этот принцип в общую тетрадку или черновик.
Komplexität: intermediate
Fallstudien: Name: Формирование архитектуры учебного пакета Capstone
Szenario: Студент проходит вторую часть курса и дошел до главы 3. До этого он изучал различные инциденты, включая node_not_ready и appointment_latency, и теперь пытается понять, как связать их с основным кейсом high_memory_usage для итогового ревью.
Aufgabe: Соблазн смешать все изученные инциденты в одном пакете capstone/, что приведет к путанице и нарушению правила «один проект — один production-контур». Также существует риск попыток реализовать полноценный Kubernetes кластер вместо учебной симуляции.
Lösung: Студент применяет «Короткую карту переноса». Он оставляет в центре внимания только high_memory_usage. Все остальные кейсы он использует только как источники проверяемых принципов. Например, из node_not_ready он берет только правило «не закрывать инцидент без доказательств восстановления» и адаптирует его для своего основного кейса, сохраняя это в файл genealogy.md.
Ergebnis: Каталог capstone/ остается чистым и сфокусированным. Студент экономит время, не распыляясь на настройку нескольких доменов, и формирует сильный, когерентный пакет доказательств, который легко читать без контекста.
Gewonnene Erkenntnisse: Второй том читается как одна лабораторная ветка, а не набор разрозненных рецептов.
Продакшн-термины (Grafana, PagerDuty) — это роли для сценарного анализа, а не призыв поднимать тяжелую инфраструктуру.
Дополнительные инциденты — это лишь «маленькие лабораторные окна» для отработки конкретных механизмов.
Verwandte Konzepte: Сквозной кейс
Карта переноса
Пакет доказательств (capstone/)
Lerntipps: Не застревайте на терминов: если в главе встретился термин, которого нет в минимальном словаре (genealogy.md, validation.md, judgment.md, readiness.md), просто пропустите его при первом чтении. Вернетесь к нему, когда он понадобится для заполнения файла в capstone/.
Разделяйте стеки: пишите основной продукт на TS/Hono, а для симуляции стресс-тестов или проверок бюджетов используйте готовые Python-скрипты из examples/ без попыток их интегрировать в прод.
Следите за тегами команд: запускайте только то, что помечено как [runnable]. Интерфейсы [project script] и [conceptual interface] нужны только для понимания будущей архитектуры.
После каждой главы задавайте себе вопрос: «Какой один новый проверяемый вывод я должен добавить в capstone/?» Если ответа нет — перечитайте «Минимальный маршрут».
Zusätzliche Ressourcen: Book2/examples/readme.md: Инструкции и описания runnable-скриптов для каждой конкретной главы.
Examples/templates/capstone-dossier.md: Заполненный пример того, как должен выглядеть итоговый ответ (артефакты после первого прохода).
Examples/smoke all.sh: Главный скрипт для быстрой проверки работоспособности всех учебных симуляций на вашей машине.
Zusammenfassung: Раздел «Лаборатория AgentClinic-production» задает строгие, но освобождающие рамки для изучения production-разработки без боли реальной инфраструктуры. Главный вывод: фокусируйтесь на одном сквозном инциденте (high_memory_usage), собирайте пакет артефактов постепенно (по одному файлу на главу) и используйте дополнительные сценарии только как источники инвариантов и правил. Главное правило — ваш итоговый capstone/ должен быть понятен рецензенту без истории вашего чата с ИИ.