Известная ошибка в ITIL — это проблема, которая уже была проанализирована, но ещё не была решена
Как работают известные ошибки и зачем они нужны? Покажу между делом и чуть.
Пусть у нас есть абстрактная служба ИТ, в которой разработка в одном подразделении, а эксплуатация в другом. К примеру такая:
Пусть у нас несколько сотен информационных систем и один сменный «круглосуточный» администратор. Который не может знать тонкости всех систем. Пусть у нас есть система дистанционного обучения, которую создал департамент разработки.
Допустим, на этапе создания программного продукта, разработчик обнаружил, что у него иногда не закрываются соединения с базой данных. Исправлять долго, а приложение уже глючит. В этом случае разработчик регистрирует известную ошибку, примерного такого вида.
Это информация для сменного администратора, который следит за несколькими сотнями информационных систем. Можно быстро понять, что делать, если всё зависнет, к примеру. Нехитрым образом у нас возникла инструкция для сменного администратора, которому не обязательно знать что-то о проблемах соединений в Java,
Администратор, ответственный за эксплуатацию, регистрирует проблему, для контроля её решения. Это важно, чтобы решение проблемы разработчиками, контролировала вертикаль эксплуатации. Проблема имеет такой упрощённый вид:
Видите, в ней есть наша известная ошибка: «Java/Проблема хранения и раздачи Connection Pool во временное пользование»! Проблема помечена, как связанная с базой данных, операционному директору легко вычленить данный класс проблем и «предъявить» исполнительному директору, который отвечает за организацию эксплуатации данной системы.
Исполнительный директор в ответ «нагнёт» департамент разработки. И инициирует доработку системы:
Пост максимально краткий, написан во время рабочего процесса, по оценке функциональности elma365(противоречивые ощущения, возможно напишу обзор). И. Это пример, как организовать процесс и минимизировать ручное управление.
И. Здесь организован взаимный контроль из мультагентной архитектуры процесса.
