
# Составляемая микросервисная архитектура ИИ для масштабируемой автоматизации вопросов по безопасности

Предприятия утопают в постоянно растущем потоке вопросов по безопасности, оценок поставщиков и аудитов соответствия. Традиционные монолитные инструменты не успевают, особенно когда необходимо интегрироваться с разрозненными экосистемами продуктов, поддерживать многоязычные запросы и предоставлять трассировку в реальном времени.

**Составляемая микросервисная архитектура**, построенная вокруг больших языковых моделей (LLM) и генерации с поддержкой поиска (RAG), предлагает способ масштабировать автоматизацию, сохраняя гибкость и управление, требуемые регулируемыми отраслями. В этом руководстве мы:

* Описываем основные принципы проектирования, которые делают систему **безопасной, аудируемой и расширяемой**.  
* Проводим подробный разбор референс‑реализации, диаграммированную с помощью Mermaid.  
* Показуем, как каждый сервис может быть развернут независимо в Kubernetes, безсерверных FaaS или на периферийных средах.  
* Предлагаем практические рекомендации по управлению данными, наблюдаемости и непрерывному улучшению.

> **TL;DR:** Разделите платформу автоматизации вопросов на небольшие, чётко определённые сервисы, разместите LLM за безсостоянием уровня инференса и используйте событийно‑ориентированные конвейеры, чтобы поддерживать единый источник правды для доказательств и контроля версий.

---

## 1. Почему стоит собрать, а не строить гигантский монолит?

| Монолитный подход | Составляемые микросервисы |
|-------------------|----------------------------|
| Одна кодовая база, трудно масштабировать отдельные нагрузки (например, инференс LLM). | Независимое масштабирование – инференс ИИ может работать на GPU‑нодах, а хранилище остаётся на экономичных объектных хранилищах. |
| Жёсткая связность делает обновления рискованными; ошибка в UI может вывести из строя всю систему. | Асинхронные события или HTTP‑API обеспечивают слабую связность и изоляцию отказов. |
| Ограниченная языковая интеграция – часто привязана к одному стеку. | Полиглотная поддержка – каждый сервис может быть написан на языке, оптимальном для задачи (Go для аутентификации, Python для оркестрации ИИ, Rust для высокопроизводительных конвейеров). |
| Аудит и соответствие становятся кошмаром, т.к. логи сплетены. | Централизованный журнал событий + неизменяемый аудит‑лог обеспечивает чёткую, запросную трассировку для регуляторов. |

