Что это. Сколько всего времени ваши сервисы были недоступны за период журнала.

Как считаем. Складываем длительности всех инцидентов, но параллельные интервалы склеиваем: два инцидента, шедших одновременно с 10:00 до 11:00, дают час простоя, а не два. Без склейки цифра завышается тем сильнее, чем крупнее инфраструктура.

Откуда определение. Наш расчёт. Понятие простоя - от availability в глоссарии ITIL 4: способность сервиса выполнять согласованную функцию, когда она нужна.

Что нужно от вас. Уже посчитано - число в строке.

Если строка янтарная: нужно поле со временем закрытия инцидента, иначе длительности не существует. Если строка серо-синяя: расчёт входит в тариф Base и выше.

Что это. Доля времени, когда сервис работал, от всего времени наблюдения. Это то самое число, которое произносят как «три девятки».

Как считаем. Время работы / (Время работы + Простой). По каждому названному вами сервису отдельно. Инцидент, задевший три сервиса, засчитывается каждому из трёх целиком: с точки зрения одного сервиса он лежал всё это время. Складывать простои сервисов между собой нельзя - получился бы двойной счёт, поэтому сводной доступности «по всей инфраструктуре» мы не печатаем принципиально.

Откуда определение. Формула - Google SRE Book, гл. 3 «Embracing Risk», дословно. Понятие availability - глоссарий ITIL 4.

Что нужно от вас. Отметьте критичные сервисы в списке и укажите целевой уровень (например 99,9%). Считаем сразу после ответа, отчёт перезагружать не нужно.

Что это. Цель вроде 99,9% сама разрешает какое-то время простоя. Это разрешённое время и есть бюджет. Показатель говорит, сколько бюджета вы уже потратили.

Как считаем. Допустимый простой = длина вашего периода x (1 - цель). Израсходовано = фактический простой / допустимый простой x 100%. Период берём фактический - ровно столько дней, сколько в вашем журнале, без округления до месяца. Значение выше 100% значит, что бюджет исчерпан и цель за период не выполнена.

Откуда определение. Google SRE Book, гл. 3: бюджет - это разница между целью и фактическим временем работы, остаток «ненадёжности» на период.

Что нужно от вас. Одну цифру - целевую доступность. Без цели показателя не существует: бюджет отсчитывается от обещания, а не от данных.

Что это. RTO - срок, за который сервис обязан вернуться в строй после аварии. Показатель отвечает, в какой доле случаев вы в этот срок уложились.

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

Откуда определение. ISO 22300:2021 (словарь к ISO 22301): RTO - «период времени после инцидента, в течение которого продукт, услуга или деятельность возобновляются, а ресурсы восстанавливаются». Стандарт платный, номер пункта мы не подтверждали и поэтому на него не ссылаемся.

Что нужно от вас. Целевое время восстановления в часах. Если оно разное для разных сервисов - назовите цель для самого критичного.

Что это. Сколько времени проходит от регистрации инцидента до его закрытия.

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

Откуда определение. ITIL 4 называет это MTRS, mean time to restore service: «показатель того, как быстро сервис восстанавливается после отказа». В словаре надёжности IEC 60050-192 то же число зовётся MTTR (термин 192-07-23). Число одно, имена разные - в отчёте пишем по-русски.

Что нужно от вас. Уже посчитано.

Если строка янтарная: нужно поле со временем закрытия инцидента.

Что это. Сколько инцидент шёл до того, как вы о нём узнали. Это слепая зона: сервис уже лежит, а заявки ещё нет.

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

Откуда определение. Стандарта нет. MTTD - устоявшаяся практика управления инцидентами, и мы говорим об этом прямо, а не выдаём практику за норму.

Что нужно от вас. Целью не лечится - нужен экспорт с отдельным полем «фактическое начало» (в системах его зовут по-разному: start time, occurred at, время возникновения). Догрузите такой экспорт по той же ссылке, и строка посчитается.

Что это. Сколько заявка ждала, пока за неё возьмётся человек. Показывает работу очереди и дежурной смены, а не сложность самой поломки.

Как считаем. Время принятия в работу минус время регистрации.

Откуда определение. Стандарта нет. MTTA - практика сервис-деска.

Что нужно от вас. Нужен экспорт с полем «время принятия в работу» (взят в работу, назначен, acknowledged - смотря как называется у вас).

Что это. Какая часть инцидентов уложилась в согласованные с бизнесом сроки.

Как считаем. По каждому приоритету отдельно: сколько инцидентов этого приоритета закрыто не позже вашего норматива. Сводить приоритеты в одно число нельзя - норматив у них разный, и общая цифра скрыла бы просрочку по критичным. Считаем, только если приоритет заполнен не менее чем у 60% записей; ниже этого порога цифра говорит о качестве заполнения журнала, а не о работе службы.

