Биллинг NetUP

[mastermind]

Просто имел личный опыт руководства бизнес процессами, построенными на ПО UTM.

т.е. вы сначала UTM купили а потом начали бизнес-процессы строить на его основе?

[GreeNGO]

Просто имел личный опыт руководства бизнес процессами, построенными на ПО UTM.

т.е. вы сначала UTM купили а потом начали бизнес-процессы строить на его основе?

Нет. Мы купили две компании (точнее они вынуждены были продаться), оказывающие VoIP и ПД, которые имели UTM 5 версии и пытались на нем стоить бизнес. Только и всего :)

[Chistiakov_A]

Просто имел личный опыт руководства бизнес процессами, построенными на ПО UTM.

т.е. вы сначала UTM купили а потом начали бизнес-процессы строить на его основе?

Нет. Мы купили две компании (точнее они вынуждены были продаться), оказывающие VoIP и ПД, которые имели UTM 5 версии и пытались на нем стоить бизнес. Только и всего :)

Если не секрет, что пришло на замену?

[GreeNGO]

Просто имел личный опыт руководства бизнес процессами, построенными на ПО UTM.

т.е. вы сначала UTM купили а потом начали бизнес-процессы строить на его основе?

Нет. Мы купили две компании (точнее они вынуждены были продаться), оказывающие VoIP и ПД, которые имели UTM 5 версии и пытались на нем стоить бизнес. Только и всего :)

Если не секрет, что пришло на замену?

В одном случае самописный, под сертификатом UTM. Во втором случае Phonekeeper 5.0 плавно замененный на BG Billing (Bitel), работающий с связке с Протей МКД (mCore) софствитч класса 5.

[Chistiakov_A]

В одном случае самописный, под сертификатом UTM.Во втором случае Phonekeeper 5.0 плавно замененный на BG Billing (Bitel), работающий с связке с Протей МКД (mCore) софствитч класса 5.

В принципе, ничего неожиданного... Я надеялся, что будет какая-нить сенсация... :((

[GreeNGO]

Биллинг - это ваше поле игры, вам виднее - кто на рынке

[Vicus]

В одном случае самописный, под сертификатом UTM.Во втором случае Phonekeeper 5.0 плавно замененный на BG Billing (Bitel), работающий с связке с Протей МКД (mCore) софствитч класса 5.

В принципе, ничего неожиданного... Я надеялся, что будет какая-нить сенсация... :((

Вот вам бы у ребят из Битела поучиться бы... И биллинги делать и клиентов суппортить.. Edited April 1, 2007 by Vicus

[Chistiakov_A]

Вот вам бы у ребят из Битела поучиться бы... И биллинги делать и клиентов суппортить..

Вы хотели сказать, поучиться писать биллинги на JAVA? :)) Тут половина людей воет, что их ява даже в виде интерфейса админа не устраивает, а другая Оракл требует - и тут на те! UTM 6 c ядром на яве :lol:

 

Тут критик воскликнет: "Здесь все в черном цвете..." (с) Да, возможно наш интерфейс админа не очень удачен... Я бы даже сказал весьма неудобен. И яву надо уметь готовить (кстати, на подходе новая удобная админка), но нагруженные компоненты биллинга на яве - это уже слишком...

[Vicus]

Вот вам бы у ребят из Битела поучиться бы... И биллинги делать и клиентов суппортить..

Вы хотели сказать, поучиться писать биллинги на JAVA? :)) Тут половина людей воет, что их ява даже в виде интерфейса админа не устраивает, а другая Оракл требует - и тут на те! UTM 6 c ядром на яве :lol:

 

Тут критик воскликнет: "Здесь все в черном цвете..." (с) Да, возможно наш интерфейс админа не очень удачен... Я бы даже сказал весьма неудобен. И яву надо уметь готовить (кстати, на подходе новая удобная админка), но нагруженные компоненты биллинга на яве - это уже слишком...

