Портал №1 по управлению цифровыми
и информационными технологиями

Подходы к учёту простоя услуг

Опубликовано 17 мая 2019
Рубрики: SLA, SLM, BRM, Вопрос из зала, Обо всём на свете, Практика и опыт
Комментарии

В редакцию портала поступил вопрос:

Добрый день, в процессе заключения SLA есть необходимость согласования подхода к корректному учету простоев ИТ-услуги (и даже сервисной операции), а именно: как справедливо определить, когда услуга простаивает полностью, а когда — частично, и как это учесть в расчете показателя доступности.

Например, части пользователей (или клиентов) функционал (=ИТ-услуга) доступен, а части — нет. При этом нет уверенности, что все затронутые сбоем потребители сообщили о недоступности, а систем мониторинга, которые точно бы определили число пострадавших, нет.

Если ориентироваться на то, что простоем считать только случаи, когда инфраструктура (сервера, БД) или прикладная часть отказывают полностью, то такие ситуации происходят крайне редко, и мы, не учитывая прочие сбои, которые случаются значительно чаще, получим некорректное представление о доступности ИТ-услуг.

Подскажите, пожалуйста, есть ли какие-то общепринятые подходы к учету полного и частичного простоя услуг? Насколько корректно будет ввести какой-то показатель количества затронутых потребителей в единицу времени, при достижении которого мы будем считать, что услуга недоступна полностью для всех (даже тех, кто не обратился)?

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление уровнем услуг и каталогом услуг
Разработка каталога, SLA, метрик качества, расчёт доступности

Также по теме:

Комментариев: 6

  • Сергей

    Приветствую. Поделюсь своим опытом.
    В зависимости от масштаба системы (с учётом отсутствия адекватного мониторинга) – расчёт может быть простым:
    – более N (кол-во) пользователей сообщили о сбое в течении ЧЧ (15,30,60 минут…)
    – более N (кол-во) пользователей с X (кол-во площадок) площадок сообщили о возникшем сбое в течении ЧЧ (15,30,60 минут…)
    Такой расчёт можно легко автоматизировать в системе (с учётом что услуги корректно выбираются) что бы она дальше сама мониторила и уведомляла об этом (и\или поднимала приоритет автоматически).
    Удачи.
    Всё что больше – считать КРИТОМ и полной недоступностью.

  • Владимир Невский

    Приветствую. Добавлю из своего опыта.
    Ввести чекбокс: есть/нет простоя сервиса.
    Ввести понятие уровень или степень деградации сервиса (в %):
    0% – нет простоя;
    10-90% – частичная недоступность и/или потеря производительности;
    100% – полная недоступность сервиса.
    Проставление значений на основании экспертного мнения или математической формулы (7 банкоматов из 100 встали – сервис деградировал на 7 %); вводить только для значительных (major) инцидентов, т.к. по остальным – не важно/трудоемко.

    • Екатерина

      Спасибо. От параметра деградации мы как раз и хотим уйти в сторону более точных вычислений, как и от того, чтобы учитывать простои только по критичным событиям, т.к. при этом влияние инцидентов прочих приоритетов на оценке уровня услуг не сказывается (а на впечатлении о качестве услуг у клиентов и пользователей сказывается).

  • Дмитрий Исайченко

    1. Учёт доступности (как и вообще измерение качества) корректнее вести не в разрезе услуг, а в разрезе SLA, поскольку отказы могут по-разному влиять на разных потребителей одной и той же услуги (отказы сети, например, могут влиять на определенные группы пользователей, а само влияние может быть различно, поскольку в разных SLA могут быть согласованы разные календари предоставления услуги).
    2. Понятие частичного отказа иногда на практике вводится. В этом случае для расчёта показателей доступности необходимо знать полный состав сервисных операций, чья доступность подлежит измерению, и их относительную важность (веса). Или просто договариваются, что частичное нарушение доступности все же по сути есть нарушение доступности и должно входить в KPI, независимо от полноты.
    3. Доступность на основании запросов пользователей корректно не рассчитать. Запросы могут использоваться только как сигнал о глобальном отказе (он же массовый инцидент, он же авария – кто как называет). Глобальный отказ обычно и регистрируется, и обрабатывается отдельно от запросов пользователей.
    4. После устранения глобального отказа процесс должен предусматривать формирование отчёта, в котором приводятся точные временные границы отказа, услуги и функции, затронутые отказом, степень влияния (полный отказ или деградация). Этот отчёт согласуется руководством и является основанием для расчета доступности по всем SLA, затронутым отказом.

    • Екатерина

      Спасибо.
      1. Конечно, учет доступности будет производиться для конкретного SLA, согласно спецификации услуг и сервисных операций, включенных в охват соглашения.
      2. Доступность услуги будет рассчитана из доступностей включенных в нее сервисных операций, с учетом веса каждой из них. Например, есть услуга авторизации в личном кабинете клиента. Авторизация может быть выполнена разными способами (это будут сервисные операции):
      – постоянным логином/паролем;
      – ЭЦП;
      – временным автоматически сгенеренным кодом.
      Мы получаем N обращений от клиентов, что авторизация по паролю не работает. При этом, у клиентов, авторизующихся другими способами, проблем нет. К тому же мы не знаем точное число пострадавших (кто-то не обратился, кто-то в этот момент услугой не пользуется и пр.)
      В этом случае, получается, единственным способом, признать, что сервисная операция полностью недоступна – это ввести критерий N обратившихся в единицу времени.
      Контраргументы со стороны ИТ:
      – больше времени на подтверждение/отклонение простоя: ранее в учет попадали только критичные сбои);
      – погрешность при вводе параметра N: инфраструктура распределенная, все N пострадавших могут находиться на одном сервере, тогда как другие потребители на других серверах проблем не испытывают).

      • Татьяна

        Добрый день.
        Можно пойти по пути “тот, кто закрывает инцидент в системе ITSM – указывает % доступности той или иной операции”. То есть, ИТ придется научиться определять % затронутых пользователей.
        А дальше возникнет потребность в еще большей точности.
        Если у вас есть полный список операций и их связь с услугами – вы можете прийти к автоматическому определению % деградации именно для них, при наличии сформулированных не функциональных требований: график доступности, время отклика, максимальная интенсивность, выполнение без ошибок и др.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.