Пользователь
Логин:
Пароль:
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

 

Опрос


Погода

SLA + SL

Форумы
Обновления
Поиск
Пользователи 
Правила
Помощь
Войти

Страницы: Пред. 1 2 3 4 5 След.
SLA + SL, Управление уровнем сервиса
Я говорил о том , что правило может накладываться на системные действия и это приводит к тому что одно действие заменяет другое, как результат ничего не происходит.
Возьмите Запрос и заполните так чтоб СЛА не было в запросе, рул отработает?
Да отрабатывает сразу, т.е. это если заполняю без заявителя, который потребляет SLA. Григорий, а у Вас отрабатывает тоже в таком случае или во всех, когда есть и SLA?
Изменено: Наталья Мась - 04.05.2012 15:56:11
Да вроде работает... Привадите четкий пример, когда оно не отрабатывает. Попробуем на тестовом стенде.
Коллеги, всем доброго времени суток.
Появилась новая нетривиальная задача для HP OV SD (SP37), а именно - реализовать расчет времени недоступности устройств (платежные терминалы).
Задача поставлена следующим образом:
Есть n-ное количество платежных терминалов по всей филиальной сети (все часовые пояса РФ), часть из них обслуживаются силами ИТ, а часть - аутсорс.
Требуется реализовать процесс по расчету доступности устройств (без учета SLA для пользователей) за месяц с учетом всех часовых поясов, времени работы аутсорса и времени работы самих терминалов.
На текущий момент вижу пока единственный вариант позволяющий осуществлять подобный расчет - введение SLA для Конфигурационных единиц (КЕ, CI, они же терминалы).
Вопрос, возможно ли осуществить подобный функционал в HP OV SD?
Изменено: Владислав Черняткин - 29.09.2014 23:41:56
В теории возможно, если есть информация по недоступности (терминала), то нужно только логику определить.
Какая логика закладывается в формулировку «Процесс»? Ведь процесс может быть сложным или простым… smile:)
Цитата
Григорий Ненашев пишет:
В теории возможно, если есть информация по недоступности (терминала), то нужно только логику определить.
Какая логика закладывается в формулировку «Процесс»? Ведь процесс может быть сложным или простым…

Григорий,
информация по недоступности терминала будет получаться из 2-ех источников:
1. Пользователи;
2. Система мониторинга (уже настроено взаимодействие при регистрации сбоев через e-mail).
Логика следующая - поступает сбой, с момента регистрации сбоя до момента завершения сбоя в HP OV SD - недоступность терминала. Простым вычитанием из даты завершения даты регистрации недоступность некорректна, так как расчет производится по астрономическому времени, а не по фактическому времени работы терминала.
Из того, что сейчас смог реализовать в HP OV SD:
Создал отдельные SL (Уровень услуги) по всем промежуткам работы терминалов, привязал к ним соответствующие SLA и Service(Услуги).
Поле "Услуга" (для прописывания в обращении SLA и уровня услуги, так как через DB и UI Rule заполнять эти поля автоматически нет возможности, см. скрин DB Rule и SC) в обращении предполагал заполнять с помощью DB или UI Rule следующим образом:
"Когда создается новая запись "обращение"
OR Когда изменяется запись "обращение"
where NOT (КЕ;Уровень услуги пустое)
Test (Upd ate Data) Услуга se t to [КЕ Managed by service]"
Но при включенном вышеприведенном правиле Услуга не проставляется. К другим данным кроме [КЕ Managed by service] привязать не могу, так как корректно определяться SLA, SL и Service не будут.
Проблема, насколько я понимаю, в том, что в форме услуги поле "Managed CIs" не активно, соответсвенно в нем я не могу привязать КЕ к конкретной услуге (см. скрин Managed CIs).
Сорри, если изложил несколько сумбурно...
Рисунок
DB Rule.png (6.74 КБ) [ Скачать ]
Рисунок
SC.png (4.44 КБ) [ Скачать ]
Изменено: Владислав Черняткин - 01.10.2014 00:45:33
Сходу сложно сказать, но как вариант триггер на таблицу повесить, тогда правило будет работать не на прикладе, а на БД.
Цитата
Григорий Ненашев пишет:
Сходу сложно сказать, но как вариант триггер на таблицу повесить, тогда правило будет работать не на прикладе, а на БД.

Текущий вопрос отпал, я сам не досмотрел, что создал услугу с категорией "Business", а не "Operations management" smile;)
Теперь встал вопрос как должны быть связаны услуга, SLA и КЕ для отработки стандартного правила установки уровня услуги.
Изменено: Владислав Черняткин - 01.10.2014 03:06:38
Мне кажется логику нужно строить так, в системе нужно создать новую ветку и в эту ветку складывать все сообщения с ключем, который бы летел от мониторинга. При наступлении события, в КЕ менять статус, доступен или не доступен. В вот отчеты уже строить из журнала по изменениям данного статуса… (Не очень красиво, но должно работать…)
smile:lamo: простите за глупый вопрос, полистал форум но не нашел ответ..
По какому принципу выбирается SLA в Инцидентах? с чем связано с КЕ или Организацией (по принципу заявок)?
Ситуация: есть сервис с 4-5 SLA для разных организаций (филиалов) с разным уровнем и часами работы. при отрабатовании правила о просрочке, к примеру, с галочкой use supported hours берется рабочее время наименьшего (точно не могу понять какого именно) SLA. т.е. рабочие часы решения Инцидента расчитывается по SLA филиала, хотя организация в Инциденте указана не филиал.
Страницы: Пред. 1 2 3 4 5 След.

Сегодня были (гостей: 3, пользователей: 0, из них скрытых: 0)