Перейти к содержимому
Калькуляторы

USERSIDE - программное обеспечение для оператора связи

Коллеги, интересует мнение о данном продукте в разрезе функционала Order Management и Helpdesk.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Коллеги, интересует мнение о данном продукте в разрезе функционала Order Management и Helpdesk.

Жопа. По заказам, нет отдельного мобильного клиента для монтажников. По хелпдеску нет емейл тикет трекера. По крайней мере я когда смотрел - не нашел этого.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Жопа. По заказам, нет отдельного мобильного клиента для монтажников. По хелпдеску нет емейл тикет трекера. По крайней мере я когда смотрел - не нашел этого.

 

А какие есть ещё продукты с аналогичным функционалом?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А какие есть ещё продукты с аналогичным функционалом?

Других таких нет. Если только в кучку несколько собрать и использовать API для взаимодействия между ними. ЮС к слову умеет заявки с почты забирать, но это для галочки, и разработчики рекомендуют юзать API (кстати, простое и удобное, но пока есть не все, что хотелось бы)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Других таких нет.

 

Ну что же вы так категорично? Их масса, но, к примеру, NetCracker или Amdocs не в моём бюджете. :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо, не знал про них!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вышла новая версия UserSide 3.10

 

Из основного:

 

- Новый модуль usm_cabletest

- Обратное взаимодействие с биллингом uBilling v.0.8.0+ (можно из-под UserSide изменять в биллинге у абонента баланс, тариф, смотреть на лету историю и актуальные данные по абоненту (ФИО, тариф, баланс)

- Оборудование. Функционал по работе с CWDM

- Покрытие. Возможность вывода номеров узлов связи/муфт и т.п. на карту

- Покрытие. Возможность вывода произвольных надписей/текста на карту

- Покрытие. Объекты на карте загружаются только при нужном масштабе карты

- Тарифы. Добавлены группы тарифов

- Абоненты. Возможность указывать дополнительные номера телефонов в карточке абонента

- Операторы. В настройке профиля оператора дублируется настройка прав доступа к типам заданий

- Оборудование. Возможность указания порта для SNMP-опроса коммутаторов (для каждого коммутатора свой настраиваемый порт)

- В форме для удалённого закрытия наряда можно прикрепить файл

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а можно 4 модуля адд дроп на узле между собой без активки скоммутировать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Дропы пока не добавили, к сожалению

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

http://userside.eu/ru/price.php?country_id=ru

 

С 2 квартала - цены для РФ пересмотрены (уменьшены).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Почитал ChangeLog Юзерсайда и после фразы "Мы начинаем постепенный переход на PostgreSQL. " рекомендую клиентам оставаться на версии 3.9.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть предложение: пусть все несогласные с PostgreSQL напишут разработчикам на почту или тикет в ЛК клиента о своём нежелании работать с этой СУБД и потребуют от них провести опрос среди всех клиентов об отношении к переходу на эту СУБД. Не надо просто тихо оставаться на 3.9, надо поднимать бучу и коллективно продавливать отказ от обязательного перехода на PostgreSQL.

Переход на PostgreSQL должен быть опциональным или от него вообще следует отказаться, это наша позиция.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Миграция на PG? Я джва... шесть лет этого ждал! Нытики со своей bdb на стероидах идут лесом! У разработчиков наконец-то появится доступ к нормальным типам геоданных, это минимум. А у пользователей будет наконец-то нормальная производительная база.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Миграция на PG? Я джва... шесть лет этого ждал! Нытики со своей bdb на стероидах идут лесом! У разработчиков наконец-то появится доступ к нормальным типам геоданных, это минимум. А у пользователей будет наконец-то нормальная производительная база.

Да хоть в дёсны лобызайтесь со своей ненаглядной PG. Фанбои PG идут лесом.

Если у оператора 100% приложений успешно работают на MySQL, то зачем ему ради одного US с PG связываться? Все плюсы PG нивелируются минусами администрирования двух разных СУБД параллельно.

Как минимум должна быть возможность выбора между MySQL и PostgreSQL в настройках US.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как минимум должна быть возможность выбора между MySQL и PostgreSQL в настройках US.

+

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вот когда (никогда) мыскль сумеет в нормальное надежное хранение, нормальные типы данных и нормальные процедуры, вот тогда можете рассказывать за мыскль.

 

Для страдающих синдромом утенка - администрировать неожиданно PG в разы проще вашей недоделки. Кстати, сейчас в наличии имеем аж три реализации мыскля - каноничная от оракакеля, хипстерская мария и НИХовская от перконы. Разница между ними невелика, но так как взгляды на развитие команд разработчиков у этих трех продуктов разные, вожно Вангу из могилы не поднимать, чтобы предсказать дальнейшее расхождения вплоть до несовместимости. Итак, какую именно реализацию мыскля надо поддерживать разработчикам?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для страдающих синдромом утенка - администрировать неожиданно PG в разы проще вашей недоделки.

 

Будьте добры поделиться:


     
  1. не дырявой веб-админкой для PostgreSQL
  2. мануалом тюнинга ZFS под хранилище PostgreSQL
  3. мануалом тюнинга PostgreSQL при базах свыше 16ГБ
  4. аналогами mytop, mysqltuner, mysqlbackup
  5. Опциями беспроблемного бэкапа PostgreSQL при наличие аналогов MySQL - событий, триггеров, функций.
  6. Рабочей схемой master-slave для инкриментного бэкапа на удаленный сервер.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Геоданные содержат всего три переменные - идентификатор, координаты по X, координаты по Y. Далее по идентификатору вешаем любые свои поля.

 

А у пользователей будет наконец-то нормальная производительная база.

У меня на продакшене Mysql выдает 10Krps на сложных запросах с Join и Insert. У операторов в телекоме только биллинг или Zabbix могут быть ресурсоемкими.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

"Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь."

Генри Форд

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну вообще решаемо через всякие БД движки, для пхп это доктрина и ему подобные.

А там уже кому чего. Ну и не вижу ничего криминального держать две разные бд на одном сервере. Тем более что Postgresql не сильно уж и отличается от mysql.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мнение Антона понятно. Остаемся на версии 3.9.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Будьте добры поделиться:

 

не дырявой веб-админкой для PostgreSQL

 

C 1997 года все админитраторские функции выполнялись исключительно

через psql. Напомните, плз, когда там в psql нашли последние уязвимости?

 

мануалом тюнинга ZFS под хранилище PostgreSQL

 

Очередной случай бана в гугле?

 

мануалом тюнинга PostgreSQL при базах свыше 16ГБ

 

Опять вопрос про гугл. И это, 16 гигов это просто несолидно:

SELECT 
 SUM((relpages * 8) / 1024) AS size_mb
 FROM pg_class;
size_mb 
---------
 160779
(1 строка)

 

Рецепты сводятся к правки 2-3 параметров. Описания методики их вычисления описаны даже на русском языке.

 

аналогами mytop, mysqltuner, mysqlbackup

 

Из всего перечисленного смысл разве что pg_top имеет. Вы извините, но отдавать тюнинг СУБД, от которой зависит

нормальное функционирование предприятия на откуп какой-то утилиты, это какое-то эникейство. Если не знаешь что крутить,

то или изучай, или не лезь. Про бэкап вообще молчу. Я до сих пор в тихом а.....е от мануалов как в мыскле снять актуальный

консистентный бэкап базы без прерывания сервиса. Даже забебспокоился поиском аналогичных решений и для PG, ибо мало ли что.

 

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

В PG для снятия консистентного бэкапа достаточно сказать pg_dump bla-bla-bla, ну или pg_dimpall и все. Для клиентов базы процесс

пройдет незаметно. Бэкапом будет снимок базы на момент запуска утилиты. Все.

 

Опциями беспроблемного бэкапа PostgreSQL при наличие аналогов MySQL - событий, триггеров, функций.

 

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

 

Рабочей схемой master-slave для инкриментного бэкапа на удаленный сервер.

 

Как бы сказать помягче... В PG проблемы с реализацией мысклевых велопедов, по той причине, что все что надо уже имеет правильную реализацию. См. WAL-журналирование.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Будьте добры поделиться:

 

не дырявой веб-админкой для PostgreSQL

 

C 1997 года все админитраторские функции выполнялись исключительно

через psql. Напомните, плз, когда там в psql нашли последние уязвимости?

 

psql -- PostgreSQL interactive terminal

Терминал неинтересен.

Никто пользователю рутовский доступ и даже shell не будет давать. Особенно на шардинг хостинге.

 

мануалом тюнинга ZFS под хранилище PostgreSQL

 

Очередной случай бана в гугле?

Продемонстрируйте хоть один рабочий и внятно задокументированный мануал.

 

мануалом тюнинга PostgreSQL при базах свыше 16ГБ

 

Опять вопрос про гугл. И это, 16 гигов это просто несолидно:

 

SELECT 
 SUM((relpages * 8) / 1024) AS size_mb
 FROM pg_class;
size_mb 
---------
 160779
(1 строка)

 

Рецепты сводятся к правки 2-3 параметров. Описания методики их вычисления описаны даже на русском языке.

 

Советы закончились?

А если при базе 16ГБ памяти на сервере всего 8ГБ ?

 

аналогами mytop, mysqltuner, mysqlbackup

 

Из всего перечисленного смысл разве что pg_top имеет. Вы извините, но отдавать тюнинг СУБД, от которой зависит

нормальное функционирование предприятия на откуп какой-то утилиты, это какое-то эникейство. Если не знаешь что крутить,

то или изучай, или не лезь. Про бэкап вообще молчу. Я до сих пор в тихом а.....е от мануалов как в мыскле снять актуальный

консистентный бэкап базы без прерывания сервиса. Даже забебспокоился поиском аналогичных решений и для PG, ибо мало ли что.

 

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

В PG для снятия консистентного бэкапа достаточно сказать pg_dump bla-bla-bla, ну или pg_dimpall и все. Для клиентов базы процесс

пройдет незаметно. Бэкапом будет снимок базы на момент запуска утилиты. Все.

 

Утилиты нужны для анализа. А решение принимает DBA. Черный ящик будете сами администрировать на локалхосте и будете на LOR'e рассказывать, какой вы крутой админ.

Про снимки - не смешно. Попробуйте выгрузить из памяти базы, сделать снимок, а потом опять загрузить данные в память.

И если вы не научились бэкапить Mysql - кто ж вам виноват? :)

 

