Нужен ли процесс управления доступностью?

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

Причина 1: Доступность уже обеспечивается другими процессами

Взглянем на задачи процесса:

  • Создавать и вести план доступности, отражающий текущие и будущие потребности заказчиков.

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

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

Диагностика и решение инцидентов и проблем – задачи соответствующих процессов.

  • Оценивать влияние изменений на доступность услуг и ресурсов.

Дело процесса управления изменениями.

Почти все задачи процесса, как они описаны в ITIL,– уже являются областью ответственности других процессов: управление инцидентами, проблемами, изменениями, SLM и так далее. Вопросы «где проходит граница с другими процессами», «есть ли у управления доступностью уникальные задачи» и «почему все эти дела должны быть выделены в процесс» на уровне перечня задач остаются открытыми.

Причина 2: Управление доступностью – это функция

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

Процесс – это последовательность действий, объединенных общей логикой, триггером, результатом. По мнению авторов ISM Method, далеко не все «процессы» ITIL соответствуют этому определению. В отношении управления доступностью с этим легко согласится: несмотря на наличие стрелочек, трудно сложить из кирпичей концептуальной модели ITIL логичную повторяемую последовательность исполнения процесса:

availability_mgmt

Тем не менее, что можно вынести из ITIL в отношении управления доступностью? Сервис-провайдер должен:

  1. Проектировать новую или проводить существенное изменение услуги с учетом доступности (закладывать в решение необходимые механизмы отказоустойчивости).
  2. Управлять рисками недоступности услуг. Оценивать риски недоступности, разрабатывать и внедрять контрмеры (механизмы обеспечения доступности) на всех этапах жизненного цикла услуги.
  3. Тестировать механизмы в рамках внедрения сервисного решения и уже внедренные механизмы обеспечения доступности на периодической основе.
  4. Отслеживать текущий уровень доступности, готовить отчетность, анализировать отклонения и готовить предложения по совершенствованию.

Дела, безусловно, важные. Но, на мой взгляд, в реальной жизни п.1 выполняется в рамках проектной деятельности архитекторами решений; п.2 – в рамках управления рисками (если такая практика есть), в рамках управления непрерывностью или не выполняется вовсе. П.3 распадается на две части: проверки внедряемых механизмов проводится в рамках управления релизами/изменениями/проектами; тестирование уже имеющихся средств резервирования и обеспечения отказоустойчивости – аналогичная задача есть в процессе управления непрерывностью. П.4: в отношении услуг – задача SLM; в отношении инфраструктуры анализ отклонений и разработка решений может быть работой в рамках управления проблемами.

Что получается: нет никакого процесса управления доступностью? Все распространенные своды знаний обходятся с Availability Management, в отличие от ITIL, достаточно бесцеремонно: ISO/IEC 20000 совмещает управление доступностью с управлением непрерывностью, COBIT5 и CMMI for Services – с управлением мощностями, MOF включает наряду с управлением непрерывностью, мощностями и безопасностью в функцию надежности. Радикальнее всех поступили авторы ISM Method, которые практику управления доступностью относят к Quality Management (наряду с Capacity, Security, Continuity Management и даже управлением проблемами). Задача Quality Management – «сдерживать риски, которые угрожают предоставлению ИТ-услуг и обеспечивать совершенствование предоставления ИТ-услуг».