Да мне глубоко <...> на чем он написан, хоть на бейсике. Он работает, просто работает и делает то, что от него требуется и не надо религиозных войн Java vs C++. Все зависит от прямоты рук и понимания того, что ты делаешь. У бгбиллинг суппорт вменяемый, есть глюк - сутки работы и нет его. Вспомним-ка песни вашего суппорта? Или плати бабки за хотлайн, или пасись со всеми на форуме, авось авторы сжалятся и взгялнут на проблему. Или вспомним ваш монументальный труд на Perl? Черт с ним с обсчетом, но радиус на перле был отдельной песней... Да что там перл, вы до последнего времени Си-шный радиус не могли стабилизировать, столько копий ваши пользователи сломали на форуме.

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

Мне интересно, УТМ может провернуть такой трюк? Допустим один из вариантов:

косяк в тарифе с неправильной ценой или косяк с тарификацией в самом биллинге, который замечается далеко не сразу? Что в этом случае можно сделать в УТМ? В бгбиллинге, можно поправить ошибку в тарифе/тарификации и тупо запустить перерасчет всех сессий за нужный промежуток.

Научилась ли ваша система делать сброс впн-сессий? У нас на выбор: PoD, SNMP...

Да за одни только скрипты предобработки радиус-пакетов, скрипты запускаемые по событию или расписанию я готов поклясться в верности бгбиллингу до самой смерти... И все это штатно в биллинге, а не где-то сбоку и не фиг пойми где. Уже столько оригинальных идей на базе этого биллинга + скрипты реализовано и еще куча ждет своего часа. У меня до сих пор есть лицензия на УТМ5, но как я не поставлю очередной билд, там что-нибудь сломано или работает задом на перед.

Edited April 2, 2007 by Vicus

[Chistiakov_A]

Да мне глубоко <...> на чем он написан, хоть на бейсике. Он работает, просто работает и делает то, что от него требуется и не надо религиозных войн Java vs C++.

Это абсолютно верно. Каждая вещь - для своих задач.

 

Все зависит от прямоты рук и понимания того, что ты делаешь. У бгбиллинг суппорт вменяемый, есть глюк - сутки работы и нет его. Вспомним-ка песни вашего суппорта? Или плати бабки за хотлайн, или пасись со всеми на форуме, авось авторы сжалятся и взгялнут на проблему. Или вспомним ваш монументальный труд на Perl? Черт с ним с обсчетом, но радиус на перле был отдельной песней... Да что там перл, вы до последнего времени Си-шный радиус не могли стабилизировать, столько копий ваши пользователи сломали на форуме.

Согласен. Ресурс, выделенный сейчас (а то, что было раньше - вообще мрак) недостаточен для оперативного развития продукта.

 

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

Тут могу поспорить на ящик пива ;). Без обид, но UTM 5 пережевывает более 10Мбит потока NetFlow.

Это более 300ТБ/мес. Транзитный оператор. 2000 клиентов, являющихся провайдерами. В топе не более 5%. Java не осилит и на порядок менее. Но если Вам хватает - тогда я Вас прекрасно понимаю. Опять же - все для своих задач. Траффик инмпектор - отличное решение для офиса или SOHO-телекома.

 

Мне интересно, УТМ может провернуть такой трюк? Допустим один из вариантов:косяк в тарифе с неправильной ценой или косяк с тарификацией в самом биллинге, который замечается далеко не сразу? Что в этом случае можно сделать в УТМ? В бгбиллинге, можно поправить ошибку в тарифе/тарификации и тупо запустить перерасчет всех сессий за нужный промежуток.

Такого нет. Только спецсредствами.

 

Научилась ли ваша система делать сброс впн-сессий? У нас на выбор: PoD, SNMP... Да за одни только скрипты предобработки радиус-пакетов, скрипты запускаемые по событию или расписанию я готов поклясться в верности бгбиллингу до самой смерти... И все это штатно в биллинге, а не где-то сбоку и не фиг пойми где. Уже столько оригинальных идей на базе этого биллинга + скрипты реализовано и еще куча ждет своего часа. У меня до сих пор есть лицензия на УТМ5, но как я не поставлю очередной билд, там что-нибудь сломано или работает задом на перед.

Если в BG Billing все работает и устраивает - я рад за Вас. Я серьезно. Желаю удачи и продуктивного развития данному продукту. Код UTM 5 слишком обширен и мы не можем столь оперативно его модифицировать. Так же есть и некоторые административные проблемы.

[GreeNGO]

Согласен. Ресурс, выделенный сейчас (а то, что было раньше - вообще мрак) недостаточен для оперативного развития продукта.

И вы еще при этом полезли в разработку IPTV продуктов, где пласт технологий намного сложнее и ресурсов требуется еще больше ? Смелые ребята, аплодирую стоя :)

 

Код UTM 5 слишком обширен и мы не можем столь оперативно его модифицировать. Так же есть и некоторые административные проблемы.

Кхм, а как вы тогда сможете оперативно реагировать на пожелания клиентов ? Т.е. вы перекладываете свои внутренние орг.проблемы на плечи клиентов, покупающих ваш продукт ? Супер ! :) Долгие продолжительные аплодисменты !

 

P.S. Данный топик ушел далеко от обсуждения продуктов для iPTV рынка - в сторону биллинга.. Следовательно, чатсь ветки смело можно переносить в тред - "Обсуждение программного обеспечения"

Edited April 3, 2007 by GreeNGO

[Magnum72]

Вот вам бы у ребят из Битела поучиться бы... И биллинги делать и клиентов суппортить..

Вы хотели сказать, поучиться писать биллинги на JAVA? :)) Тут половина людей воет, что их ява даже в виде интерфейса админа не устраивает, а другая Оракл требует - и тут на те! UTM 6 c ядром на яве :lol:

 

Тут критик воскликнет: "Здесь все в черном цвете..." (с) Да, возможно наш интерфейс админа не очень удачен... Я бы даже сказал весьма неудобен. И яву надо уметь готовить (кстати, на подходе новая удобная админка), но нагруженные компоненты биллинга на яве - это уже слишком...

Да нетапу что оракл что яву все бестолку..

Два примера:

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

 

Таблица транзакций трафика и содержит у среднего оператора около 50 миллионов строк,

но длинну ряда этой таблицы можно уменьшить минимум в два раза, потому как совсем не обязательно закладывать в размер поля INT11 когда оно больше чем enum ('0','1') содержать не может по определению, и так почти со всеми полями. про индексы я молчу их видимо в пьяном угаре влепили.

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

 

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

 

Про транзакции я молчу, оказывается их нужно включать и заканчивать после каждого sql запроса например при удалении абонента ,притом это запросы делают единую логическую операцию,

 

 

По техподдержке:

До сих пор понять не могу нафига мне заказанная услуга мониторинга, если мне приходится постоянно звонить и говорить что у меня падает биллинг, или перестает считатся трафик

Хотлайн зашибись работает, из порядка 30 оставленных и подтвержденных багов только о паре было было сообщено в листах исправлений начиная с версии 5.2 и закрывать заявку автоматически поле любого комментария это не нормально ну и сроки реагирования хотлайна на третий день после открытия заявки мягко говоря вызывают недоумение. Вторую неделю прошу выяснить почему у меня начал тупить и падать биллинг после обновления на 004 билд, никакой реакции, кроме сочувствия

 

Извиняюсь накипело, но это делеко не все просто писать недаело..

[Chistiakov_A]

Да нетапу что оракл что яву все бестолку..

Два примера:

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

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

 

Таблица транзакций трафика и содержит у среднего оператора около 50 миллионов строк, но длинну ряда этой таблицы можно уменьшить минимум в два раза, потому как совсем не обязательно закладывать в размер поля INT11 когда оно больше чем enum ('0','1') содержать не может по определению, и так почти со всеми полями. про индексы я молчу их видимо в пьяном угаре влепили. но самый прико в этих таблицах это три поля значения которых равны дате списания но округлены до часов дней и месяцев которые служат только для отчетов с группировкой результатов по часам дням и месяцам.. на резонный вопрос че курили почему не юзаете функции year mount было сказано что они не поддерживаются постгресом. Зашибись приплыли, зачем заявлять о поддержке трех типов баз данных когда дальше банального селекта без условий в них ничего не применяется..

Структура БД будет кардинально изменена в 5.3, но опять же, никакие операции туда выноситься не будут.

 

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

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

 

По техподдержке:

До сих пор понять не могу нафига мне заказанная услуга мониторинга, если мне приходится постоянно звонить и говорить что у меня падает биллинг, или перестает считатся трафик

Хотлайн зашибись работает, из порядка 30 оставленных и подтвержденных багов только о паре было было сообщено в листах исправлений начиная с версии 5.2 и закрывать заявку автоматически поле любого комментария это не нормально ну и сроки реагирования хотлайна на третий день после открытия заявки мягко говоря вызывают недоумение. Вторую неделю прошу выяснить почему у меня начал тупить и падать биллинг после обновления на 004 билд, никакой реакции, кроме сочувствия

Извиняюсь накипело, но это делеко не все просто писать недаело..

Почему-то жалоб на работу техподдержки через форму обратной связи или по почте на info@netup.ru или в виде официального письма не поступало, поэтому основания для принятия мер нет...

[mastermind]

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

[mikevlz]

Да нетапу что оракл что яву все бестолку..

Два примера:

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

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

 

...

 

Почему-то жалоб на работу техподдержки через форму обратной связи или по почте на info@netup.ru или в виде официального письма не поступало, поэтому основания для принятия мер нет...

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

А еще, возможно, есть справедливое опасение, что для "более серьезного" решения придется потратить на несколько порядков больше ресурсов(время и квалификация - здесь основное, никак не деньги), чтобы оно просто работало.

Если ув. Магнум72 скажет, сколько человекочасов пришлось потратить их компании на то, чтобы довести продукт до ума, посчитает потери компании(недополученную прибыль) возникшие от тог, что заявленный функционал просто не работает, а покупателя кормят завтраками "все будет в следующем билде", что ВЫ ему сможете на это ответить? Что у вашей компании есть "более серьезное" решение за другие килобаксы, которое имеет этот же заявленный функционал? Тогда объясните, зачем он должен будет платить Вам эти килобаксы, если этот же функционал заявлен в биллинге?

По поводу техподдержки - сам такое наблюдал, что там сидят гордые птицы "ежи", пока не пнешь - не полетят. Тому же D-Link я за техподдержку НЕ плачу, но в их интерактивной системе консультации покупателя (форум) могу получить ответы, по почте меня проконсультируют по интересующему меня вопросу, по телефону объяснят как что-то делать. И что характерно - никого пинать не надо. Я инициировал запрос через доступное мне средство связи - получил ответ. У вашей же компании я заплатил деньги не за то,что мне ответят грамотно на вопрос, а за то, что я просто смогу задать вопрос, может быть даже без ответа.

[Chistiakov_A]

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

Как, интересно мне, можно доделать что-либо недоделанное программистами закрытого продукта? o_O

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

 

А еще, возможно, есть справедливое опасение, что для "более серьезного" решения придется потратить на несколько порядков больше ресурсов(время и квалификация - здесь основное, никак не деньги), чтобы оно просто работало.

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

 

Если ув. Магнум72 скажет, сколько человекочасов пришлось потратить их компании на то, чтобы довести продукт до ума, посчитает потери компании(недополученную прибыль) возникшие от тог, что заявленный функционал просто не работает, а покупателя кормят завтраками "все будет в следующем билде", что ВЫ ему сможете на это ответить? Что у вашей компании есть "более серьезное" решение за другие килобаксы, которое имеет этот же заявленный функционал? Тогда объясните, зачем он должен будет платить Вам эти килобаксы, если этот же функционал заявлен в биллинге?

Я смогу ответить, что к внедрению биллинга нужно подходить соответсвующим образом с соответствующими кадрами и т.д. Обычная практика - заказать пресейл (как поступает большинство). Система сдается под ключ: устраивает - плати, не устраивает, нет проблем - ищи другую. Смешно другое. Когда люди заказывают персонализированную систему "за другие килобаксы", я бы сказал за другие десятки/сотни килобаксов, они зачастую не знают, чего хотят и требования ТЗ выясняются до года, после чего подписывается договор и после внедрения оказывается, что они передумали. Типичная практика. Просто никто не привык серьезно относиться к вопросу внедрения ПО. Вот и все.

