О пользе FTA

Решая задачи управления рисками и непрерывностью ИТ-услуг, я искал инструмент, который в условиях ограниченных ресурсов аналитиков и сложностей с привлечением технических экспертов, позволял бы получить максимально точный ландшафт рисков и полную картину нарушений доступности. Да еще хотелось, чтобы с его помощью была возможна вероятностная оценка, и сразу можно было представить, как полученные и не очень устраивающие цифры исправлять.

В книге Service Design любимого пятитомника говорится о методе анализа дерева отказов (Fault-Tree Analysis, далее – FTA), но уж слишком вскользь, чтобы обратить на него внимание. Стандарт ISO 31010 “Risk Management – Risk assessment techniques”, выступает более развернуто и, приводя следующий пример (см. рис), показывает, как с помощью дерева можно получить наглядное представление путей возникновения конечного нежелательного события с использованием булевой логики (элементов «и», «или», «исключающее или» и «не»).

FTA_ISO31010

Нам, как ITSM-специалистам, этот метод  может быть интересен по следующим причинам:

  • Мы можем понять логику, ведущую к нежелательному состоянию ИТ-услуги (отказу системы, нарушению функциональности, снижению доступности), а значит, приготовиться ко всем возможным вариантам развития событий (управление непрерывностью) и знать, где «стелить соломку» (управление рисками).
  • Мы можем использовать метод FTA при проектировании систем (Service Design), в части разработки спецификаций и требований к конкретным компонентам на основании требований заказчиков к показателям гарантии, для выявления потенциальных отказов и отклонения заведомо неудачных архитектур услуги.
  • Кроме того, FTA может быть использован в качестве диагностического инструмента для выявления и исправления корневых причин (управление проблемами), а также формирования диагностических карт (управления инцидентами).

Наконец, имея статистику по базовым событиям (листья дерева), мы можем найти вероятность конечных событий, а значит вычислить фактический и прогнозируемый уровни доступности.

Рассмотрение FTA целой услуги слишком громоздко, поэтому встает вопрос выбора событий верхнего уровня. Выбор будет обусловлен целями анализа, и в каких-то случаях может быть уместно рассматривать сбои ИТ-систем, ПО и оборудования. Однако на практике мне показалось наиболее эффективным разбивать услугу по функциональности, а затем рассматривать события отказа этой функциональности. В частности, функциональность ITSM-системы в рамках услуги технической поддержки пользователей можно разделить на следующие блоки:                

  • Доступ инженера к базе обращений
  • Web-доступ инженера к базе обращений
  • Web-доступ пользователя к базе обращений
  • Обработка обращений (эскалация, закрытие)
  • Отправка уведомлений
  • Импорт
  • Формирование отчетности

Очевидно, что критичность функций различна, и такая разбивка очень облегчает задачу определения уровня ущерба от реализации риска и вычисления целевых показателей восстановления конфигурационных единиц (КЕ), так как легко установить, к отказу какой функциональности ведет отказ КЕ.

Дерево для сценария «Недоступность функции «Обработка обращений»:

FTA_Esc

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

Итак, с помощью FTA – дедуктивного метода, направленного на анализ сверху-вниз – можно получить достаточно полную картину всего спектра нежелательных событий, связанных с конкретной услугой, и «причин» их возникновения.  На следующем шаге базовые (нижние) события могут быть положены:

  • В основу другого дерева отказов (для более детального анализа);
  • Или же в основу дерева событий – для анализа снизу вверх, определения всех возможных последствий, связанных с данным событием.

Таким образом, мы можем обнаружить ранее упущенные сценарии, а, следовательно, повысить полноту и точность картины.

Применяете ли вы FTA в своей практике? Какие методы идентификации, анализа и оценки нежелательных событий и дестабилизирующих факторов используете? Насколько востребованы результаты такого анализа?

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

ITIL ITIL Intermediate: Planning Protection and Optimization

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

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

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

  1. Павел

    «I don’t believe CMDB is going to make that much difference to your ITIL processes. You sure won’t be able to automate any but the most basic impact analysis (the sort of thing vendors demo). The most sophisticated modelling tools on the market struggle to predict performance degradations, yet most SLAs put at least as much importance on performance as availability. They even struggle to predict availability whenever IP networks are involved, especially if the internet enters the equation (though complex intranets are challenging enough).

    So after all that time and money a human is still going to have to look at a proposed change and make a judgement call; better informed than before, for sure, but still operating on imperfect information. Perhaps that money would have been better spent on a few nicer reports and exploratory tools, and another change management person, and a golf course for the staff.

    In the past, companies wasted fortunes and diverted key resources for years trying to have one common relational database, and/or one common enterprise data model, and/or one repository of meta-data. They are doing it again trying to have one common repository of identity, or one repository of objects or Web Services. The sooner technologists and vendors stop peddling this kind of magic-fix crud the better off we will all be.

    ITIL is about fixing the people and the processes, and only then implementing pragmatic tools to help them. How such an idealistic, bloated, infeasible, technology-will-solve-all-our-problems concept as CMDB got in there is beyond me.

    CMDB is the only major example of ITIL describing what-should-be rather than what-is-and-how-to-manage-it, and it fails the test of common sense.»

    IT Skeptic

    www.itskeptic.org/itil-cmdb-skeptic

    0
    0

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

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

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

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

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