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

Ключевые практики управления доступностью и непрерывностью

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

Собственно, вопросы есть уже к списку ключевых практик, которые необходимы для реализации назначения процесса. Здесь необходимо сделать оговорку, что я рассматриваю вариант ISO/IEC 20000, согласно которому управление доступностью и непрерывностью совмещены. Однако суть упражнения не поменяется и при разделении процессов. С оглядкой на ITIL и COBIT5 Enabling Processes получается следующий список ключевых практик:

  1. Планирование доступности и непрерывности на основе требований бизнеса

Раз уж мы должны обеспечить согласованный уровень доступности, он должен быть определен и документирован в SLA, а кроме того явно задана граница доступности и недоступности (об этом я писал в заметке про критерий доступности). Возможная метрика, которая покажет успехи в этом направлении: полнота определения требований и критериев доступности по ИТ-услугам.

Ключевое значение на способность предприятия реагировать на ЧС и восстанавливать критические ИТ-услуги является наличие документированных процедур по реагированию, восстановлению и возврату к штатному функционированию ИТ-услуг (планов непрерывности). В отсутствии таковых рассчитывать на восстановление в соответствии с RTO и RPO практически не приходится. С точки зрения планирования непрерывности важно обеспечить надлежащий охват, как правило, критичных услуг/VBF планами непрерывности. Возможная метрика: полнота покрытия критичных ИТ-услуг/VBF планами непрерывности.

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

  1. Снижение рисков нарушения доступности

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

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

  1. Проведение регулярных тестирований механизмов обеспечения доступности и непрерывности

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

Вроде набор правильный, но есть чувство недосказанности. Или нет? Буду признателен за фидбек.


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

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

Комментариев: 2

  • Anton Boganov

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

    • Не уверен, что до конца понял вопрос. 

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

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


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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT