Инциденты, требующие доработок ПО

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

Итак, процесс обеспечивает своевременность решения инцидентов. Инциденты регистрируются, решаются, закрываются. Не успели вовремя – просрочка и штраф группе поддержки, задержавшей решение (иногда всем группам пропорционально вкладу). Справедливо? Безусловно.

Но что если инцидент не может быть устранен силами ИТ-подразделения и требует доработки ПО на стороне подрядчика? Книжный ответ простой: ИТ-подразделение несет ответственность и за своих подрядчиков, которые являются такими же компонентами услуги как серверы, сети, СХД, сопровождение которых осуществляется внутренними силами. Учитывая опыт работы во внешнем сервис-провайдере, такой ответ меня всегда удовлетворял и казался предельно логичным. Ведь внешний сервис-провайдер самостоятельно выбирает подрядчиков. Почему заказчика должно волновать, с чем именно связан сбой, если сервис-провайдер несет ответственность за конечную услугу?

Дела обстоят иначе у внутреннего ИТ-подразделения: некоторые подрядчики (особенно вендоры ПО) могут быть «навязаны» руководством компании. Корректно ли штрафовать за нарушение нормативов группы поддержки ИТ-подразделения, когда инцидент требует доработки на стороне такого подрядчика? Можно определить в SLA особые обстоятельства, по которым увеличивать нормативы, скажем, до нескольких недель. Вроде бы решение. Однако нередко контракт с вендором предполагает фиксированное количество часов на доработки в месяц. Очередью доработок ПО управляют бизнес-подразделения, и легко представить картину, в которой незначительный дефект, связанный с инцидентом, будет бесконечно вытесняться более приоритетными заданиями, которые требуются для проведения важных бизнес-изменений. 

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

Одним из таких механизмов может быть остановка таймера. Как только диагностика инцидента показывает, что без доработки ПО не обойтись, инцидент переводится в специальный статус и ждет решения связанного изменения. После того, как изменение закрыто, работа по инциденту возобновляется, хотя, вероятнее всего, останется получить только подтверждение пользователя. Плюсы: пользователь имеет возможность понятным образом отслеживать статус по доработке; в случае неудачного решения может вернуть инцидент в работу; как время работы над инцидентом учитывается только тот период, когда мяч на стороне внутренних групп поддержки. Минусы: «бэклог» таких особых инцидентов в крупных компаниях может со временем достигать сотен записей. И вообще такой балласт, который будет переходить из периода в период и мозолить глаза менеджеру, может довольно странно смотреться в процессе, жизненный цикл объектов которого, как правило, исчисляется часами, иногда, днями.

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

Оба варианта мне кажутся допустимыми при условии:

  1. Помощи пользователю здесь и сейчас. Все знают хрестоматийный пример с переключением рабочей станции на другой принтер – в этом сценарии инцидент с обходным решением может быть закрыт как решенный. Но что если инцидент связан с неверным расчетом значений в отчете по причине некорректно заложенной логики – обходного решения может не быть как такового. Неплохо бы не оставлять пользователя с этой ошибкой наедине на несколько недель, и оказать посильную помощь перед переводом в статус «доработка» или применением особого кода закрытия.
  2. Информирования пользователя по ходу выполнения доработки.
  3. Наличия дополнительных контролей за инцидентами, требующими доработок. И перевод в статус «доработка» с остановкой таймера, и применение специального кода закрытия дают большое пространство для злоупотреблений со стороны групп поддержки, стремящихся избежать штрафов за просрочку. Легитимность использования любого из механизмов требуется регулярно проверять.