**Составляемая** модель воплощает философию *«строишь то, что нужно, и заменяешь то, что не нужно»*. Она соответствует динамичной природе вопросов по безопасности, где регулярно появляются новые контрольные рамки (например, [ISO 27001 Rev 2](https://www.iso.org/standard/27001)) и командам необходимо быстро адаптироваться.

---

## 2. Ключевые архитектурные столпы

1. **Бесстатный API‑шлюз** – точка входа для UI, SaaS‑коннекторов и внешних инструментов. Обрабатывает аутентификацию, валидацию запросов и ограничение скорости.  
2. **Микросервисы предметных областей** – каждый инкапсулирует ограниченный контекст:  
   * **Сервис вопросов** – хранит метаданные вопросов, версии и назначения задач.  
   * **Сервис доказательств** – управляет артефактами (политиками, скриншотами, журналами аудита) в неизменяемом объектном хранилище.  
   * **Сервис оркестрации ИИ** – формирует подсказки, запускает RAG‑конвейеры и возвращает черновики ответов.  
   * **Сервис обнаружения изменений** – следит за загрузкой новых доказательств, инициирует переоценку затронутых ответов.  
   * **Сервис уведомлений** – отправляет сообщения в Slack, Teams или по email заинтересованным сторонам.  
3. **Шина событий (Kafka / Pulsar)** – гарантирует доставку событий «по крайней мере один раз» (например, `EvidenceUploaded`, `AnswerDrafted`).  
4. **Стек наблюдаемости** – трассировки OpenTelemetry между сервисами, метрики Prometheus и логи Loki.  
5. **Engine политики как кода** – проверяет правила соответствия (написанные в Rego или OPA) перед тем, как ответ будет помечен «окончательным».  

Все сервисы взаимодействуют через **gRPC** (для низкой задержки) или **REST** (для внешних интеграций). Дизайн поощряет *«глупые каналы, умные эндпоинты»* — бизнес‑логика живёт там, где ей место, а шина лишь транспортирует сообщения.

---

## 3. Поток данных – от вопроса к аудируемому ответу

Ниже представлена диаграмма Mermaid, визуализирующая типичный жизненный цикл запроса.

```mermaid
flowchart TD
    subgraph UI["Пользовательский интерфейс"]
        UI1["\"Веб‑интерфейс\""] -->|Отправить вопрос| AG["\"API шлюз\""]
    end

    AG -->|Аутентификация и валидация| QMS["\"Сервис вопросов\""]
    QMS -->|Получить шаблон| AIOS["\"Сервис оркестрации ИИ\""]
    AIOS -->|Извлечь релевантные доказательства| ES["\"Сервис доказательств\""]
    ES -->|Объекты доказательств| AIOS
    AIOS -->|Сгенерировать черновик ответа| RAG["\"Конвейер RAG\""]
    RAG -->|Вывод LLM| AIOS
    AIOS -->|Сохранить черновик| QMS
    QMS -->|Сгенерировать событие AnswerDrafted| EB["\"Шина событий\""]
    EB -->|Триггер| CDS["\"Сервис обнаружения изменений\""]
    CDS -->|Перезапустить при изменении доказательств| AIOS
    CDS -->|Создать событие AnswerUpdated| EB
    EB -->|Уведомить| NS["\"Сервис уведомлений\""]
    NS -->|Отправить в Slack/Email| UI

    style UI fill:#f9f,stroke:#333,stroke-width:2px
    style AG fill:#bbf,stroke:#333,stroke-width:1px
    style QMS fill:#bfb,stroke:#333,stroke-width:1px
    style AIOS fill:#ffb,stroke:#333,stroke-width:1px
    style ES fill:#fbb,stroke:#333,stroke-width:1px
    style RAG fill:#fdd,stroke:#333,stroke-width:1px
    style CDS fill:#ddf,stroke:#333,stroke-width:1px
    style NS fill:#cfc,stroke:#333,stroke-width:1px
```

**Ключевые моменты потока**:

1. **Пользователь отправляет** новый вопрос или выбирает существующий.  
2. **API‑шлюз** проверяет JWT, проверяет лимиты и перенаправляет запрос в Сервис вопросов.  
3. Сервис вопросов вытягивает шаблон вопроса и публикует событие в Сервис оркестрации ИИ.  
4. **Сервис оркестрации ИИ** выполняет шаг *retrieval* – запрашивает у Сервиса доказательств все артефакты, релевантные текущему контролю (через векторное сходство или поиск по ключевым словам).  
5. Полученные контексты вместе с шаблоном подсказки передаются в **конвейер RAG** (например, `openAI/gpt‑4o‑preview`).  
6. Черновик ответа сохраняется обратно в Сервис вопросов, помеченный как *«в ожидании проверки»*.  
7. **Сервис обнаружения изменений** наблюдает загрузки новых доказательств. Если политика обновилась, он пере‑запускает RAG‑конвейер для затронутых ответов.  
8. После одобрения ревьюером, **Engine политики как кода** проверяет, что ответ удовлетворяет всем правилам, прежде чем зафиксировать его в неизменяемом журнале аудита.  

---

## 4. Подробности реализации

### 4.1. API‑шлюз (Envoy + OIDC)

* **Маршрутизация** – `POST /questionnaires/:id/answers` → `questionnaire-service`.  
* **Безопасность** – Принудительно проверять scopes (`questionnaire:write`).  
* **Ограничение скорости** – 100 запросов/минуту на арендатора, чтобы контролировать затраты на LLM.

### 4.2. Сервис вопросов (Go)

```go
type Questionnaire struct {
    ID          string            `json:"id"`
    Version     int               `json:"version"`
    Controls    []Control        `json:"controls"`
    Drafts      map[string]Answer `json:"drafts"` // key = control ID
    AssignedTo  map[string]string `json:"assigned_to"` // userID
}
```

* Использует **PostgreSQL** для реляционных данных, **EventStoreDB** для доменных событий.  
* Предоставляет gRPC‑методы `GetTemplate`, `SaveDraft`, `FinalizeAnswer`.

### 4.3. Сервис доказательств (Python + FastAPI)

* Хранит файлы в **MinIO** или **AWS S3** с шифрованием на уровне бакета.  
* Индексирует содержимое в **Qdrant** (векторная БД) для поиска сходства.  
* Предлагает эндпоинт `POST /search`, принимающий запрос и возвращающий top‑k ID артефактов.

### 4.4. Сервис оркестрации ИИ (Python)

```python
def generate_answer(question: str, evidence_ids: List[str]) -> str:
    evidence = fetch_evidence(evidence_ids)
    context = "\n".join(evidence)
    prompt = f"""Вы — специалист по соответствию.
    Используя следующие доказательства, дайте краткий ответ на вопрос:\n{context}\n\nВопрос: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content
```

* **RAG** – комбинирует векторный поиск с системной подсказкой, требующей указания ID доказательств.  
* **Кеширование** – хранит сгенерированные ответы в течение 24 ч, чтобы избежать дублирования запросов к LLM.

### 4.5. Сервис обнаружения изменений (Rust)

* Подписывается на события `EvidenceUploaded`.  
* Вычисляет **хеш** нового артефакта и сравнивает его с уже привязанными к каждому контролю доказательствами.  
* При превышении порогового различия публикует `AnswerRequiresRegen`.

### 4.6. Сервис уведомлений (Node.js)

* Слушает `AnswerDrafted`, `AnswerFinalized`, `AnswerRequiresRegen`.  
* Формирует сообщения для Slack, Teams или email.  
* Поддерживает **дедупликацию** – уведомление отправляется один раз per изменение per questionnaire.

---

## 5. Безопасность и управление

| Вопрос | Митигaция |
|--------|-----------|
| **Утечка данных** – подсказки могут содержать конфиденциальные политики. | Использовать **локальный инференс LLM** (напр. Llama 3.2) внутри VPC. Маскировать PII перед отправкой во внешние API. |
| **Неавторизованный доступ к доказательствам** | Применять тонко‑granular ACL через OPA‑политики в Сервисе доказательств. |
| **Дрейф модели** – ответы ухудшаются со временем. | Планировать **периодическую оценку** против эталонного корпуса и переобучать шаблоны подсказок. |
| **Аудит** | Каждый переход состояния фиксируется в неизменяемом журнале событий, хранящемся в **WORM S3**. |
| **Соответствие GDPR/CCPA** | Реализовать рабочий процесс **right‑to‑be‑forgotten**, который удаляет пользовательские доказательства из векторной БД и объектного хранилища ([GDPR](https://gdpr.eu/)). |
| **ISO 27001** | Проверить, что политики хранения, шифрования и контроля доступа соответствуют требованиям ISO 27001. |
| **HIPAA / SOC 2** | Для компаний в сфере здравоохранения расширить правила OPA, чтобы обеспечить требуемые защитные меры. |

---

## 6. Стратегии масштабирования

1. **Горизонтальное автоскейлирование (HPA)** – масштабировать поды Сервиса оркестрации ИИ исходя из загрузки GPU (`nvidia.com/gpu`).  
2. **Очереди для всплесков** – использовать сегментацию Kafka, изолируя трафик высокоприоритетных арендаторов.  
3. **Снижение холодного старта** – поддерживать «тёплый» пул контейнеров для сервера инференса LLM (например, через **KEDA** с кастомным скейлером).  
4. **Контроль расходов** – внедрить **бюджет токенов** на арендатора; автоматически ограничивать или тарифицировать перерасход.

---

## 7. Наблюдаемость и непрерывное улучшение

* **Распределённые трассировки** – OpenTelemetry спаны от UI‑запроса → API‑шлюз → Сервис оркестрации ИИ → RAG → Сервис доказательств.  
* **Метрики** – `answer_draft_latency_seconds`, `evidence_upload_bytes`, `llm_token_usage`.  
* **Агрегация логов** – структурированные JSON‑логи с транслируемым `request_id` во всех сервисах.  
* **Цикл обратной связи** – после финализации ответа фиксировать комментарии ревьюеров (`review_score`). П feeding‑back‑ом обучать модель‑усиления, регулируя температуру подсказки или выбирая альтернативные источники доказательств.

---

## 8. Пошаговый путь миграции для существующих команд

| Фаза | Цель | Действия |
|------|------|----------|
| **0 – Оценка** | Составить карту текущего рабочего процесса вопросов. | Идентифицировать источники данных, определить таксономию контролей. |
| **1 – Создание фундамента** | Развернуть API‑шлюз, аутентификацию и базовые сервисы. | Контейнеризировать `questionnaire-service` и `evidence-service`. |
| **2 – Внедрение ИИ** | Запустить RAG на пилотном вопросе. | Использовать песочницу LLM, вручную проверять черновики. |
| **3 – Автоматизация событий** | Подключить конвейер обнаружения изменений. | Включить авто‑перегенерацию при обновлении доказательств. |
| **4 – Ужесточение управления** | Добавить OPA‑политики, неизменяемый журнал аудита. | Перейти на продакшн‑инференс LLM (on‑prem). |
| **5 – Масштаб и оптимизация** | Автоскейлить GPU‑поды, внедрить контроль расходов. | Запустить стек наблюдаемости, установить SLO. |

Постепенно внедряя составляемую архитектуру, команды избегают риска «одним ударом» и могут уже на ранних этапах продемонстрировать возврат инвестиций (обычно **30‑50 % сокращение** времени ответа на вопросы).

---

## 9. Обеспечение будущей готовности стека

* **Federated Learning** – обучать лёгкие адаптеры на данных каждого арендатора без выгрузки исходных доказательств, повышая релевантность ответов при соблюдении суверенитета данных.  
* **Zero‑Trust Service Mesh** – использовать **Istio** или **Linkerd** с взаимной TLS для защиты внутреннего трафика.  
* **Семантическое управление** – расширить Engine политики как кода, чтобы проверять не только содержание ответа, но и **семантическую схожесть** между доказательствами и формулировкой контроля.  
* **Генеративная трассируемость** – сохранять точные параметры LLM (temperature, top‑p, системную подсказку) вместе с каждым ответом для форензической проверки.

---

## 10. Заключение

Составляемая микросервисная архитектура превращает автоматизацию вопросов по безопасности из **мучительной ручной работы** в **масштабируемый, аудируемый и постоянно улучшающийся механизм**. Разделяя обязанности, используя LLM через безсостоящий RAG‑слой и связывая всё событием, организации могут:

* Отвечать на запросы поставщиков за минуты, а не дни.  
* Держать доказательства всегда актуальными благодаря авто‑перегенерации.  
* Предоставлять регуляторам чёткую, неизменяемую трассировку.

Начинайте с малого, быстро итеративно улучшайте, и пусть микросервисы помогут сделать соответствие **фичей**, а не узким местом.

---

## Смотрите также

- [OPA Policy-as-Code for Micro‑services](https://www.openpolicyagent.org/docs/latest/policy-language/)