Первый Service Desk 4.5, второй Omnitracker
Если в ваших руках оказался Service Desk 4.5 будьте готовы к тому, что система в один прекрасный момент может упасть. Произойти это может как правило из-за многих факторов, например:
Не оптимизирована системы
Не оптимизирована база данных
Не оптимизированы сервера
Не оптимизирована клиентская часть
Но как показывается практика этого может и не произойти, в зависимости от того как используется система. Ведь в системе может работать и 100 человек, а может работать и 1000 человек. Как говорится насколько сложно реализована модель системы. На столько сложно поддерживать и мониторить систему, а также реагировать на все возможные ошибки в режиме online.
Как правило первые симптомы болезни системы я бы отнес к «Торможению» или «Повисанию» системы. Все начинается с предоставления специалистам возможности строить свои представления. Как только дать такую возможность знайте, система в первую очередь подвергается опасности зависать. При чем само зависание может произойти не сразу, начинается все постепенно, каждый сотрудник начинает строить свои сложные представления. Тем самым каждый раз специалист делает запрос в базу данных, каждое новое поле это дополнительная нагрузка.
Чтобы избавится от данной проблемы необходимо для тех полей которые используются чаще всего в настроенных представлениях добавить индекс. Тем самым данная ошибка улетит, но сделать это можно только на базе данных в ручную. Либо воспользоваться штатными средствами базы данных для анализа транзакционных логов. После чего система сама предложит варианты добавления индексов, добавлять все я бы не советовал, а подобную практику всегда лучше проводить сначала на тестовом стенде, а только потом на боевом. Как правила не у всех есть в арсенале тестовый стенд, но ведь никто не мешает его сделать.
В отличии от Service Desk 4.5 система Omnitracker позволяет добавить индекс не заходя в базу данных. Открывается нужное поле и выставляется индекс. Производительность пожалуй самая больная тема любой системы, одно из наблюдений показало, что система Service Desk 4.5 в отличии от Omnitracker может жить на виртуальной машине. Если появилась потребность в уменьшении затрат на сервер, то Omnitracker живет только на железном сервере, а не на виртуальном, хотя в рекомендация это сказано. Мы все таки решили испытать Omnitracker на виртуальном железе, да еще и в кластере, привело это к бессонным ночам, и кучи потраченного времени. Какой бы мощный не был у вас сервер, поведение системы неадекватное.
Service Desk 4.5 в кластер собирался простым включением нового сервера, и подключения его к основной базе данных. Omnitracker собирается в кластер через дополнительную сеть. На сервере обязательно должен быть второй сетевой интерфейс, который по хорошему должен напрямую быть соединен ко второму серверу, своего рода прямое подключение ко второму серверу. Если потребуется в кластер добавить еще один сервер, тогда на сетевом оборудовании нужно объединять все эти сервера в единую подсеть. При этом нужно не забывать, что все должны само объединение должно быть на одном оборудование. Когда система работает в виртуальной среде, нередки случаи потери пакетов, а документация этот момент исключает, поэтому тут есть такое исключение.
Еще одно из отличий это возможность создание портала самообслуживания средствами Omnitracker, т.к. в Service Desk 4.5 подобный портал приходилось писать самостоятельно. Управление данным порталом позволяет управлять им непосредственно из основной оснастки приложения. Если требуется добавить какую либо автоматизированную заявку, можно делегировать подобные права какому либо сотруднику. И администратор системы уже не будет заниматься подобными вопросами. Система позволяет назначить права доступа практически в любых направлениях, это безусловно огромный плюс, т.к. в Service Desk 4.5 большинство вопросов приходилось на плечи администратора системы. Конечно исключать полностью админов из процесса это неправильно, хотя система это позволяет, тогда мы вернемся к проблеме производительности и к появлению новых проблем и ошибок. Поэтому доверять ведение каких либо справочников стоит в тех местах где это не приведет к массовой проблеме.
Интеграция или как это можно еще назвать заливка данных в систему, если в Service Desk 4.5 данную операцию приходилось настраивать полностью администратору системы, тот тут система позволяет делегировать подобные полномочия кому либо. А сам процесс импорта колоссально отличается от Service Desk 4.5, при чем в лучшую сторону. Стало удобнее сам процесс определения полей откуда куда, модель заливки, проверка данных, время запуска, права запуска, ведение логирования, отправка отчетов т.п. В общем данных раздел заслуживает отдельной темы для разговора. Те кому постоянно требуется заливать данные в CMDB, или обновлять их процесс выгрузки и загрузки данных можно автоматизировать даже на уровне сетевой папки.
Из минусов хотелось бы отметить тот же факт, что и в Service Desk 4.5 если включить запись всех входящей и исходящей почты. В Service Desk 4.5 данным объектом является скрытый раздел Email в котором хранится вся почта. При больших объемах данный механизм начинает плодить проблему в производительности, приведу один пример. «Поступило новое письмо по почте, система должна создать обращение и привязать к этому обращению созданный email, что происходит на практике, система создает письмо, но привязка происходит с задержкой, как и записи по журналу, а если поток входящей почты будет составлять 100 обращений в минуту, туда будут входить не только почта на регистрацию, но и технологическая информация, обновление данных, подтверждение, отклонения, и.т.п. Другими словами система начнет захлёбываются в данном потоке. Решение в Service Desk 4.5 отключить данных механизм, либо ежедневно скриптами удалять ненужные сообщения.» В отличии от Omnitracker данный механизм позволяется нам определять какие сообщения нужно писать в базу, а какие нет, также есть возможность настроить удаление в автоматическом режиме тех сообщений которые потеряли свою актуальность. Поэтому вопрос производительности всегда встает на первый план.
Журнал по обращениям в базе данных это самая большая таблица системе, Service Desk 4.5 в которой хранились непосредственно данные, то в Omnitracker данный механизм реализован на уровне 0.1.2 цифр, а сами данные хранятся в других таблицах. Тем самым журнал все равно остается самой большой таблицей, но производительность, как правило данный раздел интересен группе анализа, тем кто строит отчеты и анализирует данные. Это тоже отдельная тема для разговора, но могу привести небольшой пример, если раньше для анализа данных взятых в Service Desk 4.5 и попытаться произвести сбор данных скажем за квартал, то скорость подсчета может составлять и 2 и 3 часа, в зависимости от сложности отчета. А также в зависимости от того как именно написан код вычислений. Если есть время, то большинство отчетов можно перевести в режим автоматического формирования на уровне SQL сервера и делать рассылки на нужные адреса или просто дать доступ к web просмотру отчета, с возможностью открыть непосредственно сам объект отчета, будь это обращение или инцидент. На тему отчетов можно долго и много вести разговоров, т.к. каждый отчет, как и цель отчета должны подвергается целесообразности того или иного отчета, что отображает данный отчет, на что влияет, достоверность данных, и т.д. даже вид отчета играет свою роль.
Из админских штучек появилась очень полезный механизм теперь при удалении объектов из системы объект всегда можно восстановить, но есть одно маленькое исключение если есть права на удаление и если тот сотрудник который удалил какой-то объект не подтвердил его полное удаление при выходе из системы. Также все удалённые объекты может удалить администратор системы например в вечернее время также по закрытию приложения.
В Service Desk 4.5 если настроить правило отправить email администратору системы с какой-то информацией об удаляемом объекте например, кто удалил, то на почту прилетало пустое сообщение, что произведено удаление объекта и все. А в Omnitracker данный механизм показывает, кто удалил, и что удалил, появляется возможность контроля.
В системе Omnitracker появилась такая возможность как написать свой скрипт, который бы выполнялся как на стороне клиентской части так и на стороне сервера, при этом все это уже задокументировано в Omnitracker. В Service Desk 4.5 подобный механизм был аналогом API.
Из плюсов Service Desk 4.5 была простая система поиска, в Omnitracker поиск это целый переработанный модуль, довольно сложно реализован, в Service Desk 4.5 было намного проще, что либо найти, если немного вникнуть в Omnitracker то и с ним не возникнет проблем с поиском, только немного больше отнимает времени. К вопросу поиска по системе можно отнести настройку представлений, также на эту тему можно рассказывать очень много и долго. Озвучу на мой взгляд пожалуй самую полезную штуку поиска, это полнотекстовый поиск, в системе определяются поля по которым возможен полнотекстовый поиск, тем самым если мы, что-то будем искать, то поиск будет производится по всем полям сразу, а не по одному. Отмечу что данный поиск не будет затрагивать саму базу системы, что является ключевым моментом данного поиска, если в Service Desk 4.5 кто-то захотел поискать все обращения по всей базе за весь интервал существования системы, то специалист выполняющий данную операцию может просто остановить работу всех подразделений которые работают с Service Desk 4.5. Это может привести к остановке не только подразделений, но и всей организации если данный продукт является входящей точной всей компании. Поэтому уделять внимание производительности и модели реализации поиска нужно с большим приоритетом.
Подведем небольшие итоги:
Я не стал затрагивать очень большой объем информации т.к. все в одном обзоре и не опишешь, например с чем нам пришлось столкнутся в момент миграции с Service Desk 4.5 на Omnitracker. Или какие ошибки чаще всего встречаются на виртуальной жизни серверов. Или как рисуются формы, как пишутся правила, тонкости работы приложения, и.т.п. Все выше сказанное является личным мнением, и личным опытом, где-то я мог ошибиться, надеюсь меня поправят если такое встретится )). Как говорится все мы люди и все мы ошибаемся, есть такое высказывание, не ошибается только тот, кто ничего не делает.
На этом я пожалуй остановлюсь, если у вас возникли какие вопросы задавайте их ниже, либо на нашем форуме.
С уважением,
Григорий Ненашев
