Фактическая услуга Actual Service
Простыми словами
Actual Service — это модель услуги в том виде, в каком она реально развёрнута: перечень конфигурационных единиц продуктива и их связей, за который отвечает компонент «Configuration Management» потока Detect to Correct. Архитектор закрывает им вопрос „что у нас на самом деле работает и из чего оно собрано“. Путать его надо не с логической услугой (та живёт в Requirement to Deploy и экземпляра ещё не имеет), а с Desired Service из потока Request to Fulfill: Desired Service — спецификация заказанного экземпляра, Actual Service — то, что получилось после исполнения, и связаны они один к одному именно ради сверки. Формулировка стандарта об их согласованности мягкая — «Should be kept in sync with the Desired Service», а не требование совпадения: расхождение реализации допускается и как раз фиксируется в Actual Service.
Примеры
Атрибут Location разрешает описывать расположение с любой подробностью: «Location of the Actual Service. Can vary from high-level country to city or low-level, such as building or room.» То есть глубину инвентаризации выбирает внедряющая организация, а не стандарт.
The Open Group IT4IT™ Reference Architecture, Version 2.1 (2017, C171), разд. 8.4.6 — ключевые атрибуты Actual Service
Стандарт объясняет назначение пары „желаемое — фактическое“ проверкой правильности развёртывания: «Create traceability and enable verification of correct deployment/fulfillment.» Без Actual Service нечем доказать, что доставлено именно заказанное.
The Open Group IT4IT™ Reference Architecture, Version 2.1 (2017, C171), разд. 7.4.6 — связи объекта данных Desired Service
Раздел о модели интеграции берёт этот объект как пример хранения транзитивного замыкания связей: «As an example, the Actual Service object maintains a link to the accompanying Desired Service object.» Такое хранение стандарт явно не предписывает и держит предписанную модель связей минимальной.
The Open Group IT4IT™ Reference Architecture, Version 2.1 (2017, C171), разд. 3.4.4 — примечание о транзитивном замыкании связей
Определение из первоисточника
дословная выпискаRepresents the realized deployment of the service. Includes Configuration Items that represent the implemented service components. Should be kept in sync with the Desired Service, but includes specific implementation characteristics and details.
Представляет реализованное развёртывание услуги. Включает конфигурационные единицы, представляющие внедрённые компоненты услуги. Должна поддерживаться в синхронизации с желаемой услугой, но включает конкретные характеристики и детали реализации.
ИсточникThe Open Group IT4IT™ Reference Architecture, Version 2.1. The Open Group, 30.01.2017, C171, US ISBN 1-937218-84-3
Основные параметры
Атрибуты этой сущности по справочнику источника.
- Ключевые атрибуты по стандарту: Id — Unique identifier of the Actual Service.; Name — Name of the Actual Service.; Type — Type of the Actual Service (e.g., infrastructure service, customer-facing service, enabling service, front office, etc.).; CreateTime — Date/time the Actual Service was created.; LastModifiedTime — Date/time the entry was last modified in a significant way.; Owner — Group or person that is assigned to own the Actual Service.; Location — Location of the Actual Service. Can vary from high-level country to city or low-level, such as building or room. Обязательные связи объекта: Actual Service to Event (n:m); Actual Service to Service Contract (1:n)
Связи
Исходящие
- Обязательная связь объектов данных, кардинальность n:mEvent
- Обязательная связь объектов данных, кардинальность 1:nService Contract
- Обязательная связь объектов данных, кардинальность n:mRun Book
Входящие
- Обязательная связь объектов данных, кардинальность 1:1Desired Service
- Обязательная связь объектов данных, кардинальность 1:nService Monitor
- Обязательная связь объектов данных, кардинальность n:mEvent
- Обязательная связь объектов данных, кардинальность n:mIncident
- Обязательная связь объектов данных, кардинальность n:mProblem, Known Error
- Обязательная связь объектов данных, кардинальность n:mRFC
- Обязательная связь объектов данных, кардинальность n:mRun Book
Как измерить
Доля времени, в течение которого критичные для бизнеса системы доступны. KPI ценностного потока Detect to Correct; сам стандарт оговаривает, что управление доступностью в этом потоке ещё не представлено и будет рассмотрено в будущих редакциях (разд. 8.4.9).
Доступность = время работоспособного состояния / общее время наблюдения
- время работоспособного состояния время, когда система выполняла свои функции
- общее время наблюдения весь период, за который считается доступность
Среднее время между отказами. Парный к MTTR показатель: тот измеряет, как быстро чинят, этот — как редко ломается.
MTBF = суммарное время работоспособного состояния / число отказов за период
- время работоспособного состояния суммарная наработка между отказами
- число отказов количество отказов за период
Actual Service — услуга в том виде, в каком она развёрнута, вместе с составом конфигурационных единиц продуктива. Доступность и наработка на отказ относятся именно к этому объекту, а не к логической услуге: у той экземпляра ещё нет, и отказывать в ней нечему.
Связанные понятия
Опишите архитектуру своей компании в Storm
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormРеестр процессовИмитационное моделированиеАрхитектура систем и интеграций