Доступность сервиса по клиентским минутам: почему пять минут сбоя бывают разными

Два инцидента длились по пять минут. Первый остановил весь сервис, второй затронул только одного из ста клиентов. Если смотреть лишь на часы работы платформы, оба сбоя выглядят одинаково. Для бизнеса с отдельными клиентскими окружениями полезно посчитать время недоступности с учётом числа затронутых клиентов. Получится показатель, который отличает массовый простой от локальной проблемы, сохраняя возможность увидеть пострадавшего клиента отдельно.

Определить, кому услуга должна быть доступна

Знаменатель — минуты, в которые конкретный клиент имел право пользоваться услугой. Активная оплаченная подписка может давать это право круглосуточно; договор с рабочими часами — только в согласованном расписании. Не используйте количество вошедших пользователей: во время сбоя люди не могут войти, и такой знаменатель автоматически уменьшится вместе с проблемой. Нужен независимый реестр действующих обязательств.

Возьмём сто клиентов с круглосуточным доступом и час наблюдения. Всего это шесть тысяч клиентских минут. При полном пятиминутном сбое потеряно пятьсот, доступность равна 91,67%. При таком же сбое одного клиента потеряно пять, доступность равна 99,9167%. Изменилось число затронутых клиентских минут, хотя длительность инцидента одинакова. Именно это различие и должен показывать показатель.

Сначала объединить пересекающиеся интервалы

Допустим, мониторинг записал две причины одного сбоя у клиента: базу данных и API. Если обе длились одни и те же пять минут, складывать их нельзя: клиент потерял пять минут услуги, а не десять. На уровне каждого клиента объедините пересечения интервалов недоступности и обрежьте их границами действующего договора и отчётного периода. Только после этого суммируйте минуты между клиентами.

clients = [f'C{i}' for i in range(100)]
entitled = {(c,m) for c in clients for m in range(60)}
# Each pair denotes the full minute [m, m+1).
platform = {(c,m) for c in clients for m in range(10,15)}
local_api = {('C0',m) for m in range(10,15)}
local_db = {('C0',m) for m in range(12,15)}
def availability(*incidents):
    down = set().union(*incidents) & entitled
    return len(down), 1-len(down)/len(entitled)
full_lost, full_avail = availability(platform)
local_lost, local_avail = availability(local_api, local_db)
print({'entitled_minutes':len(entitled),
       'full':(full_lost,round(full_avail*100,4)),
       'local':(local_lost,round(local_avail*100,4))})
assert full_lost == 500 and local_lost == 5
assert round(full_avail*100,2) == 91.67
assert round(local_avail*100,4) == 99.9167

Общий показатель не отменяет отчёт пострадавшему

В локальном сценарии общая доступность почти 99,92%, но клиент C0 получил лишь 91,67% в своём часе. Поэтому рядом с общим результатом покажите распределение по клиентам и список тех, кто нарушил договорный порог. Иначе крупная база здоровых окружений скроет длительный простой одного. Для компенсаций применяют конкретные условия договора и его окно, которое может отличаться от общего оперативного отчёта.

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

Сделать метрику полезной для приоритетов

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

Когда число клиентов в течение месяца растёт, считайте знаменатель по фактическим интервалам договоров. Новый клиент, подключившийся в последний день, не добавляет полный месяц. Тогда сравнение периодов не будет зависеть от грубого снимка справочника на конец месяца. Результат такого отчёта — обоснованный выбор, что исправлять: общую точку отказа, локальную конфигурацию или длительное восстановление отдельных окружений.

Продолжить работу с данными

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