В своей практике я встречал варианты организации процесса согласно ISO/IEC 20000 (совмещение управления доступностью и непрерывностью), но и здесь не все однозначно (об этом в другой раз). Интересно, какие варианты в реальной жизни возможны еще? Коллеги, если встречали управление доступностью или его кусочки в «дикой природе», буду признателен за комментарии.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Planning Protection and Optimization

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

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

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

  1. Дмитрий Исайченко

    Я много думал об этом. Мое мнение — в ITIL несколько непривычно определены термины Процесс и Функция (в том же eTOM, а точнее — GB921, это сделано по-другому, аккуратнее). Эти определения иногда приводят к путанице, а иногда являются поводом для подобных вопросов. Хотя повода, по сути, нет. Поясню.

    Процесс в ITIL — это "a structured set of activities designed to accomplish a specific objective". Функция — это "a team or group of people...". Согласно этим определениям управление доступностью — безусловно процесс.

    А подобные вопросы возникают просто потому, что мы привыкли немного к другим понятиям. То, что в ITIL называется функцией, это по сути организационное подразделение (organizational unit). Под функцией мы обычно понимаем некоторую область ответственности организации или ее части. Например, основные функции коммерческой организации — продвижение, продажи, поставки товара, обслуживание клиентов. А один из стндартных разделов положения о структурном подразделении — функции данного подразделения. Процесс же — это некоторый способ организации деятельности, направленной на реализацию одной или нескольких функций или ее части. То есть функция — это содержание (что делать), а процесс — форма, способ (как делать). И, разумеется, функция может быть реализована в виде нескольких взаимосвязанных процессов и наоборот.

    И в этом смысле управление доступностью — конечно функция (и, кстати, вспомните SMF в MOF). Хороший аналогичный пример здесь — это управление безопасностью, которое в ITIL тоже названо процессом. Может ли управление информационной безопасностью быть единым процессом в том смысле, в котором автор спрашивает про управление доступностью? На мой взгляд, ответ очевиден.

    Такой ответ годится?

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

      Дмитрий, рассуждения очень любопытные, спасибо!

      Если ставить вопрос "управление доступностью — процесс или функция?" или "может ли быть управление доступностью едиными процессом?", то наверное дан исчерпывающий ответ. Более того универсальный для всех подобных затруднительных ситуаций. И пример с управлением ИБ тоже очень понятный. С моим пониманием совпадает.

      Но вторая часть вопроса, которую хотелось прояснить: вот то, что ITIL называет управлением доступностью (не важно, процесс это, функция или, скажем, практика — как предлагают нам авторы ISM Method) — вот оно как и где? Как в реальной жизни (могут быть) организованы оценка рисков недоступности, тестирование механизимов обеспечения недоступности, расследование инцидентов недоступности и далее по картинке с видами деятельности. Какие из видов деятельности совмещаются с другими "практиками" по управлению услугами? С какими? Что остается чисто проектными задачами? И так далее. Понятно, что возможны самые разные компоновки. Интересны жизненные.

      0
      0
  2. Альберт

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

    0
    0
  3. Владимир

    Я встречал  в живой природе процесс управления доступностью в части расчета доступности и потерь Бизнес-процессов на основании Инцидентов, регистрируемых в Service Desk (аналог расчёта Service Level Management). 

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

    По-простому - это был инструмент, с помощью которого можно было увидеть/обратить внимание только на те Инциденты, из-за которых бизнес страдал больше всего (по сути, лупа для наблюдения и выжигания недостатков в процессе управления инцидентами).

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

    Расчет доступности и потерь сводился к расчету доступности объектов в процентах:

    — Бизнес-операций (шагов БП).

    — Бизнес-процессов (исходя из доступности входящих в них Бизнес-операций).

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

    — Информационных систем (Конфигурационных элементов), которые деградировали от Инцидентов.

    — Также рассчитывались потенциальные финансовые потери, возникшие из-за снижения уровня доступности бизнес-процессов (в рублях): по сути, это виртуальная недополученная прибыль исходя из фактической прибыли и доступности БП, с помощью которого получили эту прибыль (например, заработали на сервисе за неделю 100 рублей, при этом сервис был доступен на 98%, т.е. 2 рубля потеряли из-за Инцидентов, оказывающих влияние на сервис).

    Для расчета доступности нужно было иметь:

    — Таблицу зависимостей: на какую величину деградирует бизнес процесс/бизнес операция/подразделение при падении Информационной системы (сервиса).

    — Фактическое время падения и восстановления сервиса (из Service Desk).

    — Степень деградации сервиса от конкретного инцидента (из Service Desk).

    — Различать функциональные и инфраструктурные инциденты (в Service Desk): про функциональном инциденте — деградирует функция Информационной системы (как правило, одна бизнес операция из таблицы зависимостей), при инфраструктурном инциденте — деградируют все бизнес операции/процессы, использующие в своей работе Информационную систему по таблице зависимостей. 

    В общем, т.к. всё это было непросто/трудозатратно + была процедура  согласования с бизнесом — расчет доступности был выведен в отдельный (от процесса управления инцидентами) процесс.

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

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

      У меня два вопроса:

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

      Рассчитали, дальше нужно делать выводы и предложения по улучшению ситуации, проводить улучшения. Это является задачей процесса? 

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

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

      0
      0
      1. Владимир

        1. Охват процесса - все бизнес процессы, по которым фиксируются Инцидеты в SD и по которым есть таблицы зависимостей. Сбор информации идет из SD. Таблицы зависимостей являются задачей процесса (добавляются новые, некоторые параметры изменяются).

        После расчета — смотрим на данные и разбираем только те инциденты, которые существенно влияют на доступность БП. По сути, нужно всеми силами пытаться решить такие инциденты: с временным или постоянным решением (это задача процесса управления инцидентами).

        2. Да, данные берутся из SD: есть отдельные поля — время начала/окончания простоя, есть чекбокс массовости, есть чекбокс — нет простоя.

        Конечно, инциденты пересикаются во времени. Данные из SD выгружаются в Excel. Расчет ведется в Excel с написанными макросами, которые зачитывают временные интервалы простоя, таблицу взаимозависимостей и др... и на основании формул — выводят результаты.

        0
        0

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

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

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

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

НОЯ
27
Учебный курс:
Основы ITIL (очно)