Перейти до

Готовность использованиее SaaS


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

Тоесть покупать канал или транспорт это нормально? рисков нету? и моск никто не будет кушать из за проблем?

То что сгорит БП на сервере и в течении какого либо времени сервисы будут лежать и работа фирмы встанет это тоже нормально?

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

 

Давайте рассматривать чем в ответственности представители SaaS сервива отличаются от сотрудника Вашей компании который допустим может что либо повердить?

Риски, связанные с собственным персоналом можно оценить и предупредить. SaaS - чёрный ящик.

 

Может всё же дело в доверии нашего рынка к подобного рода решениям? или просто не готовность нашего рынка?

Интересно было бы услышать о успешных внедрениях mission-critical SaaS на "ихнем" рынке.

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

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Как вы себе представляете мониторинг и анализ работы сети, отвязанный от работы сети?

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

<p> </p><div>Пропадает связность между вашим интернетом и нашим интернетом. Ну вот часть "интернета" отвалилась. абоненты в панике, у оператора ни биллинг ни мониторинг не работает.

Тоесть покупать канал или транспорт это нормально? рисков нету? и моск никто не будет кушать из за проблем?

То что сгорит БП на сервере и в течении какого либо времени сервисы будут лежать и работа фирмы встанет это тоже нормально?

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

 

Давайте рассматривать чем в ответственности представители SaaS сервива отличаются от сотрудника Вашей компании который допустим может что либо повердить?

Риски, связанные с собственным персоналом можно оценить и предупредить. SaaS - чёрный ящик.

 

Может всё же дело в доверии нашего рынка к подобного рода решениям? или просто не готовность нашего рынка?

Интересно было бы услышать о успешных внедрениях mission-critical SaaS на "ихнем" рынке.

 

У многих средних и мелких провайдеров бюджет позволяет дубилровать всё критически важное? Я про реалии?

У многих каналы продублированы в той же емкости как и рабочий канал?

Просто я не видел что бы многие купили кошку и продублировали её. Я не у многих видел продубилрованное ядро сети, и точки агрегации трафика.

 

Предугадать? Можно, но многие ли в реале об этом уже сейчас позабоитились? Обиженный сотрудник который сносит базу и все бекапы.

 

Посмотрите на CRM, ERP системы ondemand. Там и данные по клиентам, и сделки, и графики работ, и планироване проектов. И это тоже риски, потерять базу клиентов.

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

У многих средних и мелких провайдеров бюджет позволяет дубилровать всё критически важное? Я про реалии?

У многих каналы продублированы в той же емкости как и рабочий канал?

Просто я не видел что бы многие купили кошку и продублировали её. Я не у многих видел продубилрованное ядро сети, и точки агрегации трафика.

Предугадать? Можно, но многие ли в реале об этом уже сейчас позабоитились? Обиженный сотрудник который сносит базу и все бекапы.

"Network core SaaS - мы не гарантируем вам работоспособности, но признайтесь - у вас ведь и так бардак."

Интересная стратегия продвижения. Попробуйте - отпишитесь :)

 

Посмотрите на CRM, ERP системы ondemand. Там и данные по клиентам, и сделки, и графики работ, и планироване проектов. И это тоже риски, потерять базу клиентов.

А в сфере телекома?

 

http://www.computerw...er-list-stolen/

http://news.cnet.com...0136540-92.html

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

Отваливается внешний канал на 10 минут (работы у апстрима либо авария). При внешнем биллинге - теряется связь с брасами, сессии благополучно дропаются на биллинге (ибо брас считается умершим), но живут на брасах, при возобновлении линка - имеем выдавшиеся 2 пользователям ip. 2 вариант - считать брас со всеми его абонами живым до указания вручную что он умер - еще более идиотичен в итоге будет. Также на время отсутствия связи техперсонал слепой ибо система мониторинга померла вместе со всем прочим. Отказ вашего сервера/канала связи до вашей техплощадки оборачивается убытками для провайдера (эдак несколько тысяч грн в час, особенно при простое в несколько часов а для провов, обслуживающих юриков - намного больше).

 

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

 

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

 

Вам уже сказали, какие сервисы можно выносить. Всяческая картография к примеру, ERP, CRM и т.д., только им нужно будет еще обеспечить интерфейс с биллингом/софтом мониторинга, стоящим на техплощадке прова (ну либо дать апи RPC). Это, при более-менее вменяемых ценах, возможно будет популярным. Но аж никак не те сервисы, для которых у нормальных провайдеров поднимаются отказоустойчивые кластеры.

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

У многих средних и мелких провайдеров бюджет позволяет дубилровать всё критически важное? Я про реалии?

У многих каналы продублированы в той же емкости как и рабочий канал?

Просто я не видел что бы многие купили кошку и продублировали её. Я не у многих видел продубилрованное ядро сети, и точки агрегации трафика.

Предугадать? Можно, но многие ли в реале об этом уже сейчас позабоитились? Обиженный сотрудник который сносит базу и все бекапы.

"Network core SaaS - мы не гарантируем вам работоспособности, но признайтесь - у вас ведь и так бардак."

Интересная стратегия продвижения. Попробуйте - отпишитесь :)

 

Посмотрите на CRM, ERP системы ondemand. Там и данные по клиентам, и сделки, и графики работ, и планироване проектов. И это тоже риски, потерять базу клиентов.

А в сфере телекома?

 

http://www.computerw...er-list-stolen/

http://news.cnet.com...0136540-92.html

 

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

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

Отваливается внешний канал на 10 минут (работы у апстрима либо авария). При внешнем биллинге - теряется связь с брасами, сессии благополучно дропаются на биллинге (ибо брас считается умершим), но живут на брасах, при возобновлении линка - имеем выдавшиеся 2 пользователям ip. 2 вариант - считать брас со всеми его абонами живым до указания вручную что он умер - еще более идиотичен в итоге будет. Также на время отсутствия связи техперсонал слепой ибо система мониторинга померла вместе со всем прочим. Отказ вашего сервера/канала связи до вашей техплощадки оборачивается убытками для провайдера (эдак несколько тысяч грн в час, особенно при простое в несколько часов а для провов, обслуживающих юриков - намного больше).

 

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

 

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

 

Вам уже сказали, какие сервисы можно выносить. Всяческая картография к примеру, ERP, CRM и т.д., только им нужно будет еще обеспечить интерфейс с биллингом/софтом мониторинга, стоящим на техплощадке прова (ну либо дать апи RPC). Это, при более-менее вменяемых ценах, возможно будет популярным. Но аж никак не те сервисы, для которых у нормальных провайдеров поднимаются отказоустойчивые кластеры.

 

По порядку идем:

 

1. Такие элементарные проблемы как пропадание внешнего канала на 1, 3 и т.д. часа предусмотрит любой инженер/архитектор програмного обеспечения. Я же не говорил что SaaS в таких случаях будет совсем беспомощным. Кастельно биллинга. И опять же как я писал эти проблемы не являются прямым минусом SaaS решения, это проблемы проектирования инфраструктуры и софта(многое элементарно учитывается)

 

2. Случай с ДЦ мирохоста помните? Подумайте какая разница в таком случае SaaS или не SaaS если ДЦ обесточен. Второй ДЦ продублировать? Вариант, но какие деньги? Из этого вывод что разница небольшая между SaaS и cacti который будет внутри сети.

 

3. Ну по поводу хрензнаекто и хрензнаетгде это уже немного утопически. С таким успехом можно и отказатся от использования всего что не вы сделали руками. Многие админы роются в ядре линукс на предмет наличия бэкдоров? А ведь при очередном обновление где-то может и поселится вредоносный код...

 

4. А вот здесь хорошо подметили. Подобное решение для провайдеров предусматривает все возможности взаимодействия и гибкость(в пределах разумного) с внутренней инфраструктурой.

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

Блин, Юра - да никто не вынесет свои сервисы кудато за бугор, непонятно к кому... Особенно на этом форуме.

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

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

<p>

<br />

По порядку идем:<br />

<br />

1. Такие элементарные проблемы как пропадание внешнего канала на 1, 3 и т.д. часа предусмотрит любой инженер/архитектор програмного обеспечения. Я же не говорил что SaaS в таких случаях будет совсем беспомощным. Кастельно биллинга. И опять же как я писал эти проблемы не являются прямым минусом SaaS решения, это проблемы проектирования инфраструктуры и софта(многое элементарно учитывается)</p>

<br />

<p>

</p>

<div>Пропадает связность между вашим интернетом и нашим интернетом. Ну вот часть "интернета" отвалилась. абоненты в панике, у оператора ни биллинг ни мониторинг не работает. Что делать?</div>

<div>Вы просто не понимаете. Что как раз для мелких и средних провайдеров продублировать сервисы дешево и легко. Для крупных становится сложнее - резко растет стоимость. Ни в первом, ни во втором случае критические сервисы не будут вынесены за пределы сети (максимум на техплощадку аплинка, от которого и так сеть зависит на 90%).</div>

<div> </div>

<p>

</p>

<div>2. Случай с ДЦ мирохоста помните? Подумайте какая разница в таком случае SaaS или не SaaS если ДЦ обесточен. Второй ДЦ продублировать? Вариант, но какие деньги? Из этого вывод что разница небольшая между SaaS и cacti который будет внутри сети.</div>

<div>

</div>

<div>Вы сможете прогарантировать что в случае пожара, изъятия, масок шоу в одном-двух ДЦ ваши сервисы продолжат работу?</div>

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

<div> </div>

<div>

</div>

<p>3. Ну по поводу хрензнаекто и хрензнаетгде это уже немного утопически. С таким успехом можно и отказатся от использования всего что не вы сделали руками. Многие админы роются в ядре линукс на предмет наличия бэкдоров? А ведь при очередном обновление где-то может и поселится вредоносный код...</p>

<div>

</div>

<div>Ну вы опять путаете теплое с мягким: каналы можно продублировать. Линуксом пользуются миллионы и тысячи копаются в его коде выискивая блох. Реакция на блок достаточно быстрая. А у вас черный ящик, в который вы не хотите никого пустить.</div>

<div> </div>

<div>Возьмите CRM, ERP, супорт, почту, вебсайты и т.п. - то, что позволяет лежать некоторое время без вреда для работы абонентов.</div>

Ссылка на сообщение
Поделиться на других сайтах
1. Такие элементарные проблемы как пропадание внешнего канала на 1, 3 и т.д. часа предусмотрит любой инженер/архитектор програмного обеспечения. Я же не говорил что SaaS в таких случаях будет совсем беспомощным. Кастельно биллинга. И опять же как я писал эти проблемы не являются прямым минусом SaaS решения, это проблемы проектирования инфраструктуры и софта(многое элементарно учитывается)

Инженер в состоянии предусмотреть доступ к внешней системе мониторинга при отсуствии внешнего канала? :) Биллинг в состоянии будет определить, отпал ли нас, или нас жив но связи с биллингом у него нет? :)

 

2. Случай с ДЦ мирохоста помните? Подумайте какая разница в таком случае SaaS или не SaaS если ДЦ обесточен. Второй ДЦ продублировать? Вариант, но какие деньги? Из этого вывод что разница небольшая между SaaS и cacti который будет внутри сети.

Разница огромна. Потому как автономное питание у нас к примеру 3-6 часов, за это время вполне можно развернуть и запустить резервный генератор. Что в ДЦ при аварии? :)

 

3. Ну по поводу хрензнаекто и хрензнаетгде это уже немного утопически. С таким успехом можно и отказатся от использования всего что не вы сделали руками. Многие админы роются в ядре линукс на предмет наличия бэкдоров? А ведь при очередном обновление где-то может и поселится вредоносный код...

Вы не правы. Никто не знает, как у вас сделаны бекапы/дублирование серверов. Никто не знает, кто ваши сервера обслуживает. Никто не знает, как быстро вы способны (и способны ли вообще) восстановить работоспособность после физического выхода сервера из строя (пожар в ДЦ к примеру, или еще что).

 

4. А вот здесь хорошо подметили. Подобное решение для провайдеров предусматривает все возможности взаимодействия и гибкость(в пределах разумного) с внутренней инфраструктурой.

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

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

Все хотел спросить, а что на счет SaaS для отдельных задач?

 

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

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

Логи, графики - критический сервис мониторинга.

Бэкапы да, но и это место уже занято от амазона до селектела - только крон настрой и следи за балансом счета.

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

Я имел ввиду длительное хранение логов и работа с ними. Хотя не знаю, чего вы все так против выноса критических компонентов наружу. Если это будет в несколько раз дешевле, чем конструировать самому - почему нет? Это же конкурентное преимущество.

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

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

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

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

Берем билинг (то что принято считать билингом в IP сетях Украины), когда отваливается модуль биллинга, некому продлить сессию на радиусе, сессия валится - сушите весла.

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

+ когда обрывается волокно у тебя, ты знаешь что оно порвалось, варишь его. Ты точно можешь сказать - эта проблема решится через 2-3-8 часов. Когда ты зависишь от кого-то, даже при наличии SLA, все равно у тебя нет возможности контролировать и прогнозировать. Тебе нужно верить тому что говорят. А если сервер сгорел - ты ночью пошел поднимать из бэкапа, а если у них сгорел ДЦ, ты даже выставить счет не сможешь ибо форсмажор.

 

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

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

Да ну, зачем радиус и вообще зачем клиентам от биллинга зависеть? Все вполне может работать и без него и тогда выносить его наружу очень выгодно и без риска :)

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

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

Да ну, зачем радиус и вообще зачем клиентам от биллинга зависеть? Все вполне может работать и без него и тогда выносить его наружу очень выгодно и без риска :)

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

а вы собственно знаете что такое биллинг и почему сервисы абонентов от него зависят?

Вы похоже несколько оторваны от реалий. Тут несколько человек распинаются на тему критических сервисов и их доступности. Разъяснили все варианты угроз. Разъяснили какими проблемами это грозит. В итоге ни на один из вопросов по угрозам ответа дано не было кроме глупости: "зачем клиентам от биллинга зависеть".

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

Да ну, зачем радиус и вообще зачем клиентам от биллинга зависеть? Все вполне может работать и без него и тогда выносить его наружу очень выгодно и без риска :)

 

Для этого, большинству, которые работают с pppoe придется перестраивать сеть, все то что работает без проблем и кушать не просит, только ради того чтоб вынести биллинг? Вы в это верите? Биллинг, сам по себе не приносит проблем. Тем, кому предлагается это SaaS, уже имеют купленные сервера и все работает как часы. Где тут дешевле?

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

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

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

Для этого, большинству, которые работают с pppoe придется перестраивать сеть, все то что работает без проблем и кушать не просит, только ради того чтоб вынести биллинг?

Все правильно, переделывать что-то всегда дорого, SaaS не для них, а для новых провайдеров. Но в перспективе специалистов держать дороже и рано или поздно инженеры поуходят и надо будет что-то решать, вот тогда SaaS себя и покажет.

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

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

Берем билинг (то что принято считать билингом в IP сетях Украины), когда отваливается модуль биллинга, некому продлить сессию на радиусе, сессия валится - сушите весла.

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

 

А Вы опять за своё. А что ни у кого в сети не было проблем? не рвались сессии? не были потери или петли в сети после грозы, проблемы с STP, оборудование на котором сэкономили и оно подгадило работу сети на пару дней. Всё это есть и будет еще долго время.

 

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

 

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

 

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

+ когда обрывается волокно у тебя, ты знаешь что оно порвалось, варишь его. Ты точно можешь сказать - эта проблема решится через 2-3-8 часов. Когда ты зависишь от кого-то, даже при наличии SLA, все равно у тебя нет возможности контролировать и прогнозировать. Тебе нужно верить тому что говорят. А если сервер сгорел - ты ночью пошел поднимать из бэкапа, а если у них сгорел ДЦ, ты даже выставить счет не сможешь ибо форсмажор.

 

Вы забыли что Вы всё еще зависите от многих факторов. Пример, надо попасть на дом, ключи были, но уже не подходят, в жеке создают задержку и т.д. Или здесь у Всех попадание к узлам связи идеально в любое время суток?(не верю сам работаю в телекоме). А когда Вы арендуете волокна? тоже есть проблемы, Вы ждете от аплинкера решения и всё и при этом не всегда есть возможность отказатся от аплинкире ввиду отсутствия выбора.

 

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

 

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

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

Для этого, большинству, которые работают с pppoe придется перестраивать сеть, все то что работает без проблем и кушать не просит, только ради того чтоб вынести биллинг?

Все правильно, переделывать что-то всегда дорого, SaaS не для них, а для новых провайдеров. Но в перспективе специалистов держать дороже и рано или поздно инженеры поуходят и надо будет что-то решать, вот тогда SaaS себя и покажет.

 

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

 

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

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

