Но прежде чем мы начнем рассматривать развитие системы, давайте взглянем на текущую структуру Вашей системы. Скорее всего, у большинства из Вас используются штатные механизмы. То есть, как систему установили, так ее и эксплуатируете. Service Desk 4.5 можно довести до ума, при этом потребуется не так уж и много сил, главное знать, что Вы хотите увидеть на выходе.
Приступим: Первый, назовем его «Системное изменение», второй, назовем «Правила системы».
Системные изменения: меняем штатный механизм работы системы на тот, что необходим Вам. Сюда мы отнесем «Принцип работы правил. Изменение штатного функционала на нештатный».
Думаю, лучше привести пример: Скажем у Вас 12 app серверов, каждый из которых работает по своим направлениям, кто-то почту разбирает, кто-то с пользователями работает, web-приклад, агент-сервер и т.п. Главное, что их объединяет - это «scheduled tasks», у каждого сервера он свой. На самом деле, это плохо, обратите внимание: каждый сервер занимается свои делом, а тут выходит, что у них есть что-то общее. Изменив системную логику, можно отобрать у каждого сервера данный функционал и направить его на отдельный сервер, который будет работать только с этими объектами.
Вы спросите, зачем это нужно? Ситуация такова, допустим, в Вашей системе включена возможность групповой правки. И есть правила, которые каким-то действием генерируют scheduled tasks, но создание данного scheduled происходит на том сервере, на котором производили изменения. А теперь представьте себе ситуацию, что проверка данного события совпадет с максимальной нагрузкой на систему. Как правило, это утро, если взглянуть на схему изнутри, то можно представить, как плохо становиться серверу, которому нужно обрабатывать не только запросы специалистов, но еще и запросы Scheduled, исполняя при этом еще и правила системы. Т.е нагрузка увеличивается в два раза. Отсюда могут рождаться новые проблемы. Замедление или зависание приклада, повышенная нагрузка на базу данных, ошибки java. Казалось, одна мелочь, а может столько проблем создавать.