Идея «исполняемых данных» или «активных документов»: документ содержит не только текст, но и код, который обеспечивает доступ к содержимому или автоматизирует действия. В контексте DevOps это напрямую связано с runbook'ами, которые можно не только читать, но и выполнять — через скрипты, Ansible, CI.

Пример: в Markdown соседствуют шаги и fenced-блок с языком bash — RAG отдаёт цитату, а дежурный копирует команды в терминал без поиска по вики.

Активные документы

Классическая формулировка: данные становятся самодостаточными, если к описанию приложен исполняемый код — скрипт, который интерпретирует структуру или выполняет действия. Иначе документ зависит от внешнего ПО; при его отсутствии доступ к смыслу теряется. В случае runbook'а «исполняемость» — это привязка к реальным командам и пайплайнам.

Runbook как активный документ

Runbook в базе знаний может содержать не только шаги текстом, но и ссылки на скрипты, плейбуки Ansible, задачи в CI. Один документ — цель, условия, шаги, откат; код живёт в репозитории и вызывается по ссылке или по имени. Чат по базе знаний возвращает runbook и ссылку на скрипт; оператор выполняет или запускает автоматизацию.

Баланс

Встроенный в документ код должен быть простым, надёжным и безопасным. На практике чаще разделяют: документ в Confluence или в RAG, исполняемая часть — в Git (скрипты, плейбуки). Связь — по именам, путям, тегам. Так runbook остаётся «активным» через однозначную связь с кодом, без риска раздувать документ небезопасным скриптом.

Практики применения

Оформляйте runbook'и с полями «цель, предусловия, шаги, откат»; связывайте с скриптами и репо.
Индексируйте в RAG — чат по базе подскажет нужную процедуру и ссылку на исполняемый код.

Кратко: исполняемые документы — описание плюс код. Runbook'и делаем «активными» через явную связь с скриптами и плейбуками в Git; чат по базе знаний выдаёт и текст, и ссылку на исполняемое.