Когда регистрировать проблему?

Теория логична и понятна (воспользуемся определениями из ITIL 4): проблема — это причина или потенциальная причина инцидента или инцидентов, в то время как инцидент – это незапланированное прерывание услуги или снижение ее качества. Мы занимаемся управлением проблемами, чтобы инциденты оказывали меньшее влияние на наши услуги, в том числе за счет снижения их количества, и в идеальном случае – чтобы вообще не происходили, потому что мы как раз-таки устранили проблему — ту ошибку, из-за которой они возникали.

Разобравшись с теорией, мы начинаем переходить к практике — выстраивать у себя управление проблемами, чтобы, устранив причины инцидентов, мы больше не тратили на них свои ресурсы: силы, время и деньги. И тут мы обнаруживаем, что вопросов больше, чем казалось изначально, и самый первый вопрос, который у нас возникает – получается, теперь при каждом инциденте нам нужно регистрировать проблему? Ведь у каждого инцидента есть какая-то причина, почему он произошел.

В чем сложность?

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

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

Как принять решение?

Давайте посмотрим примеры вопросов, на которые можно опереться, чтобы принять решение, регистрировать проблему или нет:

• Является ли инцидент, чью причину мы хотим выяснить или который мы хотим предотвратить (если говорить про проактивное управление проблемами), значительным? Это один из самых частых критериев, определяющий необходимость регистрации проблемы, и это вполне обоснованно: из-за особо сильного влияния значительного инцидента на бизнес мы категорически не хотим, чтобы такой инцидент или произошел повторно (или даже в первый раз). Более того, регистрация проблемы в случае значительного инцидента является обязательной согласно стандарту ISO/IEC 20000-1.
• Насколько высоко суммарное влияние инцидентов, вызванных (предположительно) одной проблемой? Тут требуется следующее пояснение: инциденты являются симптомом того, что где-то есть ошибка или уязвимость, но взаимоотношение инцидент – ошибка может быть многое-ко-многим. Схожие инциденты могут быть вызваны одной ошибкой, а могут быть просто совпадением (в один день отчет не выгружается из-за сбоя в базе данных, а в другой день – из-за недоступности сервера); непохожие между собой инциденты могут быть вызваны одной ошибкой (почта не отправляется у одного пользователя и отчет не грузится у другого, потому что у них была установлена некорректная версия обновления). Так что до того, как мы проанализируем проблему, мы можем лишь предположить, что инциденты связаны между собой, но основываясь на этом предположении мы можем оценить суммарное влияние этих инцидентов для принятия решения о регистрации проблемы. Влияние мы можем оценивать, например, в суммах затрат, связанных с простоем бизнеса из-за инцидентов, в суммах затрат ИТ-ресурсов, тратящихся на решение инцидентов, в опасности для репутации нашей компании. Соответственно, чтобы работа с проблемой была не напрасной тратой ресурсов, нужно оценить суммарное влияние инцидентов, которые она вызвала или может вызвать и сопоставить со стоимостью решения проблемы. Какое соотношение будет говорить о необходимости регистрировать проблему и дальше работать с ней – зависит от конкретной организации.
• Насколько велика вероятность, что ошибка вызовет (повторные) инциденты? Возможно, даже не углубляясь в анализ, нам из нашего экспертного опыта понятно, что инцидент возникнет при очень редком стечении обстоятельств. Действительно ли есть необходимость регистрировать проблему в этом случае? Если мы уже знаем, как с таким инцидентом быстро справиться – возможно, да, чтобы у нас в базе известных ошибок уже было зафиксировано обходное решение. Но если и вероятность возникновения инцидента крайне мала, и его влияние прогнозируется не очень высокое, и на анализ, в чем все же корневая причина и как ее устранить, нужно непропорционально много времени, возможно, нет смысла регистрировать эту проблему.
• Нет ли уже аналогичной зарегистрированной проблемы? Банально, но это может упускаться из виду: если схожая проблема уже зарегистрирована, нет смысла регистрировать дубль, но есть смысл разобраться с тем, а почему снова возникла идея, зарегистрировать такую проблему. Наша команда недостаточно информирована о проблемах, которые уже зарегистрированы? Схожие инциденты возникли в другой части организации, которая не в курсе нашей деятельности? Возможно, такая ситуация будет триггером либо к повышению влияния уже зарегистрированной проблемы, либо к улучшению работы нашего процесса, например повышению осведомленности сотрудников о том, как работать с базой проблем и известных ошибок.
• Поможет ли нам хоть чем-то регистрация этой проблемы? Определенно, мы не сможем устранить все проблемы, потому что не всё зависит от нас и существуют разные ограничения: например, технологические или обусловленные нашей зоной влияния. Так, если возможность устранить ошибку находится на стороне поставщика, но он не заинтересован в устранении этой ошибки, то нам придется жить с ней, однако в рамках управления проблемами мы можем придумать обходное решение, пусть и не идеальное, чтобы все же хоть как-то снизить вероятность возникновения инцидентов или их влияние на услугу. Если же мы не можем сделать вообще ничего (просто так устроен мир, и с этим нужно просто смириться), возможно, нет смысла и регистрировать проблему. Иметь запись о проблеме просто ради самой записи – не имеет большого смысла.
• А насколько хорошо мы в принципе умеем управлять проблемами? Если мы находимся только-только в процессе становления данной практики, то регистрация слишком большого количества проблем может демотивировать: мы еще не умеем их толком решать, у нас не отлажены процессы, технологии, а у нас уже зарегистрирована целая куча проблем. Возможно, стоит подходить к охвату регистрируемых проблем итеративно: например, сначала только проблемы, связанные со значительными инцидентами (причем, уже произошедшими), потом, по мере накопления опыта, – с часто повторяющимися и так далее.

 

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

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