Евгений Новашов (автор тем)

Коллеги, добрый день.
Предлагаю поделиться опытом учета Ремонта СВТ в ServiceDesk.
На этапе внедрения системы (2003г.) данный процесс очень хорошо лег в Problem Managment.
Основные плюсы:
1. Применение обходного решения в Incident Managment: инцидент закрывается с обходным или временным решением (подменный фонд, сетевая печать и т.д.) при этом создается Проблема на ремонт.
2. Подходящая терминология: Проблема - неизвестная причина одного или нескольких инцидентов. Причина выхода из строя оборудования не известна т.е. начинается этап планирования и исследования проблемы.

На текущий момент у нас идет полноценное внедрение данного процеса (Управление проблемами) и принятое решение по ремонтам в 2003г. стало не очевидным.

Коллеги, добрый день.
Возник спор, что относится к Изменениям, а что нет.
Является ли внеплановая остановка сервиса Изменением.
Т.е. возник Инцидент недостаточно места, для устранения необходимо остановить сервис, удалить файлы и запустить сервис.
Моё мнение, что данная процедура относится к Изменениям.

Коллеги всем доброго времени суток.
Предлагаю поделится архитектурой БД:
У нас БД стоит на Oracle 10.2 (виртуальный сервер Linux - 4 процессора, 16 Гб ОЗУ), размер базы составляет 25 Гб. В системе 1,5 мил заявок, столько же Работ, около 0,5 мил KE.
Сталкиваемся с проблемами производительности, причина проблем - низкая производительность выполнения SQL запросов из-за отсутствия индексирования (во многих запросах). Проблему можно решить включением "статистики" в БД Oracle (есть такая фишка). В результате Oracle анализирует архитектуру таблиц и сам находит оптимальный путь исполнения запроса. Но почему то при статистики БД виснет через час (пока не разобрались в чем проблема).
Конкретный пример: если специалист находится в 2 группах, то "События сегодня" (Service Today) отрабатывает за 40 сек., если в одной за 1 сек. Причина в том, что при нескольких группах SQL запрос строится на команде IN в результате индексы не берутся.
Будем дальше "копать" причину зависания при "статистике".

Коллеги имеется SD 4.5 SP 23. Наткнулись на проблему с временными зонами. При отправке писем испонителям о назначенных заявках с использованием стандартного шаблонам "Service call Assignment Notification" система использует временную зону сервера, а не группы..сотрудника..аккаунта. т.е. сервер SD в Новокузнецке отправляет письмо специалисту в Москву в письме есть поле Deadline, в самой заявке Deadline 11:00 (к примеру) в письме же пишет 14:00 (+3 часа - часовой пояс Новокузнецка).

Скорее всего можно решить обходным путем через Calculate Fields или математику в DB Rule но все же... Система должна поддерживать такую простую функциональность.

Кто сталкивался с подобным глюком ОТЗОВИТЕСЬ !!! Заранее благодарен.

Коллеги, добрый день.
Кто-нибудь находил, где настраивается время дисконекта в консоле, по экспертной оценке по умолчанию стоит около 2 часов.