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

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

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

Добрый день, в процессе заключения 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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT