Jump to content
Калькуляторы

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

+

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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


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

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

Share this post


Link to post
Share on other sites

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

Генри Форд

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

не дырявой веб-админкой для 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-журналирование.

Share this post


Link to post
Share on other sites

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

 

не дырявой веб-админкой для 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ГБ), а тем более распределенные (чаще всего с шардиногом).

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

Share this post


Link to post
Share on other sites

Никто пользователю рутовский доступ и даже 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, ни на изменения. Подлость высшего порядка, поэтому я не понимаю ваших страданий, не впечатлен методами решения.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now