---
title: 'Операционная доменная модель'
description: 'Сущности, связи, владение и правила жизненного цикла операционной доменной модели, на которой строятся все проблемы, задачи и показатели здоровья.'
section: 'Operations Center'
weight: 3
related:
  - operational-issues
  - detectors-and-canons
---

## Операционная доменная модель

Operational Health Matrix строится на единой операционной доменной модели, которая определяет ключевые сущности, связи и зоны ответственности в масштабах всей IIoT Платформы.

Каждый процесс, детектор, API-эндпоинт и аналитический компонент работает с одной и той же доменной моделью, что обеспечивает согласованность во всей системе.

Доменная модель устраняет неоднозначность, минимизирует дублирование данных и даёт общий операционный язык всем компонентам платформы.

### Основные сущности

Домен Operational Health Matrix состоит из следующих основных сущностей:

- Asset
- Detector
- Evidence
- Operational Issue
- Task
- Root Cause
- Health
- Knowledge Article
- Massive Incident
- SLA Policy
- Team
- User
- Notification
- Attachment
- Comment
- Audit Record

Каждая сущность владеет собственным жизненным циклом и участвует в одном или нескольких операционных рабочих процессах.

### Asset (актив)

Asset — центральная сущность платформы.

Каждый наблюдаемый физический или логический объект представлен как Asset.

Типичные примеры:

- счётчик газа
- датчик давления
- корректор
- RTU
- шлюз
- контроллер клапана
- телеметрический блок
- устройство связи
- программный компонент

Каждый Asset содержит:

- уникальный идентификатор;
- тип;
- модель;
- производителя;
- серийный номер;
- владельца;
- регион эксплуатации;
- конфигурацию;
- версию прошивки;
- коммуникационный профиль;
- состояние жизненного цикла.

### Detector (детектор)

Detector — аналитический компонент, отвечающий за преобразование телеметрии в операционные наблюдения.

Detector не создаёт бизнес-логику.

Его ответственность ограничена выявлением наблюдаемых паттернов и формированием доказательств.

Атрибуты Detector включают:

- Identifier
- Version
- Canon
- Confidence
- Status
- Accuracy Metrics
- Health

### Evidence (доказательство)

Evidence представляет собой неизменяемое доказательство, подтверждающее операционный вывод.

Источниками Evidence могут быть:

- телеметрия;
- журналы связи;
- записи аудита;
- подтверждение пользователя;
- загруженные фотографии;
- системная диагностика;
- внешние системы.

Evidence не может быть изменено после создания.

Если требуется исправление, создаётся новый объект Evidence, а предыдущая версия сохраняется.

### Operational Issue (операционная проблема)

Operational Issue представляет подтверждённую эксплуатационную проблему, требующую расследования или устранения.

Каждый Operational Issue содержит:

- Canon;
- Severity;
- Priority;
- Status;
- Owner;
- Root Cause;
- SLA Policy;
- Verification State;
- Operational History.

Operational Issue — главный операционный объект платформы.

### Task (задача)

Task представляет исполняемое действие, необходимое для устранения Operational Issue.

Задачи не могут существовать самостоятельно.

Каждый Task принадлежит ровно одному Operational Issue.

Один Operational Issue может содержать несколько задач.

### Root Cause (первопричина)

Root Cause представляет подтверждённую первопричину одного или нескольких Operational Issues.

Несколько Operational Issues могут ссылаться на одну и ту же Root Cause.

Эта связь обеспечивает эксплуатационную аналитику в масштабах предприятия и выявление повторяющихся проблем.

### Health (здоровье)

Health — вычисляемый операционный показатель.

Health существует для:

- актива;
- площадки;
- региона;
- организации;
- всей экосистемы.

Значения Health всегда рассчитываются автоматически.

### Knowledge Article (статья базы знаний)

Knowledge Article хранит проверенный эксплуатационный опыт.

Каждая статья может ссылаться на:

- канонические проблемы;
- корневые причины;
- типы активов;
- версии прошивки;
- эксплуатационные процедуры;
- документацию производителя.

### Massive Incident (массовый инцидент)

Massive Incident группирует несколько Operational Issues, возникших из общего эксплуатационного события.

Он предоставляет единый объект управления для масштабных инфраструктурных инцидентов.

## Операционные принципы

Operational Health Matrix следует нескольким архитектурным принципам, которые определяют поведение каждой подсистемы.

### Актив прежде всего (Asset First)

Каждое эксплуатационное событие связывается с Asset.

Активы остаются первичными объектами на протяжении всего жизненного цикла.

### Управление через Issues

Эксплуатация управляется через Operational Issues, а не через отдельные тревоги или события телеметрии.

### Решения на основе доказательств

Каждый операционный вывод должен быть подтверждён одним или несколькими объектами Evidence.

Неподтверждённые предположения никогда не рассматриваются как установленные факты.

### Сначала первопричина, затем устранение

Корректирующие действия по возможности направлены на подтверждённые причины, а не на наблюдаемые симптомы.

### Человек в контуре (Human-in-the-Loop)

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

Критические действия требуют явного подтверждения человеком.

### Объяснимая аналитика

Аналитические выводы остаются прозрачными.

Каждая рекомендация включает подтверждающие доказательства и сведения об уровне уверенности.

### Неизменяемый аудит

Операционная история не может быть переписана.

Каждое изменение порождает новую запись аудита.

### API-first подход

Каждая возможность платформы доступна через документированные API.

Пользовательские интерфейсы и внешние интеграции опираются на одни и те же операционные сервисы.

### Событийно-ориентированная архитектура

Операционные изменения распространяются в виде событий.

Это делает возможными асинхронные интеграции и масштабируемые конвейеры обработки.

## Операционная модель данных

Платформа следует единой операционной модели данных.

```mermaid
flowchart TD
    A["Asset"] --> DET["Detector"]
    A --> EV["Evidence"]
    A --> ISSUE["Operational Issue"]
    ISSUE --> TASK["Task"]
    ISSUE --> RC["Root Cause"]
    ISSUE --> SLA["SLA Policy"]
    ISSUE --> CMT["Comment"]
    ISSUE --> ATT["Attachment"]
    A --> HLT["Health"]
    A --> KB["Knowledge Articles"]
```

### Владение

Каждая сущность имеет ровно одного владельца жизненного цикла.

| Сущность          | Владелец жизненного цикла      |
| ----------------- | ------------------------------ |
| Asset             | Реестр активов                 |
| Detector          | Аналитика                      |
| Evidence          | Сбор данных                    |
| Operational Issue | Эксплуатация                   |
| Task              | Эксплуатация                   |
| Health            | Аналитика                      |
| Knowledge Article | Совершенствование эксплуатации |
| Massive Incident  | Эксплуатация                   |

### Правила жизненного цикла

Доменная модель соблюдает несколько инвариантов:

- Активы никогда не удаляются, пока существуют исторические Operational Issues.
- Evidence неизменяемо.
- Задачи не могут существовать без Operational Issue.
- Root Causes могут быть общими для нескольких Issues.
- Значения Health вычисляются и не могут быть отредактированы вручную.
- Audit Records ведутся в режиме append-only.
- Knowledge Articles остаются версионируемыми на протяжении всего жизненного цикла.

Эти ограничения обеспечивают согласованность, прослеживаемость и воспроизводимость во всей платформе Operational Health Matrix.