Портал №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: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;