---
title: 'Операционные проблемы и жизненный цикл'
description: 'Operational Issue как единица работы — базовая модель, различие Issue и Task, одиночные и массовые виды, workflow статусов с матрицей переходов и неизменяемый журнал аудита.'
section: 'Operations Center'
weight: 4
related:
- domain-model
- priorities-and-sla
- execution-and-queue
---
import Image from '@/components/docs/Image.astro';
## Operational Issue
`Operational Issue` — центральная сущность OHM.
Это stateful-объект, который представляет эксплуатационную проблему на протяжении всего жизненного цикла.
### Базовая модель
```yaml
id: OHM-2026-001842
kind: single
canon: no_hourly_archive
title: 'Hourly archive is missing'
priority: P1
severity: critical
confidence: 0.94
scope:
organization: 'Demo Gas Utility'
region: 'Tashkent'
asset_id: 'station-5690'
ownership:
zone: backend_integration
assignee: 'Integration-2'
timestamps:
first_detected_at: '2026-07-21T04:00:00Z'
created_at: '2026-07-21T04:03:12Z'
acknowledged_at: '2026-07-21T05:10:00Z'
due_at: '2026-07-22T04:00:00Z'
resolved_at: null
status:
workflow: in_progress
snapshot: persistent
overdue: false
unattended: false
chronic: false
root_cause:
class: communication
hypothesis: 'device does not establish a communication session'
confidence: 0.82
confirmed: false
evidence: []
tasks: []
history: []
related_issues: []
knowledge_articles: []
```
### Issue и Task — разные сущности
Issue отвечает на вопрос:
> Какая эксплуатационная проблема должна быть устранена?
Task отвечает на вопрос:
> Какое конкретное действие необходимо выполнить?
Один Issue может содержать несколько задач. Для Issue _отсутствует архив по 38 устройствам_:
- Task 1 — проверить доступность шлюза;
- Task 2 — проверить серверную очередь;
- Task 3 — сравнить версии прошивки;
- Task 4 — связаться с оператором связи;
- Task 5 — выполнить выборочную полевую проверку.
Закрытие одной задачи не закрывает Issue автоматически.
### Единичные и массовые Issues
OHM использует одну модель для двух масштабов:
| Вид | Описание |
| ---------- | ---------------------------------------------------- |
| `single` | проблема одного актива или одной логической сущности |
| `massive` | системный инцидент, затронувший группу активов |
| `manual` | проблема, зарегистрированная человеком |
| `external` | проблема, импортированная из внешней системы |
## Жизненный цикл Operational Issue
### Основной workflow
```mermaid
flowchart TD
S1["Обнаружен"] --> S2["Проведён триаж"]
S2 --> S3["Назначен"]
S3 --> S4["Принят"]
S4 --> S5["В работе"]
S5 --> S6["Ожидает проверки"]
S6 --> S7["Проверен"]
S7 --> S8["Решён"]
S8 --> S9["В архиве"]
```
Дополнительные завершения:
- отменён;
- дубликат;
- не воспроизведён;
- устранение не планируется;
- риск принят.
### Статусы workflow
| Статус | Значение |
| ----------------------- | ----------------------------------------------------- |
| `detected` | Issue создан автоматически или вручную |
| `triaged` | проверены критичность, зона и первичный контекст |
| `assigned` | определён ответственный исполнитель |
| `accepted` | исполнитель подтвердил принятие |
| `in_progress` | ведутся работы |
| `awaiting_verification` | работа заявлена как выполненная, ожидается проверка |
| `verified` | результат подтверждён |
| `resolved` | Issue закрыт с установленным результатом |
| `archived` | завершённый объект перемещён в долговременную историю |
| `cancelled` | Issue отменён по обоснованной причине |
| `duplicate` | Issue является дубликатом другого объекта |
| `not_reproduced` | проблема не подтверждена при проверке |
| `wont_fix` | принято управленческое решение не устранять |
| `accepted_risk` | риск формально принят уполномоченным лицом |
### Snapshot-статус
Помимо workflow, OHM хранит состояние проблемы по ежедневному детекторному слепку:
| Snapshot status | Значение |
| --------------- | -------------------------------------------- |
| `new` | проблема появилась впервые |
| `persistent` | проблема сохраняется |
| `worsened` | состояние ухудшилось |
| `improved` | состояние улучшилось, но проблема не исчезла |
| `cleared` | детектор больше не подтверждает проблему |
| `reopened` | проблема появилась повторно после закрытия |
Workflow и snapshot status не смешиваются.
Пример: `workflow_status = in_progress` при `snapshot_status = improved`.
Это означает, что работа продолжается, а объективные данные уже показывают улучшение.
### Матрица переходов
| Текущий статус | Допустимые переходы |
| --------------------- | ----------------------------------------------- |
| detected | triaged, assigned, duplicate, cancelled |
| triaged | assigned, cancelled, accepted_risk |
| assigned | accepted, in_progress, reassigned |
| accepted | in_progress, reassigned |
| in_progress | awaiting_verification, escalated, accepted_risk |
| awaiting_verification | verified, in_progress |
| verified | resolved |
| resolved | reopened, archived |
| reopened | triaged, assigned, in_progress |
| любой активный | duplicate, cancelled |
Каждый переход записывается в неизменяемый журнал событий.
## Журнал аудита (Audit Trail)
Все значимые действия записываются в неизменяемую историю.
Событие содержит:
```yaml
event_id: EVT-9038172
issue_id: OHM-2026-001842
event_type: status_changed
timestamp: '2026-07-23T10:14:00Z'
actor:
type: user
id: 'usr-231'
role: 'zone_manager'
before:
status: assigned
after:
status: in_progress
reason: 'Diagnostics started'
source:
ip: 'masked'
client: 'web'
correlation_id: 'req-982310'
```
Обязательно журналируются:
- создание;
- назначение;
- переназначение;
- изменение приоритета;
- изменение срока;
- изменение статуса;
- комментарий;
- добавление Evidence;
- подтверждение root cause;
- ручная верификация;
- принятие риска;
- применение статьи KB;
- объединение и разделение Issues;
- изменение конфигурации детектора;
- экспорт и интеграционные действия.