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

  • Рубрики

  •  
  • Авторы

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

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT