Граница между двумя процессами – управление доступностью и управление непрерывностью ИТ-услуг – неочевидна, и часто вызывает сложности, особенно у тех, кто только знакомится с ITIL. Действительно, процессы используют схожие техники. В основе обоих процессов лежит понятие риска: мы должны идентифицировать нежелательные события, угрожающие вывести из строя услуги, затем думать, как с этим справляться. И в том, и в другом случае требуется понимание критических бизнес-функций (VBF) и анализ влияния отказов услуг/систем на бизнес-процессы (BIA). Оба процесса, в конечном счете, решают задачу обеспечения устойчивости организации к отказам.

Так ли важно разделять эти процессы? На прошедшем недавно курсе PPO мы с группой составили небольшую табличку, иллюстрирующую различия, которую я с незначительными правками привожу здесь:

CONT не интересуют незначительные и короткие сбои, не имеющие серьезного влияния на бизнес. В охват CONT попадают риски, связанные со значительным ущербом независимо от вероятности их наступления. Это часто ЧС, disasters, такие как пожары, затопления, отключения электричества, недоступность ЦОДа или целых площадок и т.д. Несмотря на то, что AVA не забывает о негативном влиянии отказов на бизнес-процессы, в процессе также рассматриваются незначительные прерывания отдельных компонентов.

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

Назначение AVA: обеспечение того, что уровень доступности предоставляемых услуг соответствует текущим и будущим согласованным требованиям заказчиков при разумном уровне затрат. Мы пытаемся достичь максимального уровня доступности при имеющихся ресурсах, оптимизируем. CONT, не забывая, конечно, об экономической оправданности мер, почти всегда создает избыточность (резервные площадки, подменный фонд оборудования, соглашения на предоставление мощностей в случае ЧС). Задачи – явно конфликтующие, и на определенном масштабе не совмещаемые в одной голове.

Процессы используют разные метрики. В AVA – это:

• MTRS – среднее время восстановления услуги.
• MTBF – среднее время между сбоями (от возобновления работы после сбоя до следующего сбоя).
• MTBSI – среднее время между инцидентами (от сбоя до следующего сбоя).

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

• RTO (recovery time objective) – целевое время восстановления. За какое время после сбоя мы должны возобновить предоставление услуги.
• RPO (recovery point objective) – целевая точка восстановления. ЧС часто приводят к полному отказу или даже разрушению систем и потери данных. В зависимости от того, потеря данных за какой период критична для бизнеса, мы понимаем, какую частоту и способ резервного копирования должны выбрать.

AVA работает со статистикой, анализирует тенденции, CONT озабочен тем, как не допустить значительные разовые простои.

Несмотря на все различия, ISO 20000 эти два процесса объединяет, а MOF4 идет еще дальше и вводит функцию надежности, в которой учтены все четыре аспекта гарантии (доступность, мощность, безопасность, непрерывность).

Что вы думаете о границе между управлением доступностью и управлением непрерывностью? Какой подход ближе: объединять/разделять? Может быть, есть практический опыт реализации этих процессов.

ОБУЧЕНИЕ

IT Service Management

Учебные курсы от соавторов ITIL 4