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

Доска аварий

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

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

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

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

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

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

  • Andrey Kapustin

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

    Также интересуюсь у кого какой опыт был на заданную тему.

  • Вадим

    безусловно попадались )))) вот, например, ссылочка:
    http://maps.yandex.ru/?text=%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F%2C%20%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0%2C%201-%D1%8F%20%D0%94%D1%83%D0%B1%D1%80%D0%BE%D0%B2%D1%81%D0%BA%D0%B0%D1%8F%20%D1%83%D0%BB%D0%B8%D1%86%D0%B0&sll=37.670483%2C55.72598&ll=37.670483%2C55.725980&spn=0.065103%2C0.015743&z=15&l=map%2Ctrf%2Ctrfe&trfm=cur&trfst=false

    видны инциденты, видны связи, можно провести детальный анализ с помощью мозга, рук и мышки )))

    а если серьезно, то IMHO граница между автоматизацией и работой человека должна быть проведена разумно. если всё переложить на систему, то человек, её запрашивавший станет не нужен.

  • Виталий

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

  • Андрей В.

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

    В итоге “доска аварий” сводится к дэшборду с корневыми объектами моделей здоровья различных услуг: услуга “красная” или “зеленая”. Если услуга “покраснела” значит недоступна или деградировала, поскольку появилась нештатная ситуация с какой то из проверок, которую мы сами решили выполнять в рамках модели здоровья. Ключевой фактор успешности такого подхода – продуманная адекватная модель здоровья, которая разумеется должна постоянно уточняться.

  • ZW

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

    • Андрей В.

      Почему же титанических? При работающем Change Mgmt можно планировать в RFC задание на изменение модели здоровья услуги, если CI меняет свои свойства.

      • ZW

        Это пока количество изменений не превышает скорость отработки Change Mgmt.

        • Андрей В.

          Значит (слишком) много изменений, плохо – нестабильная ИТ-инфраструктура)).
          Управление изменениями в каком-то смысле призвано тормозить деятельность по изменениями, чтобы лишний раз заставить подумать а надо ли, и если надо, то все ли учтено (в т.ч. актуализация мониторинга)..

  • Pavel Solopov

    исключить детальный анализ никогда не удастся. К сожалению без головного мозга человек далеко не уйдёт.
    Но надо понимать, что бывают ситуации типовые, и не типовые. Каждый инцидент, когторый мы зафиксируем может приводить как к типовой, так и к нетиповой ситуации. Их соотношение требует отдельного изучения, но думаю, что где-то в районе стандартных 80 на 20.
    Однозначно потребуется большая работа, чтобы сначала выявить и описать те самые 80 процентов типовых ситуаций, а затем работа поменьше, чтобы пул тех самых типовых пополнять.
    Ну а что вы хотите, ИТ сейчас становится большим сложным производством требующим соответствующих подходом. Думаете с какой-нибудь газокомпрессорной станцией или прокатным станом проще?
    Только там уже давно преобладает нацчно-инженерный подход. А в ИТ пока всё больше шаманство и упрощенчество. 🙂


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM