Тема: Часть 21. Qwen Code-процесс для DataLakeHouse
Уровень сложности: Средний
Расчётное время изучения: 90-120 минут (теория: 45 минут, практика: 45-75 минут)
Предварительные требования: Базовое понимание Data Lakehouse архитектуры
Знакомство с dbt (data build tool) и его моделями
Понимание концепции data contracts (ODCS, ODPS)
Опыт работы с системами контроля версий (Git)
Общее представление об AI-агентах и LLM-инструментах
Понимание принципов разделения обязанностей (separation of duties) в банковской среде
Цели обучения: Объяснить, почему процесс SDD должен быть разбит на отдельные команды с точками подтверждения человеком, а не выполняться одной командой
Описать назначение и зону ответственности каждой из пяти команд: /sdd:profile, /sdd:contract, /sdd:build, /sdd:verify, /sdd:release
Различать навыки (skills) и субагентов (sub-agents) и объяснять, почему генератор и ревьюер должны быть разными ролями
Определить, в каких случаях следует внедрять хуки и какие классы изменений они должны блокировать
Сформировать минимальную карту процесса с артефактами для команды DataLakeHouse
Обзор: Глава 21 объединяет материалы всего тома в работающий цикл взаимодействия с Qwen Code при работе с DataLakeHouse. В центре внимания — пятишаговый процесс /sdd:profile → /sdd:contract → /sdd:build → /sdd:verify → /sdd:release, в котором каждая команда имеет узкую роль и точку подтверждения человеком. Главная идея главы: одна команда никогда не должна выполнять весь процесс целиком, особенно в банковских данных, где дрейф контракта может быть обнаружен слишком поздно. Рассматриваются навыки (data-profiler), субагенты (data-contract-review), концепция хуков как дисциплинарного слоя, а также типовая ошибка — создание единой команды /sdd:do-everything, которая стирает подтверждения человеком и снова превращает SDD в автопилот. Глава завершает том, давая читателю возможность осознанно выбирать, какая команда за что отвечает, и какой артефакт должен зафиксировать решение.
Ключевые концепции: Sdd (specification-driven development): Подход, при котором работа с данными начинается с формальной спецификации (контракта) источника, а не с прямого изменения моделей. В контексте Qwen Code это означает, что действия агента определяются явным контрактом между источником и потребителем, а не импровизацией LLM.
Пятишаговый процесс /sdd:profile → /sdd:contract → /sdd:build → /sdd:verify → /sdd:release: Разделение всего цикла работы с данными на пять отдельных команд, каждая из которых имеет узкую ответственность и точку подтверждения человеком. Эта декомпозиция не даёт агенту неограниченной власти над данными.
/sdd:profile: Команда наблюдения за источником. Считывает метаданные, схемы, объёмы, статистику и формирует Schema Manifest — артефакт с фактами о данных без записи моделей. Не имеет права менять структуру marts или contracts.
/sdd:contract: Команда формулирования или проверки обещания. Работает с ODCS/ODPS-документами, описывающими, что источник гарантирует потребителю. Не трогает модели — только спецификации.
/sdd:build: Команда внесения изменений в dbt-модели. Срабатывает после того, как контракт утверждён человеком. Генерирует SQL, но не должна сама себя валидировать.
/sdd:verify: Команда запуска проверок и поиска дрейфа. Выполняет dbt build, тесты, сравнение фактических данных с контрактом. Ищет расхождения между обещанием и реальностью.
/sdd:release: Команда сборки пакета доказательств. Формирует артефакты для стейкхолдеров: что изменилось, какие тесты прошли, кто подтвердил.
Data-profiler (навык): Узкий навык чтения источников и формирования манифеста. Возвращает только факты, не имеет права писать модели. Пример навыка, ограничивающего роль агента.
Data-contract-review (субагент): Субагент в режиме только чтения, который применяет чек-лист ревью к предложенным изменениям. Не может править SQL — только рецензировать.
Разделение ролей генератора и ревьюера: Принцип, согласно которому автор изменений и проверяющий должны быть разными сущностями. Иначе агент проверяет собственные догадки, что в банковских данных опасно.
Точки подтверждения человеком: Места в процессе, где агент обязан остановиться и передать решение живому специалисту. Без этих точек SDD вырождается в автопилот.
Хуки (hooks): Механизм автоматической блокировки опасных классов изменений: PII-поля в models/marts/, изменение YAML контракта без метки подтверждения, изменение grain без заметки о влиянии. Хуки не заменяют ревью, а не дают очевидной ошибке до него дойти.
Артефакт: Материальный результат работы команды (Schema Manifest, обновлённый ODCS, изменённая dbt-модель, отчёт ревьюера). Правило: если команда не оставляет артефакт, она не нужна на первом проходе.
Карта процесса: Минимальный визуальный выход главы — таблица соответствия команд и артефактов. Позволяет быстро объяснить команде, кто за что отвечает.
Дрейф контракта: Расхождение между тем, что обещает источник (контракт), и тем, что реально происходит с данными. Особенно критичен в банковской среде, где дрейф обнаруживается слишком поздно.
Pii (personally identifiable information): Персональные данные клиентов. Добавление полей с префиксом pii_ в marts-модели — типовой опасный класс изменений, который должен блокироваться хуком.
Grain (зерно модели): Уровень детализации записей в dbt-модели (например, «один клиент — одна строка»). Изменение grain без явной заметки о downstream-влиянии — частый источник ошибок.
Важные даты: Внедрение sdd в datalakehouse: Этап зрелости процесса, на котором становятся видны повторяющиеся нарушения — признак того, что пора писать хуки
Первый практический зачёт: Момент, после которого команда уже понимает типовые нарушения и может формулировать правила для хуков
После /clear: Момент, когда особенно важен ревьюер в режиме только чтения: если он не может понять изменение по файлам, значит автор оставил смысл в чате — это сигнал плохой дисциплины
Практические упражнения: Название: Упражнение 1: Составление карты процесса для своего проекта
Проблема: Вы работаете в банковской команде DataLakeHouse, которая переходит на SDD с Qwen Code. Опишите карту процесса: какие пять команд вы будете использовать, какой артефакт оставляет каждая из них, и где стоит точка подтверждения человеком. Используйте формат таблицы из главы.
Решение: Шаг 1. Выпишите пять команд в правильном порядке: /sdd:profile, /sdd:contract, /sdd:build, /sdd:verify, /sdd:release. Шаг 2. Для каждой команды определите артефакт: profile → Schema Manifest; contract → обновление ODCS/ODPS; build → изменение dbt-модели; verify → dbt build + проверочные факты; release → пакет доказательств. Шаг 3. Добавьте шестую строку для data-contract-review → отчёт ревьюера. Шаг 4. Пометьте стрелками, где находится подтверждение человеком (между contract и build, между verify и release). Шаг 5. Проверьте себя: есть ли артефакт у каждой команды? Если нет — эта команда лишняя на первом проходе.
Сложность: beginner
Название: Упражнение 2: Разделение ролей автора и ревьюера
Проблема: Прогоните один и тот же запрос на изменение dbt-модели (например, добавление поля customer_segment в marts-таблицу) в двух режимах: (а) один агент делает всё сам — профилирует источник, предлагает изменение, пишет SQL и ревьюит его; (б) разделение ролей: агент-автор предлагает изменение, агент-ревьюер в режиме только чтения проверяет. Сравните, какие замечания появляются только при разделении ролей.
Решение: Шаг 1. Подготовьте контекст: описание источника, текущий контракт, существующую dbt-модель. Шаг 2. Режим (а): попросите одного агента выполнить весь цикл. Зафиксируйте, какие риски он сам себе разрешил. Шаг 3. Режим (б): запустите автора — он пишет изменение. Запустите ревьюера в режиме только чтения (только файлы, без чата) — он применяет чек-лист. Шаг 4. Сравните результаты. Типичные замечания, появляющиеся только при разделении: «не описано влияние на grain», «не обновлён ODCS», «отсутствует тест на NULL в новом поле», «не проверено, кто потребители этой колонки», «не отмечено, что поле может содержать PII». Шаг 5. Сформулируйте вывод: разделение ролей выявляет риски, которые автор не замечает, потому что они находятся «за пределами его оптимизма».
Сложность: intermediate
Название: Упражнение 3: Проектирование первого хука
Проблема: Команда провела три спринта по SDD. Анализ ревью показал, что чаще всего повторяются три нарушения: (1) в models/marts/ появляются поля с префиксом pii_; (2) изменение YAML контракта без метки подтверждения человека; (3) изменение grain модели без заметки в PR-описании. Спроектируйте один хук, который блокирует все три класса изменений. Опишите его концептуально (без кода).
Решение: Шаг 1. Сформулируйте условие блокировки: хук срабатывает при попытке записи файлов в models/marts/. Шаг 2. Правило 1: если новый или изменённый файл содержит поле, начинающееся с pii_ — заблокировать коммит с сообщением «PII в marts требует отдельного согласования». Шаг 3. Правило 2: если в PR изменён любой файл в каталоге contracts/ или .odcs.yaml, и в сообщении коммита/PR отсутствует маркер «contract-approved» — заблокировать. Шаг 4. Правило 3: если в models/marts/ изменён файл, и в нём изменена строка {{ config(materialized=..., grain=...) }} или эквивалентная — потребовать в описании PR наличие строки «grain-impact:». Шаг 5. Решите, в каком порядке хук выдаёт ошибки и какие — только предупреждения. Шаг 6. Зафиксируйте: хук не заменяет ревью, а не даёт очевидной ошибке до него дойти.
Сложность: intermediate
Название: Упражнение 4: Диагностика ошибки «/sdd:do-everything»
Проблема: Команда создала единую команду /sdd:do-everything, которая профилирует источник, обновляет контракт, генерирует dbt-модель, запускает тесты и публикует отчёт. Через месяц в продакшн попало поле с PII, которого не было в контракте. Проведите разбор: какие точки подтверждения человеком были стёрты и какие артефакты отсутствовали?
Решение: Шаг 1. Перечислите точки подтверждения, которые должна была иметь команда: (а) после profile — подтверждение, что Manifest корректен; (б) после contract — подтверждение, что обещание согласовано со стейкхолдерами источника; (в) после build — подтверждение, что изменение корректно; (г) после verify — подтверждение, что пакет доказательств полон. Шаг 2. В команде /sdd:do-everything все эти точки слиты в одно автоматическое выполнение. Человек видит только финальный отчёт, а не промежуточные артефакты. Шаг 3. Какие артефакты отсутствовали: Schema Manifest не был проверен экспертом по источнику; обновление ODCS не было подписано владельцем данных; ревьюер контракта не получил отдельный тикет; в логах нет метки подтверждения человека. Шаг 4. Где именно «пропустили» PII: агент добавил поле в marts, потому что видел его в источнике, а контракт на этот источник либо не обновлялся, либо был сгенерирован автоматически. Шаг 5. Вывод: единая команда стирает подтверждения человеком и превращает SDD в автопилот. Решение — разбить на пять команд и явно потребовать ручного подтверждения между ними.
Сложность: advanced
Кейсы: Название: Кейс 1: Внедрение пятишагового SDD в банковском DataLakeHouse
Сценарий: Средний розничный банк (5 млн клиентов) внедряет Qwen Code для ускорения разработки dbt-моделей в корпоративном DataLakeHouse. До внедрения аналитики тратили до 40% времени на описание источников и согласование контрактов, а изменения часто шли в обход формальных процедур. Пилотная команда из 6 инженеров данных начинает с создания пяти отдельных команд: /sdd:profile, /sdd:contract, /sdd:build, /sdd:verify, /sdd:release.
Задача: Главные вызовы: (1) как убедить команду не сворачивать процесс в одну команду из-за «неудобства» переключения; (2) как формализовать точки подтверждения человеком так, чтобы они не превратились в формальные галочки; (3) как настроить разные роли для генератора и ревьюера, чтобы последний не зависел от контекста чата; (4) как выбрать первый класс изменений для блокировки хуком, не переусложнив процесс.
Решение: Команда пошла в несколько этапов. Этап 1: создали файлы .qwen/commands/sdd/profile.md, contract.md, build.md, verify.md, release.md — каждый со своей узкой инструкцией. Этап 2: ввели навык data-profiler, который возвращает только Schema Manifest без права писать модели. Этап 3: выделили субагента data-contract-review, работающего только с файлами репозитория (режим только чтения) и применяющего чек-лист. Этап 4: после первого месяца проанализировали повторяющиеся нарушения — выяснилось, что в 4 из 11 случаев PII-поля попадали в marts без отметки в ODCS. Это стало основой для первого хука, блокирующего запись полей с префиксом pii_ в models/marts/. Этап 5: зафиксировали карту процесса и сделали её обязательной частью онбординга новых аналитиков.
Результат: Через три месяца: среднее время от запроса на изменение до релиза сократилось на 28% (с 9 до 6.5 дней), количество регрессий от неконтрактных полей упало до нуля, время на описание источника — на 35%. Главный качественный эффект: появился явный владелец каждого артефакта и явная точка, где решение принимает человек, а не LLM.
Извлечённые уроки: Разделение на пять команд — это не бюрократия, а способ сделать ответственность видимой: профиль не пишет модели, ревьюер не правит SQL, генератор не утверждает свою безопасность
Хуки полезны только после того, как команда сама увидела повторяющиеся нарушения — иначе хук либо слишком слабый, либо слишком раздражающий
Ревьюер в режиме только чтения особенно ценен после /clear: если он не может понять изменение по файлам, значит автор оставил смысл в чате — это сигнал плохой дисциплины, который легко поймать формальной проверкой
Карта процесса — минимальный, но обязательный артефакт: без неё новые члены команды не понимают, где их точка подтверждения
Связанные концепции: Пятишаговый процесс /sdd:profile → /sdd:contract → /sdd:build → /sdd:verify → /sdd:release
Навыки и субагенты
Разделение ролей генератора и ревьюера
Точки подтверждения человеком
Хуки
Название: Кейс 2: Ошибка единой команды /sdd:do-everything в core banking DataLake
Сценарий: Крупный банк (топ-10) в попытке «ускорить DataOps» создал единую команду /sdd:do-everything, которая сама профилировала источник, обновляла контракт, генерировала dbt-модель, запускала тесты и публиковала отчёт. Идея была в том, чтобы один запрос от аналитика превращался в законченное изменение за один цикл. Первые два месяца всё работало гладко.
Задача: На третий месяц в marts-таблицу mart_customer_360 попало поле passport_series с префиксом pii_, которого не было в ODCS-контракте источника. Поле ушло в три downstream-отчёта, в том числе в регуляторный дашборд ЦБ. Сложность: (1) команда не оставляла промежуточных артефактов — был только финальный отчёт; (2) Schema Manifest не проверялся человеком-экспертом по источнику; (3) обновление ODCS было сгенерировано автоматически, без подписи владельца данных; (4) в логах не было метки ручного подтверждения. Восстановление причин заняло больше недели.
Решение: Банк отказался от /sdd:do-everything и перешёл к пяти командам. Профиль и контракт были переданы отдельной роли — Data Steward. Генератор dbt-моделей получил ограниченную область (только build) и запрет на обновление contracts/. Ревьюер data-contract-review был запущен как отдельный субагент в режиме только чтения, который получает только diff из Git, а не контекст чата. Хук был написан сразу: он блокирует любую запись в models/marts/ с полем, начинающимся на pii_, и требует метки contract-approved в любом изменении ODCS-файлов. Точки подтверждения человеком были закреплены в политике безопасности: ни одна dbt-модель не уходит в main без подписи Data Steward в PR-описании.
Результат: В течение следующего квартала подобных инцидентов не повторялось. Аудиторы ЦБ отдельно отметили наличие явной карты процесса с артефактами как положительный сигнал зрелости DataOps. Скорость разработки восстановилась через 6 недель после первоначального снижения — аналитики признали, что пять коротких шагов с явными подтверждениями быстрее, чем одна длинная команда с разбором инцидента в случае ошибки.
Извлечённые уроки: Единая команда /sdd:do-everything удобна в демонстрации, но опасна в банковских данных: подтверждение человеком исчезает, а дрейф контракта обнаруживается слишком поздно
Артефакт — это не отчёт, а точка опоры для расследования: когда нет Schema Manifest и нет подписанного ODCS, некому предъявить претензию и нечем доказать, что было обещано
Разделение ролей — это не формальность, а способ узнать, кто должен был заметить проблему: после ошибки именно роль показывает, где был пропущен шаг
Хуки в банковской среде должны блокировать не «всё подозрительное», а узкий известный опасный класс — иначе их начнут обходить
Связанные концепции: Типичная ошибка: /sdd:do-everything
Дрейф контракта
PII в marts
Артефакт как точка опоры
Хуки как дисциплинарный слой
Название: Кейс 3: Эволюция от навыка к субагенту в команде риск-моделирования
Сценарий: Команда риск-моделирования в инвестбанке использует Qwen Code для ускорения подготовки витрин для моделей кредитного скоринга. На первом этапе они описали data-profiler как навык, а data-contract-review — как простую инструкцию в чате. Через два месяца стало ясно, что «ревью в чате» легко игнорируется: автор просто отвечает «всё ок» и продолжает.
Задача: Проблема: ревьюер должен быть структурно отдельной ролью, а не модой поведения того же агента. Когда ревью — это чат-инструкция, агент остаётся в той же сессии и наследует контекст автора, включая его уверенность в правильности решения. Кроме того, ревьюер должен видеть только файлы, а не переписку, иначе он будет оценивать не код, а намерения.
Решение: Команда вынесла ревью в отдельный субагент data-contract-review с собственным системным промптом и режимом только чтения к репозиторию. Единственный вход — diff из Git, никакого контекста чата. Чек-лист ревью был формализован и теперь включает пункты: «поле с префиксом pii_ — запрещено в marts», «изменение grain — требуется grain-impact в описании», «обновление ODCS — требуется contract-approved в коммите», «новая зависимость от источника — требуется profile повторно». Вне сессии /clear ревьюер остаётся полностью функциональным, что и требовалось.
Результат: За квартал среднее число замечаний, найденных ревьюером, выросло с 0.4 до 2.7 на PR. Особенно ценным оказалось замечание «непонятно по файлам, что делает изменение» — оно появлялось у авторов, которые привыкли объяснять логику в чате, а не в коммитах. Это заставило команду ужесточить практику commit messages и PR-описаний, что улучшило общее качество кода независимо от AI-инструмента.
Извлечённые уроки: Навык (skill) и субагент (sub-agent) — это разные уровни изоляции: навык сужает роль в той же сессии, субагент даёт отдельный контекст и режим
Ревьюер в режиме только чтения работает лучше всего после /clear: его нельзя убедить, потому что у него нет доступа к чату
Чек-лист ревью должен быть явным, иначе ревью вырождается в «всё выглядит нормально»
Замечание «непонятно по файлам» — это не баг ревьюера, а фича: оно ловит плохую документацию изменений
Связанные концепции: Навыки и субагенты
data-contract-review
data-profiler
Режим только чтения
Чек-лист ревью
Советы по изучению: Сначала соберите карту процесса на бумаге, прежде чем создавать файлы команд: пять команд, пять артефактов, явные точки подтверждения. Это займёт 20 минут, но сэкономит недели борьбы с /sdd:do-everything
Прогоните одну задачу в двух режимах — одной командой и пятью — и зафиксируйте разницу в количестве найденных рисков. Это нагляднее любой теории
Не пишите хуки раньше, чем увидите повторяющиеся нарушения: первые два-три спринта собирайте статистику, а потом формулируйте правила
Всегда держите ревьюера в режиме только чтения и без доступа к чату: это единственный способ заставить автора писать понятные коммиты и PR-описания
После /clear проверяйте, может ли ревьюер понять изменение по файлам. Если нет — это сигнал, что автор оставил смысл в чате, и дисциплина требует исправления
Принцип «если команда не оставляет артефакт, она не нужна на первом проходе» — хороший фильтр: пять команд дают пять артефактов; команда без артефакта — это либо лишний шаг, либо плохо сформулированная роль
Связывайте каждое правило с классом изменений: PII в marts, изменение grain, обновление ODCS без метки. Абстрактные правила вроде «код должен быть качественным» не работают ни в ревью, ни в хуках
Используйте терминологию главы: «точка подтверждения человеком», «артефакт», «дрейф контракта», «зерно». Это общий язык, который позволяет команде быстро согласовать изменения
Дополнительные ресурсы: Open data contract standard (odcs): Стандарт описания контрактов данных, используемый в главе. Помогает формализовать обещание источника потребителю. https://bitol-io.github.io/open-data-contract-standard/
Dbt (data build tool): Инструмент трансформации данных, упомянутый в контексте команд /sdd:build и /sdd:verify. Документация: https://docs.getdbt.com/
Pii в data lakehouse: Обзор практик работы с персональными данными в озеро-хранилищах данных. Полезен для понимания, почему PII в marts — типовой опасный класс
Data contracts (март лопес-рестрепо и др.): Концептуальная база по data contracts как способу фиксации обещаний между производителями и потребителями данных
Qwen code и qwen3-coder: Документация по AI-инструменту Qwen Code, включая работу с командами, навыками и субагентами. https://qwenlm.github.io/
Spec-driven development (sdd): Методология, лежащая в основе главы. Смежная с BDD и TDD, но с фокусом на спецификации данных и контракты
Separation of duties (sod) в банковской среде: Концепция из области внутреннего контроля банков, объясняющая, почему генератор и ревьюер должны быть разными ролями
Резюме: Глава 21 собирает весь том в работающий цикл Qwen Code-процесса для DataLakeHouse: пять команд (/sdd:profile, /sdd:contract, /sdd:build, /sdd:verify, /sdd:release), каждая с узкой ролью, явным артефактом и точкой подтверждения человеком между ними. Главная мысль: одна команда не должна делать весь процесс — иначе подтверждения человеком исчезают, а дрейф контракта обнаруживается слишком поздно, что особенно критично в банковских данных. Навыки (data-profiler) и субагенты (data-contract-review) полезны, когда сужают роль: профилировщик не пишет модели, ревьюер не правит SQL, генератор не утверждает свою безопасность. Хуки — это следующий уровень дисциплины, но их нельзя писать раньше процесса: сначала команда должна увидеть повторяющиеся нарушения (PII в marts, изменение ODCS без метки, изменение grain без заметки), а затем формализовать их в правила. Минимальный выход главы — карта процесса с пятью командами, пятью артефактами и одной строкой для отчёта ревьюера. После прочтения читатель должен уверенно отвечать на три контрольных вопроса: почему процесс нельзя делать одной командой, чем навык отличается от субагента и где должно стоять подтверждение человеком.