AWatch-rus/docs/BUSINESS_RISK_RU.md

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

Оперативный отчет содержит раздел:

## Риски подразделений
## Динамика бизнес-рисков
## Кандидаты в инциденты

Раздел можно использовать в PDF/Markdown-отчете для руководителя.

Executive Summary

Executive summary показывает до 3 наиболее рискованных подразделений, если их уровень риска выше LOW.

Формат:

Подразделение Бухгалтерия: HIGH — причина: низкий Trust KPI

Если подразделение 3+ дня подряд находится в HIGH или CRITICAL, добавляется отдельный вывод:

Подразделение Бухгалтерия сохраняет высокий риск несколько дней подряд.

Также выводятся до 3 кандидатов в инциденты:

Кандидат в инцидент risk-candidate-...: HIGH — KPI не принят

Ограничения

• Это proxy-модель управленческого риска, а не юридическое заключение.
• Для точной интерпретации нужны корректные expected nodes, стабильная telemetry и актуальные department rollups.
• Если данных по подразделению нет, риск может повышаться из-за недостаточной доказательной базы, а не из-за фактической работы сотрудников.
• risk_incident_candidates - только очередь review required; реальные инциденты создаются отдельно ответственным сотрудником.