Я так и не понял, как можно довести закрытый продукт до ума?

 

По поводу техподдержки - сам такое наблюдал, что там сидят гордые птицы "ежи", пока не пнешь - не полетят. Тому же D-Link я за техподдержку НЕ плачу, но в их интерактивной системе консультации покупателя (форум) могу получить ответы, по почте меня проконсультируют по интересующему меня вопросу, по телефону объяснят как что-то делать. И что характерно - никого пинать не надо. Я инициировал запрос через доступное мне средство связи - получил ответ. У вашей же компании я заплатил деньги не за то,что мне ответят грамотно на вопрос, а за то, что я просто смогу задать вопрос, может быть даже без ответа.

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

Edited April 12, 2007 by Chistiakov_A

[mikevlz]

претензии по архитектуре БД вы уже читали выше. Насколько мне известно, оптимизацию структуры БД Магнум делал сам, по крайней мере в части индексации. Всякие наколенные поделки для приема вебмани-платежей вспоминать будем? В прайсе на биллинг прием платежей заявлен как стандартная фича(по состоянию на лето 2006г), модуль интеграции, позволяющий принимать вебмани вышел в начале 2007 года, чуть-ли не в феврале. До этого делалось наколенным способом в виде самописного php скрипта с использованием рапиды или payment_tool. Это не доделывание закрытого коммерческого продукта?

Шедевр в виде raw_fd_script по обработке файлов детальной статистики - это песня... Надо быть великим программером от шелла, чтоб написать скрипт из двух строк. В то же время можно было предложить нечто аналогичное продукту авторства Магнума и его коллеги.

[Chistiakov_A]

претензии по архитектуре БД вы уже читали выше. Насколько мне известно, оптимизацию структуры БД Магнум делал сам, по крайней мере в части индексации. Всякие наколенные поделки для приема вебмани-платежей вспоминать будем? В прайсе на биллинг прием платежей заявлен как стандартная фича(по состоянию на лето 2006г), модуль интеграции, позволяющий принимать вебмани вышел в начале 2007 года, чуть-ли не в феврале. До этого делалось наколенным способом в виде самописного php скрипта с использованием рапиды или payment_tool. Это не доделывание закрытого коммерческого продукта?

Где вы видели, что изначально был заявлен прием платежей из тех же вэбманей? Абстрактная утилита приема денег - payment tool имелась. Так же платежи принимались нашими скриптами, но из тех систем, что были заявлены (та же рапида и е-порт). Это добавление функционала, который

 

Шедевр в виде raw_fd_script по обработке файлов детальной статистики - это песня... Надо быть великим программером от шелла, чтоб написать скрипт из двух строк. В то же время можно было предложить нечто аналогичное продукту авторства Магнума и его коллеги.

[mikevlz]

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

[Chistiakov_A]

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

Что-то мой ответ покоцался, а редакт глючед :(( Я люблю место своей работы и люблю свою работу, но есть моменты... которые меня просто бесят. Ровно как и клиентов.

[Magnum72]

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

 

Как, интересно мне, можно доделать что-либо недоделанное программистами закрытого продукта? o_O

Это надо сказать большое спасибо программистам MySql которые сделали лог поступающий запросов в mysql/

 

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

 

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

 

Да я писал такой вопрос но меня больше интересует тот факт как при заказанной и регулярно оплачиваемой услуге мониторинга биллинг не работал целый час? Почему ваши специалисты имея доступ к моей системе требуют у меня utm5core.dump файлы? Я без понятия поxему при падении ваш биллинг их не создает. у меня заказаны все озвученные на сайте услуги поддержки вашего биллинга, это не мои проблемы. Почему я найдя проблему должен найти откуда она исходит, просидев несколько часов анализируя логи мускула и debug.log биллинга, потом убедить вас в этом что эта проблема реально существует, после этого вы ее подтверждаете и соответствующий мантис ид проблемы успешно проходит от версии к версии неисправленным.

 

Я смогу ответить, что к внедрению биллинга нужно подходить соответсвующим образом с соответствующими кадрами и т.д. Обычная практика - заказать пресейл (как поступает большинство). Система сдается под ключ: устраивает - плати, не устраивает, нет проблем - ищи другую. Смешно другое. Когда люди заказывают персонализированную систему "за другие килобаксы", я бы сказал за другие десятки/сотни килобаксов, они зачастую не знают, чего хотят и требования ТЗ выясняются до года, после чего подписывается договор и после внедрения оказывается, что они передумали. Типичная практика. Просто никто не привык серьезно относиться к вопросу внедрения ПО. Вот и все.

Я так и не понял, как можно довести закрытый продукт до ума?

 

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

 

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

 

Вот объясните мне зачем в дебаг лог при каждой попытке поиска пользователя по логину, вываливать при 15000 пользователей около 60000 тысяч строк абсолютно ненужной инфы, и при этом детализацию дебаг лога невозможно изменить, ядро после выполнения поиска пользователя продолжает еще секунд 20 дописывать в лог эту инфу.

Неправильно с любой очки зрения засасывать ядром все таблицу пользователей и потом выбирать из нее данные подходящие под условия выборки, в крайнем случае попробуйте хотя бы разделись запросы на простые и сложные

 

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

 

Или ну вот убейте но я не понимаю зачем создавать в таблице которая ежемесячно пополняется на 20-40 миллионов строк три столбца которые занимают 33 байта размера ряда (при длине ряда около 100 байт) и служат только для того чтобы сформировать отчеты по часам или месяцам

 

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

 

Зачем блин вешать автоинкремент на ид в таблице discount_transactions_iptraffic_all если там ид записи берется равной ид в таблице discount_transactions_all ?

 

Или какие функции выполняет заявленный NBS сервер в предаче данных из биллнга и 1с и обратно если данные о импортируемых платежах в 1с берутся из таблицы отчета изменений пользователя,

 

Не ну на то что сумма в акте сформированном на основании счета отличается от суммы счета мне уже плевать я написал свое.

 

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

 

Я не хочу чтобы со мной разговаривали в тоне "как с клиентом который умеет запускать ворд"

И хочу получать адекватные ответы в хотлайне а не отписки "после которых заявка автоматически получает статус закрытой"

 

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

 

Самое смешное мы готовы купить и ваше решение по IPTV и модули работы с 1с и даже официальную консольную админку стоимостью в два раза больше стоимости биллинга (это купим точно), но нас пугает текущее отношение к нам как к клиентам и текущее плачевное состояние по исправлениям и поддержке, мне сейчас потратить 50-70 килобаквсов на ваше решение иптв просто страшно, и я вас уверяю продажи вашиего иптв среди ваших же клиентов утм5 будет носить единичный характер, какая бы она хорошая не была. Клиентскую базу нужно не только набирать но еще и поддерживать холить и лелеять.

 

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

[jab]

Успокойтесь, Вас поимели.

[user_anonymous]

Еще вопрос вдогонку: UTM5 и flow-tools берут статистику из одного источника. Почему же биллинг выдает большие цифры, чем следует из лога NetFlow?

[mikevlz]

Вы на рынке были хоть раз? Как обвешивают видели? Вот это из той же оперы :) либо до flow-tools не все пакеты доходят. UDP не гарантирует доставку пакетов.

[user_anonymous]

Вы на рынке были хоть раз? Как обвешивают видели? Вот это из той же оперы :) либо до flow-tools не все пакеты доходят. UDP не гарантирует доставку пакетов.

сомневаюсь сильно в том: flow-tools в логи пишет при потере пакетов, и несколько случаев потери действительно имело место. Однако, по моим прикидкам, этого было бы однозначно недостаточно, чтобы нагнать такую разницу в показаниях. И причем у разных клиентов. И flow-tools, и UTM5 вертятся на одном и том же сервере, но слушают разные порты. Киса, с которой льется поток, ругнулась на то, что уже есть такой адрес для сброса, но поток отдает. Вот сижу и думаю, кому из них верить. Сам больше склоняюсь доверять flow-tools, чем этому пожирателю ресурсов.

 

PS Я прекрасно понимаю, что держать два коллектора на одном хосте - неправильно. Но, увы, по-другому не получается.

Edited April 17, 2007 by user_anonymous