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

На что слезть с Lanbilling

hsvt

я не сторонник Ланбиллинга, но в вашем случае это проблема администрирования БД и дисковой подсистемы(вряд ли они вам рекомендовали zfs), а совсем не Ланбиллинга, такое с любой базой может случится. Почистили бы reject-ы из auth_history...

 

Другое дело, что эти рукожопые постоянно и значительно меняют структуру БД, что вообщем-то несколько странно. ну и да, про отсутствие понятия релиза как такого уже сказали, просто правят баги и вносят новые фичи(=баги)

Share this post


Link to post
Share on other sites

Вы вообще хоть на их сайт заходили? Заполняете анкету и по вас развертывают на месяц виртулку полнофункциональную

 

Скажу больше, даже по телефону разговаривал=)

 

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

Share this post


Link to post
Share on other sites

Вы вообще хоть на их сайт заходили? Заполняете анкету и по вас развертывают на месяц виртулку полнофункциональную

 

Скажу больше, даже по телефону разговаривал=)

 

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

Конечно получал, и изучал не один месяц.

Share this post


Link to post
Share on other sites

Конечно получал, и изучал не один месяц.

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Табличка auth_history весит 20 гигов, tmp_table_size и max_heap_table_size были выставлены на 256M, по их рекомендациям, что соответствует свободной памяти. C livecd сейчас при попытке монтирования ФС уходит так же в глубокую задумчивость.При попытке смонтировать получил такое. Оживить пока что ни как не получается, думайте сами.

 

А при чем здесь сетевые решения? То, что у вас развалилась ZFS каким боком относится с разрабам? Они, конечно, тоже молодцы что альтерят таблицы по 20 ГБ и я их ни разу не защищаю. Но вам бы тоже головой надо думать и смотреть update.sql. Тем более он более-менее документирован и можно посмотреть, что меняется от ревизии к ревизии БД.

 

А вообще, честно говоря, у сетевых решений вот такой подход:041784738e93775da34edfd7861be15c.jpeg

 

Реализовывать бизнес-логику на C это боль. Ладно радиус или DHCP - там все должно работать с низкими задержками. Но, блин, какая разница - заведется договор за 300 мсек или одну секунду

Тем более у них в радиус вынесена часть бизнес-логики и там внутри адская каша. Бинарник на 70 метров как бы намекает.

Share this post


Link to post
Share on other sites
Табличка auth_history весит 20 гигов, tmp_table_size и max_heap_table_size были выставлены на 256M, по их рекомендациям, что соответствует свободной памяти. C livecd сейчас при попытке монтирования ФС уходит так же в глубокую задумчивость.При попытке смонтировать получил такое. Оживить пока что ни как не получается, думайте сами.

 

А при чем здесь сетевые решения? То, что у вас развалилась ZFS каким боком относится с разрабам? Они, конечно, тоже молодцы что альтерят таблицы по 20 ГБ и я их ни разу не защищаю. Но вам бы тоже головой надо думать и смотреть update.sql. Тем более он более-менее документирован и можно посмотреть, что меняется от ревизии к ревизии БД.

 

Да понятно, что надо смотреть update.sql, но копаться в кучи кода да еще и не везде понятного тоже как то не доставляет. А вы думаете здесь любая другая ФС продолжила бы работать в штатном режиме? (Без холиваров) Будь то UFS или ext4... Обновления были и не раз на этом сервере, если появлялись ошибки - скрипт останавливался. Сейчас у них поменялась логика обновления БД. Я вижу здесь причинно следственную связь, поэтому причастнность сетевых решение есть может и косвенная.

Edited by hsvt

Share this post


Link to post
Share on other sites

Юзаем Ланбиллинг, сидим на нем с версии 1.5, то есть очень долго. Если озадачиться элементарными средствами диагностики перед апдейтом - всё нормально. Обновлять через update.sql без предварительной проверки на тестовой машине - никогда в жизни. Завели второй сервер, настроен 1-в-1 как боевой. На нём вся отладка, тест, потом заливаем на боевой. Затраты на содержание тестовой машины небольшие, а результат налицо. В остальном под личные хотелки что-то дописывать придется с любым биллингом.

Share this post


Link to post
Share on other sites
Юзаем Ланбиллинг, сидим на нем с версии 1.5, то есть очень долго. Если озадачиться элементарными средствами диагностики перед апдейтом - всё нормально. Обновлять через update.sql без предварительной проверки на тестовой машине - никогда в жизни. Завели второй сервер, настроен 1-в-1 как боевой. На нём вся отладка, тест, потом заливаем на боевой. Затраты на содержание тестовой машины небольшие, а результат налицо. В остальном под личные хотелки что-то дописывать придется с любым биллингом.

 

Мы так же делаем. Только у нас специальная виртуалка, на которую БД сливается xtrabackup'ом перед всяким обновлениями или новыми фичами. Если идет что-то не так, то можно быстро вернуться к снапшоту до обновления.

Share this post


Link to post
Share on other sites

Идеального биллинга нет. Ланбиллинг использует, к слову, Транстелеком. Думаю, вы понимаете, что они не на ровном месте выбрали его. Я понимаю и сильные и слабые стороны ЛБ и не являюсь каким-то апологетом этой платформы. Просто лучшее - враг хорошего. Если бы передо мной стоял вопрос выбора, я бы сваял лабораторию и запустил в работу два биллинга параллельно. Это всё равно дешевле, нежели технические, денежные и репутационные издержки. Как вспомню, как в 2006 году ЦентрТелеком (в миру Ростелеком) менял биллинг - до сих порт в дрожь бросает.

Share this post


Link to post
Share on other sites

Амы сидели на УТМ и ланбиллинге, пересели на Гидру....

Share this post


Link to post
Share on other sites
Юзаем Ланбиллинг, сидим на нем с версии 1.5, то есть очень долго. Если озадачиться элементарными средствами диагностики перед апдейтом - всё нормально. Обновлять через update.sql без предварительной проверки на тестовой машине - никогда в жизни. Завели второй сервер, настроен 1-в-1 как боевой. На нём вся отладка, тест, потом заливаем на боевой. Затраты на содержание тестовой машины небольшие, а результат налицо. В остальном под личные хотелки что-то дописывать придется с любым биллингом.

Мы клиентам это принудительно делаем (= Биллинг — это не та система, что может лечь и отдохнуть, зачастую мы понимаем это лучше клиентов. Оракл, например, берет много на себя, но это не означает, что он поощряет безрассудство.

Share this post


Link to post
Share on other sites

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

 

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

 

Если такие функции не реализованы - это устаревший биллинг.

Share this post


Link to post
Share on other sites

Биллинг должен решать задачи бизнеса. Если задача бизнеса — установка биллинга, то это странный бизнес.

Share this post


Link to post
Share on other sites

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

 

С другой стороны, биллинг не должен заниматься проектированием сети или работать администратором. Без админа, который знает и понимает, как работает его сеть, обойтись сложно. И админ, как бы не должен узнавать впервые из инструкции биллинга, какие методы аутентификации могут применяться в сети. :)

Share this post


Link to post
Share on other sites

vop

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

 

ИМХО самое важное это иметь как можно меньше баз данных, в идеале одну, а приложений может быть много

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

vop

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

 

Ну давайте посмотрим. Администратор сети должен понимать и знать, как работает его сеть? Да должен. Еще лучше, если администратор, исходя из своих знаний опыта, а так же, потребностей сети, будет сам заниматься созданием архитектуры сети предоставления услуг. Ну, или уж, поручит это тем, кто будет в регулярной доступности. Но совершенно глупо выглядит ситуация, когда сеть проектируется в рамках ограничений, накладываемых биллингом "который посоветовали знакомые пацанчки".

 