Опциями беспроблемного бэкапа PostgreSQL при наличие аналогов MySQL - событий, триггеров, функций.

 

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

 

Я пока что вижу хипстеров, которые даже не читали про математику и алгоритмы.

 

Рабочей схемой master-slave для инкриментного бэкапа на удаленный сервер.

 

Как бы сказать помягче... В PG проблемы с реализацией мысклевых велопедов, по той причине, что все что надо уже имеет правильную реализацию. См. WAL-журналирование.

 

Вы просто не эксплуатировали средние (16-128ГБ) и большие базы (свыше 128ГБ), а тем более распределенные (чаще всего с шардиногом).

И все это под большой нагрузкой. И это все надо бэкапить безпроблемно. И стараться при этом не лочить таблицы. Иначе после таймаутов и ошибок запросов, вам позвонит начальник и пропесочит по самые не хочу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Никто пользователю рутовский доступ и даже shell не будет давать. Особенно на шардинг хостинге.

Вы меня удивляете. Вот вам трещина в мироздании - psql умеет работать по сети. И этого полностью

хватает для манипуляций с пользовательской базой.

 

Продемонстрируйте хоть один рабочий и внятно задокументированный мануал.

Засада в том, что нет принципиальной разницы в том, как тюнить ZFS для MySQL и PG. Разве что

в случае с PG требуется меньше приседаний и танцевальных па.

Советы закончились?

А если при базе 16ГБ памяти на сервере всего 8ГБ ?

 

В случае с мысклем это серьезная проблема, я так понимаю?

 

KiB Mem:   3091340 total,  3018820 used,    72520 free,   215104 buffers
KiB Swap:  4193276 total,   157040 used,  4036236 free,  1068968 cached

 

это как раз там, где объем базы 160Гб.

 

Конкретные задачи требуют конкретные решения. Если вам лень прочитать короткое руководство на русском (!!!) языке, которое ищется за два клика, я вам готов помочь

с решением за прайс скромный.

 

Утилиты нужны для анализа. А решение принимает DBA. Черный ящик будете сами администрировать на локалхосте и будете на LOR'e рассказывать, какой вы крутой админ.

Про снимки - не смешно. Попробуйте выгрузить из памяти базы, сделать снимок, а потом опять загрузить данные в память.

И если вы не научились бэкапить Mysql - кто ж вам виноват? :)

Какой чудный оксюморон - "Mysql DBA". Повторю: в PG для снятия бэкапа не надо городить многоходовочный сложносочиненный велосипед по той простой причине, что в нем нет того генетического дефекта, каким блистает мыскль. В PG снятие бэкапа это рутинная операция при успешном завершении всегда дающая восстановимые корректные данные. И без разницы где в момент начала бэкапа были данные - на носителях, кэше, буферах - все данные по завершенным транзакциям обязательно попадут в бэкап. И да, я специально не учился бэкапить мыскль, ибо не нужно. А когда нужно, я лучше погашу сервисы и сделаю бэкап "на холодную" серез mysqldump, ибо простой второстепенных поделок стоит дешевле, чем горотьба кластеров ради онлайн бэкапа клиентских днявочек.

Я пока что вижу хипстеров, которые даже не читали про математику и алгоритмы.

Что ж так в сторону поплыли... В мыскле какие-то проблемы с бэкапом триггеров, функций и так далее? Не сочувствую, ибо "бачiли очi, шо куповали". В PG с бэкапом и восстановлением всего этого проблем нет.

Вы просто не эксплуатировали средние (16-128ГБ) и большие базы (свыше 128ГБ), а тем более распределенные (чаще всего с шардиногом).

И все это под большой нагрузкой. И это все надо бэкапить безпроблемно. И стараться при этом не лочить таблицы. Иначе после таймаутов и ошибок запросов, вам позвонит начальник и пропесочит по самые не хочу.

Размер базы я чуть выше привел, так что не надо про объемы. Да, и такой момент, при бэкапе PG не лочит таблицы, представляете? Ни на SELECT, ни на изменения. Подлость высшего порядка, поэтому я не понимаю ваших страданий, не впечатлен методами решения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.