Перейти до

посоветуйте биллинг для 20к абонентов


Рекомендованные сообщения

ага, а когда Линус Торваль перестал заниматься линуксом то Линукс умер )

подмена понятий. между критически широко распространенной открытой разработкой с готовым комьюнити и коммерческим продуктом с закрытой разработкой.

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 55
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

За деньги? Да кто угодно. Вы ж пишете за деньги? Вот и другие буду писать. А при 20 к абонентов - денег хватит на нормальную девелоп группу, корая будет с 8 часовым рабочим днем сидеть и стучать по кн

Собсно сабж.

просто оно дело попробовать, а другое на 10к переходить на другую систему. Ладно, всем спасибо, идею понял - новичек форума по умолчанию клоун.

подмена понятий. между критически широко распространенной открытой разработкой с готовым комьюнити и коммерческим продуктом с закрытой разработкой.

 

Где закрытая разработка ?

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

еще один наивный, считающий, что многолетне-проверенные решения хуже чем написанное на коленке. Все вокруг дураки, один он умный...

В многолетне-проверенных решениях обычно не хватает элементарной гибкости, чтобы внедрить некую нестандартную фичу (да хоть изменение скорости пакета в ночное время при некоем рейтинге выше порогового) - и приходится это делать через анус, либо перелопачивать всю логику. От того, если есть достаточный уровень знаний для написания своего или хотя бы разработки правильной структуры системы и схемы данных, в которую потом тыкать носом исполнителя - свое будет лучше. Хотя для этого нужно как минимум пощупать проверенные решения и понять, что в них сделано неправильно.

 

IMHO большая часть любого биллинга - веб морда и различные консоли управления, так называемое 'ядро' в виде десятка скриптов куда проще устроено и легко поддается допиливанию, в отличии от монструозных порталов..

Вот потому ядро и веб-морду надо разносить. Чем дальше - тем лучше. В идеале - обмен логики (или прочих клиентов, типа всяческих абонентских утилит) с ядром должен вестись по какому-то RPC (XMLRPC или что-то типа того). Чтобы логику можно было поправить под нужды уже сейчас, а рюшечки к ней уже допиливать потом, если планируется что-то грандиозное.

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

еще один наивный, считающий, что многолетне-проверенные решения хуже чем написанное на коленке. Все вокруг дураки, один он умный...

В многолетне-проверенных решениях обычно не хватает элементарной гибкости, чтобы внедрить некую нестандартную фичу (да хоть изменение скорости пакета в ночное время при некоем рейтинге выше порогового) - и приходится это делать через анус, либо перелопачивать всю логику. От того, если есть достаточный уровень знаний для написания своего или хотя бы разработки правильной структуры системы и схемы данных, в которую потом тыкать носом исполнителя - свое будет лучше. Хотя для этого нужно как минимум пощупать проверенные решения и понять, что в них сделано неправильно.

 

вот тут в точку только ключевая фраза тут "достаточный уровень знаний"

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

Уважаемый топикстартер, мне кажется вам было бы на много проще выбрать что-то, составив список того что у вас уже сипользуется. Написать такой себе Requirement Catalog, далее выложить его, и подождать чего вам предложат.

20к на этом этапе звучит как вопрос в автосалоне - "Дайте мне машину у которой тормозной след 20м".

 

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

 

Какой биллинг вам нужен?

 

И тут начинаются наводящие вопросы типа:

- Нужно ли генерировать инвойсы или достаточно посчитать?

- Нужен ли вам Realtime или достаточно HOT-биллинга для ваших задач?

- Какой жизненный цикл у ваших абонентов сейчас? Предвидется? (припейд или постпейд).

Из этого выплывает ответ на вопрос - нужна ли вам конвергентность.

- У вас плавающий биллинговый период?

- Количество тарифов/продуктов на данный момент (это влияет на скорость и стоимость миграции абонентов)

- тут же возникает вопрос миграции абонентов, есть ли уже эти абоненты, в каком биллинге они сейчас?

 

Далее, когда определились с этим, идет капасити (только здесь говорится о количестве абонентов и суммарном трафике который нужно обрабатывать), под это дело владельцы биллингов делают HW sizing (и вы смотрите, нужно ли покупать сановский кластер или же p4 хватит по это дело). Потом идет планирование, инсталяция, ИНТЕГРАЦИЯ (вот этот пункт, как раз миграция абонентов, переделка API под вашу CRM, настройка сетевого провиженинга и прочих радостей, которые нужно оговорить ДО).

 

Вот так вот, в кратце, выглядит выбор биллинга.

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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...