
# Съставима AI микросервизна архитектура за мащабирана автоматизация на въпросници за сигурност

Предприятията са потънали в непрестанно растящия поток от въпросници за сигурност, оценки на доставчици и одити за съответствие. Традиционните монолитни инструменти се борят да се справят, особено когато трябва да се интегрират с различни екосистеми от продукти, да поддържат многоезични заявки и да предоставят реално‑времеви записи за одит.  

**Съставим микросервизен архитектурен модел**, построен около големи езикови модели (LLM) и генериране с разширено извличане (RAG), предлага начин за мащабиране на автоматизацията, като запазва гъвкавостта и управлението, изисквани от регулираните индустрии. В това ръководство ще:

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

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

---

## 1. Защо да съставяме, а не да изграждаме гигантски монолит?

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

**Съставимият** модел прегръща философията *„изграждаш това, от което се нуждаеш, и заменяш това, което не ти е нужно“*. Той съответства на динамичната природа на въпросниците за сигурност, където нови контролни рамки (например [ISO 27001 Rev 2](https://www.iso.org/standard/27001)) се появяват редовно и екипите трябва да се адаптират бързо.

---

## 2. Основни архитектурни стълбове

1. **Безсъстоящ API шлюз** – входна точка за UI, SaaS конектори и външни инструменти. Обработва автентикация, валидация на заявки и throttling.  
2. **Домейново‑специфични микросервизи** – всеки капсулира ограничен контекст:  
   * **Услуга за въпросници** – съхранява метаданни, версии и разпределение на задачи.  
   * **Услуга за доказателства** – управлява артефакти (политики, скрийншоти, одитни записи) в неизменимо обектно хранилище.  
   * **Услуга за оркестрация на AI** – композира prompts, изпълнява RAG конвейри и връща чернови отговори.  
   * **Услуга за откриване на промени** – следи актуализации на доказателства и задейства преоценка на засегнатите отговори.  
   * **Услуга за известяване** – изпраща събития към Slack, Teams или имейл до заинтересованите страни.  
3. **Събитийна шина (Kafka / Pulsar)** – гарантира доставка поне веднъж за домейнови събития (напр. `EvidenceUploaded`, `AnswerDrafted`).  
4. **Стек за наблюдаемост** – OpenTelemetry трасета между услугите, Prometheus метрики и Loki логове.  
5. **Policy‑as‑Code engine** – оценява правила за съответствие (написани в Rego или OPA) преди отговорът да бъде маркиран като „окончателен“.  

Всички услуги комуникират чрез **gRPC** (за ниска латентност) или **REST** (за външни интеграции). Дизайнът насърчава *глупави тръби, умни крайни точки* – бизнес логиката живее там, където принадлежи, докато шина само транспортира съобщения.

---

## 3. Поток на данните – От въпрос към проверяем отговор

По‑долу е Mermaid диаграма, визуализираща типичен жизнен цикъл на заявка.

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

    AG -->|Автентикация & Валидация| QMS["Услуга за въпросници"]
    QMS -->|Извличане на шаблон| AIOS["Услуга за оркестрация на AI"]
    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/имейл| 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, проверява rate‑limit и препраща към Услугата за въпросници.  
3. **Услугата за въпросници** извлича шаблона и изпраща събитие към Услугата за оркестрация на AI.  
4. **Услугата за оркестрация** извършва стъпка за извличане – заявява Услугата за доказателства за всички артефакти, релевантни на текущия контрол (чрез векторно сходство или keyword match).  
5. Получените контексти, заедно със шаблона за prompt, се подава в **RAG конвейер** (напр. `openAI/gpt‑4o‑preview`).  
6. Черновият отговор се съхранява обратно в Услугата за въпросници, маркиран като *„чака преглед“*.  
7. **Услугата за откриване на промени** следи нови качвания на доказателства. Ако политика бъде актуализирана, тя повторно задейства RAG конвейера за засегнатите отговори.  
8. Финалните прегледащи приемат или редактират черновата; при приемане **Policy‑as‑Code двигателят** валидира, че отговорът удовлетворява всички правила, преди да го впише в неизменим одитен лог.  

---

## 4. Детайли за имплементацията

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

* **Маршрутиране** – `POST /questionnaires/:id/answers` → `questionnaire-service`.  
* **Сигурност** – Налага обхвати (`questionnaire:write`).  
* **Rate limiting** – 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** с шифроване на ниво bucket.  
* Индексира съдържанието в **Qdrant** (векторна DB) за търсене по сходство.  
* Предлага endpoint `POST /search`, който приема заявка и връща топ‑k артефакти.

### 4.4. Услуга за оркестрация на AI (Python)

```python
def generate_answer(question: str, evidence_ids: List[str]) -> str:
    evidence = fetch_evidence(evidence_ids)
    context = "\n".join(evidence)
    prompt = f"""You are a compliance specialist.
Using the following evidence, answer the question concisely:\n{context}\n\nQuestion: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content
```

* **RAG** – Комбинира векторно търсене с *system prompt*, инструктиращ моделa да цитира идентификатори на доказателствата.  
* **Кеширане** – Съхранява генерирани отговори за 24 ч. за да се избегнат дублирани LLM заявки.

### 4.5. Услуга за откриване на промени (Rust)

* Абонира се за събития `EvidenceUploaded`.  
* Изчислява **хаш** на новия артефакт и прави **diff** спрямо съществуващите доказателства, свързани с всеки контрол.  
* Ако разликата надвиши конфигурируем праг, публикува `AnswerRequiresRegen`.

### 4.6. Услуга за известяване (Node.js)

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

---

## 5. Сигурност и управление

| Проблем | Мерка |
|---------|-------|
| **Изтичане на данни** – Prompt‑овете могат да съдържат чувствителни политики. | Използвайте **локален LLM inference** (напр. Llama 3.2) зад VPC. Маскирайте ПИИ преди изпращане към външни API‑та. |
| **Неоторизиран достъп до доказателства** | Прилагайте фини ACL‑и чрез OPA правила в Услугата за доказателства. |
| **Изместване на модела** – Отговорите се влошават с времето. | Планирайте **периодични оценки** спрямо референтен корпус и преобучавайте prompt‑овете. |
| **Одитируемост** | Всеки преход в състоянието се записва в неизменим журнал, съхраняван в **WORM S3**. |
| **Съответствие с GDPR/CCPA** | Реализирайте **право на забрава**, което изтрива потребителски‑специфични доказателства от векторната DB и обектното хранилище ([GDPR](https://gdpr.eu/)). |
| **ISO 27001** | Валидирайте, че политики за задържане, шифроване и контрол на достъпа съвпадат със стандарт ISO 27001. |
| **HIPAA / SOC 2** | За здравни и SaaS доставчици, разширете OPA правила, за да полагате необходимите защити. |

---

## 6. Стратегии за мащабиране

1. **Horizontal Pod Autoscaling (HPA)** – Мащабирайте подовете за оркестрация на AI според GPU натоварването (`nvidia.com/gpu`).  
2. **Burst‑able опашки** – Използвайте Kafka партициониране, за да изолирате интензивни наематели.  
3. **Намаляване на cold‑start** – Поддържайте топ пул от контейнери за LLM inference сървъра (напр. чрез **KEDA** с персонализиран скалар).  
4. **Контрол на разходите** – Прилагайте **бюджетиране на токени** за всеки наемател; автоматично throttling или таксуване за превишение.

---

## 7. Наблюдаемост и непрекъснато подобряване

* **Разпределено трасиране** – OpenTelemetry спанира от заявка от UI → API шлюз → AI оркестрация → RAG → Услуга за доказателства.  
* **Метрики** – `answer_draft_latency_seconds`, `evidence_upload_bytes`, `llm_token_usage`.  
* **Агрегация на логове** – Структурирани JSON логове със `request_id`, пропагирани през всички услуги.  
* **Обратна връзка** – След като отговорът е окончателен, събирайте коментари от преглеждащите (`review_score`). Използвайте ги за **reinforcement learning** модел, който настройва температурата на prompt‑овете или избира алтернативни източници на доказателства.

---

## 8. Стъпка‑по‑стъпка път за миграция на съществуващи екипи

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

Чрез инкрементално приемане на съставимата архитектура, екипите избягват риска от “голямо преливане” и могат да демонстрират ранна Възвръщаемост (често **30‑50 % намаляване** на времето за отговор на въпросници).

---

## 9. Бъдеща готовност на стека

* **Федеративно обучение** – Тренирайте леки адаптери върху данните на всеки наемател без да премествате суровите доказателства, подобрявайки релевантността на отговорите, като уважавате суверенитета на данните.  
* **Zero‑Trust Service Mesh** – Използвайте **Istio** или **Linkerd** с взаимно TLS за сигурност на вътрешния трафик.  
* **Семантично управление** – Разширете Policy‑as‑Code двигателя, за да валидира не само съдържанието, но и **семантичното сходство** между доказателствата и формулировката на контролите.  
* **Генеративна трасируемост** – Съхранявайте точните LLM параметри (temperature, top‑p, system prompt) заедно с всеки отговор, за форензикен преглед.

---

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

Съставимият микросервизен модел трансформира автоматизацията на въпросници за сигурност от **болезнена ръчна задача** в **мащабируем, проверяем и постоянно подобряващ се двигател**. Чрез раздвояване на отговорностите, използване на LLM чрез безсъстоящ RAG слой и свързване на всичко със събитийно‑движна артерия, организациите могат:

* Да отговарят на оценки на доставчици за минути вместо дни.  
* Да поддържат доказателствата винаги актуални чрез автоматично откриване на промени.  
* Да предоставят на регулаторите ясен, неизменим одитен запис.  

Започнете малко, итеративно напредвайте и нека философията на микросервизните системи ви води към бъдеще, в което съответствието е **функция**, а не пречка.  

---

## Вижте още

- [OPA Policy‑as‑Code за микросервизи](https://www.openpolicyagent.org/docs/latest/policy-language/)