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

Всегда ли Known Error – ошибка?

Согласно ITIL® процесс «Управление проблемами» (Problem Management) направлен на минимизацию негативного влияния на бизнес инцидентов, вызванных ошибками в ИТ-инфраструктуре и предотвращение повторного возникновения таких инцидентов [SO, 4.4.1.1].

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

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

Разумеется, в идеальном мире на фазе проектирования (Service Design) мы должны предусмотреть все варианты сочетаний и все режимы эксплуатации. Ну, или, как минимум, выявить «узкие места» при внедрении (на фазе Service Transition). Но…

Находясь в командировке, я встретил в одном из отелей такую табличку (фото 1).

ДействиФото 1тельно, пол в ванной был не только не оборудован дренажным отверстием (что, вообще-то не редкость), но и расположен выше пола в остальной части номера. При этом отсутствует классический бортик, который мог бы помешать вытеканию воды из санузла (фото 2).

Возможно, это, как говорят в нашей компании, профессиональная деформация сознания, но, первое о чём я подумал: «Интересно, сколько инцидентов и какого масштаба произошло, а также кто и в какой момент времени осознал, что нужно проанализировать эту проблему, чтобы появилась эта табличка, которая есть не что иное, как запись об известной ошибке (Known Error)?»

Следующий вопрос, на который, не редко и в обычном (ITSM) Фото 2процессе управления проблемами сложно получить достоверный ответ: «Какое решение выбрать?»

Спектр, как обычно широк – от системного (структурного) решения перестроить ванную (да, чего уж там, всё здание!) заново, заложив необходимый дренаж; до построения бортика, который бы препятствовал вытеканию воды в комнату; выбранного отелем варианта и т.д. (можно ведь вообще ванную комнату закрыть или…)

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

Можно ли считать отсутствие сливного отверстия в полу ошибкой дизайна? Строго говоря, если мы подходим к Service Design с позиций рекомендуемых ITIL, – да. Но при этом мы ведь понимаем, что во многих ИТ-инфраструктурах  ванных комнатах отверстий нет. Таким образом, мы имеем инфраструктуру как данность. И, более того, возможно, никогда ни с какими инцидентами не столкнёмся. И будем вполне обоснованно считать нашу инфраструктуру не имеющей ошибок. Но, если случится инцидент, как, видимо, произошло в данном отеле, нам придётся что-то делать. И, если мы не сможем поменять инфраструктуру, придётся поменять порядок эксплуатации и/или режим потребления услуги (“закрывайте шторку, уважаемые пользователи”).

Поэтому неважно, что стоит за “известной ошибкой” (known error), – ошибка или не ошибка. На практике процессу управления проблемами, по идее, должно быть всё равно, какова природа корневой причины (была ли она обусловлена действительно чей-то ошибкой) – его задача минимизировать влияние.

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

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM