Pull to refresh
17
0
Владимир Фисейский @fiseisky

Разработка IT-продуктов, IT-управление, DevOps

Send message
Хороший вопрос) Да, платные решения, конечно, рассматривались — куда ж без них. Не буду вдаваться в конкретные цифры, потому что это было достаточно давно и все уже сто раз поменялось. Но в какой-то момент я понял, что овчинка не стоит выделки. Внедрение сервисдеска — процесс очень небыстрый. Все сразу точно освоено не будет и вообще не факт, что оно когда-нибудь пригодится.

То есть здесь противоборствуют две силы — получить сразу навороченное решение, долго его внедрять, еще дольше подгонять под себя и понять, что никто этим не пользуется по причине того, что туда заявку 10 минут заводить. У меня был отрицательный опыт использования сервисдеска именно с такой проблемой. С другой стороны, я прекрасно понимал, что не знаю, чего на самом деле хочу и что мне будет нужно. Потому стоило взять самое примитивное и просто попробовать, чтобы потом выбрать решение наиболее соответствующее моему профилю деятельности.

В этом плане платные сервисдески просто подавляют своей развитой функциональностью. Есть все, прежде чем начнешь полноценно работать надо проштудировать пару талмудов и то не факт что поможет. Ну и цена, конечно, не последний аргумент тут — если бесплатное решение обеспечивает нужную функциональность с нормальным качеством, не вижу смысла переходить на платное. Потому пока и выбран RT. По совокупности параметров он оказался максимально близок к тому, что мне изначально хотелось.
Спасибо за вопрос! Конечно, не понравилось и не получилось гораздо больше, чем удалось. Причем как в техническом плане, так и в бизнесе, в целом.

Рассказывать же о том, что удалось, разумеется, приятнее. В отличие о того, что добавило шишек на лбу. Я про грабли :).

Если это интересно, про грабли техподдержки стоит, наверное, рассказать отдельно. Попробую сделать это в следующей своей заметке. Что скажете?
Можно посмотреть в сторону FusionPBX. Но надо понимать, что написание диалпланов для него требует понимания того, как они вообще устроены и работают в Freeswitch. В Elastix и FreePBX все-таки попроще. Я бы вам посоветовал остановиться на FreePBX, раз вам Elastix приглянулся.
Да-да, вы меня прекрасно понимаете. Когда переносил диалплан в FusionPBX, пришлось немного поплакать кровавыми слезами. Потому что любовно написанные диалпланы никак не лезли в условную логику FusionPBX. Какие-то цифры, какие-то необязательные редиректы, необходимость держать в голове то, что extension-ы входящей маршрутизации лежат в определенном месте общего набора extension-ов. Что можно рабочее время запилить прямо в extension, но тогда оно не будет отображаться в web-интерфейсе. Или запилить в интерфейсе и понять, что для него создался отдельный extension и непонятно, как оттуда прыгнуть назад. Документация… не будем о грустном. Но при этом это пока единственный адекватный интерфейс. Остальные или не развиваются, или полуфабрикат, как Kazoo. Который круто выглядит по возможностям, но для нас дикий оверинжинеринг.
Вы не поверите — используем. Но это не отменяет необходимости интегрирования. На FusionPBX переехали относительно недавно, до этого была еще пара попыток переехать, обе неудачные. Переезд, кстати, состоялся, в основном, для того, чтобы дать доступ к некоторым сервисам телефонии (просмотр статуса линий, просмотр CDR) другим сотрудникам. Мне и в консоли жилось хорошо. Но все равно пока впечатление, как при плохо подогнанном пиджаке, вроде норм, но тут чутка жмет, тут перекошено. Мной внесены некоторые изменения в скрипты FusionPBX, в частности, добавлены per-user variables для гибкого управления тем, кому с какой исходящей линии звонить. Изменен extension blacklist-а, потому что я хотел, чтобы спамеры слушали мартышек. Freeswitch всегда меня поражал своей гибкостью. Ты думаешь — а вот сейчас я что-нибудь эдакое как проверну! И оно работало. о_О С FusionPBX ограничений стало больше. Но это так, мое старческое брюзжание. =)
Ага, тоже хорошая вещь, но у меня против нее было несколько «но». У нас, в основном, используются софтфоны — аппаратный телефон всего один. А они очень разношерстные и поддерживают все разные протоколы для телефонной книги. Дополнительно все осложняется тем, что кто-то сидит на Винде, кто-то на Линухах, где адекватных софтфонов вообще раз-два и обчелся. И вдобавок хотелось, чтобы поименованные записи попадали в CDR, что при локальном запросе соответствия номер -> контакт недостижимо. У меня, на самом деле, есть набросок скрипта, который готовит телефонную книгу для MicroSIP, но он пока не дописан. Предполагалось его размещать тоже на Freeswitch.
Что касается оценки занятости ниши тут наверное найдутся разные мнения, но на мой субъективный взгляд рынок очень даже открыт как к новым игрокам, так и к идеям. Кейсов конечно и свежих много, а приведённые по-моему 2013 и 2014 гг.
Если честно, не встречался с нестандартным поведением окон и пока ничего сказать не могу насчет их необычности. Но рискну предположить — проблема заключается в способе рисования на экране и, скорее всего, затрагивает все клиенты.
Он подходит только для Linux-хостов, у нас же почти сугубо винда.
Я отключаю secure screen при вводе пароля и UAC выскакивает на стандартном экране без обрыва сессии. Да, возможно несколько понижает безопасность, но лучше решения пока не нашлось.

Смотря с какой позиции лучше. Про VPN много сказано ранее, удаленный помощник тоже непросто настроить да и подтверждений он требует прилично.
Я рад за них и их админов, но что тут отвечать не знаю, честно.
Золотые слова.
1. У меня нет такой информации, машина прекрасно управляется удаленно.

2. Противоречия нет. MAC-адрес, если мы, конечно, не китайцы и не занимаемся всякими грязными трюками вроде подмены MAC является уникальным. Но в то же время функция, которая преобразует MAC в число схлопывает его до 9-значного номера, которых всего 1 миллиард. То есть есть вероятность, что найдутся 2 MAC, которые дадут одинаковое число на выходе. Но с учетом количества машин которые мы подключаем, этот вопрос непринципиален. Да, можно и свой генератор с хранением номеров, ктож спорит, просто его делать дольше, чем намахать такой мини-скрипт. С другой стороны я ничем никого не ограничиваю. =)

3. У меня есть VPN до клиентов, но он не решает вопроса доступа к каждой машине. Или надо каждый компьютер подключать к нашему VPN, что не очень рационально. Плюс есть пересекающиеся подсети, что создает проблемы при маршрутизации. Плюс клиенты иногда просят помощи на рабочих местах, которые стоят за пределами офиса. Мне показалось, что такое решение будет рациональнее.

4. На этот комментарий нет особого смысла отвечать. Я рад за товарища и сам использую Remmina, но техподдержка сидит на Windows. где Remmina нет, потому вопрос адресной книги там актуален.

Интересный проект. Оставил себе на заметку.
Посмотрю. Спасибо.
Скорее всего такая однобокость связана с особенностями использования. То есть я написал, с чем столкнулся сам. А адресную книгу использовал вот эту: https://sourceforge.net/projects/vncaddressbook/.
Вариант удаленного администрирования.
Спасибо за статьи. Репитер, как я понял, — оригинальный код, переписанный на перле.
Интересное решение. Обязательно взгляну и проверю.
Да, на слабых каналах UVNC сложно использовать.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity