Давайте рассмотрим несколько ходов развития системы.
Но прежде чем мы начнем рассматривать развитие системы, давайте взглянем на текущую структуру Вашей системы. Скорее всего, у большинства из Вас используются штатные механизмы. То есть, как систему установили, так ее и эксплуатируете. Service Desk 4.5 можно довести до ума, при этом потребуется не так уж и много сил, главное знать, что Вы хотите увидеть на выходе.
Приступим: Первый, назовем его «Системное изменение», второй, назовем «Правила системы».
Системные изменения: меняем штатный механизм работы системы на тот, что необходим Вам. Сюда мы отнесем «Принцип работы правил. Изменение штатного функционала на нештатный».
Думаю, лучше привести пример: Скажем у Вас 12 app серверов, каждый из которых работает по своим направлениям, кто-то почту разбирает, кто-то с пользователями работает, web-приклад, агент-сервер и т.п. Главное, что их объединяет - это «scheduled tasks», у каждого сервера он свой. На самом деле, это плохо, обратите внимание: каждый сервер занимается свои делом, а тут выходит, что у них есть что-то общее. Изменив системную логику, можно отобрать у каждого сервера данный функционал и направить его на отдельный сервер, который будет работать только с этими объектами.
Вы спросите, зачем это нужно? Ситуация такова, допустим, в Вашей системе включена возможность групповой правки. И есть правила, которые каким-то действием генерируют scheduled tasks, но создание данного scheduled происходит на том сервере, на котором производили изменения. А теперь представьте себе ситуацию, что проверка данного события совпадет с максимальной нагрузкой на систему. Как правило, это утро, если взглянуть на схему изнутри, то можно представить, как плохо становиться серверу, которому нужно обрабатывать не только запросы специалистов, но еще и запросы Scheduled, исполняя при этом еще и правила системы. Т.е нагрузка увеличивается в два раза. Отсюда могут рождаться новые проблемы. Замедление или зависание приклада, повышенная нагрузка на базу данных, ошибки java. Казалось, одна мелочь, а может столько проблем создавать.
Можно открыть любой объект из командной строки. Например Вы хотите открыть объект SC (Service Call – Назовем «Обращения» ) или WO – Задания , Персонал;
Для этого будем использовать sd_dataform.bat - "%SD_CLIENT2008HOME%bin\sd_dataform.bat" – для 2008 клиента. Пишем (bat - файл).
Предположим у Вас есть поле комментарии (промежуточное поле), внеся в это поле какую либо информацию, данные попадут в поле информация. - с комментарием кто добавил. Например, так:
Теперь можно немного углубиться в дерби. Т.к мы рассматриваем систему с точки зрения администраторов, то нужно взглянуть на это с точки зрения специалиста. Допустим, кто-то добавил информацию в обращение, которое я должен исполнить, но я об этом не знаю. Решение довольно простое, отправлять уведомления специалисту который записан в поле «Специалист», при условии, что (Регистрация изменено не равно System administrator) и поле специалист не пусто. При изменении поля комментарии. Далее мы просто можем отправить исполнителю обращения весь текст поля информация.
Если мы создали представление в админке из под 2008 версии, то мы можем получить разного рода ошибки на версии 4.5.
Например:
Вкладка «Другие» - настройка вида представления, шрифта, линий, раскраски.
С недавнего времени начал отключать правила, за которые отвечает scheduled task. Причина всему этому «Групповые правки» ‘пользователей’ и завязка на DB.
Итак, возьмем для примера простые два условия:
• Предположим, мы хотим закрывать все обращения, которые находятся в каком-то статусе более 7 дней.
• Далее, мы хотим видеть все нарушения по «срокам исполнения» обращений и помечать такие элементы.
Построение системы рано или поздно начинается с настройки почты, а точнее с полей From Adress и Replay To
За основу возьмем стандартную схему построения входящей почты.
Создается список рассылки, в который включается почтовые адреса назначения. Для примера sd1, sd_today, sd_archive – (будут входить в список рассылки helpdesk@domain.ru)
Одна из самых больных тем администраторов почтовых систем - Это СПАМ. Как известно Спам это одна из наиболее постоянных, каждодневных проблем, приходит левое сообщение с рекламой, с левого ящика, на который нельзя ответить. А точнее ответить-то можно, но в ответ система будет плевать, что такого почтового ящика не существует. Если Ваш Service Desk смотрит наружу, то наверняка вы столкнулись с тем, что на каждое сообщение (не зарегистрированное) система плюнет фразу, «Ваш е-mail не зарегистрирован» у кого как. Расскажу, как можно избавить администраторов exchange от такого спама, а для себя мы избавим систему от лишних сообщений, и лишних проверок на фальшивые email-ы.
Как бы мы не следили за системой, а контроль все-таки дожжен быть. Еще в 2006 году поставили систему на круглосуточный мониторинг, (за основу взяли показатели CPU, Service, RAM, HDD) – но как показала многолетняя практика этого не достаточно. Если взглянуть на это с точки зрения мониторинга, то все отрабатывает корректно, а если с точки зрения администратора, то возникает задержка в принятии решения.
Начнем с того, что у нас есть Active Directory и кадровая система постоянная на платформе SAP. Все это дело нужно скрестить с Service Desk 4.5.
Поделим все на этапы.
•Получение данных из SAP.
•Написание DTS пакета на SQL.
•Загрузка данных в SQL полученных из SAP «Средствами DTS».
•Выгрузка данных из Active Directory «Средствами DTS».
•Выгрузка данных из Active Directory с удалением двойников по ФИО «Средствами DTS».
•Выгрузка данных из Service Desk «Средствами DTS».
•Первичная загрузка данных в Service Desk.
•Финальная загрузка данных в Service Desk.
Теперь все по порядку.
Получение данных из SAP
Предположим, что данные из кадров мы можем получать только раз в сутки (Ночью), в определенном формате «Фалы TXT».
Хотел бы на своем примере показать, как себя ведет система при большой нагрузке. При этом всю нагрузку держат 3 сервера (APP). service desk
Сервера все разные, а нагрузки парой бывают такими, что даже при самом правильном распределении баланса это не спасает.
Почтовый сервер:
Сервер занимается только почтой и ни чем другим.
Два оставшихся сервера, держат всех пользователей, это порядка 300 в online. Это превышение нормы на 214% на сервер, не отработка правил составляет 0,4% в день. (Неотработанные Scheduled, или сбой в работе).
