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

Вопрос из зала: Обходное решение проблемы или типовое решение инцидента?

Опубликовано 12 апреля 2012
Рубрики: Вопрос из зала, Управление инцидентами, Управление проблемами
Комментарии

Владимир спрашивает:

И снова о проблемах… в продолжении последнего семинара Евгения Шилова.

Утрировано рассмотрим ситуацию с ошибкой в книге ITILv3 2007.

В Книге в двух местах дано разное определение термина проблема. Из-за этого на экзаменах люди допускают ошибки и не набирают соответствующий бал.

Проблемой в данном случае является ошибка в книге.

Инцидентом низкий бал на экзамене.

Решением инцидента является апелляция, результатов экзамена.

Обходным решением проблемы является исключение из экзамена вопросов связанных с ошибкой.

Структурным решением является переиздание книг.

Вопросы:

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

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

Я для себя в голове давно разделил эти понятия и считаю… обходным решением проблемы только механизмы предотвращающие появление инцидентов даже если структурное решение ещё не найдено \ разработано.

Если под обходным решением предлагается типовой механизм решения инцидентов при их появлении… для меня это типовое решение инцидента, а не обходное решение проблемы…

При этом проблем менеджмент может предлагать как обходные решения проблем, так и типовые решения инцидентов.

Хотелось бы услышать вашу точку зрения по данному вопросу :)Может я где-то запутался :)

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

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

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

  • Георгий

    Первый раз слышу про понятие “обходное решение проблемы”

    Ничего личного, но я не удивлен, что экзамен не сдан…

    • Лялеко Владимир

      (ITIL Service Operation) Уменьшение или устранение
      влияния инцидента или проблемы, для которых
      в текущий момент недоступно полное разрешение.
      Например, перезапуск отказавшей конфигурационной
      единицы. Обходные решения для проблем
      документируются в записях об известных ошибках.
      Обходные решения для инцидентов, которые
      не привязаны к записям о проблемах,
      документируются в записях об инцидентах.

      http://itsmforum.ru/ZAM-test/Russian_2011_Glossary_v2.0.pdf

      Если придираться к стилистике, то нужно писать обходное решение ДЛЯ проблемы, но думаю сути вопроса это не меняет.

      Кстати если к космическим книгам обращаться не однозначности становится только больше 🙁
      “Уменьшение ИЛИ устранение влияния инцидента ИЛИ проблемы” везде ИЛИ… и никаких рекомендаций на сей счёт.

      • Георгий

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

  • Георгий

    хотя может это я отстал от жизни )

  • Alexander Popov

    Георгий, ну зря вы так, workaround всегда был, есть и будет есть 🙂

    С мнением автора согласен.

    • Георгий

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

      • Alexander Popov

        Скорее:
        “Мы не знаем корневой причины этой проблемы, на исследование требуется время, но чтобы избежать новых инцидентов, мы ставим заглушку в виде workaround”
        imho

        • Георгий

          ваш вариант существенно красивее звучит. понятно, сорри

          при случае, ткните плз носом в раздел книжки где это описано, надо видимо освежить память (((

          • Alexander Popov

            Что-то вроде этого http://www.itlibrary.org/index.php?page=Work_Arounds

            • Георгий

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

              в глоссарии вижу что есть, а по тексту вот ваще не помню… склероз видимо

          • Константин Нарыжный

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

            Угадайте, у кого подслушал;)

            • Лялеко Владимир

              У нас уши на одну волну настроены :))))))))

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

              Не может быть!
              Источник, верно, тот же, что про разметку и асфальт? 🙂

            • Вадим

              воспользуюсь (насчет столика)))))
              а я-то хотел клея под давлением накачать…

              • Роман Журавлёв

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

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

                  Говорят есть более простые способы достижения схожего результата.

                  • Вадим

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

        • Лялеко Владимир

          +1 Вот только под заглушкой многие понимают механизмы действий для устранения инцидентов при их появлении. Даже сегодня на семинаре прозвучал пример обходного решения, в виде перезагрузки сервера при его зависании. После этого возникло непонимание и вопросы…

  • Stepan Taborovets

    Хороший пример со скрипящим полом.
    А вот реальная ситуация, по моему очень близкая по сути.
    Инцидент – “зависает” приложение. Услуга не предоставляется. Устранение инцидента – перезапуск клиентской части приложения.
    Кандидат на проблему.
    Анализ проблемы выявляет, что приложение “зависает” из-за “зависания” одного из процессов на сервере. По этой ситуации открыт кейс у производителя ПО. Ответ вендора – будет учтено в следующем релизе.
    Обходное решение проблемы – написан скрипт, который каждый час перезапускает службу на сервере. Инциденты практически прекратились.
    Окончательное решение проблемы будет проведено после получения релиза от вендора.

    • Роман Журавлёв

      Степан, спасибо, это именно то, что мы имеем в виду, говоря про обходные решения проблем.

      • Grigory Kornilov

        Зависать стало все чаще – перезагружать тоже стали все чаще …

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

        И уже не ‘интересно’, что зависает приложение по факту из-за разваливающейся дисковой подсистемы хостящего сервера … ждем релиза от вендора.

        Найти причину проблемы и решить ее или применять workaround … в основном все применяют workaround, пока не сильно страдают пользователи.

        • Stepan Taborovets

          Давайте попробуем ещё раз.
          По инцидентам открыта проблема. Анализ проблемы приводит к появлению записи об известной ошибке. Применяем “обходное решение” и ждём от вендора нового релиза, устраняющего проблему окончательно.
          Но ведь проблему мы не закрываем. Значит прямая обязанность Менеджера проблем отслеживать эту ситуацию и рано или поздно её закрыть. Конечно, здесь не обойтись без Изменений, но отвечает за эту ситуацию Менеджер проблем.
          Если он свою работу на выполняет, значит его необходимо “мотивировать”.
          Вот как-то так…

          • Grigory Kornilov

            Еще раз, ok.

            Дано
            1. зарегистрированная проблема – “зависает приложение”
            2. найден по проблеме п1 workaround – “перезагружить приложение”
            3. В записе о проблеме записано : проблема известна, ожидаем новый релиз 01.2014г
            4. Инциденты повторяются
            5. SD инциденты решает применяя workaround

            Как вы думаете что сподвигнет SD не решать инцидент применяя workaround или пересмотреть корневую причину проблемы возникновения “зависает приложение” и ее workaround?

            Имхо только существенное учащение возникновения инцидентов.

            • Stepan Taborovets

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

              • Grigory Kornilov

                В такой трактовке я бы считал это не workaround, а maintenance plan.

                И надо понять что сподвигнет и кого проверить необходим ли он вашей системе в текущем виде (например через неделю, месяц …) .

                • Роман Журавлёв

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

                  Здесь все – как в управлении рисками: если мы живем с уязвимостью, пусть и снизив вероятность проявления риска, мы обязаны время от времени убеждаться в том, что классификация риска и выбранная стратегия управления по-прежнему актуальны. Это может быть частью текущей операционной деятельности, но не перестает от этого быть управлением рисками. Так же точно ничто не мешает сделать описанную деятельность по управлению проблемами (контроль известных ошибок) частью maintanace plan. А, например, обновление базы известных ошибок при выпуске новых версий КЕ – часть release plan.
                  Григорий, так?

                  • Grigory Kornilov

                    1. “ни что не мешает” для меня не понятно, хотелось бы увидеть предложение модели.

                    Часто ли можно встретить в крупных компаниях роль Problem Manager (управляющий процессом проблемами), обычно есть роль – Manager of Problem (управляющий\ответственный за конкретную проблему).

                    2. Maintanance отличается от workaround своей упреждающей ролью.

                    Если бы перезагрузка реализовывалась при достижении потребления сервисов определенного объема памяти (monitoring incident), я бы назвал это workaround. Если перезагрузка раз в неделю ибо-эбо, то это упреждение инцидентов и модель управления этим не понятна.

                    • Роман Журавлёв

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

                      А еще он (PRB) может пытаться предотвратить возникновение инцидентов. Для этого он предлагает “решения проблем”. Они тоже могут быть структурными (исправление “слабого звена”) или обходными (изменение, при котором ошибка остается в инфраструктуре, но существенно снижается вероятность ее проявления и/или влияние этих проявлений на бизнес). Оба варианта реализуются с помощью изменения инфраструктуры.

                      Первое направление деятельности можно отнести к поддержке (support), второе – к сопровождению (maintainance). Workarounds применимы в обоих случаях, но “обходят” они разное.

                      **
                      по п.1 – imho, именно в крупных компаниях выше вероятность встретить менеджера процесса PRB, среди обязанностей которого – координация работы менеджеров отдельных проблем.

                  • Stepan Taborovets

                    Все, правильно, Роман. Главное понимать, кто отвечает за доведение до ума создавшейся ситуации. И так ли уж важно, как мы будем называть эту ситуацию, особенно на английском языке…
                    Мне кажется, что это и есть RealITSM
                    🙂

  • Вадим

    другой (наверное хороший?) пример

    Имеем инцидент – опоздание на работу по причине, сами понимаете, пробок.
    Проблем две: – много машин, – мало дорог.
    Обходное решение – выезжать пораньше (и проводить в дороге побольше времени).
    Системное решение ждем от вендора))))

    • Вадим

      а вот и вендор подоспел))) со своим системным решением

      Регулярно появляются слухи о новом, инновационном смартфоне от компании LG. На этой неделе пошли разговоры о том, что южно-корейский производитель работает над концепцией «думающего» телефона, которую планируется использовать в будущих продуктах под управлением Android. Некоторые подробности о концепции в компании уже раскрыли. Например, вы ложитесь спать и ставите на смартфоне будильник на 6 утра. Пока вы спите, смартфон использует GPS для определения дорожной обстановки и, с учетом необычно оживленного движения, включает будильник на полчаса раньше, чтобы вы успели добраться до работы.

      )))))))))))))))

      • Роман Журавлёв

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

  • Pavel Solopov

    Чтобы говорить о системном и обходном решении. Нужно иметь некое проектное – идеальное состояние системы (не помню как оно там в классике именуется).
    При подходе же к построению систем – как придёться, по ходу разберёмся. Мы рискуем обвешаться обходными решениями, которые на самом деле являются системными.

    Как гласит народная мудрость: Нет ничего более постоянного, чем что-то временное.

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

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

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