Откуда определение. ITIL 4: service level - метрики ожидаемого или достигнутого качества; SLA - документированное соглашение о требуемых услугах и ожидаемом уровне обслуживания.

Что нужно от вас. Целевые сроки по каждому приоритету (например: критичный - 4 ч, высокий - 8 ч, обычный - 24 ч).

Если приоритет в журнале не ведётся или заполнен реже, чем у 60% записей: сначала нужен экспорт с этим полем - цель без приоритета применить не к чему.

Что это. Какая часть инцидентов после закрытия не открылась заново. Прямая мера качества починки: заявку закрыли или проблему решили.

Как считаем. Доля инцидентов, у которых нет признака переоткрытия.

Откуда определение. Стандарта нет, это практика сервис-деска.

Что нужно от вас. Нужен экспорт с полем «переоткрыт» либо с историей смены статусов - по истории мы восстановим факт возврата в работу сами.

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

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

Откуда определение. Стандарта нет. ITIL 4 определяет только escalation и service desk; самой метрики в глоссарии нет.

Что нужно от вас. Нужен экспорт с полем «группа решения» или «линия поддержки».

Что это. Сколько инцидентов было за период и сколько времени в среднем проходит между ними.

Как считаем. Число записей и интервалы между соседними инцидентами - медиана, среднее и P95. Обязательная оговорка: мы считаем интервал между инцидентами в услуге, а не между отказами оборудования. Это не паспортная надёжность железа.

Откуда определение. ITIL 4, MTBF: «показатель того, как часто сервис или иной конфигурационный элемент отказывает». IEC 60050-192, термин 192-05-13, mean operating time between failures.

Что нужно от вас. Уже посчитано.

Что это. Отвечает, собран ли ваш простой в нескольких точках или размазан ровно. Если собран - работа по короткому списку даёт непропорционально большой эффект.

Как считаем. Сортируем сервисы по вкладу в простой и смотрим, какую долю дают верхние. Дополнительно считаем коэффициент Джини - меру неравенства вклада: 0 значит «все сервисы вносят поровну», ближе к 1 - «почти всё приходится на единицы».

Откуда определение. Наш расчёт (анализ Парето). Заимствованных норм нет: сравниваем вашу инфраструктуру с ней же, а не с чужим средним.

Что нужно от вас. Уже посчитано.

Если строка янтарная: нужно поле «сервис или узел» - без него простой не к чему привязать. Если серо-синяя: расчёт входит в тариф Base и выше.

Что это. Какая часть инцидентов повторяет уже виденное. Повтор - признак того, что причина осталась на месте.

Как считаем. Группируем инциденты по сервису и схожести описания, считаем долю записей во вторых и последующих повторениях. Как это читать: повтор указывает на проблему - по ITIL 4 это «причина или потенциальная причина одного или нескольких инцидентов». Это не упрёк тому, кто закрывал инцидент: он свою работу сделал, причина живёт уровнем выше.

Откуда определение. Наш расчёт; трактовка - ITIL 4, problem.

Что нужно от вас. Уже посчитано.

Если строка янтарная: нужно поле «сервис или узел». Если серо-синяя: тариф Base и выше.

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

Как считаем. Ищем следы изменения в тексте описания заявки. Обязательная оговорка: это нижняя оценка. Мы видим только то, что человек написал словами; изменения, о которых в заявке не упомянули, в эту долю не попадут. Точное число даёт только сверка с журналом изменений - см. строку «доля аварийных изменений».

Откуда определение. Наш расчёт. Это не DORA change failure rate, и мы намеренно не ставим рядом это имя: у DORA в знаменателе развёртывания, у нас - инциденты. Показатели считают разное.

Что нужно от вас. Уже посчитано.

Если строка янтарная: нужно поле «описание заявки». Если серо-синяя: тариф Base и выше.

Что это. Как инциденты распределены по классам важности.

Как считаем. Считаем долю каждого приоритета, но только если поле заполнено не менее чем у 60% записей. При меньшем заполнении разбивка описывает дисциплину заполнения журнала, а не реальную картину поломок, и мы её не печатаем.

Откуда определение. ITIL 4, incident: незапланированное прерывание услуги или снижение её качества. Шкалы приоритетов стандарт не задаёт - берём вашу.

Что нужно от вас. Уже посчитано.

Если строка янтарная: нужен экспорт с полем «приоритет» либо его заполнение.

Что это. Какая часть инцидентов разобрана до причины, а не просто закрыта после восстановления сервиса.

Как считаем. Доля записей с заполненной первопричиной или со связью с проблемой.

