forum.lissyara.su

Ветка для обсуждения статьи http://www.lissyara.su/?id=1569
З.Ы. Как обычно сутки обкатываю статью, затем делаю открытой.

А на Apache 2.0 никак нельзя было?
Статья хорошая, а тикеты зло. Вроде все сначала красиво, хорошо - мониторинг
за суппортом идет, кто-сколько сделал и тд. Но время сжирает на оформление
этого бреда много. В результате, все что можно решить за 2 минуты по телефону
занимает 10 с четким расписыванием проблемы и ее закрытия. Я сделал просто -
положил на оформление заявок х..

Сколько пользователей ты обслуживаешь? Сколько сотрудников в твоем подчинении занимаются техподдержкой? Каким образом ведешь контроль исполения заявок? В какой форме отчитываешься вышестоящему руководству? Сколько офисов/подразделений в том числе удаленных территориально у тебя на обслуживании?
Я думаю что ответы на эти вопросы прояснят необходимость или ненужность использования подобных систем.
На apache2 встает практически без изменений. Если нужно будет, то внесу поправки для использования на apache2. Просто у меня хостинг на apache1 работает, поэтому про него и писал.

Я тебе "снизу" пояснил почему это все ущербно. Я один обслуживаю
порядка 80 компов и 5 серверов, и кучу орг техники в придачу, на двух
площадках. Три дня в неделю появляется более опытный коллега, который
мне помогает. Я знаю сколько времени уходит на написание заявки, и решение
проблемы, и описание ее в hpov. Моя работа протекала бы более рационально,
если бы я не тратил на писанину время.

serge писал(а):Если нужно будет, то внесу поправки для использования на apache2. Просто у меня хостинг на apache1 работает, поэтому про него и писал.

Разницу с Apache 2 напиши, пожалуйста. В силу нарастающей актуальности последнего

Опять же один. Это кстати позволяет избежать части проблем. Но когда 2-3 и более людей начинают работать совместно над решением проблем порой одного и тогоже пользователя начинают возникать разногласия. Одновременно за одну и туже проблему могут взяться 2 человека и положительного результата это не принесет.
Большие организации в любом случае не смогут отказаться от работы по заявке, будь она в бумажном или электронном виде. Раздавать сотрудникам свой телефон это совершенно не выход. Если пользователей немного, порядка 30-50, с учетом в день около 3-5 обращений, то это еще терпимо, а если речь идет о более 1000 сотрудников? Один человек здесь физически не справиться. А держать в голове все заявки... там же не hdd
В моем случае я пришел к необходимости имспользования этой системы для централизованного сбора заявок, распределения по исполнителям и ведения очередности исполнения. Даже несмотря на то что, пользователей у меня в данный момент не более 100. Но в отделе 3 человека, занимающиеся тех. поддержкой. Без этого схема работы отдела техподдержки имела "коридорно-звонковый" вариант. Т.е. тебя кто-то перехватывает в коридоре, ты говоришь что это не по твоей части, но тебя уговаривают зайти поглядеть почему не работает. В итоге ты поняв проблему обещаещь передать ее нужному человеку, пока идешь к нему тебе звонят и просят поглядеть уже на другую проблему и ты автоматом забываешь про первую.... ИТОГО: суеты много, а решений проблем почти нет, и самое главное на всех совещаниях когда какой-то отдел, чтото не успел сделать все успешно валится на IT-шников. Типа мы за ними весь месяц бегали, чтобы они нам комп починили, а они гады такие нас игнорировали и поэтому мы вот ничего не сделали А реально обращение с проблемой если и поступало, то в последние 2-3 дня, когда уже ничего сделать было нереально. Вот когда мне надоело выслушивать эти бредни, то принял решения все обращения в отдел документировать. Пусть это займет какое-то время, но это, во всяком случае, для меня как начальника отдела снимет головную боль из-за этой неразберихи.
Возможно сумбурно, но как есть)))

Andy писал(а):Разницу с Apache 2 напиши, пожалуйста. В силу нарастающей актуальности последнего

Ок, седня допишу.

спасибо за тикеты, буду думать как у себя внедрять

Щас на RT сижу, вот хочю перейти на otrs так как она менее тормзнутая (хотя otrs не намного лучше ) если какой нибудь способ автоматизирванно перезнать базу из RT в OTRS ?

Ой, serge так это ты автор статьи ? Не узнал, богатым будешь ? как жизнь?

to wizard:
Так не зря ж с тобой советовался)
Норм жизнь... налаживается потихоньку

По пожеланиям трудящихся разобрался с Apache2 http://www.lissyara.su/?id=1570
====
И первую и вторую статью периодически буду дописывать в соответствии с рекомендациями и степенью внедрения этой системы в продакшен. Отдельное спасибо wizard'у

хорошая тема -)
вот интерестный (не по статье момент):

В результате, все что можно решить за 2 минуты по телефону
занимает 10 с четким расписыванием проблемы и ее закрытия.

у меня тоже самое, решил поэтапно прийти к такой системе...т.к. реально - да много времени уходит.
Причина на мой взгляд: юзеры не могут изложить суть пробелмы "в один заход" , что им надо и теряеться время на выяснение
"подробностей". Поэтому пока существует расслыка admins@domain.com которую все читаюти куда все пишут че хотят. А потом когда
научим юзерей писать/выкладывать суть задачи и сами поймем что и как требовать тогда наверно на Вэб тоже
подумаю пересодить.

ЗЫ: за статью спс !

to Morty:
Ну не без этого. Хотя я для себя понял что можно и нужно переходить уже, т.к. все равно часть пользователей сразу не разберется что к чему и будут рабоать по старой схеме. Но все равно найдутся "подвинутые" юзеры и за ними потянуться остальные.
З.Ы. Вообще реформы никогда не проходят гладко. Например, переход на домен и личные учетки мне столько нервов в свое время попортил, а сейчас это норма для корпоративной сети и все признали что так проще и удобнее

THX за статью. поставилось влет на apache22. Юзаю, тещу... буду думать как в продакшн пустить

А по поводу удобности. Хорошо, можно обойтись без подобной системы если все локально или в пределах
города... а если нет ? А если я вот сижу в Минске.. а система работает в Москве... ???
Могу рассказать с чем сталкиваемся и чем удобны подобные системы.
Замечательно если заказчик предоставит канал удаленный чтобы можно было подключиться чего то подправить,
настройки подрихтовать.... а как правило наше программное работает на системах физически не связанных с
интернетом и никто туда его в жизни ради своего спокойствия не подрубит. Второй аспект... ну супер если обслуживаем
систему написанную под свои нужды.. а если программное обеспечение стоит у 20 заказчиков.. причем с абсолютно
разными конфигами и даже версиями... Тут чтобы не запутаться и ничего не перепутать монстром надо бы.. а по почтовой
переписке заколебешся выяснять что к чему. Дальше бывает вообще весело... есть верхний саппорт который самый умный
и сидит в офисе.. а есть "полевой" саппорт который кочует по заказчикам... доступ через веб к такой системе очень упрощает
ситуацию... Вообщем это хорошая система.. другой вопрос что ее надо грамотно внедрить и обучить заказчика и саппорт пользовать ее )

а вот не подскажете ли как в Дебиане 4.0 это чудо установить? Дело в том, что при установки из репозитория, инсталлятор сразу пытается к базе MySQL подцепиться (MySQL конечно же я сам выбираю), но MySQL сервер на другом компе, а инсталлтор пытается найти на localhost'е... Из-за этого при попытке правильно прописат базу через веб-интерфейс (http://<имя компа>/otrs/installer.pl) выскакивает ошибка:
Software error:
install_driver(mysql) failed: Can't locate DBD/mysql.pm in @INC (@INC contains: /usr/sbin/../../Kernel/cpan-lib /usr/sbin/../.. ../../ /usr/share/otrs/Kernel/cpan-lib /usr/share/otrs/ /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . /etc/apache2 /usr/sbin/../.. /usr/sbin/../../Kernel/cpan-lib) at (eval 114) line 3.
Perhaps the DBD::mysql perl module hasn't been fully installed,
or perhaps the capitalisation of 'mysql' isn't right.
Available drivers: DBM, ExampleP, File, Proxy, Sponge.
at /usr/share/otrs//Kernel/Modules/Installer.pm line 202

For help, please send mail to the webmaster (webmaster@localhost), giving this error message and the time and date of the error
Т.к. при установке приходится пропускать пункт "Настроить базу данных для otrs2 с помощью dbconfig-common"

Чет подсказывает что модуль для MySQL не стоит.

а статью спасибо, но otrs на ура по докам ставиться, интереснее другое У кго есть живой опыт внедрения ? Каковы впечатления ?

Розничная торговля, куча (порядка 100) филиалов по региону 3 человека в IT.
Классическая ситуация и, как догадываетесь, начальству отчёты подавай и IT не работают, а только денег просят.
Тикеты провели приказом по компании. Грубо говоря - "нет тикета - нет проблемы" Юзерам голву вебом не забивали, а все пишут на спец. ящик, а otrs уже по теме разбирает в какую очередь (не только IT). Первый месяц юзеры тупили жестоко, но потом начальство им вставило и всё. Проблем никаких. Я, наверное, первый раз увидел, как реагирует генеральный на месячный отчёт по отработанным заявкам. Даже удивился: "Это вы на самом деле всё сделали?"... Потом дали доступ руководству на некоторые очереди - они теперь сами смотрят и хвастаются
Так что используйте тикеты, а юзеров и то же руководство можно поставить перед фактом.

WBR, Sph.
---MCP

Да вот еще serge пробовал ли Trac Project
Давно присматриваюсь может статью накатать.
Довольно забавная вещь посмотри что скажешь?

У нас в компании всё крутится на аналогичной системе- Mantis.
Моё субъективное мнение- Мантис удобнее и гибче чем OTRS.

Raven2000 писал(а):Да вот еще serge пробовал ли Trac Project
Давно присматриваюсь может статью накатать.
Довольно забавная вещь посмотри что скажешь?

Проснулись... :-)
http://forum.lissyara.su/viewtopic.php? ... rac#p62296

а коекто обещал статью про внедрение

?

просто было бы здорово, если бы ктонить написал статью именно про внедрение, как подводные камни и тд. Тем более статья про установку таким намеком легким кончается ...