Теперь про биллинг. Это понятно, что авторы наворачивают в биллинги функции, несвойственные им, тем самым, привлекая покупателей. Хоть стратегически это и не верно, но оставм это в стороне. Биллинг должен, просто обязан выполнять свою основную функцию - быть инструментом продажи услуг. Мягко говоря, он должен вести учет клиентов, услуг, и просто обязан правильно считать, с точностью до копейки. Ну, что бы абонент потом не звонил, и не спрашивал - "почему абонплата 500 рулей, а мне насчитало 500 рублей и 16 копеек?". Не отвечать же им, что "зато у нас в биллинге есть база активки". :) Ну а как продаются услуги технологически, биллингу знать не обязательно. Он должен обладать достаточным количеством формализмов в интерфейсе взаимодействия, что бы туда уместились любые технологические решения, и что бы он мог отобразить весь набор параметров, необходимых для продажи услуг клиентам (т.е. параметры контроля и управления). Например, биллинг положено знать, что для продажи ресурса надо ему указать идентификатор ресурса, пароль, опционально параметр, название и список значений которых предоставляет плагин услуги (например, ip-адрес), ну и набор разных опций. Помимо этого плагин услуги может "сообщить" биллингу, что он понимает набор управляющих атрибутов, таких, как "active", "blocked", "25Mbit" и так далее. В любом случае, желательно соблюдать принцип необходимости и достаточности объектов обработки и хранения (запутанно малость). Этот принцип подразумевает, что каждый модуль системы должен оперировать только теми данными, которые необходимы для его полноценной работы. Любые лишние данные только усложняют работу и снижают надёжность. Лень примеры описывать. Может как-нить в другое время и в другом месте.

 

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

 

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

 

Или другой пример - работа с платежными системами. В принципе, по сути, все они работают по схожему алгоритму. Более того, есть примеры, когда две-три системы работают практически по одному сценарию, но вставив собственный тег в заголовок, что делает их в принципе, не совместимым. В результате, каждый биллинг пишет свой набор плагинов под платежные системы. Казалось бы, чего проще - унифицируйте интерфейс внесения платежа на лицевой счет клиента, да и используйте нормальный платежный интегратор, который имеет все нужные для этого плагины. А если еще укатать платежки на то, что бы они не морозили каждый своё API на свою супер-систему, а унифицировали его, то вообще бы огромный кусок проблем ушел бы в сторону.

 

Ладно, есть много вещей, которые бы было полезно обсудить. Но как-то облом это делать.

 

ИМХО самое важное это иметь как можно меньше баз данных, в идеале одну, а приложений может быть много

 

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

Edited by vop

Share this post


Link to post
Share on other sites

Или еще пример. Информеры. Вы знаете хоть один биллинг, имеющий интерфейс для информеров? Не говоря уж о информерах, имеющих требования лояльности к интерфесам биллнгов? Нет унификации, зато есть N информеров, умноженных на M биллингов - как результат N*M сценариев разборки хьюман страниц регулярных выражений, из которых треть давно не поддерживается в актуальном состоянии и не работает.

 

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

Share this post


Link to post
Share on other sites

vop

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

 

Ну давайте посмотрим. Администратор сети должен понимать и знать, как работает его сеть? Да должен. Еще лучше, если администратор, исходя из своих знаний опыта, а так же, потребностей сети, будет сам заниматься созданием архитектуры сети предоставления услуг. Ну, или уж, поручит это тем, кто будет в регулярной доступности. Но совершенно глупо выглядит ситуация, когда сеть проектируется в рамках ограничений, накладываемых биллингом "который посоветовали знакомые пацанчки".

 

Теперь про биллинг. Это понятно, что авторы наворачивают в биллинги функции, несвойственные им, тем самым, привлекая покупателей. Хоть стратегически это и не верно, но оставм это в стороне. Биллинг должен, просто обязан выполнять свою основную функцию - быть инструментом продажи услуг. Мягко говоря, он должен вести учет клиентов, услуг, и просто обязан правильно считать, с точностью до копейки. Ну, что бы абонент потом не звонил, и не спрашивал - "почему абонплата 500 рулей, а мне насчитало 500 рублей и 16 копеек?". Не отвечать же им, что "зато у нас в биллинге есть база активки". :) Ну а как продаются услуги технологически, биллингу знать не обязательно. Он должен обладать достаточным количеством формализмов в интерфейсе взаимодействия, что бы туда уместились любые технологические решения, и что бы он мог отобразить весь набор параметров, необходимых для продажи услуг клиентам (т.е. параметры контроля и управления). Например, биллинг положено знать, что для продажи ресурса надо ему указать идентификатор ресурса, пароль, опционально параметр, название и список значений которых предоставляет плагин услуги (например, ip-адрес), ну и набор разных опций. Помимо этого плагин услуги может "сообщить" биллингу, что он понимает набор управляющих атрибутов, таких, как "active", "blocked", "25Mbit" и так далее. В любом случае, желательно соблюдать принцип необходимости и достаточности объектов обработки и хранения (запутанно малость). Этот принцип подразумевает, что каждый модуль системы должен оперировать только теми данными, которые необходимы для его полноценной работы. Любые лишние данные только усложняют работу и снижают надёжность. Лень примеры описывать. Может как-нить в другое время и в другом месте.

 

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

 

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

 

Или другой пример - работа с платежными системами. В принципе, по сути, все они работают по схожему алгоритму. Более того, есть примеры, когда две-три системы работают практически по одному сценарию, но вставив собственный тег в заголовок, что делает их в принципе, не совместимым. В результате, каждый биллинг пишет свой набор плагинов под платежные системы. Казалось бы, чего проще - унифицируйте интерфейс внесения платежа на лицевой счет клиента, да и используйте нормальный платежный интегратор, который имеет все нужные для этого плагины. А если еще укатать платежки на то, что бы они не морозили каждый своё API на свою супер-систему, а унифицировали его, то вообще бы огромный кусок проблем ушел бы в сторону.

 

Ладно, есть много вещей, которые бы было полезно обсудить. Но как-то облом это делать.

 

ИМХО самое важное это иметь как можно меньше баз данных, в идеале одну, а приложений может быть много

 

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

 

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

 

Зная тонкости с обеих сторон(и со стороны разработки и с позиции эксплуатации), могу сказать что идеальная система для оператора, должна иметь единую, связанную базу данных(а не просто слить 3 БД в одну с разными названиями таблиц и без связей между ними)), в которой должны быть всех тех.данные(и по по активке и по пассивке и по тарифами и т.д.), а уж интерфейсов к ней может быть несколько - один для тёточек, которые заводят абонентов/активируют услуги, другой для тех кто следит за падением хостов, третий может быть для формирования отчёта. Даже не важно как это будет реализовано - в одном или нескольких (веб)приложении, главное чтоб все данные были заведомо связаны между собой и чтоб не получалось так, что на сети 1000 свитчей, из них в мониторинг внесли 800 и ещё 200 с одним и тем же IP.

 

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

 

А правильно было бы заняться вопросами унификации, которая полностью отсутствует в этой отрасли. Точнее, единственная унификация, которая есть, касается сопряжение менеджмента и технологии доступа - протокол RADIUS, за который всем приходится так цепляться, несмотря на все его недостатки. Унификация менеджмента позволила бы потребителям набирать себе систему управления такую, какую они бы хотели, из качественных компонентов, а не "телерадиомагнитолу", в которой есть все, но какое-то всё оно "недопиленое".

 

Это уже изобрели. Openflow и модная аббревиатура SDN.

 

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

 

Отраслью рулят вендоры оборудования, а не операторы. Операторы просто выбирают среди того, что предлагает вендор. А хотелки оператор->вендор обычно выглядят так "посмотрите, вендор XXX умеют фичу YYY, запилите у себя такую же". Операторы это щас обычные коммунальные службы, со всеми вытекающими.

Вот как вы думаете пишутся требования к оборудованию на тендорах? Берутся тех. характеристики Cisco/Juniper/Alcatel/Ericcson/etc. (предпочтительное подчеркнуть) и записываются в требования, иногда что-то корректируется, иногда добавляется, если это реализовать заведомо легко.

Share this post


Link to post
Share on other sites

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

 

Но часто проблема лежит в другом месте. Биллинг стоит денег, порой не малых, и покупая продукт, хочется начать его изучение без лишних проблем. Что бы проблем не было, система должна устанавливаться в автоматическом режиме, при этом все ее модули должны поставляться в пакете установки. Некоторые биллинги требуют установки линукса или иной системы, SQL или иного сервера, различных модификаций других программных продуктов, при этом требуется вводить какие-то команды текстом и т.п. Такой подход не правильный, т.к. при установке можно ошибиться, а потом вылезет проблема, при этом ее будет сложно найти и исправить.

Share this post


Link to post
Share on other sites

Saab95

Проще сказать, что биллинги до 20К абонентов должны распространяться в формате .ova. Раскатал виртуалку на гипервизор за минуту, активировал и пользуйся.

Share this post


Link to post
Share on other sites
Вы рассуждаете как разработчик биллинга(и, возможно, ещё каких-то сопутствующих систем), вам нужно разрабатывать(кушать свой хлеб) много систем, не просто модулей к одной системе, а полностью независимых систем, со своими БД и прочим. Я говорю вам как потребитель ПО(хотя ещё чуть больше года назад сам занимался разработкой таких систем(всего, кроме биллинга)). Так вот, я не согласен с Вами оп всем пунктам.

 

Я и не призывал к согласию. Более того, отсутствие согласия и есть корень многих современных проблем. :) Как разработчик (условно), как раз, я и не стремлюсь написать все, что надо, ибо все это будет хренового качества. Это объективно.

 

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

 

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

 

Про какую обертку вы говорите - не приложу ума. Биллинг - он биллинг, при унификации может пользоваться данными других систем. Например, от системы мониторинга получать информацию о состоянии ресурсов продаваемых услуг. От системы учета - получать технические ресурсы закрепленные за продаваемой услугой. Не копировать в свою базу, и именно использовать. И т.д. Но вряд ли менеджер офиса должен управлять настройкой свичей из биллинга, верно? Для этого есть свои инструменты у системного администратора.

 

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

 

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

 

Ну, что бы было лучше понятно, пример из совершенно другой области. Вот вы набираете в броузере какой-нибудь URL. Ваш броузер, пользуясь унифицированным интерфейсом, по сути, определяет ip-адресс по домену. При этом, ему пофиг, где, как и в каком формате эти данные храняться, как они там на ns добавляются и редактируются. Есть унифицированный протокол, и программы им пользуются. Далее он пользуется другим унифицированным интерфейсом, что бы получить другие данные (http и т.д.)

 

а уж интерфейсов к ней может быть несколько - один для тёточек, которые заводят абонентов/активируют услуги, другой для тех кто следит за падением хостов, третий может быть для формирования отчёта. Даже не важно как это будет реализовано - в одном или нескольких (веб)приложении, главное чтоб все данные были заведомо связаны между собой и чтоб не получалось так, что на сети 1000 свитчей, из них в мониторинг внесли 800 и ещё 200 с одним и тем же IP.

 

И в результате, у каждого своя база, свои интерфейсы, и свои костыли. :)

 

Это уже изобрели. Openflow и модная аббревиатура SDN.

 

И какое отношение сетевые протоколы настройки имеют к вопросам унификации управления продажами услуг? :)

 

Отраслью рулят вендоры оборудования, а не операторы. Операторы просто выбирают среди того, что предлагает вендор. А хотелки оператор->вендор обычно выглядят так "посмотрите, вендор XXX умеют фичу YYY, запилите у себя такую же". Операторы это щас обычные коммунальные службы, со всеми вытекающими.

Вот как вы думаете пишутся требования к оборудованию на тендорах? Берутся тех. характеристики Cisco/Juniper/Alcatel/Ericcson/etc. (предпочтительное подчеркнуть) и записываются в требования, иногда что-то корректируется, иногда добавляется, если это реализовать заведомо легко.

 

И какое отношение вендоры имеют к технологии учета клиентов и услуг? Или это вы начали рассуждать, как админ/монтажник? :)

Share this post


Link to post
Share on other sites

Вы вообще хоть на их сайт заходили? Заполняете анкету и по вас развертывают на месяц виртулку полнофункциональную

 

Скажу больше, даже по телефону разговаривал=)

 

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

Сааб, ты гонишь. Мы с Латерой давно сотрудничаем, чего от них я не когда не видел, так это крохоборства. Либо ты что-то не договариваешь, либо врешь.

Share this post


Link to post
Share on other sites
Проще сказать, что биллинги до 20К абонентов должны распространяться в формате .ova. Раскатал виртуалку на гипервизор за минуту, активировал и пользуйся.

 

Т.е. должно быть как в анекдоте:

-Как работает трансформатор?

-У-у-у-у-у-у!

 

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

А подход "далее-далее-готово" способствует копипастингу конфига без понимание что там к чему.

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
Sign in to follow this