Методика CFIA как инструмент управления доступностью
Отказ одного компонента системы может привести к отказу всей системы / всего сервиса, или привести к частичному отказу системы/сервиса, или не привести к отказу вовсе. Как получить наглядную картинку, демонстрирующую влияние отказа компонентов на доступность сервиса?
CFIA – один из вариантов ответа на этот вопрос. CFIA – это Component Failure Impact Analysis, метод анализа влияния отказа компонента.
Изначально разработанная компанией IBM, а затем ставшая частью библиотеки ITIL®, методика CFIA чаще всего используется в процессе управления доступностью. Например, в ITIL® v3, CFIA рассматривается как часть проактивной составляющей процесса управления доступностью. Основные возможности методики CFIA:
- определение КЕ (конфигурационных единиц), способных привести к нарушению доступности сервиса;
- выявление КЕ, не имеющих резервирования;
- определение SPOF (Single Points of Failure – единых точек отказа);
- помощь при оценке рисков и возможных финансовых затрат на доступность;
- оценка необходимости документирования вариантов восстановления.
Давайте разберемся как в несколько шагов реализовать CFIA:
- 1. Выберите ИТ-сервисы, которые требуется проанализировать. Создайте список КЕ, от которых зависит сервис (возможно, с помощью процесса управления конфигурациями).
- 2. Используя любое удобное средство, постройте таблицу, в верхней строке которой расположите ИТ-сервисы, а в первом столбце перечислите все значащие КЕ. На пересечении сервиса и КЕ поставьте один из трёх вариантов отметок:
- a. Х – сбой КЕ приводит к остановке сервиса
- b. М – сбой КЕ приводит к остановке сервиса, но существует возможность замены его вручную (промежуточный backup или warm start)
- c. А – сбой КЕ приводит к остановке сервиса, но существует возможность его автоматической замены (немедленный backup или hot start)
Если сбой КЕ не влияет на доступность сервиса, оставьте поле пустым.
В итоге получится матрица CFIA, где основное внимание требуется уделить значениям Х и М
|
КЕ \ ИТ-сервисы |
Сервис 1 |
Сервис 2 |
|
Приложение 1 |
X |
|
|
Приложение 2 |
X |
|
|
Кабель 1 |
M |
M |
|
Кабель 2 |
M |
M |
|
Кабель 3 |
M |
M |
|
Диск |
A |
A |
|
ПК 1 |
X |
|
|
ПК 2 |
X |
|
|
Сервер |
X |
X |
|
Маршрутизатор |
A |
|
|
UPS |
X |
M |
матрица CFIA
Чем больше сервисов затрагивает сбой КЕ, тем больше значимость этой КЕ, которая в случае наличия отметки Х будет являться единой точкой отказа (SPOF). Чем больше КЕ в составе сервиса помечены отметкой Х, тем больше уязвимость данного сервиса.
Задумайтесь над следующими вопросами:
- Является ли эта КЕ единой точкой сбоя (SPOF)?
- Как влияет отказ данной КЕ на работу сервиса? Ведет к полной остановке сервиса? Приводит к неработоспособности нескольких пользователей? Какие потери бизнеса возможны при сбое?
- Какова вероятность выхода из строя данной КЕ? Что можно сделать, чтобы этого избежать?
- Могут ли изменения привести к сбою данного компонента? Может ли пользователь явиться причиной сбоя?
- Стоит ли задуматься о мерах избыточности? Сколько это будет стоить?
На каком-то этапе использования данной методики, возможно, придет понимание необходимости наличия процедур реагирования на сбой КЕ. В этой связи полезно будет задаться следующими вопросами:
- Как мы реагируем на сбой КЕ?
- Каким процедурам мы следуем? Они документированы? Они могут быть улучшены? Они могут быть автоматизированы?
- Следует ли дополнительно обучить персонал?
- Следует ли использовать новые инструменты и техники?
Хорошо организованная методика CFIA на любом уровне (инфраструктура, процесс, организация) будет являться наглядным источником информации для принятия решений и анализа RFC (Request for Change – запросов на изменение), не требуя при этом высокой зрелости процессов или дорогостоящих средств автоматизации.
Кроме процесса управления доступностью, CFIA может так же применяться в процессах управления инцидентами, проблемами, конфигурациями, непрерывностью ИТ-сервисов.
Данный инструмент может пригодиться при оценке рисков в любом процессе и деятельности ИТ.