Откуда определение. ITIL 4: problem - причина или потенциальная причина инцидентов; known error - проблема, которая проанализирована, но не устранена (наличие обходного решения при этом не обязательно).

Что нужно от вас. Поле в вашем журнале не ведётся. Само по себе это уже вывод: повторяющиеся инциденты закрываются без разбора причины, значит они вернутся. Чтобы увидеть число - нужен экспорт с полем «первопричина» или со связью инцидентов с проблемами.

Что это. Какая часть изменений вносится в режиме «надо было вчера», без обычного согласования. Высокая доля означает, что плановый процесс не поспевает за реальностью.

Как считаем. Доля аварийных изменений от всех изменений за период.

Откуда определение. ITIL 4: emergency change - изменение, которое «должно быть внедрено как можно скорее»; standard change - заранее авторизованное изменение с низким риском.

Что нужно от вас. Полем в журнале инцидентов это не лечится: знаменатель здесь - изменения, а не инциденты. Нужна выгрузка из журнала изменений за тот же период. Она же уточнит строку «доля инцидентов со следом изменения» - сейчас там нижняя оценка по тексту описаний.

Что это. Какая часть поломок пришла извне вашего периметра - от провайдера, вендора, подрядчика. Это цифра для разговора с поставщиком, а не с вашей командой.

Как считаем. Доля инцидентов с указанием внешней виновной стороны.

Откуда определение. ITIL 4, практика управления поставщиками (supplier management practice).

Что нужно от вас. Нужен экспорт с полем «виновная сторона» или «поставщик».

Что это. Какую долю операций процесса вы считаете допустимым потерять, прежде чем признать нарушение операционной надёжности.

Как считаем. Журнал инцидентов знает, что сервис был затронут, но не знает, сколько операций при этом не прошло - а показатель считается именно от операций. Одного допустимого значения здесь мало: нужна ещё фактическая доля.

Откуда определение. Положение Банка России № 787-П от 12.01.2022, п. 3, показатель 1. Целевые значения кредитная организация определяет сама, на основании статистики не менее чем за двенадцать месяцев - то есть по собственной истории, а не по чужому среднему.

Что нужно от вас. Целью не лечится - нужна выгрузка с числом операций технологического процесса за тот же период (или готовая доля затронутых операций по каждому инциденту). Тогда допустимое значение из вашего внутреннего документа станет с чем сравнивать.

Что это. Предел длительности одного инцидента - сколько сервис может лежать единовременно.

Как считаем. Доля инцидентов, уложившихся в ваш предел, и перечень тех, что не уложились, с длительностями.

Откуда определение. 787-П, п. 3, показатель 2.

Что нужно от вас. Допустимое время простоя в рамках одного инцидента (в часах).

Что это. Годовой предел простоя по процессу.

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

Откуда определение. 787-П, п. 3, показатель 3.

Что нужно от вас. Допустимое суммарное время простоя за календарный год (в часах).

Что это. Насколько процесс был доступен именно в те часы, когда он обязан работать. Ночной простой в круглосуточном процессе и в процессе «с 9 до 18» - разные события.

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

Откуда определение. 787-П, п. 3, показатель 4.

Что нужно от вас. Два ответа: режим работы процесса (например «круглосуточно» или «пн-пт 09:00-18:00») и допустимое значение показателя.

Что это. Шесть показателей о состоянии ресурсов: загрузка ключевых ресурсов по 95-му перцентилю, задержка передачи пакетов, доля потерянных пакетов, неравномерность задержки, успешность резервного копирования и сроки сертификатов, доля компонентов без поддержки вендора. Они отвечают на другой вопрос, чем весь остальной отчёт: не «что уже сломалось», а «где вы близко к краю».

Как считаем. Сравниваем ваши значения с отраслевым профилем. Для сетевых показателей у ITU-T есть редкая вещь - числовые границы, а не только определения (Y.1541, Таблица 1: средняя задержка до 100 мс для класса 0, вероятность потери пакета до 1x10^-3). Сам стандарт оговаривает, что значения предварительные, и мы эту оговорку воспроизводим.

Откуда определение. ITU-T Y.1540 (07/2016) - IPTD, IPLR, IPDV; ITU-T Y.1541 (05/2002), Таблица 1 - числовые границы. Загрузка ресурсов, бэкапы и поддержка вендора стандарта с числовой нормой не имеют, это практика. Слово «джиттер» мы не используем: у ITU-T такого термина нет, есть «вариация задержки» (IPDV).

Что нужно от вас. Журнал инцидентов эти шесть показателей не содержит в принципе. Пришлите выгрузку метрик за тот же период: время измерения и колонка значений по каждому показателю.