Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

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

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT