Доступность ИТ-услуг перестала быть техническим параметром — сегодня это показатель, напрямую влияющий на доверие бизнеса к IT. Когда корпоративная почта недоступна в течение часа, или ERP-система «зависает» в момент закрытия отчётного периода, последствия измеряются не только минутами простоя, но и реальными убытками. Цель практики управления доступностью (Availability Management) — не просто отслеживать сбои, а выстроить системную работу по обеспечению стабильности сервисов в соответствии с ожиданиями бизнеса.
Назначение практики: баланс требований и возможностей
В методологии ITIL доступность определяется как способность ИТ-услуги или её компонентов выполнять свои функции в определённый период времени. Управление доступностью это практика, которая гарантирует, что услуги предоставляются на согласованном уровне, удовлетворяющем потребности заказчиков и пользователей.
Ключевая задача практики найти баланс между тремя факторами: требованиями бизнеса к доступности сервисов, затратами на обеспечение этого уровня и приемлемыми рисками. Нельзя обеспечить 99,99% доступности для всех услуг без кратного роста затрат на инфраструктуру. Необходимо понять, какие сервисы критичны для бизнеса, а где допустимы более мягкие требования.
Деятельность по управлению доступностью включает несколько направлений работы:
Определение и согласование требований к доступности с бизнес-подразделениями, фиксация их в соглашениях об уровне услуг (SLA).
Проектирование доступности на этапе создания или изменения сервиса: оценка рисков, выбор архитектурных решений (резервирование, кластеризация).
Мониторинг и измерение фактического уровня доступности, сравнение с целевыми показателями.
Реагирование на инциденты, влияющие на доступность, и анализ их причин для предотвращения повторения.
Постоянное улучшение — использование собранных данных для повышения надёжности инфраструктуры.
Важный принцип: управление доступностью должно быть преимущественно проактивным. Гораздо дешевле и эффективнее заложить механизмы отказоустойчивости на этапе проектирования, чем пытаться «допилить» работающий сервис после серии сбоев.
Метрики доступности: такой арбуз нам не нужен
Измерение доступности — это не просто подсчёт процентов. Выбранные метрики должны быть понятны бизнесу и давать объективную картину, а не создавать иллюзию благополучия («эффект арбуза» — зелёный снаружи, красный внутри).
Базовые метрики доступности
Наиболее распространённый способ — выражение доступности в процентах от согласованного времени работы:
Доступность (%) = (Плановое время работы — Время простоев) / Плановое время работы × 100%
При этом важно различать:
- Плановые простои (техническое обслуживание) обычно не включаются в расчёт, если они согласованы с бизнесом и проведены в оговоренное время.
- Внеплановые простои как правило именно они учитываются как недоступность.
Типичные целевые уровни: 99,9% (около 43 минут простоя в месяц), 99,95% (около 22 минут), 99,99% (около 4,3 минут). Для высококритичных систем могут устанавливаться цели 99,999% («пять девяток») — около 26 секунд простоя в месяц.
Дополнительные показатели
Процентный показатель доступности полезен, но он не отражает ни масштаб влияния сбоя, ни эффективность восстановления. Поэтому также используются следующие метрики:
- MTBF (Mean Time Between Failures) — среднее время между сбоями. Характеризует надёжность сервиса: чем больше этот показатель, тем реже происходят отказы.
- MTRS (Mean Time to Restore Service) — среднее время восстановления сервиса после сбоя. Отражает ремонтопригодность и эффективность процессов Incident и Problem Management. Иногда используется схожий показатель MTTR (Mean Time to Recover).
- MTBSI (Mean Time Between Service Incidents) — среднее время между инцидентами, учитывающее все инциденты, а не только отказы.
- Минимальное время между сбоями
- Максимальное время разовой недоступности.
Однако даже эти показатели не дают полной картины. Например, простой в 10 минут в 3 часа ночи и в 10 часов утра для интернет-магазина — события с совершенно разными последствиями. Поэтому измерение доступности должно учитывать бизнес-влияние: количество затронутых пользователей, количество прерванных транзакций, оценка финансовых потерь и даже ущерба для репутации.
Метрики, учитывающие бизнес-влияние
Один и тот же простой в 15 минут в разных контекстах стоит принципиально разных денег. Поэтому метрики доступности дополняется показателями, которые оценивают не время как таковое, а последствия сбоя для бизнеса.
Количество затронутых пользователей или сегментов.
Вместо абстрактного «сервис был недоступен 20 минут» фиксируется, сколько уникальных пользователей не смогли выполнить операцию. Для внутреннего портала с 500 сотрудниками и для B2C-платформы с 50 000 активных сессий это значения разного порядка. Целевой показатель может формулироваться как «доля инцидентов, затронувших более X % пользовательской базы, не должна превышать Y % за месяц».
Количество прерванных бизнес-транзакций.
Не все операции равны. Сбой на этапе оплаты заказа критичнее, чем недоступность раздела с часто задаваемыми вопросами. Метрика считает число незавершённых транзакций за период простоя. Например: «За апрель из-за двух сбоев не завершено 147 транзакций оформления заказов». Это позволяет ранжировать инциденты не по длительности, а по влиянию на бизнес-результат.
Оценка прямого финансового ущерба от простоя.
Рассчитывается как средний чек или стоимость одного рабочего часа пользователя, умноженная на длительность сбоя и на интенсивность использования в этот период. Пример:
Для платёжного шлюза: средний чек — 15 000 руб., средняя частота транзакций в час пик — 60 операций. Простой в 5 минут в этот период даёт оценку потерь около 75 000 руб. без учёта штрафов по SLA.
Важно, что эта метрика не требует абсолютной точности — достаточно реалистичной оценки порядка величин, чтобы принимать решения о приоритетах восстановления и инвестициях в резервирование.
Балльная оценка критичности сервиса по времени суток.
Один и тот же сервис может иметь разный «вес» в зависимости от часа, дня недели или периода бизнес-активности. Например, для отчётной системы:
в рабочие дни с 9:00 до 18:00 — коэффициент критичности 10;
в вечерние часы — коэффициент 3;
в выходные — коэффициент 1.
Общая метрика доступности с учётом взвешивания считается как сумма времени простоя, умноженного на коэффициент критичности за каждый час. Это позволяет бизнесу видеть не «среднюю температуру по больнице», а реальное влияние на ключевые временные окна.
Индекс удовлетворённости бизнес-подразделений доступностью (регулярный опрос).
Формальный показатель 99,9 % может не совпадать с субъективным восприятием, если сбои приходятся на самые неудобные моменты. Раз в квартал собираются оценки от руководителей бизнес-функций по шкале «насколько доступность сервисов соответствует вашим операционным потребностям». Этот показатель часто выявляет расхождения между техническими отчётами и реальными ожиданиями — и служит триггером для пересмотра целевых уровней или архитектурных решений.
Количество бизнес-инцидентов, инициированных IT-сбоями.
Фиксируются не все технические инциденты, а только те, которые привели к остановке или задержке бизнес-процессов (например, невыполненный заказ, срыв поставки, задержка расчёта зарплаты). Эта метрика даёт бизнесу прозрачную связь: «было 12 технических сбоев, из них 3 реально остановили процесс отгрузки — это наш приоритет для улучшений».
Эти метрики не заменяют классические MTBF и проценты доступности, а дополняют их. В итоговом дашборде доступности должны сосуществовать две группы показателей:
технические (время простоя, частота возникновения сбоев, скорость восстановления) — для инженерных команд;
бизнес-ориентированные (затронутые пользователи, прерванные транзакции, потерянные деньги, критичные окна) — для диалога с заказчиками и топ-менеджментом.
Именно такое разделение превращает управление доступностью из чисто формальной деятельности в инструмент принятия решений.
