Управление доступностью – уникальный процесс. Уникальный в первую очередь тем, что является изобретением авторов ITIL и не замечен как отдельный процесс (если я не отстал от жизни) ни в одном известном мне своде знаний по управлению ИТ, кроме ITIL, или процессной модели известной мне реальной компании. Почему – вопрос, который я хочу поднять в этой заметке, и поделиться своими размышлениями на этот счет.
Причина 1: Доступность уже обеспечивается другими процессами
Взглянем на задачи процесса:
- Создавать и вести план доступности, отражающий текущие и будущие потребности заказчиков.
По услуге такой план может быть частью SIP. Кроме того, задача сильно пересекается с аналогичной в управлении мощностями.
- Участвовать в диагностике и решении инцидентов и проблем, связанных с доступностью.
Диагностика и решение инцидентов и проблем – задачи соответствующих процессов.
- Оценивать влияние изменений на доступность услуг и ресурсов.
Дело процесса управления изменениями.
- …
Почти все задачи процесса, как они описаны в ITIL,– уже являются областью ответственности других процессов: управление инцидентами, проблемами, изменениями, SLM и так далее. Вопросы «где проходит граница с другими процессами», «есть ли у управления доступностью уникальные задачи» и «почему все эти дела должны быть выделены в процесс» на уровне перечня задач остаются открытыми.
Причина 2: Управление доступностью – это функция
Крайне настораживают в списке задач процесса формулировки «давать консультации…», «участвовать в…», «отвечать за…», которые больше похожи на задачи эксперта или группы экспертов, которые вовлекаются в различные процессы, но никак не собственно процесса.
Процесс – это последовательность действий, объединенных общей логикой, триггером, результатом. По мнению авторов ISM Method, далеко не все «процессы» ITIL соответствуют этому определению. В отношении управления доступностью с этим легко согласится: несмотря на наличие стрелочек, трудно сложить из кирпичей концептуальной модели ITIL логичную повторяемую последовательность исполнения процесса:
Тем не менее, что можно вынести из ITIL в отношении управления доступностью? Сервис-провайдер должен:
- Проектировать новую или проводить существенное изменение услуги с учетом доступности (закладывать в решение необходимые механизмы отказоустойчивости).
- Управлять рисками недоступности услуг. Оценивать риски недоступности, разрабатывать и внедрять контрмеры (механизмы обеспечения доступности) на всех этапах жизненного цикла услуги.
- Тестировать механизмы в рамках внедрения сервисного решения и уже внедренные механизмы обеспечения доступности на периодической основе.
- Отслеживать текущий уровень доступности, готовить отчетность, анализировать отклонения и готовить предложения по совершенствованию.
Дела, безусловно, важные. Но, на мой взгляд, в реальной жизни п.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 (совмещение управления доступностью и непрерывностью), но и здесь не все однозначно (об этом в другой раз). Интересно, какие варианты в реальной жизни возможны еще? Коллеги, если встречали управление доступностью или его кусочки в «дикой природе», буду признателен за комментарии.
Я много думал об этом. Мое мнение – в 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 тоже названо процессом. Может ли управление информационной безопасностью быть единым процессом в том смысле, в котором автор спрашивает про управление доступностью? На мой взгляд, ответ очевиден.
Такой ответ годится?