Граница между доступностью и непрерывностью

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

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

Управление доступностью (AVA)

Управление непрерывностью (CONT)

Фокус на рисках с высокой вероятностью

Фокус на рисках с высоким ущербом (ЧС, disasters)

Больше проактивный

Больше реактивный

Снижает вероятность наступления нежелательных событий

Снижает ущерб от наступления нежелательных событий

Акцент на технических решениях

Акцент на организационных мерах

Оптимизация

Создание избыточности

Не является частью корпоративной функции

Часто является частью корпоративной функции

Business-as-usual

Форс-мажор

MTRS, MTBF, MTBSI

RTO, RPO

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 идет еще дальше и вводит функцию надежности, в которой учтены все четыре аспекта гарантии (доступность, мощность, безопасность, непрерывность).

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

ITIL ITIL Intermediate: Planning Protection and Optimization

Учебный курс: управление качеством и рисками ИТ-услуг, доступностью, мощностями, непрерывностью — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Ivan Krouglyi

    Оптимизация

    Создание избыточности

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

    В остальном полезная (для меня) статья, спасибо.

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

    Извините за поток сознания, пока каша в голове.

    1. Павел Дёмин Автор

      Про разделение рисков. Все верно. Если представить карту рисков (вероятность – по оси X, ущерб по оси Y), то в охват управления непрерывностью, как правило, попадают риски из самой верхней части карты. Список таких событий в целом универсален: пожар, затопление, отключение электричества, отсутствие ключевого персонала и т.д. Их характеризует: а) очень высокий потенциальный ущерб; б) как правило, не очень высокая вероятность; в) отсутствие объективной возможности или сложность/неоправданно высокая стоимость предотвращения. События, критичные для конкретной организации, прописывают, исходя из чего разрабатывают стратегию обеспечения непрерывности, планы реагирования и восстановления.

      Про оптимизацию/избыточность. Поясню, что имел в виду, хотя, наверное, это самая спорная часть. Конечно, и в доступности, и в непрерывности мы скорее всего наращиваем ресурсы, что стоит денег. Главный вопрос в том, что это за ресурсы? AVA должен обеспечить достижение целевых показателей и конечно использует рейды, кластеры, дублирование каналов, без которых условные 99,9%, определенные в SLA, не достижимы. CONT вводит и затем отвечает за дополнительные ресурсы, которые не используются в business-as-usual, а только в случае наступления предопределенных событий. Пожарные лестницы не используются, если лифты работают штатно, и нет угрозы персоналу; и не влияют на уровень доступности лифтов. В этом смысле, с точки зрения целевого уровня доступности, меры непрерывности, как правило, избыточны, и связаны с конкретными событиями типа disaster.

  2. Андрей

    У меня вопрос несколько общего плана — на сколько доступность и непрерывность ИТ услуги можно рассматривать в качестве самостоятельных, независимых сущностей? 

    Может ли услуга быть доступной, если её предоставаление прервано (она не непрерывна)? Можно ли ИТ услугу считать непрерывной, если она в некий момент стала недоступна?

    1. Павел Дёмин Автор

      Андрей, спасибо за вопрос.

      Забавно, что в ITIL отсутствует определение «непрерывности». ISO22301 (в прошлом BS25999), стандарт по непрерывности бизнеса, дает следующее определение:

      Business continuity – capability of the organization to continue delivery of products or services at acceptable predefined levels following disruptive incident.

      Непрерывность бизнеса – это способность организации продолжать (возобновлять) поставку продуктов или услуг на предопределенном согласованном уровне после разрушительного инцидента.

      Почти также непрерывность бизнеса определяет BCI (Business Continuity Institute):

      Business Continuity — the strategic and tactical capability of the organization to plan for and respond to incidents and business disruptions in order to continue business operations at an acceptable predefined level.

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

      Согласно ITIL, доступность – это способность ИТ-услуги или другой конфигурационной единицы выполнять согласованную функцию, когда это требуется.

      Может ли услуга быть доступной, если её предоставаление прервано (она не непрерывна)? Можно ли ИТ услугу считать непрерывной, если она в некий момент стала недоступна?

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

      Полагаю, что

    2. Нарушение доступности не всегда нарушение непрерывности. Упали, но своевременно поднялись/возобновили/продолжили (continue) работу.

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

      1. Андрей

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

        Что касается Business Continuity, то этот процесс на мой взгляд нахродится вне ИТ и служит для формирования требований к ИТ. Фактически он определяет параметры SLA — допустимое время(частота, длительность каждого и т.д.) недоступности обеспечивающей ИТ услуги, при котром еще можно продолжать бизнесс процесс без существенных потерь. И уже на основе данного параметра ИТ начинает готовить решение. Но вот в каком процессе? Помимо AVA и CONT еще и  Design есть. И вернее всё это было бы делать как раз на  этапе Design. Там связь избыточных инвестиций в надежность прямо связана с требованиями бизнеса и потому понятна. Еще одна проблема есть в определении самого понятия доступность в SLA. Оно почему-то разделяется на доступность(работает/не работает) и производительность. Лично моя позиция состоит в том, что такое разделение неправильно. Если качество услуги не соответствует требованиям бизнеса, то и услуга не доступна. Услуга доступна, но другая, не та что нужно. По моей любимой аналогии с производством это выглядит следующим образом — для сборочного процесса нет разницы — не привезли гайки вообще, либо вместо М10 привезли М8. В любом случае процесс не может выполняться.

        1. Павел Дёмин Автор

          Business Contunuity конечно вне ИТ, но от ИТ сильно зависит, в силу того, что почти нет бизнес-процессов без ИТ-составляющей. В рамках Business Contunuity определяется RTO бизнес-процесов/бизнес-операций. Далее в ИТ-непрерывности мы анализируем, какие компоненты поддерживают критические бизнес-процессы, пониманием требования (RTO) к компонентам. 

          Но вот в каком процессе? Помимо AVA и CONT еще и  Design есть. 

          Service Design -- фаза жизненного цикла услуги, на которой и управление доступностью, и управление непрерывностью играют существенную роль. Именно в книге Service Design обсуждаемые процессы и описаны.

          Еще одна проблема есть в определении самого понятия доступность в SLA. Оно почему-то разделяется на доступность(работает/не работает) и производительность. 

          Вопрос с производительностью всплывает, когда требуется определить критерий доступности. Какую ситуацию мы считаем отказом услуги, а какую -- нет. Граница обычно определяется как минимум следующими факторами:

          — затронутая функциональность (VBF/не VBF)

          — масштаб (количество затронутых пользователей/площадок/офисов)

          — уровень деградации (система в целом работает, но подключение занимает минуту, отчеты формируются, но слишком долго). Вот тут и возникают вопросы производительности.

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26