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

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

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

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

Корень зла

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

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

“Ничего не понятно, но очень интересно”.

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

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

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

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

Работы

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

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

• Интерфейсы/каналы подачи запросов по ИТ-услуге не доступны или не функциональны;
• Срок выполнения запроса с установленной в соглашении об уровне услуг (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. Обеспечить прозрачность контроля и изменений доступности:
   • Регулярная отчетность / доклад заказчику ИТ-услуги о достигнутом уровне доступности ИТ-услуги в соответствии с требованиями соглашения/договора.
   • Визуализация операционной доступности отдельных функций / ИТ-ресурсов.