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

Интервал недоступности

Организации, ставящие перед собой задачу контроля качества предоставляемых ИТ-услуг, измеряют показатель  доступности. Что такое доступность услуги и как она измеряется в реальной жизни?

Давайте разбираться.

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

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

Корень зла

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

Известна, также, формула расчета доступности, где в числителе стоит «время которое услуга была доступна», а в знаменателе «время которое услуга должна быть доступна».

«Ничего не понятно, но очень интересно».

Ответ на вопрос «что такое доступность ИТ-услуги» поставщик ИТ-услуги ищет в утверждении о предоставляемой потребителям ценности, зафиксированное (не навсегда, может меняться!) в документации по услуге, инвестиционных материалах, решениях по разработке и вводу услуги в эксплуатацию.

Ценность доставляемая потребителю обычно выражается:

  • в предоставлении пользователям ИТ-ресурсов, которыми последние пользуются для достижения собственных целей/ выполнения бизнес-операций (для корпоративных пользователей);
  • в выполнении работ в интересах пользователей.

Знание о том, что именно предоставляется пользователю, как предоставленное пользователю используется им, позволяет приблизиться к тому, чтобы сформулировать определение доступности для выбранной ИТ- услуги.

Работы

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

Примеры критериев недоступности ИТ-услуги:

  • Интерфейсы/каналы подачи запросов по ИТ-услуге не доступны или не функциональны;
  • Срок выполнения запроса с установленной в соглашении об уровне услуг (SLA) длительностью нарушен и запрос не выполнен;
  • Запросы отдельных пользователей, сгруппированных по территориальному, организационному или иному признаку не могут быть обработаны или исполнены в нарушение SLA.

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

В качестве примера, если услуга предоставляется розничному потребителю (телефонная связь) и среди предоставляемых по договору сервисных запросов есть «Консультация по подключенным тарифным опциям», то ее непредоставление его в установленный договором срок может быть сформулировано в формате интервала недоступности: от точки наступления дедлайна по запросу до момента его фактического предоставления.

В реальной жизни, поставщики телефонной связи понимают, что максимальную ценность в моменте потребители получают от наличия и качества самой телефонной связи и не включают в определение недоступности просрочку выполнения запросов.

Нарушение своевременности выполнения сервисных запросов в B2B, корпоративном сегменте могут быть быть включены в определение недоступности более явным и экзотическим образом, исходя из ценности тех или иных запросов для заказчика ИТ-услуги:

  • нарушение нормативов длительности, выделяемой на оценку запросов на доработку ИТ-системы (дисфункция процесса управления изменениями в рамках предоставляемой ИТ-услуги по поддержке и развитию ИТ-системы);
  • нарушение нормативов по выполнению запросов поддержки, связанных с закрытием операционного дня (критичное бизнес-событие в банках);
  • снижение доли своевременно обработанных запросов (произвольной критичности) ниже установленного порога на временном интервале (например, день)
Ресурсы

Если ценность предоставляется в виде предоставляемых ресурсов, то в этих случаях недоступность определяется как выявленный дефект осуществления функции ресурса. Часто ресурс может предоставлять пользователям множество функций, поэтому и определение недоступности может иметь достаточно развернутое представление.

Примеры элементов определения недоступности:

  • отсутствие трафика через канал связи;
  • деградация скорости трафика через канал связи ниже определенного порога;
  • недоступность API (отсутствие ответа);
  • скорость ответа API превышает n миллисекунд;
  • невозможно войти в ИТ-систему;
  • невозможность выполнить определенную операцию (например, закрытие операционного дня отделения банка)
  • операция закрытия операционного дня выполняется дольше n минут (скорость выполнения отдельных функций ниже оговоренных порогов)
  • главная страница магазина создается дольше 1 секунды
  • веб-сайт не может быть открыт на протяжении интервала (5 минут)
  • функции «корзины», интерфейса «оплаты», выбора точки доставки заказа не функциональны на протяжении интервала (5 минут)
  • веб-сайт считается недоступным в течении бизнес-дня, если  в течении этих суток было 2 и более пятиминутных интервалов, когда сайт не мог быть открыт, или любой интервал простоя сайта превышал 10 минут по длительности

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

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

Интервалы

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

Чаще всего ИТ-услуга в целом считается недоступной, если выполняется хотя бы один из разработанных по ней критериев недоступности.

Если несколько зафиксированных нарушения критерия доступности приводятся к одному интервалу, то эти длительности интервалов недоступности суммируются с учетом их пересечения.

Измерение

В идеальном мире единорогов все критерии доступности строго сформулированы и измеряются аппаратными средствами:

  • тотальный мониторинг доступности интерфейсов, API, веб-страниц;
  • анализ событий, логов;
  • непрерывное end to end тестирование функций (с помощью RPA и иных инструментов);
  • строгий контроль нормативов SLA по выполнению работ в зависимости от типа запроса, контекста (период сдачи отчетности) и прочих факторов;
  • автоматизированная консолидация отчетности с возможностью детализации.

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

