Оригинал статьи How to Define, Measure, and Report IT Service Availability, автор Стюарт Ренс (Stuart Rance).

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

Сотрудники ИТ-службы прикладывают много усилий, чтобы убедиться, что обозначенная цель достигнута и показать в отчетах заказчикам цифры, подтверждающие это. Обычно ИТ-компании используют для этого проценты, например, 99,999%. К сожалению, зачастую это означает, что они сосредотачиваются только на процентном измерении и упускают из виду свою истинную цель – приносить пользу заказчику.

Проблема с процентной доступностью

В основе одного из простейших способов расчета доступности лежат две части. Вы согласуете временные интервалы, в течение которых услуга должна быть доступна в отчетном периоде. Это – согласованное время обслуживания (AST). Вы измеряете время простоя (DT) в течение этого периода. Вычитаете время простоя от согласованного срока доступности сервиса и превращаете это в процент.

Если AST составляет 100 часов и время простоя 2 часа, доступность будет такой:

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

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

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

Если ваша система доставки не дает тех результатов, на которые вы рассчитываете, и вы хотели бы изучить проверенную дорожную карту для оптимизации рабочих процессов с целью повышения их предсказуемости, мы будем рады приветствовать вас на нашем курсе «Flow Metrics: управление потоковым производством на основе данных».

Определение целевых показателей доступности

Если вы хотите измерять, документировать и отчитываться о доступности таким образом, чтобы это было полезно для вашей организации и ваших заказчиков, вам нужно сделать две вещи. Во-первых, определить контекст и закрепить смысл понятия  “доступность” для вас и ваших заказчиков. Для этого вам нужно поговорить с ними.

Во-вторых, вам следует тщательно продумать ряд практических вопросов: что вы будете измерять, как вы будете собирать данные, как будете их документировать и сообщать о полученных результатах.

Общение с заказчиками

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

Но что именно сказать заказчикам? Отличной отправной точкой для разговора может стать влияние времени простоя. Ниже приведены пять вопросов, которые вы должны задать:

1. Какие бизнес-функции являются критически значимыми и имеют важнейший приоритет в защите от простоя?
2. Как время простоя влияет на бизнес?
3. Как частота простоя влияет на бизнес?
4. Какое влияние простои оказывают на производительность организации?
5. Как эти вынужденные простои воспринимают заказчики организации?

Критически значимые бизнес-функции

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

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

Таблица 1 – Важность услуг в процентном соотношении

NB: Цифры не должны в сумме давать 100%

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

Продолжительность и частота простоя

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

Я уже упоминал, что процентная доступность может быть недостаточной. Когда услуга, которая должна быть доступна в течение 100 часов, имеет 98% доступность, это показывает, что было два часа простоя. Но это может означать как один двухчасовой, так и несколько более коротких инцидентов. Относительное влияние одного длительного инцидента или ряда коротких инцидентов будет различным, в зависимости от характера бизнеса и бизнес-процессов.

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

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

Таблица 2 – Длительность отключения и максимальная частота

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

Время простоя и производительность

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

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

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

Одним из способов определения воздействия является вычисление процента потерянных пользовательских минут. Чтобы сделать это:

• Вычислите PotentialUserMinutes. Это общее количество пользователей, которые работают в единицу времени. Например, если у вас 10 сотрудников, которые работают в течение 8 часов, то PotentialUserMinutes – это 10 x 8 x 60 = 4800
• Вычислите UserOutageMinutes. Это общее количество пользователей, которые не могли работать, умноженные на время, когда они не смогли работать. Например, если инцидент помешал 5 сотрудникам работать в течение 10 минут, то UserOutageMinutes – 50.
• Рассчитайте процентную доступность, используя очень похожую формулу на ту, что мы видели ранее

В приведенном примере, мы получили следующую доступность:

Вы можете использовать эту же методику для расчета влияния потерянной доступности IP-телефонии в колл-центре с точки зрения PotentialAgentPhoneMinutes и LostAgentPhoneMinutes; в случае приложений, которые занимаются транзакциями или производством, вы можете использовать аналогичный подход для количественной оценки воздействия инцидента на бизнес. Вы сравниваете количество транзакций, которые ожидались бы без простоя, по отношению к количеству фактических транзакций или объема производства, который предполагался по отношению к фактическому.

Измерение доступности и отчётность

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

• Что вы будете измерять?
• Как вы будете собирать данные?
• Как вы будете документировать свои выводы и сообщать о них?

Что измерять

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

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

Как собирать данные

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

Сбор данных в технической поддержке

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

Данный подход, как правило, довольно недорогой. Однако может привести к спорам о точности данных о доступности.

Измерение доступности инфраструктуры и приложений

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

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

Если ваша система доставки не дает тех результатов, на которые вы рассчитываете, и вы хотели бы изучить проверенную дорожную карту для оптимизации рабочих процессов с целью повышения их предсказуемости, мы будем рады приветствовать вас на нашем курсе «Flow Metrics: управление потоковым производством на основе данных».

Фиктивные заказчики

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

Фактически – это измерение сквозной доступности. В зависимости от размера и сложности сети, внедрение этого подхода может быть достаточно дорогостоящим, к тому же он сообщает только о доступности от конкретных фиктивных заказчиков. Это значит, что небольшие сбои могут быть пропущены, например, если инцидент привел к некорректной работе определенного веб-браузера, тогда как фиктивный заказчик использует другой браузер.

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

Доработка приложений

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

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

Как документировать и сообщать о своих выводах

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

Планируйте время простоя

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

Существует несколько способов убедиться, что запланированное время простоя не приводит к раздуванию статистики. Один из них – иметь запланированное время простоя в течение определенного отрезка времени, который не включается в расчет доступности. Другой – назначить запланированное время простоя. Например, некоторые организации могут не учитывать время простоя, запланированное на будущее, на месяц вперед.

Независимо от того, что вы решите сделать, важно, чтобы ваше SLA четко определяло, как будет учитываться запланированное время простоя.

Если ваша система доставки не дает тех результатов, на которые вы рассчитываете, и вы хотели бы изучить проверенную дорожную карту для оптимизации рабочих процессов с целью повышения их предсказуемости, мы будем рады приветствовать вас на нашем курсе «Flow Metrics: управление потоковым производством на основе данных».

Соглашение об отчетном периоде

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

Например, рассмотрим ИТ-компанию, которая согласилась на услугу 24×7 и доступность 99%. Предположим, что произошел восьмичасовой перерыв:

• если мы отчитываемся о доступности еженедельно, то AST (согласованное время обслуживания) составляет 24 x 7 часов = 168 часов
• ежемесячно AST (24 x 365) / 12 = 730 часов
• ежеквартально AST (24 x 365) / 4 = 2190 часов

Ввод этих чисел в уравнение доступности дает:

• Еженедельная доступность = 100% x (168-8) / 168 = 95,2%.
• Ежемесячная доступность = 100% x (730 – 8) / 730 = 98,9%
• Квартальная доступность = 100% x (2190-8) / 2190 = 99,6%

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

В заключении

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

Это длинная статья, ниже перечислены ключевые моменты, которые затронуты в ней:

• Не нужно говорить заказчику, что вы предоставили 98% -ную доступность, если у вас нет понимания влияния 2-процентного времени простоя
• Поговорите со своими заказчиками и убедитесь, что вы понимаете влияние любого простоя на них и на конечных заказчиков
• Подумайте о способах защиты критических бизнес-процессов ваших заказчиков
• Найдите способы измерения частоты и продолжительности простоя, также степени влияния времени простоя на производительность, которые соответствуют потребностям ваших заказчиков
• Согласуйте, документируйте и указывайте показатели доступности способами, которые имеют смысл для ваших заказчиков и помогают планировать
• Используйте соответствующие инструменты, чтобы правильно оценить доступность и сообщить в отчете.

Что еще вы могли бы добавить к моим советам? Пожалуйста, пишите в комментариях.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Построение системы KPI для ИТ

Как обеспечить управление процессами, проектами, услугами, персоналом