Известная ошибка в ITIL — это проблема, которая уже была проанализирована, но ещё не была решена

Как работают известные ошибки и зачем они нужны?

Пусть у нас есть абстрактная служба ИТ, в которой разработка в одном подразделении, а эксплуатация в другом.

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

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

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

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

Видите, в ней есть наша известная ошибка: «Java/Проблема хранения и раздачи Connection Pool во временное пользование»! Проблема помечена, как связанная с базой данных, операционному директору легко вычленить данный класс проблем и «предъявить» исполнительному директору обратить внимание руководителей, ответственных за организацию эксплуатации на возникшие нюансы.

Исполнительный директор в ответ «нагнёт» донесёт информацию о сложностях в департамент разработки. И инициирует доработку системы:

Это пример того, как организовать процесс и минимизировать ручное управление.

И. Здесь организован взаимный контроль из мультиагентной архитектуры процесса.