162 lines
7.5 KiB
Markdown
162 lines
7.5 KiB
Markdown
# Business Risk
|
|
|
|
`Business Risk` - управленческий слой AWatch-rus / DetMir, который показывает
|
|
не просто активность сотрудников, а зоны организационного риска по
|
|
подразделениям.
|
|
|
|
## Назначение
|
|
|
|
Слой предназначен для руководителя и собственника бизнеса. Он отвечает на
|
|
вопросы:
|
|
|
|
- где KPI активности нельзя считать надежным;
|
|
- где активность подразделения снижена;
|
|
- где есть падение тренда;
|
|
- где проблемные рабочие места портят доверие к отчету.
|
|
|
|
Business Risk не является автоматическим обвинением сотрудников или
|
|
подразделений. Это read-only приоритизация управленческой проверки.
|
|
|
|
## API
|
|
|
|
`GET /api/reports` отдает массив `business_risk`.
|
|
|
|
Элемент массива:
|
|
|
|
- `department` - подразделение;
|
|
- `trust_score` - доверие к KPI в процентах;
|
|
- `activity_score` - индекс активности подразделения в процентах;
|
|
- `trend` - `RISING`, `STABLE`, `FALLING` или `UNKNOWN`;
|
|
- `risk_level` - `LOW`, `MEDIUM`, `HIGH` или `CRITICAL`;
|
|
- `reasons` - список человеко-понятных причин риска;
|
|
- `recommendation` - рекомендуемое действие;
|
|
- `problem_nodes_count` - сколько проблемных узлов относится к подразделению;
|
|
- `missing_nodes_count` - сколько ожидаемых узлов не прислали telemetry;
|
|
- `stale_nodes_count` - сколько узлов присылали telemetry, но данные устарели.
|
|
|
|
Также `GET /api/reports` отдает историю:
|
|
|
|
- `business_risk_history` - timeline риска по подразделениям;
|
|
- `business_risk_history_summary` - сводка динамики.
|
|
- `risk_incident_candidates` - read-only кандидаты для ручной проверки.
|
|
|
|
Элемент `business_risk_history`:
|
|
|
|
- `date` - дата daily point;
|
|
- `department` - подразделение;
|
|
- `risk_level` - `LOW`, `MEDIUM`, `HIGH` или `CRITICAL`;
|
|
- `trust_score` - доверие к KPI на момент расчета;
|
|
- `activity_score` - активность подразделения;
|
|
- `reasons` - причины риска для этой точки.
|
|
|
|
`business_risk_history_summary`:
|
|
|
|
- `departments_worsened` - сколько подразделений ухудшили риск;
|
|
- `departments_improved` - сколько подразделений улучшили риск;
|
|
- `stable_high_risk` - сколько подразделений 3+ дня остаются в `HIGH`/`CRITICAL`;
|
|
- `new_high_risk` - сколько подразделений впервые вошли в `HIGH`/`CRITICAL`.
|
|
|
|
Элемент `risk_incident_candidates`:
|
|
|
|
- `id` - стабильный идентификатор кандидата;
|
|
- `department` - подразделение, если известно;
|
|
- `owner` - ответственный, если известен;
|
|
- `hostname` - рабочее место, если кандидат связан с узлом;
|
|
- `risk_level` - ориентировочный уровень риска;
|
|
- `reason` - причина постановки в очередь проверки;
|
|
- `evidence` - технические признаки, на которых основан кандидат;
|
|
- `first_seen_utc` - первое наблюдение;
|
|
- `last_seen_utc` - последнее наблюдение;
|
|
- `recommendation` - рекомендуемое действие.
|
|
|
|
## Логика риска
|
|
|
|
На риск влияют:
|
|
|
|
- низкий `trust_score`;
|
|
- низкий `activity_score`;
|
|
- падающий тренд активности;
|
|
- отсутствие телеметрии;
|
|
- наличие проблемных узлов в SLA покрытия агентов.
|
|
|
|
`local_fallback` не считается подтвержденным KPI. Если телеметрия свежая, но
|
|
пришла из диагностического fallback-источника, она может подтверждать факт
|
|
наличия агента, но снижает доверие к KPI и повышает бизнес-риск.
|
|
|
|
Типовые причины:
|
|
|
|
- `низкий Trust KPI`;
|
|
- `низкая активность`;
|
|
- `падающий тренд`;
|
|
- `нет свежей телеметрии`;
|
|
- `много проблемных узлов`.
|
|
|
|
## UI
|
|
|
|
В портале отображается карточка `Риски подразделений`.
|
|
|
|
Показывается ТОП-10 подразделений с максимальным риском:
|
|
|
|
- подразделение;
|
|
- уровень риска;
|
|
- причины;
|
|
- рекомендация.
|
|
|
|
Карточка `Динамика рисков` показывает:
|
|
|
|
- ухудшившиеся подразделения;
|
|
- улучшившиеся подразделения;
|
|
- стабильный высокий риск;
|
|
- новый высокий риск;
|
|
- последние точки timeline с причинами.
|
|
|
|
Карточка `Кандидаты в инциденты` показывает TOP-10 записей для ручной
|
|
проверки. Это не автоматическое создание инцидента и не подтвержденное
|
|
нарушение.
|
|
|
|
## Markdown
|
|
|
|
Оперативный отчет содержит раздел:
|
|
|
|
```text
|
|
## Риски подразделений
|
|
## Динамика бизнес-рисков
|
|
## Кандидаты в инциденты
|
|
```
|
|
|
|
Раздел можно использовать в PDF/Markdown-отчете для руководителя.
|
|
|
|
## Executive Summary
|
|
|
|
Executive summary показывает до 3 наиболее рискованных подразделений, если
|
|
их уровень риска выше `LOW`.
|
|
|
|
Формат:
|
|
|
|
```text
|
|
Подразделение Бухгалтерия: HIGH — причина: низкий Trust KPI
|
|
```
|
|
|
|
Если подразделение 3+ дня подряд находится в `HIGH` или `CRITICAL`,
|
|
добавляется отдельный вывод:
|
|
|
|
```text
|
|
Подразделение Бухгалтерия сохраняет высокий риск несколько дней подряд.
|
|
```
|
|
|
|
Также выводятся до 3 кандидатов в инциденты:
|
|
|
|
```text
|
|
Кандидат в инцидент risk-candidate-...: HIGH — KPI не принят
|
|
```
|
|
|
|
## Ограничения
|
|
|
|
- Это proxy-модель управленческого риска, а не юридическое заключение.
|
|
- Для точной интерпретации нужны корректные expected nodes, стабильная
|
|
telemetry и актуальные department rollups.
|
|
- Если данных по подразделению нет, риск может повышаться из-за недостаточной
|
|
доказательной базы, а не из-за фактической работы сотрудников.
|
|
- `risk_incident_candidates` - только очередь `review required`; реальные
|
|
инциденты создаются отдельно ответственным сотрудником.
|