Unified Availability Model (UAM). Методика расчёта доступности разнородных ИТ-систем

Введение

Современные ИТ-ландшафты представляют собой разнородные и многослойные системы, ключающие (но не ограничиваясь) следующими категориями:

• API-сервисы и микросервисы,

• платёжные шлюзы,

• банковские интеграции,

• криптографические и HSM-сервисы,

• batch-процессы и ETL,

• ERP-системы (например, 1C:ERP, SAP S/4HANA, Oracle EBS),

• системы формирования отчетности.

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

Однако возможно создать единый методический подход, при котором:

• каждая система оценивается по своим собственным метрикам,

• метрики нормализуются к единой шкале,

• итоговая доступность рассчитывается как взвешенная сумма.

Такой подход позволяет:

• корректно сравнивать разные системы,

• строить интегральный показатель доступности контура,

• унифицировать отчётность и мониторинг,

• легко расширять модель под новые классы систем.

Основные определения

Доступность системы

Доступность системы \(A_i\) — это нормализованная оценка состояния системы на интервале наблюдения, принимающая значение от 0 до 1 или в процентах от 0 до 100.

Метрика

Метрика \(M_{ij}\) — количественный показатель, характеризующий состояние системы \(i\) по параметру \(j\).

Нормализация

Нормализация — преобразование метрики \(M_{ij}\) в значение \(N_{ij} \in [0,1]\) по правилам, заданным для категории системы.

Вес метрики

\(w_{ij}\) — весовой коэффициент, определяющий вклад метрики \(j\) в итоговую доступность системы \(i\), при этом: \[\sum_j w_{ij} = 1.\]

Доступность контура

Доступность контура \(A_{\text{contour}}\) — взвешенная сумма доступностей систем, входящих в цепочку бизнес-процесса.

Общая модель Unified Availability Model

Каждая система \(S_i\) имеет набор метрик: \[\{M_{i1}, M_{i2}, \dots, M_{ik}\}.\]

Каждая метрика нормализуется: \[N_{ij} = f_{norm}(M_{ij}),\] где \(N_{ij} \in [0,1]\).

Каждая нормализованная метрика имеет вес \(w_{ij}\).

Формула доступности системы

\[A_i = \sum_{j=1}^{k} w_{ij} \cdot N_{ij}.\]

Итоговое значение \(A_i\) выражается либо в \([0,1]\), либо в процентах.

Формула доступности контура

Пусть контур состоит из \(n\) систем. Тогда:

\[A_{\text{contour}} = \sum_{i=1}^{n} W_i \cdot A_i,\] где \(W_i\) — вес системы в контуре, \(\sum_i W_i = 1\).

Нормализация метрик

В модели Unified Availability Model (UAM) каждая метрика \(M_{ij}\) нормализуется к значению \(N_{ij} \in [0,1]\). Нормализация основана на четырёх фундаментальных концепциях:

1. стабильный baseline,

2. пороги SLA,

3. известные физические границы,

4. допустимые отклонения.

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

Стабильный baseline

Определение. Стабильный baseline метрики \(M\) — статистически устойчивая характеристика типичного поведения системы при отсутствии аномалий.

Baseline отражает «нормальный» режим работы и используется как точка отсчёта для выявления деградаций. Он определяется по историческим данным.

Правила нормализации.

Пусть \(B\) — baseline, вычисленный одним из статистических методов:

• медиана: \(B = \mathrm{median}(M_{\mathrm{hist}})\),

• квантиль \(p75\): \(B = \mathrm{quantile}_{0.75}\),

• экспоненциальное сглаживание: \(B = \mathrm{EWMA}(M_{\mathrm{hist}})\),

• сезонные baseline (по часам, дням недели).

Пусть \(k\) — коэффициент допуска (обычно \(1.5\)–\(2\)). Тогда:

\[\begin{equation} N_{\text{baseline}}(M) = \begin{cases} 1, & M \le kB, \\[6pt] \frac{kB}{M}, & M > kB. \end{cases} \end{equation}\]

Пороги SLA

Определение. SLA — нормативное значение метрики, определяющее границу между «допустимым» и «недопустимым» качеством работы сервиса.

Правила нормализации.

Формально SLA задаётся условиями:

\[M \le SLA \quad \text{(для latency)}, \qquad M \ge SLA \quad \text{(для success rate)}.\]

\[\begin{equation} N_{\text{SLA}}(M) = \begin{cases} 1, & M \text{ не нарушает SLA}, \\[6pt] 1 - \alpha (M - SLA), & M \text{ нарушает SLA}, \end{cases} \end{equation}\]

где \(\alpha\) — штрафной коэффициент.

Известные физические границы

Определение. Физические границы — ограничения аппаратного и архитектурного характера, не зависящие от SLA.

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

• пропускная способность канала,

• максимальное число соединений в пуле,

• лимит CPU или IO,

• архитектурный предел RPS.

Правила нормализации.

Пусть диапазон физических границ:

\[M_{\min}^{\mathrm{phys}} \le M \le M_{\max}^{\mathrm{phys}}.\]

Тогда:

\[\begin{equation} N_{\text{phys}}(M) = \frac{M_{\max}^{\mathrm{phys}} - M} {M_{\max}^{\mathrm{phys}} - M_{\min}^{\mathrm{phys}}}. \end{equation}\]

Допустимые отклонения

Определение. Допустимые отклонения — диапазон значений метрики, в пределах которого небольшие колебания не считаются деградацией.

\[D_{\min} \le M \le D_{\max}.\]

Правила нормализации.

\[\begin{equation} N_{\text{dev}}(M) = \begin{cases} 1, & D_{\min} \le M \le D_{\max}, \\[6pt] 1 - \beta (M - D_{\max}), & M > D_{\max}, \\[6pt] 1 - \beta (D_{\min} - M), & M < D_{\min}, \end{cases} \end{equation}\]

где \(\beta\) — коэффициент штрафа.

Итоговая нормализация

Для каждой метрики итоговая нормализация определяется композицией подходов:

\[\begin{equation} N(M) = w_b N_{\text{baseline}}(M) + w_s N_{\text{SLA}}(M) + w_p N_{\text{phys}}(M) + w_d N_{\text{dev}}(M), \end{equation}\]

где \(w_b + w_s + w_p + w_d = 1\).

Типовые стратегии нормализации

Линейная нормализация

\[N = 1 - \frac{M - M_{\min}}{M_{\max} - M_{\min}}.\]

Нормализация по SLA

\[N = \begin{cases} 1, & M \leq SLA, \\ 1 - k (M - SLA), & M > SLA. \end{cases}\]

Нормализация с saturating-функцией

\[N = e^{-\alpha M}.\]

Пример нормализации latency

В качестве примера рассмотрим нормализацию метрики задержки. \[N_{\text{latency}} = \begin{cases} 1, & L \leq L_{\text{baseline}},\\ \frac{L_{\text{max}} - L}{L_{\text{max}} - L_{\text{baseline}}}, & L > L_{\text{baseline}}. \end{cases}\]

Примеры применения нормализации для различных типов систем

Ниже приведены примеры операционализации нормализации метрик для четырёх критически различных классов систем: API-сервисы, криптосервисы, batch-процессы и ERP/Oracle EBS. Эти примеры демонстрируют, каким образом понятия baseline, SLA, физических границ и допустимых отклонений применяются к реальным метрикам наблюдаемости.

API-сервисы и платёжные шлюзы

Для API-сервисов основными метриками являются:

• \(M_1\): latency \(p99\);

• \(M_2\): success rate;

• \(M_3\): доля 5xx ошибок;

• \(M_4\): глубина очередей или backlog.

Пример baseline: \[B_{latency} = \mathrm{median}(L_{\mathrm{hist}}) = 85\ \mathrm{ms}.\]

Пример SLA: \[\mathrm{latency}_{p99} \le 300\ \mathrm{ms}.\]

Пример физического предела: \[L_{\max}^{\mathrm{phys}} = 2000\ \mathrm{ms} \quad (\text{лимит таймаута ядра Nginx}).\]

Допустимое отклонение: \[D_{\max} = 2.0 \cdot B_{latency}.\]

Тогда нормализация latency: \[N_{\text{API-lat}} = \begin{cases} 1, & L \le 2B_{latency},\\ \frac{2B_{latency}}{L}, & L > 2B_{latency}. \end{cases}\]

Криптографические сервисы (HSM, подпись)

Характерные метрики:

• \(M_1\): доступность HSM (онлайн/офлайн);

• \(M_2\): время подписи документа;

• \(M_3\): доля отказов подписи;

• \(M_4\): доступность слотов ключей.

Пример baseline времени подписи: \[B_{\mathrm{sign}} = \mathrm{median}(T_{\mathrm{sign}}) = 42\ \mathrm{ms}.\]

SLA: \[T_{\mathrm{sign}} \le 150\ \mathrm{ms}.\]

Физические границы: \[T_{\min}^{\mathrm{phys}} = 15\ \mathrm{ms}, \quad T_{\max}^{\mathrm{phys}} = 500\ \mathrm{ms}.\]

Допустимое отклонение: \[D_{\max} = 1.5 \cdot B_{\mathrm{sign}}.\]

Нормализация: \[N_{\mathrm{sign}} = \begin{cases} 1, & T \le D_{\max},\\[6pt] 1 - 0.01 (T - D_{\max}), & T > D_{\max}. \end{cases}\]

Batch-процессы, пачки и отчёты

Характерные метрики:

• \(M_1\): длительность выполнения job;

• \(M_2\): завершение в окно;

• \(M_3\): ошибки исполнения;

• \(M_4\): backlog и накопления в очередях.

Пример baseline: \[B_{\mathrm{job}} = \mathrm{median}(t_{\mathrm{job, hist}}) = 17\ \mathrm{min}.\]

SLA: \[t_{\mathrm{job}} \le 30\ \mathrm{min}.\]

Физический предел: \[t_{\max}^{\mathrm{phys}} = 120\ \mathrm{min} \quad (\text{переполнение batch-окна}).\]

Допустимое отклонение: \[D_{\max} = 1.2 \cdot B_{\mathrm{job}}.\]

Нормализация длительности job: \[N_{\mathrm{batch}} = \begin{cases} 1, & t \le D_{\max},\\[6pt] \frac{D_{\max}}{t}, & t > D_{\max}. \end{cases}\]

ERP / 1C:ERP

Критические метрики:

• \(M_1\): среднее время выполнения запросов в кластере 1С;

• \(M_2\): загрузка рабочих процессов (RPH, количество активных процессов);

• \(M_3\): очередь запросов на сервере 1С (request queue);

• \(M_4\): задержки на уровне СУБД (чаще всего PostgreSQL, MS SQL или Oracle).

Пример baseline времени выполнения запроса: \[B_{\mathrm{1C}} = \mathrm{median}(T_{\mathrm{request}}) = 35\ \mathrm{ms}.\]

SLA: \[T_{\mathrm{request}} \le 150\ \mathrm{ms}.\]

Физические пределы: \[T_{\min}^{\mathrm{phys}} = 10\ \mathrm{ms}, \quad T_{\max}^{\mathrm{phys}} = 800\ \mathrm{ms}.\]

Допустимое отклонение: \[D_{\max} = 2.5 \cdot B_{\mathrm{1C}}.\]

Нормализация: \[N_{\mathrm{1C}} = \begin{cases} 1, & T \le D_{\max}, \\[6pt] 1 - 0.003\,(T - D_{\max}), & T > D_{\max}. \end{cases}\]

ERP / SAP S/4HANA

Критические метрики:

• \(M_1\): SAP Dialog Response Time (включая DB Time, CPU Time, Wait Time);

• \(M_2\): Work Process Utilization (DIA, BTC, UPD, SPO);

• \(M_3\): Queue Length (SM50/SM66);

• \(M_4\): HANA DB latency и блокировки (Lock Wait Time).

Пример baseline времени отклика диалоговой операции: \[B_{\mathrm{SAP}} = \mathrm{median}(T_{\mathrm{dialog}}) = 280\ \mathrm{ms}.\]

SLA (стандарт SAP): \[T_{\mathrm{dialog}} \le 1000\ \mathrm{ms}.\]

Физические пределы (архитектурные): \[T_{\min}^{\mathrm{phys}} = 50\ \mathrm{ms}, \qquad T_{\max}^{\mathrm{phys}} = 5000\ \mathrm{ms}.\]

Допустимое отклонение: \[D_{\max} = 2.0 \cdot B_{\mathrm{SAP}}.\]

Нормализация: \[N_{\mathrm{SAP}} = \begin{cases} 1, & T \le D_{\max}, \\[6pt] 1 - 0.0005\,(T - D_{\max}), & T > D_{\max}. \end{cases}\]

ERP / Oracle EBS

Критические метрики:

• \(M_1\): ожидания в БД (TX, TM, enq:…);

• \(M_2\): активные Concurrent Managers;

• \(M_3\): глубина workflow-lag;

• \(M_4\): загрузка session pool.

Пример baseline: \[B_{\mathrm{TX}} = \mathrm{median}(\mathrm{wait\_TX}) = 8\ \mathrm{ms}.\]

SLA: \[\mathrm{wait\_TX} \le 40\ \mathrm{ms}.\]

Физический предел: \[\mathrm{wait\_TX}^{\max} = 500\ \mathrm{ms}.\]

Допустимое отклонение: \[D_{\max} = 3 \cdot B_{\mathrm{TX}}.\]

Нормализация: \[N_{\mathrm{EBS}} = \begin{cases} 1, & W_{\mathrm{TX}} \le D_{\max}, \\[6pt] 1 - 0.005(W_{\mathrm{TX}} - D_{\max}), & W_{\mathrm{TX}} > D_{\max}. \end{cases}\]

SAP IDoc / EDI интеграции

Критические метрики:

• \(M_1\): время обработки IDoc (end-to-end latency);

• \(M_2\): доля IDoc в статусах ошибки (status 51/68);

• \(M_3\): очередь IDoc-обработки (Inbound Queue / Outbound Queue);

• \(M_4\): блокировки объектов (Lock Conflicts) при обработке IDoc.

Пример baseline времени обработки: \[B_{\mathrm{IDoc}} = \mathrm{median}(T_{\mathrm{idoc}}) = 1.8\ \mathrm{s}.\]

SLA (типичное для B2B/EDI потоков): \[T_{\mathrm{idoc}} \le 5\ \mathrm{s}.\]

Физические пределы (архитектурные ограничения): \[T_{\min}^{\mathrm{phys}} = 0.5\ \mathrm{s}, \qquad T_{\max}^{\mathrm{phys}} = 30\ \mathrm{s}.\]

Допустимое отклонение: \[D_{\max} = 2.0 \cdot B_{\mathrm{IDoc}}.\]

Нормализация: \[N_{\mathrm{IDoc}} = \begin{cases} 1, & T \le D_{\max}, \\[6pt] 1 - 0.02\,(T - D_{\max}), & T > D_{\max}. \end{cases}\]

Сравнительная таблица нормализационных подходов

Сравнение подходов нормализации в UAM

Параметр	Baseline	SLA	Физические границы / Допустимые отклонения
Источник значения	Исторические данные (эмпирика)	Норматив / обязательство	Архитектурные/аппаратные ограничения
Тип контроля	Выявление деградаций	Бинарная проверка “нормы”	Контроль устойчивости и пределов ресурса
Ориентация	Поведение системы	Обязательства перед клиентом	Физические и операционные пределы
Пример для API	p50/p75 latency = baseline	latency\(_{p99} \le 300\) ms	Nginx timeout = 2000 ms
Пример для batch	median job = baseline	job \(\le\) SLA window	max job \(=\) 120 min
Пример для EBS	median TX wait	TX wait \(\le\) SLA	session pool = [0, 300]
Роль в UAM	Основа нормализации деградаций	Жёсткие штрафы за нарушение	Плавная штрафная зона перед отказом

Типы систем и рекомендуемые метрики

Ниже приведены рекомендуемые метрики и веса для различных категорий систем. Значения являются шаблоном и адаптируются под конкретный ландшафт.

API-сервисы и платёжные шлюзы

Метрика	Обозначение	Вес \(w_j\)
Success Rate	\(N_{\text{succ}}\)	0.40
Latency \(p99\)	\(N_{\text{lat}}\)	0.30
5xx Ratio	\(N_{\text{err}}\)	0.20
Очереди / backlog	\(N_{\text{queue}}\)	0.10

\[A_{\text{API}} = 0.4 N_{\text{succ}} + 0.3 N_{\text{lat}} + 0.2 N_{\text{err}} + 0.1 N_{\text{queue}}.\]

Банковские API

Метрика	Обозначение	Вес
Success Rate	\(N_{\text{succ}}\)	0.50
Timeout Ratio	\(N_{\text{timeout}}\)	0.20
Connection Failures	\(N_{\text{conn}}\)	0.20
Backlog / Queue	\(N_{\text{queue}}\)	0.10

Криптографические сервисы

Метрика	Обозначение	Вес
HSM Online	\(N_{\text{hsm}}\)	0.40
Success Rate	\(N_{\text{succ}}\)	0.30
Signing Time	\(N_{\text{sign}}\)	0.20
Slot Availability	\(N_{\text{slot}}\)	0.10

Batch-процессы

Метрика	Обозначение	Вес
Завершено в окно	\(N_{\text{deadline}}\)	0.60
Ошибки job	\(N_{\text{error}}\)	0.20
Backlog	\(N_{\text{queue}}\)	0.20

ERP / 1C:ERP

Метрика	Обозначение	Вес
Время выполнения запросов	\(N_{\text{req}}\)	0.40
Загрузка рабочих процессов (RPH)	\(N_{\text{rph}}\)	0.25
Очередь запросов	\(N_{\text{queue}}\)	0.20
DB Latency / Blocking	\(N_{\text{db}}\)	0.15

ERP / SAP S/4HANA

Метрика	Обозначение	Вес
Dialog Response Time	\(N_{\text{dialog}}\)	0.40
Work Process Utilization	\(N_{\text{wp}}\)	0.25
Queue Length (SM50/SM66)	\(N_{\text{queue}}\)	0.20
HANA DB Latency / Locks	\(N_{\text{hana}}\)	0.15

ERP / Oracle EBS

Метрика	Обозначение	Вес
Active Concurrent Managers	\(N_{\text{cm}}\)	0.35
DB Wait Events	\(N_{\text{dbwait}}\)	0.25
Session Pool Usage	\(N_{\text{sess}}\)	0.20
Workflow Lag	\(N_{\text{wf}}\)	0.20

SAP IDoc / EDI Интеграции

Метрика	Обозначение	Вес
Время обработки IDoc (latency)	\(N_{\text{idoc}}\)	0.45
Ошибка обработки (status 51/68)	\(N_{\text{err}}\)	0.30
Размер очереди IDoc	\(N_{\text{queue}}\)	0.15
Lock Conflicts / DB Blocking	\(N_{\text{lock}}\)	0.10

Доступность контура

Определение контура

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

Контур обладает следующими свойствами:

• функциональная цельность — все его части обеспечивают одну бизнес-функцию;

• логическая последовательность — элементы контура вызываются или используются в определённом порядке;

• техническая взаимозависимость — отказ одной системы приводит к снижению доступности всего контура;

• измеримость — доступность каждого компонента можно выразить числом \(A_i \in [0,1]\).

Таким образом, контур — это не инфраструктура и не архитектура как таковая, а бизнес-ориентированная цепочка зависимостей.

Состав контура

Каждый контур включает три слоя:

1. Front-системы (front-line):

   • API, веб-методы, интеграционные шлюзы,

   • мобильные или офисные интерфейсы,

   • внешние REST/gRPC сервисы.

2. Логические сервисы (mid-layer):

   • CRM/ERP-модули,

   • банковские API, плательщики, биллинговые узлы,

   • криптографические сервисы (подпись, шифрование),

   • workflow и очереди сообщений.

3. Фоновые процессы (back-office):

   • batch-процессы,

   • отчётность,

   • периодические расчёты,

   • системные транзакции ERP.

Каждый компонент контура имеет собственную доступность \(A_i\), вычисляемую в соответствии с правилами UAM.

Весовой коэффициент системы в контуре

Каждая система имеет вес \(W_i\) — коэффициент её влияния на итоговую работу контура. Он определяется на основании:

• Критичности компонента (может ли контур функционировать без него);

• Временной зависимости (участвует ли система в онлайн-части или в итоговых расчётах);

• Частоты использования (сколько запросов или транзакций проходит через систему);

• Глубины в цепочке (расположена ближе к клиенту или глубже в ядре);

• Степени связности (сколько других подсистем завязано на неё).

Формально: \[\sum_{i=1}^{n} W_i = 1, \qquad W_i \ge 0.\]

Это обеспечивает корректность интерпретации \(A_{\text{contour}}\) как доступности целого бизнес-процесса.

Формула доступности контура

\[A_{\text{contour}} = \sum_{i=1}^{n} W_i A_i,\]

где:

• \(A_i\) — доступность подсистемы (нормализованная в UAM),

• \(W_i\) — вес подсистемы в данном контуре.

Пример структуры контура

Рассмотрим контур проведения платежа:

• Платёжный шлюз — 0.25

• Банковское API — 0.25

• Подписание документов (HSM) — 0.15

• Batch/отчёты (формирование выписок) — 0.20

• ERP (Oracle EBS / SAP / 1C) — 0.15

Тогда доступность контура:

\[A_{\text{pay}} = 0.25 A_{\text{gateway}} + 0.25 A_{\text{bankAPI}} + 0.15 A_{\text{sign}} + 0.20 A_{\text{batch}} + 0.15 A_{\text{ERP}}.\]

Почему доступность контура важнее доступности отдельных систем

В реальных бизнес-процессах:

• клиенту всё равно, что ERP доступно на 99.99%, если банковское API работает на 80%;

• отказ даже одной неключевой системы (batch) влияет на entire chain;

• наличие весов позволяет реалистично учитывать вклад каждого компонента;

• \(A_{\text{contour}}\) даёт руководству показатель, связанный с бизнес-ценностью, а не технической.

Таким образом, контур является основным уровнем агрегирования доступности в Unified Availability Model.

Сквозной пример расчёта доступности контура

В данном разделе представлен синтетический, но реалистичный пример применения Unified Availability Model (UAM) к бизнес-процессу, состоящему из трёх гетерогенных систем:

• Web–сайт (frontend + backend),

• Банк–клиент API (REST шлюз банка),

• ERP–система 1C (учёт и обмен документами).

Такой контур типичен для сценариев, где пользователь формирует документ или платёж на сайте, затем веб-сервис взаимодействует с банковским API, а итоговые данные поступают в 1C для последующей обработки.

Метрики подсистем

Web–сайт

Метрики Web–сайта

Метрика	Обозначение	Вес
Success Rate	\(N_{\text{succ}}\)	0.40
Latency \(p95\)	\(N_{\text{lat}}\)	0.30
5xx Errors	\(N_{\text{err}}\)	0.20
DB/Cache backlog	\(N_{\text{backlog}}\)	0.10

Фактические значения: \[\mathrm{succ}=98.2\%,\quad p95=420\,\mathrm{ms},\quad 5xx=1.8\%,\quad \mathrm{backlog}=250.\]

Baseline / SLA: \[B_{\text{lat}}=210\ \mathrm{ms},\quad SLA=350\ \mathrm{ms},\quad L_{\max}=2000\ \mathrm{ms},\quad D_{\max}=1.8\,B_{\text{lat}}=380.\]

Нормализация: \[N_{\text{succ}}=0.82,\qquad N_{\text{lat}}=\frac{380}{420}=0.90,\] \[N_{\text{err}}\approx 0.60,\qquad N_{\text{backlog}}=0.75.\]

Итоговая доступность Web: \[A_{\text{web}} = 0.40\cdot0.82 + 0.30\cdot0.90 + 0.20\cdot0.60 + 0.10\cdot0.75 = 0.79.\]

Банк–клиент API

Метрики банк–клиент API

Метрика	Обозначение	Вес
Success Rate	\(N_{\text{succ}}\)	0.50
Timeout Ratio	\(N_{\text{timeout}}\)	0.20
Connection Failures	\(N_{\text{conn}}\)	0.20
Queue / Backpressure	\(N_{\text{queue}}\)	0.10

Фактические значения: \[\mathrm{succ}=99.1\%,\quad \mathrm{timeout}=0.7\%,\quad \mathrm{connfail}=0.3\%,\quad \mathrm{queue}=120.\]

Baseline / SLA: \[B_{\text{succ}}=99.6\%,\quad SLA_{\text{succ}}=99\%,\quad SLA_{\text{timeout}}=1.0\%.\]

Нормализация (укороченная): \[N_{\text{succ}} = 0.93,\qquad N_{\text{timeout}} = 1,\qquad N_{\text{conn}} = 0.92,\qquad N_{\text{queue}} = 0.85.\]

Доступность API: \[A_{\text{api}}= 0.5\cdot0.93 + 0.2\cdot1 + 0.2\cdot0.92 + 0.1\cdot0.85 = 0.93.\]

1C ERP

Метрики 1C ERP

Метрика	Обозначение	Вес
Blocking Transactions	\(N_{\text{blk}}\)	0.35
DB Wait Events	\(N_{\text{wait}}\)	0.25
Job Lag	\(N_{\text{lag}}\)	0.20
Exchange Queue Lag	\(N_{\text{ex}}\)	0.20

Фактические значения: \[\mathrm{blk}=12,\quad \mathrm{wait}=45\,\mathrm{ms},\quad \mathrm{lag}=6\,\mathrm{min},\quad \mathrm{queue}=240.\]

Baseline / SLA: \[B_{\text{wait}}=14\,\mathrm{ms},\quad SLA_{\text{wait}}=50\,\mathrm{ms},\quad W_{\max}=300\,\mathrm{ms}.\]

Упрощённая нормализация: \[N_{\text{blk}}=0.80,\qquad N_{\text{wait}}=0.92,\qquad N_{\text{lag}}=0.88,\qquad N_{\text{ex}}=0.75.\]

Доступность 1C: \[A_{\text{1c}}= 0.35\cdot0.80 + 0.25\cdot0.92 + 0.20\cdot0.88 + 0.20\cdot0.75 = 0.84.\]

Расчёт доступности контура

Веса систем: \[W_{\text{web}}=0.30,\quad W_{\text{api}}=0.40,\quad W_{\text{1c}}=0.30.\]

Итоговая доступность: \[A_{\text{contour}} = 0.30\cdot0.79 + 0.40\cdot0.93 + 0.30\cdot0.84 = 0.857.\]

Интерпретация

Полученное значение \[A_{\text{contour}} = 0.857\] указывает на наличие деградации контура, обусловленной главным образом Web–сервисом. Банк–клиент API является наиболее стабильной частью контура, 1C ERP находится в умеренной зоне риска из-за увеличенных очередей обмена.

Данный пример демонстрирует практическую применимость UAM для систем, которые в традиционных моделях не могут быть объединены в единый SLA или общую шкалу доступности.

Реализация в мониторинге

Prometheus

• recording rules для нормализации,

• функции clamp, rate, scalar,

• итоговые правила для \(A_i\) и \(A_{\text{contour}}\).

Zabbix

• dependent items для нормализации,

• формулы пользовательских элементов,

• триггеры на пороги \(A_i < 0.8\), \(A_i < 0.5\).

Grafana

• панели gauge,

• композитные панели SLA,

• цветовая логика 4 уровней: Green / Yellow / Orange / Red.

Иерархическая модель когерентности уровней
(расширение к Unified Availability Model)

Введение

В сложных ИТ-ландшафтах доступность бизнес-процесса зависит не только от состояния отдельных подсистем, но и от иерархии уровней зависимости: инфраструктура ограничивает прикладные сервисы, а прикладные сервисы — бизнес-логику.

Даже идеально работающий верхний уровень не способен компенсировать деградацию нижнего. Это формирует фундаментальный принцип:

Доступность контура ограничена минимальной согласованностью его базовых уровней.

Для формализации этого принципа вводится Иерархическая Модель Когерентности Уровней (ИКУ), являющаяся расширением UAM.

Архитектура уровней

Мы выделяем три уровня наблюдаемости:

1. Инфраструктурный уровень (Infra) сеть, TCP latency, ping, CPU, RAM, диски, storage, кластеры.

2. Прикладной уровень (App) HTTP 5xx, TNS, RPS, thread-pool saturation, application backlog.

3. Бизнес-уровень (Biz) скорость обработки транзакций, SLA бизнес-операций, задержка бизнес-цепочек, глубина workflow.

Каждый уровень имеет собственную доступность:

\[H_{\mathrm{infra}},\; H_{\mathrm{app}},\; H_{\mathrm{biz}} \in [0,1].\]

Проблема фиксированных весов и динамическая перенормировка

В практической эксплуатации споры между инженерами почти всегда сводятся к вопросам вида:

• «Почему ping важнее latency?»

• «Почему success-rate должен весить больше, чем backlog?»

• «Почему бизнес-показатели не доминируют над техническими?»

Эти конфликты возникают не из-за самих метрик, а из-за фиксированных весов, которые не отражают реальное состояние уровней.

Решение: в рамках уровня веса становятся динамическими— они автоматически увеличиваются для деградирующих метрик и уменьшаются для стабильных.

Это устраняет «споры о важности» и отражает естественное поведение системы.

Мягкая иерархия уровней
(Multiplicative Coherence Model)

Плавное влияние уровней друг на друга описывается формулой:

\[\begin{equation} H_{\mathrm{final}} = H_{\mathrm{infra}} \cdot \left( \alpha\, H_{\mathrm{app}} + (1-\alpha)\, H_{\mathrm{biz}} \right), \end{equation}\]

где:

• \(H_{\mathrm{infra}}\) — фундамент системы,

• \(H_{\mathrm{app}}\) — реакция приложения на состояние инфраструктуры,

• \(H_{\mathrm{biz}}\) — качество выполнения бизнес-операций,

• \(\alpha \in [0,1]\) — чувствительность сервисного уровня.

Смысл: если инфраструктура просела до 0.5, то даже идеальные App и Biz не могут дать более \(0.5 \times 1 = 0.5\).

Жёсткая иерархия
(Foundational Limit Model)

Для финансовых систем, банковских API, электронных платежей и ERP-операций действует жёсткое правило:

если фундаментальная инфраструктура недоступна — весь контур недоступен.

Это формализуется предельным оператором:

\[\begin{equation} H_{\mathrm{total}} = \min\left( H_{\mathrm{infra}}, H_{\mathrm{weighted\text{-}app\text{-}biz}} \right). \end{equation}\]

Примеры:

• если сеть падает — ERP не спасёт контур;

• если DNS недоступен — API полностью недоступно;

• если storage деградирует — batch-процессы не запускаются.

Динамическая логика весов внутри уровней

Для уровня \(L\) веса метрик пересчитываются по правилу:

\[\begin{equation} w_{j}^{\mathrm{new}} = \frac{ w_{j}^{\mathrm{base}} }{ 1 + \gamma \cdot \Delta_{j} }, \end{equation}\]

где:

• \(w_{j}^{\mathrm{base}}\) — базовый вес метрики,

• \(\Delta_{j}\) — степень её отклонения от нормы,

• \(\gamma\) — коэффициент чувствительности уровня.

Таким образом, проблемные метрики автоматически становятся весомее, и необходимость вручную «торговаться о важности ping» исчезает.

Заключение

Unified Availability Model (UAM) предоставляет формальный и расширяемый подход к расчёту доступности разнородных систем. Методика позволяет:

• реалистично сравнивать разные классы приложений;

• строить единый показатель доступности контура;

• интегрировать Prometheus, Zabbix, Grafana;

• адаптировать модель под любые новые системы.

Данная методика предназначена для практического использования в высоконагруженных и критичных для бизнеса ИТ-ландшафтах.

Аннотация к Приложению A

В Приложении A рассматриваются альтернативные подходы к агрегации метрик в разнородных ИТ-системах. Показано, почему нечеткая логика применима только внутри отдельных уровней (Infra, App, Biz), где границы нормальности размыты и опираются на экспертные оценки, и почему её использование между уровнями недопустимо из-за строгой иерархической зависимости: верхний уровень не может быть более доступным, чем нижний.

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

Приложение A формирует методологическое обоснование архитектуры UAM v2 и формализует инженерную логику построения многослойной модели доступности.

Приложение A. Fuzzy-логика и Нейросети в оценке доступности: область применения и ограничения

A.1. Почему fuzzy допустим внутри уровней (Infra / App / Biz)

A.1.1. Причины применения

Низкоуровневые метрики часто имеют размытые или неоднозначные критерии «нормальности». Типичные примеры:

• дневная и ночная латентность могут различаться в 2–3 раза при одинаковой норме;

• допустимый ping по-разному трактуется разными командами;

• backlog не имеет универсального порога, применимого к любым нагрузкам.

Общая проблема: границы между «хорошо», «нормально» и «плохо» имеют диапазонный характер.

Fuzzy-логика естественно работает в условиях:

• размытых порогов,

• экспертных оценок,

• неоднозначных режимов работы.

То есть fuzzy решает прежде всего эпистемическую¹ проблему интерпретации метрик, а не математическую задачу.

A.1.2. Что даёт применение fuzzy внутри уровня

• Снятие спорных трактовок. Размытые пороги переводят субъективные обсуждения в формальные диапазоны.

• Плавность реакции. Метрика не падает скачком, а изменяется непрерывно.

• Устойчивость к шуму. Малые колебания latency или CPU не вызывают ложных срабатываний.

• Лучшая предварительная нормализация. Fuzzy используется на этапе подготовки данных перед вычислением \(N_{ij}\).

• Гибкость без потери контроля. UAM остаётся строгой моделью, а fuzzy выступает как инструмент предобработки сырых метрик.

Таким образом, fuzzy применим только как внутриуровневая смягчающая оболочка для неоднозначных показателей Infra, App и Biz.

A.2. Почему fuzzy нельзя использовать между уровнями (Infra \(\rightarrow\) App \(\rightarrow\) Biz)

A.2.1. Причины отказа

Иерархия уровней обладает жёсткой зависимостью:

• деградация инфраструктуры неизбежно приводит к деградации приложений;

• недоступность приложений делает невозможными бизнес-операции;

• верхний уровень не может быть лучше нижнего.

Фундаментальный принцип:

когерентность верхнего уровня ограничена когерентностью нижнего.

Если применить fuzzy на стыке уровней, возникают:

• размытые зависимости,

• противоречивые оценки,

• риск «косметически нормального Biz» при критически проблемном Infra,

• потеря строгой интерпретации,

• рекурсивные колебания пересчётов.

Иначе говоря, fuzzy делает уровни «слишком равными» — что структурно неверно и противоречит их иерархической природе.

A.2.2. Что даёт отказ от fuzzy между уровнями

• Строгая иерархия ограничений. Верхний уровень не может «обмануть» фундамент ниже.

• Бизнес-ориентированная прозрачность. Менеджерам не требуется понимание сложных fuzzy-градаций.

• Корректное распространение деградаций. Если инфраструктура деградирует, App и Biz не могут демонстрировать «условно нормальное» состояние.

• Реалистичная модель доступности. Операторы \(\min(\cdot)\) и произведение обеспечивают реалистичность оценки.

• Совместимость с UAM и COE. Модель согласована с принципом онтологической ограниченности уровней.

• Отсутствие рекурсивной неопределённости. Fuzzy между уровнями приводит к неуправляемой перенормировке.

A.3. Почему мы не используем нейросети

Нейросетевые методы прогнозирования и агрегирования также были рассмотрены, но сознательно отвергнуты.

Причины:

• изменение нагрузки требует периодического или даже полного переобучения, что неприемлемо для метрики, используемой в бизнес-отчётности;

• нейросети обладают низкой интерпретируемостью решений (low interpretability);

• модель доступности должна быть аудируемой и повторяемой, что невозможно при стохастических весах;

• нейросеть оптимизирует предсказание, а не ответственность за SLA.

Таким образом, нейросети непригодны для руководящей метрики доступности.

A.4. Вывод

Fuzzy-логика может применяться только для нормализации отдельных метрик внутри уровней (Infra, App, Biz) — и не должна использоваться для агрегации уровней.

Это осознанный инженерный выбор:

• метрики имеют размытые границы → fuzzy подходит;

• уровни имеют жёсткую иерархию → fuzzy противопоказан.

---

1. в том числе человеческую↩︎