Но может быть есть и другие варианты?

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

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

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

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

  1. Rafkhat Osmonov

    Добрый день!

    Можно использовать одноименный статус "Требуется доработка", при переходе в который секундомер останавливается. А если обращений несколько, то использовать это в качестве аргумента для повышения приоритета доработки.

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

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

    0
    0
  2. Олег Иваненко

    Добрый день!

    По-моему таких инцидентов не так много. Что получается: ПО работало, работало, потом вдруг сломалось? Чаще наоборот, доработка ПО вызывает инциденты, которые должны устраняться в рамках процесса управления изменениями, непосредственно корректировкой изменения.  

    0
    0
  3. Алексей Кротов

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

    Неверная логика — даете алгоритм, как считать правильно вручную. Считаете сами. Регистрируете RFC,

    Но вот зависший "в доработке" инцидент — хуже некуда.

    0
    0
  4. Сергей Семикин

    Что получается: ПО работало, работало, потом вдруг сломалось?

    Может измениться среда, в которой работало ПО, и для восстановления решено дорабатывать именно ПО, а не среду. 

    0
    0
      1. Сергей Семикин

        Оk. Пример, используем веб-сервис со скриптами выгрузки данных на него, провайдер выполняет апдейт и скрипты перестают работать. Изменилась среда и она вне нашейц зоны контроля.

        0
        0
  5. Сергей Семикин

    Как вариант, если инцидент решен, например применено обходное решение, то инцидент можно закрыть, но "привязать" его к записи о проблеме и/или к RFC. Если не решен, то "поставить на паузу" и также привязать к записям последующих процессов (GM, PM).

    При этом возможны сложности в объяснении текущего качества услуги (обращение либо закрыто, либо по нему не работают, а упавшее качество, так и не поднялось), но предложенная структура позволит ТП быстро определить текущее состояние решения причины проблемы.

    0
    0
  6. Олег Иваненко

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

    0
    0
  7. Сергей Гончаров

    Может я ошибаюсь, но если причиной инцидента является ошибка ПО, то значит у нас на лицо проблема в виде ошибки ПО. Если обходного пути нет, значит инцидент нужно закрывать со статусом "Невозможно устранить" (или типа того по смыслу). После устранения проблемы — исправления ПО - все связанные с этой проблемой инциденты независимо от того, закрыты они или открыты, проверяются, чтобы убедиться, что проблема действительно устранена, и такие инциденты впредь больше не возникнут.

    0
    0
    1. Андрей Труфанов

      С одной стороны, в книжном понимании, ошибка ПО является причиной прерывания услуги и является проблемой, корневым источником инцидента.

      Но мне не нравится такой подход: опыт разработчика говорит о том, что проблемой должна быть названа причина, по которой эта ошибка ПО добралась до продуктивной среды, Т.е. не делать процесс управления проблемами глубиной «в одну ступень».

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

      0
      0
      1. Сергей Гончаров

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

        Вопрос автором ставился с точки зрения управления инцидентами. Если смотреть "изнутри" этого процесса, то: мы причину возникновения инцидента установили, проблему зарегистрировали. Устранить инцидент мы не можем, значит инцидент закрываем (но не забываем о нем путем привязки к проблеме) и передаем эстафету следующим участникам, которые будут разбираться в проблеме.

        0
        0
        1. Андрей Труфанов

          Обращаться к проблемам полезно, т.к. даже если у нас нет возможности устранить ошибку в ПО, как причину инцидента. В этом случае мы ищем способы и обходные решения: скрипты, правки данных, ручная предобработка. Закрывать инцидент с кодом «нельзя устранить» можно, только если это разрешено контрактом.

          При этом сама корневая причина в виде проблемы будет устранена изменением. То, о чем я хотел сказать, это чтобы процесс управления проблемами не останавливался на устранении ошибки в ПО. В силу разнообразия багов в ПО простого устранения очевидно недостаточно. Пусть будет несколько проблем: одна для устранения ошибки в ПО, вторая, например, для уточнения охвата и методики тестирования. На практике второго часто нет.

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

          0
          0
          1. Сергей Гончаров

            Я думаю, что даже если на первом остановимся, уже хорошо. Многие и до этого не доходят 🙂

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

            0
            0

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

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

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

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

ДЕК
18
Учебный курс:
Основы DevOps
ДЕК
20
Учебный курс:
Основы ITIL (очно)