ITSM Changes

[sandsnake]

Доброе всем утро.

Работаю под одним юзером которому дадены все права на все.
Создаю Change, в нем создаю 2 workorder'а. Отрабатываю workorder'ы, перевожу их в состояние closed. Workorder'ы светятся зеленым а сам Change продолжает жить в состоянии Requested.

Начитавшись форума полез в Condition. Там создаю следующий алгоритм работы:

Matching: Any expression (OR)
Expression:
ITSMWorkOrder:все:WorkOrderState:is:Закрытый
Действие:
ITSMChange:его номер:ChangeState:set:sucessful

Никаких изменений.
Создаю еще один workorder в этом Change (надеясь на то, что сейчас-то condition отловит изменения в change'се), довожу его до состояния closed. Но опять никаких изменений - Change продолжает жить в состоянии requested и светится сереньким квадратиком.

Вообще, правильно ли я понял суть работы Change? И в правильном ли месте ожидаю изменений его состояния?
Если я правильно все понял но где-то накосячил - поправьте, пожалуйста. А то уже несколько дней топчусь вокруг одной ступеньки которую вижу, но запрыгнуть не получается

[ykolesnikov]

Сам вокруг этого крутился и тоже не добился результата, потом время поджало и пока отложил. Посмотрите в сторону State Machine для Workorders & Changes - где-то там "собака порылась..."

[JohniGo]

От кабы кто расписал пошагово как это работает... Я в б прям... не знаю... расцеловал бы по Брежневски... В десны..

[sandsnake]

От кабы кто расписал пошагово как это работает... Я в б прям... не знаю... расцеловал бы по Брежневски... В десны..

Похоже, что я скоро до такого же состояния дойду

Но пока цитата из доки по ITSM касательно свойств чанги:
When creating a new Change, the status is automatically set. When modifying an existing Change, the Change Builder and Change Manager can manually set the status. Available status and result status are defined by the integrated State Machine, see the section called “Change State Machine ”.

Во втором предложении пишут, что юзеры, являющиеся Change Manager'ом и Change builder'ом могут вручную изменить статус чанги. Ткните меня носом как это сделать!

А со State Machine, я свой вопрос и запостил... На мой взгляд, все сделал логично. Но где-то бяда. Точнее, внутри чанги это называется Conditions. ykolesnikov, Вы это имели ввиду?

[yuri0001]

Да, имел в виду именно это, Stste Machine, но не Condition. Condition - это условие выполнения неких действий, при этом состояние может и не меняться, например, один агент залил системный софт, а другой - специальный. А State Machine задает порядок смены статусов и его не обойти если такие переходы не предусмотрены в ней.
Что касается установки/смены статусов вручную, сейчас системы нет под рукой, но помню, что делал в опытах, там есть пункты меню для этого. Если их нет, значит где-то в конфигурации "галки" не стоят в *ModuleRegistration параметрах или в правах агента в группах
Хотя, конечно, в Conditions прописываются и возможность смены/установки статуса
А Ваш юзер он во всех ипостасях - и Change biulder и Change Manager? В соответствии с мануалом и Вашей цитатой из него - только если они "оттуда" у них будут нужные кнопки.

[sandsnake]

Нашел как делать вручную.
В общем так: в конфигурашке меняем значение ITSMChange::Frontend::AgentITSMChangeEdit###ChangeState c 'нет' на 'да'. После чего зайдя в чангу, нажав кнопочку "Редактирование" и спустившись в самый низ, под всеми описаниями и приоритетами с импактами видим еще одно меню - изменение статуса самой чанги.

IKEA отдыхает. а ITSM'щики, похоже, насквозь прониклись идеологией этого дистрибутива: http://www.linuxcenter.ru/lib/press/sex_linux.phtml (не сочтите за рекламу, просто описание дистра крайне подходит под нашу ситуацию).

[yuri0001]

Надо еще посмотреть на cron и Generic Agent, они, похоже здесь тоже задействованы, кто или что еще может менять состояния при наступлении определенных событий

[sandsnake]

Да, generic agenta я смотрел. Глаз зацепился только за Execute Custom Module. Но моих знаний пока не хватает чтоб его как-то задействовать.
А вот с кроном ситуация следующая - в тем есть скриптик otrs.ITSMChangesCheck.pl. За обнадеживающим называнием скрывается всего-лишь нотификации касающиеся чанги.

Вообще, у меня сложилось ощущение, что статус чанги должен быть сменен человеком которому дадены такие права. В принципе, это логично: бригадир (change builder) создает Change, в ней продумывает и расписывает workorder-ы которыми занимаются уже его подчиненные. И когда подчиненные отчитались по workorder'ам изменением его статуса, бригадиру нужно проверить корректность работы подчиненных, и только тогда "поставить свою подпись" путем изменения статуса Change на Success.
Подозреваю, что именно такой дефолтный алгоритм работы Change реализовывали разработчики ITSM.

А вот для того, чтобы ввести в этот процесс автоматизацию, imho, и был введен conditions. Но мне до сих пор не понятно кто его должен отрабатывать.
Все-таки, otrs далеко не демон. Посему, события в нем могут случаться только по нажатию кнопки юзером в интерфейсе (как следствие вызовом определенного скрипта) либо из другого демона. В нашем случае это cron. Но в кроне пусто.

PS. В голове крутится шальная мысль - мы пользуем бесплатный вариант OTRS. Но есть и платный. Скорей всего фишки автоматизации присутствуют именно в платном варианте "из коробки". Т.е. нам надо напрячь умишко, и написать свой скриптик для крона который отработает condition...

[yuri0001]

Добрый день1

За обнадеживающим называнием скрывается всего-лишь нотификации касающиеся чанги.

Вполне вероятно!
В принципе, ничего страшного в этом нет, надо только подучить манагеров перейти от рефлексов к осознанным действиям.
В платном, действительно, есть кучка add-on'сов, которые облегчают жизнь корпоративному админу.
Наше дело, высосать все что можно из бесплатной части и накапать идей разработчикам как улучшить жизнь "жирным" гусеницам. На этом мир держится.

[alexus]

PS. В голове крутится шальная мысль - мы пользуем бесплатный вариант OTRS. Но есть и платный. Скорей всего фишки автоматизации присутствуют именно в платном варианте "из коробки". Т.е. нам надо напрячь умишко, и написать свой скриптик для крона который отработает condition...

НИКАКОГО платного OTRSа нет!
Есть дополнительные платные модули, которые добавляют разные фишки, которые никаким образом не влияют на основной функционал.
Что касается Conditions

Подозреваю, что именно такой дефолтный алгоритм работы Change реализовывали разработчики ITSM.

А вот для того, чтобы ввести в этот процесс автоматизацию, imho, и был введен conditions. Но мне до сих пор не понятно кто его должен отрабатывать.
Все-таки, otrs далеко не демон. Посему, события в нем могут случаться только по нажатию кнопки юзером в интерфейсе (как следствие вызовом определенного скрипта) либо из другого демона. В нашем случае это cron. Но в кроне пусто.

то Вы "просто не умеете их готовить" .
Все прекрасно работает. Если не может разобраться, можно задать "вопрос другу". Пишите в личку, поможем.

Кстати, думаю надо провести вебинар по настройке "ITSM Change". Небесплатный скорее всего, но явно намного дешевле, чем ехать на обучение в Германию

[v.b.kunin]

Добрый день!
Насколько я понимаю, переводиться change из статуса с статус могут только в соответствии с state machine. То есть из requested нельзя перевести сразу в sucessfull, если это не разрешено. Сейчас на демо-аккаунте на сайте отрс попробовал последовательно перевести одним и тем же workorder (переделывая действия в conditions пересохраняя workorder в статусе closed) change по статусам: Requested -> Pending Approval -> Approved -> In Progress -> Failed, все сработало.

[ykolesnikov]

Добрый день!
Всё сработало автоматически или Вы вручную ставили следующее состояние, выбирая из списка доступных, который и определяется State Machine?
В голове как-то крутится модель, что состояние может быть изменено системой по условию (condition) в Workorder или Change - или мы все в счастливом/несчастливом заблуждении?
Или Change Manager должет вручную, как в обычной заявке, руководствуясь уведомлении об исполнении Workorder'ов сам переводить эти состояния?
А как агенты, исполнители Workorder'ов узнают, что можно приступить к своему Workorder, который следует за предыдущим? Чего-то не хватает для складывания puzzle'а.
Можете поподробнее, "на пальцах", описать свой опыт, который у Вас получился - какая была поставлена задача, какие наряды составлены и объединены какими условиями? Что при этом происходило.

[v.b.kunin]

Добрый день!
Конечно все автоматически!
Описываю подробнее. Никакой практической задачи, кроме как разобраться в системе, не было, потому все описанное ниже делал на демо аккаунте под логином Change Manager (http://www.otrs.com/de/produkte/itsm/online-demo/).
1. Создаем Change "My Change"
2. Создаем Workorder "Approval", назначаем себя агентом
3. Создаем Workorder "Workorder", назначаем себя агентом
4. Создаем Condition "Condition Approval"
- Expressions:
OBJECT = Workorder, SELECTOR = 1 - Approval, ATTRIBUTE = Workorder State, OPERATOR = is, VALUE = closed.
- Actions:
OBJECT = Change, SELECTOR = 2012052140000014, ATTRIBUTE = Change State, OPERATOR = set, VALUE = Pending Approval.
OBJECT = Workorder, SELECTOR = 2 - Workorder, ATTRIBUTE = Workorder State, OPERATOR = set, VALUE = Accepted.
5. Создаем Condition "Condition Workorder"
- Expressions:
OBJECT = Workorder, SELECTOR = 2 - Workorder, ATTRIBUTE = Workorder State, OPERATOR = is, VALUE = closed.
- Actions:
OBJECT = Change, SELECTOR = 2012052140000014, ATTRIBUTE = Change State, OPERATOR = set, VALUE = Approved.
6. Все готово к выполнению. Теперь попеременно щелкаем руками статусы Workorder'ов и смотрим как меняется статус Change.
Логика такая: выполняется первый Workorder "Approval", после него меняется статус Change (Requested -> Pending Approval) и статус второго Workorder "Workorder" (Created -> Accepted). Далее выполняем второй Workorder "Workorder", после чего статус Change меняется Pending Approval -> Approved. Ну и так далее. Главная фишка в том, что менять статусы можно только из разрешенного в разрешенные, а это настраивается в State Machine.
Оповещения агентов при изменении статусов наверняка можно настроить через Agent Notifications в меню Администратора.

Можете посмотреть Change 2012052140000014 на демо-аккаунте http://www.otrs.com/de/produkte/itsm/online-demo/.

[ykolesnikov]

Добро!
Спасибо за развернутый ответ.
Отличная идея попробовать на Online Demo.
Еще раз спасибо. Будем продолжать разбираться.

[JohniGo]

v.b.kunin, честь Вам и хвала!!! Троекратное УРА и прочая и прочая и прочая...
Лобызаю виртуально в десны (аки обещал...)
Безмерный респект и уважуха от меня лично и от всех заинтересованных в данном вопросе граждан!!!

Теперь все встает на свои места более-менее. Можно начинать настраивать управление изменениями.
У меня пока возник единственный вопрос, состояния Изменений (Cange) и Заданий (не знаю как лучше перевести Workorder) жестко фиксируются в State Mashine? Т.е. набор доступных состояний всегда одинаков? Как-то это вроде бы не совсем логично?
Опять же не совсем понятно, как их задисаблить. Кнопка "добавить" есть, а "удалить" не наблюдается...
Тоже самое и с типами workorder-ов. Не нашел где они настраиваются...

[alexus]

Удалять такие сущности в OTRS нельзя для сохранения целостности данных. Можно только изменить. Или сделать "инвалидами".

[JohniGo]

Алексей, это уже давно стало понятно... А где им оформить инвалидность не подскажите? (как-то не нашел нигде...)
И про Машину Статусов (чуь не написал "желаний" , привет АБС) не просветите? Я понимаю, что коммерческая тайна, но все-таки...

[ykolesnikov]

Удалить переход можно внутри окна соответствующей машины - последняя колонка - "Удалить". Нажимаете в ней супротив соответствующего перехода - он и удалится.
А вот состояний добавить или убавить, не вижу где. В SysConfig - есть только установка цвета лампочек и там их можно менять - удалять и добавлять и изменять. И в настройке поиска в Changes - там тоже список состояний, который можно менять. Но вот добавятся ли они если в эти списки добавить новое - надо пробовать.

[alexus]

Инвалидность здесь - ../otrs/index.pl?Action=AdminGeneralCatalog&Subaction=ItemList&Class=ITSM%3A%3AChangeManagement%3A%3AWorkOrder%3A%3AState
Машина времени здесь - ../otrs/index.pl?Action=AdminITSMStateMachine

[ykolesnikov]

Ну конечно же, всё правильно. А то мучила дежавю, видел же, когда CMDB мучил.

AdminGeneralCatalog.png (25.14 КБ) 19433 просмотра

С миру по нитке - голому рубашка.
Спасибо, Алексей!

[JohniGo]

Огромное спасибо, коллеги.
Вот там я не догадался глянуть.
Остался у меня один ключевой вопрос: все-таки цепочка статусов для изменений и воркордеров всегда одинаковая? или их можно задавать разными для разных шаблонов?

[ykolesnikov]

Думаю, а скорее уверен, что одна, т.к. StateMachine для каждого из них одна.
Если только просто их модифицировать и добавить, дополнительно, состояний (необязательно) и возможных переходов (скажем, сразу из начала в конец) для простых изменений. Это даст возможность уже в шаблонах изменений задавать условия и изменения состояний по этим укороченным веткам.
Машину времени не обойти. Я так думаю!

[alexus]

И правильно думаете!

[JohniGo]

хм. обидно однако...
Т.е. получается что процесс прохождения изменений и процесс выполнения работ всегда одинаков и не зависит от типов того и другого?
А доступные следующие состояния фильтровать (сужать список возможных) как-то можно? или всегда одна общая схема и можно только руками выбирать по какой цепочке пойти?

[ykolesnikov]

Я так понимаю, что через Conditions, можно управлять прохождением Changes и Workorders по любой из доступных в StateMachine веток - от самых длинных, до самых коротких, лишь бы она (машина) это дозволяла. Если сделаете ветку START->In Progress->END - сможете и по ней ходить - сразу в дамки