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

Вопрос из зала: как организовать мониторинг, который никому не нужен?

Опубликовано 26 июля 2012
Рубрики: ITSM, Вопрос из зала, Практика и опыт, Эксплуатация ИТ
Комментарии

Дмитрий, один из читателей нашего портала, предлагает обсудить непростую ситуацию и задаёт три конкретных вопроса:

Передо мной стоит задача разработки системы мониторинга ИТ-инфраструктуры в крупной нефтяной компании.

Don't careУровеь ИТ-процессов – практически нулевой.  Ни процессы, ни службы (в т.ч. Service Desk) не обозначены, не регламентированы – живут своей дикой жизнью. Существующие нормативные и регламентные документы (в т.ч. SLA) носят формальный характер. Такая СИТУАЦИЯ ВСЕХ УСТРАИВАЕТ. И бизнес и ИТ считают:

  • Применение западных стандартов не для нас;
  • Затраты на стандартизацию, внедрение и поддержание процессного, а тем более сервисного подхода – необоснованными.

Естественно, при таком раскладе, возникающие инциденты и проблемы решаются реактивно, в пожарном порядке.

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

Собственно, вопросов несколько:

1-й вопрос такой: "С ЧЕГО НАЧАТЬ?". У меня, честно говоря, руки опускаются 🙁

2-й вопрос: Как лучше составить экономическое обоснование необходимости внедрения системы мониторинга ИТ инфраструктуры? С помощью методики TopS BI по определению TCO? Есть реальные примеры такого обоснования для российских компаний? На вашем сайте поиск результатов не дал 🙁

3-й вопрос: Насколько целесообразно внедрение системы мониторинга без использования практик управления в ИТ по ITSM?

Как отвечать будем, товарищи эксперты?

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

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

  • Олег Скрынник

    У меня уточнение к автору вопроса: а откуда взялась задача организации и защиты мониторинга ИТ-инфраструктуры, кто её поставил и зачем?

    Если у задачи есть заинтересованная сторона (заказчик), тогда есть хоть какие-то шансы.

    Если же задача была, скажем так, придумана, то, может, лучше перейти к другим, более интересным задачам? 🙂

  • Дмитрий

    Источников у задачи 3:

    1. Смутное понимание у ИТ (в области “Жххх”) необходимости изменений в лучшую сторону в плане предотвращения и отработки инцидентов.

    2. Частично следует из 1-го. Ежегодно для производственного контракта департамента (весьма формального) высасываются из пальца целевые показатели или проекты (однако это не означает заинтересованности исполнителя или бизнеса в их истинном достижении). Смутное осознание потребности прорвалось в формальную декларацию, что повысило статус задачи, но не гарантировало ее ресурсное обеспечение (распределение ресурсов происходит совсем по другим принципам).

    3. Личная заинтересованность автора вопроса (в т.ч. “шкурный” интерес :))

    Т.е. получается, что задачу ИТ поставил сам себе. Бизнес “ни при делах” (наверное, нормальная ситуация для Росии). Причем, в ИТ (ест., на уровне принимающих решения) есть некое облако представлений как о необходимости реализации системы, так и вариантов ее реализации (для примера: главный сисадмин считает, что у него и так все замечательно мониторится на скриптах).

    Есть ли у задачи заинтересованная сторона? Мне кажется, что для данного состояния развития ИТ в Компании, должна быть! Естественно, есть условия, среда, стратегия бизнеса (Компания не является самостоятельным оператором на рынке), которые формируют требования бизнеса к ИТ, но есть и некий уровень усложнения ИТ, при котором, что бы избежать деградации, без подобной системы не обойтись.

    • Олег Скрынник

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

      Товарищ поддерживает? Почему? В чём его интерес?
      Товарищ резко против? Почему, чего боится, что может потерять?
      Товарищ нейтрален? Прекрасно.

      Из этого простого анализа можно придумать меры и подход к основным противникам и основным сторонникам, а также понять как и чем можно заинтересовать нейтральных. Кому-то поможет TCO, кому-то – другие слова.

      Список ключевых людей в итоге получится коротким, так что не придётся искать универсальных решений для всех.

  • Дмитрий

    Конечно, вопрос о необходимости внедрения системы в описанной ситуации, достаточно интересен и привлекателен для обсуждения, но не хотелось бы, что бы дискуссия “ушла” в этом направлении. Это ведь все таки рубрика “Вопрос из зала” и … просьба о помощи :).

    • Олег Скрынник

      Эх, судя по Вашему ответу вариант “Мигрировать из этой конторы” Вам предлагать не стоит… 🙂

      Хотя в ситуации когда всем всё безразлично внедрять что угодно, хоть мониторинг, хоть процессы управления, всё равно что бороться с ветряными мельницами.

  • Максим

    Поскольку я не являюсь экспертом, то предложу не очень научный сценарий:
    1. Не пытаться сразу построить “мониторинг на всех уровнях”
    2. Найти локальную “болевую точку” в ИТ и построить для нее систему мониторинга. Система мониторинга д. б. полезна для администраторов или пользователей или менеджеров уровня руководителей групп или начальников отделов.
    3. Когда система покажет свою полезность на уровне “простых смертных” – показать ее на доступном уровне руководства, присовокупив рассказ о том, как система позволяет повышать, уменьшать, усиливать и т. д.
    4. Если руководство проникнется идеей, то Вы получите бюджет на развитие системы, если нет – то результатом предшествующей работы будет не груда графиков и таблиц, а полезная для кого-то система.

    • Vladimir Kalenov

      Полностью поддержу.
      Здесь еще один вопрос – а в чем собственно задача?
      Для чего мониторинг ИТ-инфраструктуры?
      Образно говоря, система мониторинга инфраструктуры – система пожарной сигнализации. Сигналы о чем вы хотите получать? Встал сервер? Замедлилась операция? Упал канал? Очередь обработки заявок на кредит больше 10? Через 10 минут возможно снижение времени обработки одной кредитной заявки на 13%?

      Обычно на первом этапе речь о том, что “сисадмин” узнавать о проблеме должен раньше пользователей. Здесь система мониторинга – это экспертиза специалиста, его скрипты и логи, плюс возможность рассказать о “выловленной” ошибке заинтересованным (руководитель, функционалы, ServiceDesk). Это подъемная задача, с ощутимым результатом и как уже сказали “результатом … работы будет не груда графиков и таблиц, а полезная для кого-то система.”.

      • Олег Скрынник

        Максим и Владимир, согласен с вами. Любой приличный мониторинг должен начинаться с задачи. В жизни, конечно же, он начинается с выбора, закупки и установки ПО, но это известный тупичок.

        Определив что именно и зачем нужно мониторить, кому и в чём это поможет, можно 1) сузить задачу, уйдя от мегамасштабов; 2) найти новых сторонников для реализации.

  • Станислав Уштей

    Дмитрий, попробуйте разыграть такие слова как МВЗ и РСМ- нужные бюджетчикам и помогающие в решении вопросов связанных с ТСО. В некотором роде, при удачном раскладе – вам не придется городить “навороченный” мониторинг – вы остановитесь на очень крупных КЕ. Ну и сможете поиграться с ИТ-архитектурой

  • Яков Рутман

    Прежде всего нужно понять на каком уровне нужен мониторинг. Но в любом случае стоит начать с малого.
    1. Т.к. в компании не построена служба Service desk, то, прежде всего, требуется ее организация на каком-то базовом уровне. Организовать работу подразделения на нескольких сервисах, и пусть они предоставляются внутри подразделения IT.
    Затем следует введение мониторинга нескольких малозначительных систем, сервисов или КЕ. Нужно понять как работает сам мониторинг, какие действия предпринимать в том или ином случае, кто будет выполнять работу и в каком порядке, кто будет регистрировать инциденты и пр. Сделать выводы. Только потом переходить на сложные системы.
    2. Экономическое обоснование всему этому может послужить сокращение времени на локализацию проблемных участков инфраструктуры, а как следствие сокращение времени простоя сервисов, что положительно сказывается на уровне предоставления сервисов.
    3. Без применения практик ITSM вы просто внедрите систему мониторинга, что пополнит зоопарк систем, используемых в компании и никакого ощутимого и видимого эффекта не получите. Инциденты по прежнему будут решаться неизвестно кем и как, в авральном режиме. Следовательно и экономическое обоснование будет выглядеть не так, а никак.
    Удачи.

    • Vladimir Kalenov

      Не могу согласиться – ServiceDesk, как и ITSM вообще не важен для обеспечения эффективного мониторинга.

      Эти решения могут быть интегрированы, но опять же, для какой-то цели.

      Система мониторинга оперирует событиями, а не инцидентами. риравнивать эти понятия губительно и для управления инцидентами и для эффективного мониторинга.

      Практическое наблюдение – Работающая система мониторинга не сокращает времени простоя, система мониторинга позволяет не допустить простоя. Доказать экономический эффект почти невозможно, а вот психологический эффект при наличии у руководителей “дашборды” системы мониторинга очень сильный.
      ServiceDesk же нужен исключительно как средство коммуникации с пользователями и PR для “админов”.

      • Яков Рутман

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

        • Олег Скрынник

          Ага. Мониторинг нельзя строить без управления инцидентами, ведь кто-то должен их решать управляемо, а не абы как.

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

          Управление проблемами, в свою очередь, не имеет смысла без чёткого управления изменениями, ведь проблемы нужно решать структурными решениями, а это изменения.

          Управление изменениями зависит от наличия и актуальности конфигурационных данных, посему – придётся и управление конфигурациями организовать…

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

          • Яков Рутман

            Олег, соглашусь с вами только в одном случае. Если нужно внедрить мониторинг ради мониторинга. Вся библиотека ITIL не даром написана и все процессы завязаны воедино. При правильном следовании всем практикам можно создать работоспособную, отвечающую всем правилам службу поддержки.
            Окончательный же ответ на вопрос из зала: если процесс мониторинга никому не нужен, то не имеет смысла его создавать.

            • Vladimir Kalenov

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

      • Станислав Уштей

        Сейчас у Бизнеса появилась новая игрушка “Process Performance Management” – поэтому нужно быть уверенным, что проблему с “дашбоордами” уже не решают другие по другому

  • Андрей Радосельский

    Делать мониторинг без ITSM можно и нужно.
    Есть опыт реализации именно в описанных условиях.

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

    Начинать надо с доступности. Сначала сетевая доступность, потом доступность прикладного уровня (базы данных и сервера приложений), третьим этапом – доступность для пользователя сервиса (т.н. Бизнесс Процес Монитор). Без SLA и SLO.

    И на этом можно остановится.

  • Дмитрий

    Спасибо всем, кто поделился опытом или здравыми мыслями. Наверное, действительно, сначала нужно достичь определенной зрелости в ИТ-процессах, а потом внедрять полноценный мониторинг инфраструктуры. Когда возникнет четко осознанная потребность и неизбежная необходимость (имея в виду полноценный мониторинг на всех уровнях). Возможно и остальные составляющие ITSM будут расти рядышком. А пока будем внедрять “для галочки”.

  • Вадим

    интересная тема, жаль, что я к ней опоздал )))
    кажись, я знают эту компанию (по крайней мере одну компанию, подходящую под описание, я точно знаю))))
    не прочитал все ветки обсуждения, поэтому возможно повторю кого-то

    IMHO пока не будет понимания зависимости результатов деятельности тех же бизнес подразделений (добычи нефти, или что они там с нефтью делают: качают, перерабатывают) от работоспособности инфраструктуры, а равно как и от скорости выявления сбоев (и т.п.), и от способов (= сценариев) отработки подобных нештатных ситуаций (НШС) – никому никакая система мониторинга не будет нужна. зачем?
    при этом пускать ИТишников в “свой огород” ессно никто не будет (ну во-первых, там уже пасутся АСУТПшники, а во-вторых, в случае чего всегда есть возможность руками покрутить какой-нибудь вентиль), т.к. это повышает вероятность снижения целевых показателей. кому этого надо?
    к тому же ИТишники за это зарплату получают, зачем же упрощать их работу, вдруг они бездельничать начнут.

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

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

  • Евгений

    Очень знакомая ситуация.

    Взависимости от вменяемости руководства компании, конечно, но:

    1. собрать и представить информацию о подобных решениях в других компаниях с их результатом использования (оргполезности, финансовые выгоды, и т.п.);

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

    3. то же , что в п.2 в ситуациях превентивных действий на основании тенденции (при отсутствии внешней подачи энергии UPS начал разряжаться, уже пошли его менять, не дожидаясь выключения оборудования и звонка пользователя.

    4. (редко, с кем можно) психологические моменты авралов, удоство работы ИТшников – это атмосфера и мотивация персонала – стратегические преимущества.

     

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.