А Вы опять за своё. А что ни у кого в сети не было проблем? не рвались сессии? не были потери или петли в сети после грозы, проблемы с STP, оборудование на котором сэкономили и оно подгадило работу сети на пару дней. Всё это есть и будет еще долго время.

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

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

 

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

Поясняю: от проблем на магистрали не уйдешь. Но если есть резерв, то в течении 2-3-4-5-6 часов люди вполне комфортно смогут работать на нем (не забываем про приоритезацию ключевых абонентов), а не плевать в потолок и ждать пока починят.

 

 

Вы забыли что Вы всё еще зависите от многих факторов. Пример, надо попасть на дом, ключи были, но уже не подходят, в жеке создают задержку и т.д. Или здесь у Всех попадание к узлам связи идеально в любое время суток?(не верю сам работаю в телекоме). А когда Вы арендуете волокна? тоже есть проблемы, Вы ждете от аплинкера решения и всё и при этом не всегда есть возможность отказатся от аплинкире ввиду отсутствия выбора.

речь идет о ключевых сервисах или о работе одного дома в большой сети? вы действительно не понимаете разницы?

 

 

 

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

у них выбора нет. у них не работал = не продал за это время. в телекоме не работал = потерял постоянных клиентов, которые приносят постоянную прибыль.

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

 

Я лишь защищаю свою позицию видение пользы от использования SaaS. Возможно в результате этой дискусии я найду более правильный ракурс на данный вопрос.

 

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

 

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

 

Поясняю: от проблем на магистрали не уйдешь. Но если есть резерв, то в течении 2-3-4-5-6 часов люди вполне комфортно смогут работать на нем (не забываем про приоритезацию ключевых абонентов), а не плевать в потолок и ждать пока починят.

 

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

 

речь идет о ключевых сервисах или о работе одного дома в большой сети? вы действительно не понимаете разницы?

 

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

 

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

 

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

 

 

у них выбора нет. у них не работал = не продал за это время. в телекоме не работал = потерял постоянных клиентов, которые приносят постоянную прибыль.

 

Не работал = не продал, нечем оплачивать ЗП, расходы, нету развития и это дорога в один конец. Клиент везде одинаковый и надо соответствовать требованиям клиентов.

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

Для этого, большинству, которые работают с pppoe придется перестраивать сеть, все то что работает без проблем и кушать не просит, только ради того чтоб вынести биллинг?

Все правильно, переделывать что-то всегда дорого, SaaS не для них, а для новых провайдеров. Но в перспективе специалистов держать дороже и рано или поздно инженеры поуходят и надо будет что-то решать, вот тогда SaaS себя и покажет.

 

Мужики, а нафига вам дался этот телеком с их гигом за чирик? Как насчёт банковского сектора?

1. Поднимаете оракл постгрес mysql (он уже поддерживает транзакции)

2. Денежки зачислены на счёт, денежки списаны со счета

3. Лепим апи для банка

4 ...

5. PROFIT!

 

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

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

Для этого, большинству, которые работают с pppoe придется перестраивать сеть, все то что работает без проблем и кушать не просит, только ради того чтоб вынести биллинг?

Все правильно, переделывать что-то всегда дорого, SaaS не для них, а для новых провайдеров. Но в перспективе специалистов держать дороже и рано или поздно инженеры поуходят и надо будет что-то решать, вот тогда SaaS себя и покажет.

 

Мужики, а нафига вам дался этот телеком с их гигом за чирик? Как насчёт банковского сектора?

1. Поднимаете оракл постгрес mysql (он уже поддерживает транзакции)

2. Денежки зачислены на счёт, денежки списаны со счета

3. Лепим апи для банка

4 ...

5. PROFIT!

 

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

 

Крайность )) не надо метатся в крайности.

 

Вы же дома себе автономно, воду, свет, газ и т.д. не подключили? В подвале запас золота положили? )))) это уже крайности.

 

Хотя, инфрастурктура банков некоторых распологается в ДЦ не принадлежащем банку, а всё по договорах, контрактах...

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

Крайность )) не надо метатся в крайности.

Не крайность. Ирония.

Аргументы уже изложены неоднократно. Представьте рынку такой сервис, сделайте его успешном и докажите, что оппоненты ошибались :)

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

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

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

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

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

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

Вхід

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

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

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


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