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

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

Управление доступностью – уникальный процесс. Уникальный в первую очередь тем, что является изобретением авторов 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 (совмещение управления доступностью и непрерывностью), но и здесь не все однозначно (об этом в другой раз). Интересно, какие варианты в реальной жизни возможны еще? Коллеги, если встречали управление доступностью или его кусочки в «дикой природе», буду признателен за комментарии.

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

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

  • Я много думал об этом. Мое мнение – в 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 тоже названо процессом. Может ли управление информационной безопасностью быть единым процессом в том смысле, в котором автор спрашивает про управление доступностью? На мой взгляд, ответ очевиден.

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

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

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

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

  • Альберт

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

    • В таком случае AVM просто может рассматриваться как часть ITSCM. Это не исключает процесс, а меняет компоновку.

    • Альберт, спасибо за комментарий. Полностью совпадает с моим опытом.

  • Владимир

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

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

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

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

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

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

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

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

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

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

      • Владимир

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

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

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

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

  • Александр

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

  • Александр, практика управления доступностью (Availability management) предназначена для обеспечения доступности услуг на уровне, необходимом для удовлетворения потребностей клиентов. А проектирование и преобразование (Design and Transition) – это вид деятельности или SVC Activity, который гарантирует постоянное соответствие продуктов и услуг ожиданиям с точки зрения качества, затрат и т.д. Поэтому, если мы говорим про деятельность, она в себя включает планирование, взаимодействие и работу с информацией.
    Если же ваш вопрос касается именно практик, то в ITIL есть практики Service design (проектирование услуг) и Change enablement ( поддержка изменений). Практика проектирования услуг обеспечивает разработку продуктов и услуг, которые соответствуют назначению и условиям использования, и которые организация способна предоставлять с учётом особенностей её экосистемы. Проектирование и разработка нового или измененного продукта или услуги не должны осуществляться изолированно, а должны учитывать влияние, которое они окажут на:
    -другие продукты и услуги
    -все соответствующие стороны, включая клиентов и поставщиков
    -существующие архитектуры
    -требуемые технологии
    -практики управления услугами
    -необходимые измерения и метрики.
    Практика поддержки изменений предназначена для увеличения доли успешных изменений услуг (и продуктов), обеспечивая правильную оценку рисков, авторизацию изменений и управление графиком изменений. Она обеспечивает баланс дополнительной ценности, создаваемой изменениями и негативным влиянием, которое вполне вероятно они могут оказывать.

    • Александр

      Спасибо большое, друзья!


Добавить комментарий для Павел ДёминОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM