Портал №1 по управлению цифровыми
и информационными технологиями

Управление доступностью и управление непрерывностью: почему слушатели ITSM постоянно их путают?

Практически на каждом курсе по основам ITSM возникает один и тот же вопрос: «Разве управление доступностью и управление непрерывностью – это не одно и то же? Ведь обе практики направлены на то, чтобы ИТ-услуга работала.»

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

Начнем с самой услуги

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

Представим интернет-банк.

С функциональной точки зрения заказчик ожидает, что система позволит:

  • просматривать остатки по счетам;
  • выполнять денежные переводы;
  • оплачивать услуги;
  • открывать вклады.

Все это — функциональные требования (полезность). Они отвечают на вопрос: Что должна делать услуга? Но этим требования бизнеса не ограничиваются. Бизнес также ожидает, что интернет-банк:

  • будет доступен практически круглосуточно;
  • быстро восстановится после серьезной аварии;
  • не потеряет данные клиентов;
  • будет работать достаточно быстро даже при высокой нагрузке.

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

К ним относятся:

  • доступность (Availability);
  • непрерывность (Continuity);
  • производительность (Performance);
  • информационная безопасность (Information Security);
  • мощность (Capacity);
  • надежность (Reliability);
  • время отклика и другие характеристики качества.

 

Именно эти характеристики во многом определяют ценность услуги для бизнеса.

  Где фиксируются эти требования?

Нефункциональные требования не должны существовать в виде устных договоренностей. Они согласовываются между поставщиком и заказчиком услуги и обычно фиксируются в SLA (Service Level Agreement). Именно SLA отвечает на вопрос: Каким должен быть уровень качества предоставляемой услуги?

Например, SLA может содержать следующие показатели:

                               Показатель

                            Пример значения

 Доступность услуги

 Не менее 99,9 % в месяц

 Максимальное время восстановления (RTO)

 Не более 4 часов

 Допустимая потеря данных (RPO)

 Не более 30 минут

 Максимальное время отклика

 Не более 2 секунд

 Время обработки инцидентов

 Согласно согласованным приоритетам

Обратите внимание: в SLA не описывается, как поставщик будет достигать этих показателей. В нем фиксируется лишь то, какой уровень сервиса ожидает бизнес. И здесь появляется важная роль практик ITSM.

Кто обеспечивает выполнение SLA?

Можно представить цепочку следующим образом: Бизнес формулирует ожидания → требования фиксируются в SLA → практики ITSM обеспечивают выполнение этих требований.

Именно поэтому различные практики отвечают за разные характеристики качества услуги.

Например:

  • Управление уровнем услуг (Service Level Management) согласовывает с бизнесом требования к уровню сервиса и контролирует выполнение SLA.
  • Управление доступностью (Availability Management) обеспечивает достижение согласованной доступности услуги.
  • Управление непрерывностью услуг (IT Service Continuity Management) обеспечивает возможность восстановления услуги после крупных аварий и катастроф.
  • Управление мощностью и производительностью (Capacity and Performance Management) обеспечивает необходимую производительность и достаточную емкость сервисов.
  • Управление информационной безопасностью (Information Security Management) обеспечивает выполнение требований по защите информации.
Получается важный вывод:

Доступность и непрерывность – это не процессы и не цели сами по себе. Это характеристики качества ИТ-услуги. А управление доступностью и управление непрерывностью – это практики ITSM, обеспечивающие выполнение соответствующих требований, зафиксированных в SLA.

После этого различия между двумя практиками становятся гораздо понятнее.

Два разных вопроса

Представим тот же интернет-банк. Теперь зададим два вопроса.

Первый вопрос: Будет ли интернет-банк работать сегодня, завтра и каждый день с той доступностью, которая обещана клиентам? На этот вопрос отвечает управление доступностью.

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

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

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

Для этого анализируются:

  • архитектура решения;
  • наличие единых точек отказа;
  • причины возникновения инцидентов;
  • надежность оборудования;
  • время восстановления после обычных отказов;
  • статистика простоев.

Типичные мероприятия управления доступностью:

  • резервирование компонентов;
  • мониторинг инфраструктуры;
  • анализ доступности;
  • повышение надежности архитектуры;
  • снижение количества отказов;
  • контроль показателей MTBF и MTTR.

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

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

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

  • пожар в дата-центре;
  • масштабная кибератака;
  • длительное отключение электропитания;
  • потеря облачного региона;
  • затопление серверной;
  • стихийное бедствие.

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

  • критичные услуги;
  • допустимое время восстановления (RTO);
  • допустимая потеря данных (RPO);
  • планы аварийного восстановления;
  • резервные площадки;
  • процедуры переключения;
  • порядок возврата к штатной эксплуатации.

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

Простая аналогия: представьте современную больницу.

Управление доступностью — администрация ежедневно обеспечивает:

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

Это обычная эксплуатационная деятельность.

Управление непрерывностью — но руководство также обязано ответить на вопрос: что делать, если произойдет пожар? Для этого заранее существуют:

  • планы эвакуации;
  • резервные операционные;
  • дизельные генераторы;
  • взаимодействие с другими медицинскими учреждениями;
  • инструкции для персонала.

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

Почему возникает путаница?

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

Управление доступностью говорит: Сделаем все возможное, чтобы серьезные простои происходили как можно реже.

Управление непрерывностью отвечает: Если произошла катастрофа, то мы заранее знаем, как восстановить услугу в приемлемые сроки.

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

Сравнение двух практик

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

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

 Выполнение требований по доступности из SLA

 Выполнение требований по восстановлению из SLA

 Работа в штатных условиях эксплуатации

 Работа при чрезвычайных ситуациях

 Предотвращение отказов

 Восстановление после катастроф

 Надежность сервиса

 Устойчивость бизнеса

 Мониторинг, резервирование, анализ отказов

 Disaster Recovery, планы восстановления, резервные площадки

 Основные показатели: доступность, MTBF, MTTR

 Основные показатели: RTO, RPO

Как легко запомнить различие?

Можно использовать простое правило.

Управление доступностью отвечает на вопрос: как обеспечить работу услуги каждый день в соответствии с SLA (чтобы услуга не переставала работать)?

Управление непрерывностью отвечает на вопрос: как восстановить услугу после катастрофического события в сроки, согласованные в SLA (чтобы услугу можно было быстро восстановить после серьезной аварии)?

Итоги

Несмотря на схожесть названий, управление доступностью и управление непрерывностью решают разные задачи. Важно помнить последовательность:

  1. Бизнес определяет, каким должно быть качество ИТ-услуги.
  2. Требования к качеству, включая доступность и непрерывность, фиксируются в SLA.
  3. Практики ITSM обеспечивают выполнение этих требований.
  4. Управление доступностью отвечает за достижение требуемого уровня доступности услуги в повседневной эксплуатации.
  5. Управление непрерывностью услуг обеспечивает восстановление услуги после крупных аварий и катастроф.

Именно поэтому эти практики не конкурируют друг с другом, а дополняют друг друга.

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM