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