Управление разработкой больших проектов требует не только кода, но и описаний: модули, процедуры, архитектура, решения. Классическая идея — отобразить элементы методологии (модуль, процедура, компонент) в формализованные записи и хранить в едином репозитории. Для DevOps это документация проекта в базе знаний: ADR, схемы, runbook'и по сервисам.
Решения фиксируют в записях ADR-NNNN в docs/adr/ — RAG тогда находит контекст «почему так сделали».
Модули и процедуры как объекты
Каждый модуль или значимая процедура может быть описана как запись: название, назначение, зависимости, ссылка на код. Не обязательно тянуть полноценный граф — достаточно единого формата и индексации. По запросу «как устроен сервис X» или «где обрабатывается платёж» система возвращает релевантные описания и ссылки на репо.
Архитектура и решения
ADR (Architecture Decision Records), диаграммы компонентов, описание окружений — часть базы знаний. Хранить в Git рядом с кодом (docs/, .adr) или в Confluence с ссылками на репо. Индексировать в RAG — тогда чат по архиву отвечает на вопросы «почему выбрали X», «как сервисы связаны». Владелец документации и ревизия при изменении кода — часть процесса.
Связка с CI/CD и ревизией
Изменение в коде или конфиге, влияющее на процедуру или архитектуру, — повод обновить документ в том же PR или тикете. База знаний тогда не отстаёт от реальности. Чат по архиву даёт актуальные ответы только при регулярном обновлении индекса и самих документов.
Практики применения
- Документируйте архитектуру и решения рядом с кодом; индексируйте в RAG для чата по архиву.
- Назначьте владельца документации проекта; связывайте с регламентами и runbook'ами.
Итог: документирование проектов — модули, процедуры, ADR, схемы — как первые классы в базе знаний. Единый формат, индексация в RAG, обновление в связке с кодом. Чат по архиву — быстрый доступ к «как устроено» и «почему так».