vadimz

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

Предлагаю собраться всем на "подзаборный НАГ", кто не попал на основное действие и у кого не возвратные билеты (мы как раз такие).

planado.ru На КРОСе рассказывали, видео тут http://www.planado.ru/blog/

Позволю себе сделать уточнение для предыдущего поста. 1. Отсутствие учета дебеторки у биллинга это как можно понять? Присутствуют отчеты по взаиморасчетам с клиентом, формирование списков для отключения (КТВ) и возможность вообще работать с должниками - выбирать их, слать им смс и тд. 2. CoA - это не костыль, а технология. Суть заключается в возможности сделать что-то с BRAS по инициативе биллинга, а не только когда BRAS-у захочется сделать запрос по RADIUS. Вообще понятие "костыль" это когда вы делаете что-то "против шерсти", а не когда в рамках существующей технологии, когда красиво расписываете RADIUS-атрибуты в биллинге, их подстановки и удобными CoA-запросами, которые тоже настраиваете с интерфейса делаете дополнительные действия. 3. Самое главное, что возможности перерасчета вообще есть и для телефонии это нужно в первую очередь. Под ограниченным имеется ввиду, что абсолютно любой случай нельзя сделать "с кнопки", но можно через техподдержку. 4. HARD можно исключить между FreeRADUIS и биллингом вообще. Просто тогда при каждом чихе без кэширования будет обращение в базу и теряются все его "фишки" в виде многопоточной работы и автономного кэша на случай потери связи. А так если он кажется высокорискованным убираете его и работаете "без смазки" сразу с базой. 5. Интерфейс уже новый и очень клевый, с настраиваемыми виджетами и плюшевым интерфейсом, убогость старого отрицать бессмысленно. 6. Не обоснованно, во-первых, работа интерфейса вообще от числа абонентов не зависит, во-вторых, где вы увидели тормоза? Не дадут соврать ребята, которые смотрели презентацию на УКОС 2012 в Крыму 2 дня назад, по WiFi и непонятному к нему каналу все шустро летало с серверов в России. 7. -Erlang, -Perl. Каждый язык или каждая технология - для своих задач. AJAX - http://ru.wikipedia.org/wiki/AJAX , честно говоря даже не знаю как прокомментировать. По поводу персонала, как вы себе представляете нужно работать, чтобы сделать такое втроем? ;). Если бы это было возможно, было бы прекрасно, но даже по support понятно, что на одном внедрении сидит 5 человек (без разработчиков и прочего пресонала). По поводу рынка биллингов, интересно, куда он сдулся-то? Что, у всех в мире ВНЕЗАПНО решились вопросы с биллингом? Все как раз наоборот, по мере развития конкуренции все больше маркетинговых задач, которые со старым биллингом решать и решать и многие, кстати, это понимают.

Oracle Standart Edition One (до 2 сокетов) ~ 1098$ с техподдержкой на год. Это действительно непомерные деньги. Еще реально можно и дешевле взять со скидкой. А так, действительно, зачем Oracle, там же нормальная отказоустойчивость и реально хорошо журналируемые транзакции (можно сервак по резету перегрузить и все взлетает без потерь, транзакции продолжаются), можно дампы снимать на горячую и целостность данных не нарушится (консистентный бакап), нормальная репликация в том числе кластер можно сделать (Oracle RAC, ASM). Обновления базы можно устанавливать на горячую (накатываете обновления и потом раз и переключаете версии). Нормальный API можно сделать на стороне БД, по которому свои же приложения будут работать, то есть API будет на все автоматом, а не только на то, что разработчики сделают. Встроенные возможности по redefinition (если просто, то дефрагментация данных, по тому же трафику, реально дает существенное ускорение при работе с таблицами где по несколько десятков млн записей). Ну и куча других возможностей, которые будут ваши программисты писать годами за зарплату, выйдет дешевле? ;)

VZP, вы похоже что-то перепутали. Биллинг Гида это который hydra-billing.ru. Во-первых, с него не было ни одного перехода на другой биллинг никогда. Это легко отследить разработчикам, потому что те, кто его внедрил оплачивают техподдержку. Во-вторых, наоборот основная масса переходит с UTM и Lanbilling как раз из-за отсутствия новых функций и масштабируемости систем. В-третьих, как раз основная характеристика Гидры - нелинейная зависимость между числом абонентов и требований к железу, то есть при увеличении числа абонентов в 10 раз нагрузка на железо будет всего-лишь на несколько % выше. Если внимательно посмотреть на требования к железу http://www.hydra-billing.ru/tech/ , то они там даны исходя и текущий оптимальных конфигураций, вообще приземленных без каких-либо невероятных требований к серверам. Стартапы до 2-3 тыс абонентов вообще гоняют биллинг на десктопе Core i7 и чувствуют себя прекрасно, это что, непомерные требования к железу? ;)

Обратитесь в www.smartlogic.ru, у них есть.

Установите две двери. Первую - с резиновыми уплотнителями, вторую - обычную деревянную. Берите пример с чиновников, у них такие двери ;). Когда была одна дверь всё равно шум было слышно, после установки второй двери шума не слышно вообще.

Контакты: ICQ: 58966531 Либо личное сообщение.

Бывают нежилые и жилые помещения, если подключаемое лицо находится в нежилом помещении, то это "юрик", если в жилом - физик. Всякие телефонисты с adsl обычно подключат в жилом помещении как физика и даже не задумаются, так что выбора у нас просто нет, конкурировать надо.

Понятие "скорость" у типового абонента своё. Скорость для него это как быстро качается файл с конкретного порносайта, что вообще ничего не значит. Более-менее реально можно замерить только торрентами, когда много соединений с разных хостов. Те, кто говорят, что ВСЕГДА обеспечивают своим абонентам заявленную скорость лукавят, это просто нереально, нужно иметь очень нехилый запас по каналу. Бывают дни, например, когда очень плохая погода, выходной, все сидят дома в инете и нагрузка возрастает настолько существенно, что в целом ради одного дня в месяц держать такой запас по каналу просто не целесообразно.

Есть опыт мониторинга NAT-ов в сети при помощи различных опенсорсных тулзень в том числе и в общаге. Вот такие проблемы: 1) Если у абонента несколько ОС, в том числе он использует WMWARE, то он палится, но в этом же нет ничего плохого. 2) КПК, смартфоны - убиться можно подключать их как отдельный девайс в биллинге, соответственно тоже палятся, так как их приходится натить через wifi-роутер. 3) Всякие разработчики которые одновременно ходят с разных броузеров, тестируют веб-сайт, палятся. можно дальше продолжать, но скажу честно, определить можно, но вот отключать автоматом это уже задача другого порядка сложности. Можно писать свой обработчик логов известных опенсорсных софтин, чтобы они стали поумнее и отключали только при большой вероятности, что NAT-ится не 1-2-3 девайса, а подсетка из 5-6 компов. Так что совершенно справедливо, что одного технического решения тут быть не может и нужно ещё давить NAT-административно, с помощью тарифов, периодических обходов (в общаге это реально, в отличие от города) к тем, у кого подозрительная активность по данным мониторинга NAT. Кроме того, часто у тех, кто шарит инет на компе стоит какая-нить прога на стандарных портах с веб-мордой авторизации, можно удалённо пощумать подозрительный ip-ик и найти что там стоит, например, что-нить типа winproxy с веб-мордой на 80-ом порту. Тарифы - псевдобезлимиты, когда при превышении 40-80-100 сколько захотите Гб режется скорость или режется приоритет (если биллинг вам позволит такое хе-хе). Помегабайтная оплата, но очень жирная (включены десятки ГБ). Низкоскоростные безлимиты. Попробуйте на 512кбитах поиграться в wow, если параллельно с него же сосут торренты, это жутко будет доставать, шарить инет жутко некомфортно.

"Бесплатных" биллингов не бывает по определению. Если у него открытый исходный код и он не без поддержки, то нужно содержать программиста, чтобы он мог поправить что-то под ваши нужды и он такой специалист стоит вполне конкретных денег, сколько стоят специалисты такого уровня в вашем городе, ну скажем 1000$/мес это минимум, а в Москве-Питере больше. Что будет если этот программист свалит в другую контору, уйдёт в армию, заведёт женщину, вариантов масса, риски немеренные. Уйдёт в конце-концов в отпуск как раз по закону подлости того, когда всё нагнётся. Содержать двух таких это уже нереально дорого и не оправданно. Как такой программист-одиночка сделает нормальное тестирование для внесённых им изменений? А ему ещё надо разбираться в чужом опенсорсном коде, который, как мы знаем, обычно пишется под пиво, с разной стилистикой в модулях и с комментами на английско-абланском или вообще без них. Идём дальше, вы не в Москве, а где-нибудь в Томске, думаете легко найти адекватного прогера под опенсорс линукс биллинг? Пока маленькие, используйте какой-нибудь utm, ланбиллинг, станите побольше - онима, латера. Но упаси боже писать свой биллинг, это просто трата денег, времени. Разработка займёт у вас больше времени, чем основная деятельность, ей богу.

Мы как делаем. Если у абонента есть денег на счету на списание 1 дня из стоимости тарифа за месяц, то ему включается тариф. Дальше денежки постепенно списываются и отключает его как только он уходит в минус (он звонит и просит кредитный лимит на 2-3 дня). Так как он уже заказал услугу, то списание у него будет идти в любом случае до конца месяца, если возникнет ситуация, что он выйдет из минуса, то его включит. Таким образом можно равномерно распределять платежи, но всё равно платить надо за весь месяц в сумме, за один день нельзя.Если в конце расчётного месяца он в минусе, то через несколько дней весь период, который он не пользовался ему пересчитывается по тарифу блокировки (тут кто как хочет делает). Вот и вся любовь.