Иногда, в отсутствии достаточных средств мониторинга можно наблюдать спорные практики определения интервалов недоступности:

  • За интервалы недоступности принимаются длительности инцидентов по услугам. Чем плохо:
    • не все инциденты всегда должны трактоваться как недоступность;
    • недоступность ИТ-услуги (не отдельного компонента!!) по инциденту должна считаться как превышение MTTR, а не как полная длительность инцидента;
    • длительность зарегистрированного инцидента может быть не релевантна реального интервала недоступности: его начала и завершения;
    • критично зависит от точности классификации пользовательских запросов (инцидент или запрос на обслуживание).
  • Доступность рассчитывается для каждого из пользователей отдельно и усредняется. Чем плохо:
    • при большом числе пользователей скрывает реальное влияние простоев на небольших группах / индивидуумах;
    • игнорирует совокупное влияние недоступности на процессы корпоративного заказчика, подразумевая идентичность пользователей.
  • Отказ от измерения доступности, возможности потребления ИТ-услуги на «последней миле», в конечной точке потребления. Чем плохо:
    • потеря/отсутствие объективной обратной связи и данных по фактам реального потреблению ИТ-услуги или отказов
    • невозможность без проведения расследования определить реальное начало интервала недоступности.
  • Тестирование комплектных услуг только примитивными средствами «условно, на ping отвечает». Чем плохо:
      • отсутствие информации о действительной доступности ИТ-услуги (ресурса) для потребителя, использующего отдельные функции продукта (наличие ответа хоста на ping не гарантирует возможность выполнения авторизации и т.п.).
Что помогает в отсутствии покрывающей автоматизации?
  1. Использовать всю доступную автоматизацию для тестирования и мониторинга ИТ-ресурсов, планировать развитие средств контроля и измерений для критичных функций ИТ-ресурсов.
  2. Вынести расследование недоступности в отдельное, но строго соблюдаемое производство:
    • Разработать и четко сформулировать критерии недоступности (или подозрения на недоступность) и включить их в определение Major инцидента. Обязать и контролировать дисциплину регистрации записей о Major инцидентах при получении информации о сбоях от средств мониторинга или наличии множественных обращений с сообщениями о инцидентах.
    • Проводить по Major инцидентам отдельное расследование, в рамках которого явно устанавливается факт наличия интервала непрерывности, его начало и окончание, интервал операционной недоступности отдельных ИТ-ресурсов или функций.
  3. Использовать объективные данные ITSM системы для контроля нормативов на выполнение работ/сервисных запросов в  рамках ИТ-услуги (предполагается, что процессы поддержки, изменений системно работают, измеряются и контролируются).
  4. Обеспечить прозрачность контроля и изменений доступности:
    • Регулярная отчетность / доклад заказчику ИТ-услуги о достигнутом уровне доступности ИТ-услуги в соответствии с требованиями соглашения/договора.
    • Визуализация операционной доступности отдельных функций / ИТ-ресурсов.

 

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

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

  • Рубрики

  •  
  • Авторы

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

    • Куда растворился Access management в ITIL4?
      Коллеги, доброго дня. Неожиданный вопрос: куда растворился Access management в ITIL4? В практике Request Mgmt есть упоминание о том, что запросы на доступ управляются в практике Security Mgmt, но в описании этой практики нет об этом ничего, кроме управления инцидентами безопасности и аудита и ревью. Есть легкий намек, что эта практика используется в access control.
    • Конференция «Качество данных 2022. Стратегии, инструменты, практики, перспективы»
      Приглашаем принять участие в третьей ежегодной конференции «Качество данных 2022. Стратегии, инструменты, практики, перспективы». «Качество данных» – единственная в России конференция, полностью посвященная стратегии и практике обеспечения качества данных, гарантирующего высокий уровень бизнес-решений, сервисов и процессов. «Качество данных 2022» – это совершенно новые практические кейсы и проекты в развитии, привлекшие наибольший интерес участников предыдущих конференций.
    • Лучшие материалы Digital Enterprise за 2021 год
      Редакция Digital Enterprise поздравляет Вас с наступающим Новым годом! В этом посте мы собрали ТОП 5 авторских публикаций от экспертов Cleverics и 10 самых популярных статей портала в этом году.
    • Cleverics. Сколько курсов пройти, чтобы точно хватило?Сколько курсов пройти, чтобы точно хватило?
      В IT невозможно дойти до предела совершенства — всегда есть куда расти. Основная сложность в работе специалиста IT в том, что IT очень изменчивая область. Вам необходимо постоянно учиться, чтобы выжить во всем этом — и не остаться в колесе Сансары, когда оно будет делать новый оборот.
    • Почему запуск продукта проваливается (и как этого избежать)
      Сколько запусков новых продуктов происходит каждый год? По данным Nielsen около 30 000 среди товаров повседневного спроса. Для программного обеспечения гораздо труднее найти
    • Российскому стандарту ITAM быть!
      Управление ИТ-активами (ITAM), как дисциплина, существует уже не первое десятилетие. Однако в силу ряда причин именно сейчас ИТ-организации начинают проявлять к нему все больший практический интерес. Почему ИТ-менеджеры сейчас обращают на ITAM пристальное внимание?
    • Здравствуй, (VUCA) Новый год!
      Каждый раз, провожая уходящий год, хочется оглянуться назад, посмотреть на то, что было и попробовать помечтать и спрогнозировать то, что будет (или может быть) в новом году.
    • Возврат в системе канбан
      Что делать на доске канбан с задачей, по которой требуется переделка?
    • Записи вебинаров 21 сезона CleverTALK
      16 декабря завершился двадцать первый сезон вебинаров CleverTALK. Благодарим вас за интерес к нашим вебинарам и за то, что делитесь информацией о них!
    • Играйте в деловые игры ответственно
      Мы довольно давно проводим различные деловые игры. Надо сказать, что они действительно учат делать правильные выводы. И эти выводы рождаются благодаря приобретаемому опыту. Один
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT