Бизнес-сервисы#

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

Примеры:

Checkout
Login
Payments
Customer API
Openstack Cloud
Partner Integrations

Технический Service отвечает на вопрос: какая система или компонент затронуты?

BusinessService отвечает на вопрос: какая пользовательская возможность затронута и насколько серьёзно влияние на бизнес?

Бизнес-сервисы намеренно отделены от технических сервисов. Один бизнес-сервис может зависеть от многих технических сервисов, а один технический сервис может входить в несколько бизнес-сервисов.

Бизнес-сервис против сервиса#

Понятие	Назначение
`Service`	Технический сервис, компонент, система, приложение, база данных, очередь, инфраструктурная единица.
`BusinessService`	Бизнес-ориентированная возможность, построенная из технических сервисов.
`BusinessServiceComponent`	Сопоставление между бизнес-сервисом и техническим сервисом.
`BusinessServiceIncidentImpact`	Сохранённый снимок, связывающий группу алертов с влиянием на бизнес.
`BusinessServiceStatusHistory`	Историческая смена статусов бизнес-сервиса.

Пример:

Business Service: Checkout
Components:
- checkout-api
- billing-api
- postgres-payments
- redis-checkout

Если billing-api деградирует, бизнес-сервис Checkout может стать деградировавшим или частично недоступным в зависимости от критичности компонента и веса влияния.

Компоненты#

Бизнес-сервис вычисляется из включённых компонентов.

Каждый компонент имеет:

Поле	Значение
Технический сервис	Технический сервис, участвующий в расчёте.
Критичность	Насколько важен этот компонент для бизнес-сервиса.
Вес влияния	Множитель 0-100 для оценки влияния компонента.
Позиция	Порядок сортировки в UI.
Включён	Отключённые компоненты сохраняются, но игнорируются при расчёте статуса и определении влияния на бизнес.
Описание	Необязательное внутреннее пояснение.

Поддерживаемые значения критичности компонента:

required
critical
important
optional
informational

Компоненты required и critical оказывают наибольшее влияние на статус бизнес-сервиса. Компоненты optional и informational имеют сниженное или отсутствующее видимое влияние в зависимости от статуса и веса.

Исходный статус сервиса против эффективного статуса#

Бизнес-сервисы используют эффективный статус компонента, а не только исходный Service.status.

Исходный статус сервиса — это сохранённый технический статус сервиса:

service.status = operational

Эффективный статус вычисляется движком Service Impact на основе:

raw service status score
+ alert impact score from priority/severity
+ propagated upstream dependency score
= effective service impact score and status

Это означает, что компонент может показывать:

raw service_status: operational
effective_status: degraded
effective_status_reason: upstream_dependency

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

Бизнес-сервисы используют effective_status, чтобы влияние на бизнес соответствовало той же логике, что применяется в Service Impact v2.

Расчёт статуса#

Статус бизнес-сервиса вычисляется из включённых компонентов.

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

effective component impact score
x component criticality multiplier
x impact weight

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

business_score = 100 * (1 - product(1 - component_score / 100))

Затем комбинированная оценка преобразуется в статус бизнес-сервиса.

Типичные статусы:

unknown
operational
degraded
partial_outage
major_outage
maintenance

Точные пороги оценки реализованы в app/services/business_services/status.py.

Влияние с учётом зависимостей#

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

Пример:

Business Service: Openstack Cloud
Component: Openstack

Openstack depends on Cloud computes
Alert fires on Cloud computes

Даже если Cloud computes не является прямым компонентом бизнес-сервиса, бизнес-сервис всё равно может быть затронут, поскольку Openstack имеет эффективную деградацию, вызванную вышестоящей зависимостью.

В этом случае связь влияния инцидента может быть сохранена как:

dependency_upstream_alert

Алерты прямых компонентов сохраняются как:

component_alert

Ручное переопределение статуса#

Бизнес-сервисы поддерживают ручное переопределение статуса.

Ручное переопределение — это операционное действие, используемое, когда вычисленный статус не полностью описывает влияние на клиентов.

Примеры:

Technical services recovered, but customers still see degraded checkout.
Set Checkout to degraded for 30 minutes.

A technical warning exists, but customers are not affected.
Set Business Service to operational until the alert is fixed.

Ручное переопределение имеет приоритет над вычисленным статусом, пока оно активно.

Поля ручного переопределения:

Поле	Значение
manual_status	Статус переопределения.
manual_status_message	Необязательное сообщение оператора.
manual_status_until	Необязательное время истечения. Если пусто, переопределение остаётся активным до сброса.
manual_status_set_by_id	Пользователь, установивший переопределение.
manual_status_set_at	Время установки переопределения.
manual_status_active	Активно ли переопределение в данный момент.

Когда ручное переопределение истекает, оно игнорируется и может быть сброшено при пересчёте.

Сброс ручного переопределения пересчитывает статус бизнес-сервиса из эффективного статуса компонентов.

Записи влияния на бизнес#

Когда группа алертов влияет на бизнес-сервис, IncidentRelay сохраняет запись BusinessServiceIncidentImpact.

Эта запись хранит:

business_service
group
service
impact_status
impact_score
relation
reason
component_snapshot
active
first_seen_at
last_seen_at

Снимок полезен, поскольку он сохраняет контекст влияния на бизнес на момент инцидента.

Когда алерт разрешается или больше не влияет на бизнес-сервис, запись влияния деактивируется.

История статусов#

Изменения статуса бизнес-сервиса записываются в BusinessServiceStatusHistory.

История записывается при изменении одного из этих значений:

status
status_source
status_message

Источником статуса может быть:

calculated
manual

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

Поведение UI#

Страница бизнес-сервисов показывает:

сводные карточки
список бизнес-сервисов
бейдж статуса
команду-владельца
количество компонентов
флаг public/private
меню действий
модальное окно с деталями
таблицу компонентов
элементы управления ручным переопределением статуса
историю статусов

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

Бейджи статуса#

UI бизнес-сервисов использует общий помощник и стили бейджа статуса:

uiStatusBadge(...)
uiStatusBadgeVariantForStatus(...)
.ui-status-badge
.ui-status-badge-success
.ui-status-badge-warning
.ui-status-badge-danger
.ui-status-badge-info
.ui-status-badge-muted

Классы цвета статуса, специфичные для конкретной страницы, не должны использоваться для бизнес-сервисов.

Текущие ограничения#

Текущая реализация намеренно не включает:

отрисовку публичной страницы статуса
шаблоны уведомлений для бизнес-сервисов
аналитические дашборды
автоматическое назначение заинтересованных сторон

Тонкая настройка политики влияния алертов находится в общем слое Service Impact. Бизнес-сервисы наследуют из этого слоя влияние алертов на основе приоритета, запасной вариант по серьёзности, множители распространения по зависимостям и эффективные оценки компонентов.

Устранение неполадок#

Компонент деградировал, но бизнес-сервис по-прежнему operational#

Убедитесь, что бизнес-сервис был пересчитан и что компонент включён.

Статус бизнес-сервиса должен пересчитываться при:

обращении к эндпоинту деталей
обращении к эндпоинту пересчёта
создании/обновлении/удалении компонента
обновлении жизненного цикла алерта
обновлении нижестоящих зависимостей

Ручной статус не меняется после пересчёта#

Ручное переопределение имеет приоритет, пока оно активно. Сбросьте ручное переопределение или дождитесь истечения manual_status_until.

Компоненты исчезают после установки ручного статуса#

Эндпоинты ручного статуса должны возвращать тот же полный ответ с деталями, что и GET /api/business-services/{id}, включая components и status_history.

Статус в списке отличается от статуса в деталях#

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

Бизнес-сервисы