[joesm]

Картуччо тут уже написал откуда ноги у спора растут :)

Операторы работающие в ареале с 50+ тыс. домохозяйств и 5-10 тыс. находятся в разных экономических условиях как правило и имеют разные возможности наема специалистов.

Отсюда и разумность использования той или иной схемы.

Очень здравая мысль :) А заодно то, что работает для обслуживания 100 клиентов плохо подходит для 100k клиентов. Заставить работать можно конечно почти любую схему, все зависит от критерия понятия "работает".

[NiTr0]

Это ещё почему?

Да банально потому, что роутер - это линуксовое/бздевое ядро + квагга или что там еще для маршрутизации; брас - еще демон туннелей. Все. Биллинг - дополнительно к этому еще веб-сервер, СУБД, радиус-сервер, и прочее, прочее, прочее, типа перла/питона, скриптовых костылей, снмп и т.д.

Если у вас/ваших специалистов руки не стоят настроить брас/роутер - что с сервером биллинга/СУБД они сделать-то смогут?

 

И снова эффект масштаба. Сетевики не обслуживают биллинг. Биллинг это биллинг. ОС и железо под него - отдельный вопрос и задача. СУБД тоже отдельно.

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

А если кто-то таки обслуживает - то в чем же огромная разница между обслуживанием биллинга и софтроутера? :)

[Картуччо]

Я ж написал - сетевики не обслуживают биллинг. Разные системы обслуживают разные люди или разные отделы.

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

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

Большой!=маленький вот что я пытаюсь донести, не надо их сравнивать и навязывать свои методы работы.

[joesm]

 

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

А если кто-то таки обслуживает - то в чем же огромная разница между обслуживанием биллинга и софтроутера? :)

Если у Вас админ сети, админ серверов и админ биллинга это одно и то же лицо, это не говорит о том, что так везде и так правильно и целесообразно делать повсеместно.

[telematic]

 

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

А если кто-то таки обслуживает - то в чем же огромная разница между обслуживанием биллинга и софтроутера? :)

Если у Вас админ сети, админ серверов и админ биллинга это одно и то же лицо, это не говорит о том, что так везде и так правильно и целесообразно делать повсеместно.

Ну а о том, что у коммерческих биллингов существует техподдержка от разработчика, товарищ Нитро вообще не подозревает. В его картине мира такого нет :-)

Кстати, биллинг у меня под виндой.

[telecom]

Кстати, биллинг у меня под виндой.

Не говорите никому больше такое. Как минимум, засмеют.

[NiTr0]

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

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

 

Если у Вас админ сети, админ серверов и админ биллинга это одно и то же лицо, это не говорит о том, что так везде и так правильно и целесообразно делать повсеместно.

У вас настолько сложный биллинговый сервер, что для его обслуживания нужно держать отдельного человека? Или у человека настолько кривые руки, что он лично может обслуживать лишь один сервер на ставке?

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

 

Ну а о том, что у коммерческих биллингов существует техподдержка от разработчика, товарищ Нитро вообще не подозревает.

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

 

Кстати, биллинг у меня под виндой.

И почему я не удивляюсь, что ваши специалисты так и не осилили настроить хоть один *никс сервер - даже самый примитивный роутер - нормально? :)

[joesm]

У вас настолько сложный биллинговый сервер, что для его обслуживания нужно держать отдельного человека? Или у человека настолько кривые руки, что он лично может обслуживать лишь один сервер на ставке?

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

 

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

 

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

 

Это собственно к чему? Зачем вашему биллингу знать маршруты до всех устройств в вашей сети? Дефолтные маршруты уже отменили?

[telematic]

И почему я не удивляюсь, что ваши специалисты так и не осилили настроить хоть один *никс сервер - даже самый примитивный роутер - нормально? :)

 

... а второй билинг под линуксом. Обслуживает его отдельный сотрудник.

 

В общем, хватит уже бисер перед свиньями метать, всего вам хорошего.

[nuclearcat]

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

Тссс! Пусть все будет как есть, поэтому мы хорошо зарабатываем :)

[SmokerMan]

Как могли - Нитро с тыщей сообщений на форуме - до сих пор не встретиться с телематиком, у которого три тыщи?.. Вот главный-то вопрос... :-)

[shicoy]

Как могли - Нитро с тыщей сообщений на форуме - до сих пор не встретиться с телематиком, у которого три тыщи?.. Вот главный-то вопрос... :-)

Ой зачетно сказал :)

[Сильвер]

Ну а о том, что у коммерческих биллингов существует техподдержка от разработчика, товарищ Нитро вообще не подозревает.

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

 

Имхо, тут речь идёт не об обновлении ОС, а о ТП самого биллинга - обновление, добавление новых возможностей.

[Zarin]

У вас настолько сложный биллинговый сервер, что для его обслуживания нужно держать отдельного человека? Или у человека настолько кривые руки, что он лично может обслуживать лишь один сервер на ставке?

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

 

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

При абон. базе свыше 10 тыс.

 

Кроме того, что это все делает ИТ-специалист, общего тут мало.

 

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

 

Вы еще пользователям оспф не настраиваете ?

Изменено 29 марта, 2012 пользователем Zarin

[alks]

Вы еще пользователям оспф не настраиваете ?

 

ДА! и еще по stp с ними дружим, и рутами позволяем стать )))

шучу я

[NiTr0]

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

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

 

Это собственно к чему? Зачем вашему биллингу знать маршруты до всех устройств в вашей сети? Дефолтные маршруты уже отменили?

Писал выше. Чтобы при остановке машины, на которую указывает дефолтный маршрут, внезапно биллинг не отпал. Или еще какой сервер.

 

... а второй билинг под линуксом. Обслуживает его отдельный сотрудник.

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

 

Имхо, тут речь идёт не об обновлении ОС, а о ТП самого биллинга - обновление, добавление новых возможностей.

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

 

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

Что общего между обслуживанием серверов, планированием архитектуры и программированием например?

А системный администратор, не понимающий сетевые сервисы - это очень печально, да...

 

Вы еще пользователям оспф не настраиваете ?

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

[Картуччо]

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

Для этого существует VRRP и подобные.

[joesm]

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

Т.е. так да, нужны разные люди ? :)

 

 

 

Писал выше. Чтобы при остановке машины, на которую указывает дефолтный маршрут, внезапно биллинг не отпал. Или еще какой сервер.

 

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

[Ilya Evseev]

 

Писал выше. Чтобы при остановке машины, на которую указывает дефолтный маршрут, внезапно биллинг не отпал. Или еще какой сервер.

 

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

Для VRRP и CARP есть софтовые реализации.

То, что Вы называете "тазиками", непригодно только там, где нужна высокопроизводительная узкоспециализированная молотилка.

[joesm]

Для VRRP и CARP есть софтовые реализации.

То, что Вы называете "тазиками", непригодно только там, где нужна высокопроизводительная узкоспециализированная молотилка.

Никаких сомнений, есть. Вопрос в том сколько затрат уйдет на поддежражние этого при 10, 20, 50, 100 Гб трафика.

[kapa]

У вас настолько сложный биллинговый сервер, что для его обслуживания нужно держать отдельного человека? Или у человека настолько кривые руки, что он лично может обслуживать лишь один сервер на ставке?

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

 

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

При абон. базе свыше 10 тыс.

Забыли сказать "сильно" "свыше 10 тыс.".

 

Если сажать одного человека на биллинг, второго на роутинг, третьего на свичинг,... то нужно, как минимум, каждого резервировать.

Ещё бы неплохо для каждого (почти каждого) дежурство придумать - услуги-то 7*24 предоставляете? Т.е. уже резервировать не дублем.

Так на OPEX и разориться можно даже с 10 тыс. базой.

[Alex/AT]

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

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

Изменено 29 марта, 2012 пользователем Alex/AT

[NiTr0]

Для этого существует VRRP и подобные.

Существуют. И на тазиках тоже существуют. Только применимость их всегда и везде - спорная.

 

Т.е. так да, нужны разные люди ? :)

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

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

 

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

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

 

Не поверите - любой коммерческий сертифицированный биллинг.

Опять же, разработка (а то, что вы назвали - именно разработка) и обслуживание - разные вещи.