Jump to content

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


Recommended Posts

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

 

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

 

Рассматирваете ли Вы подобную модель использование програмного обеспечения? есть недоверие? и тому подобное.

Link to post
Share on other sites
  • Replies 66
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

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

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

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

Link to post
Share on other sites

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

К тому же плюсы от использования такой схемы - минимальны. В основном на этапе внедрения.

 

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

Link to post
Share on other sites

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

 

Согласен. А как обстоят дела с сотрудниками которые по сути могу слить информацию по биллингу? В мелких и средних помоему этому вопросу мало кто уделяет внимание.

 

Вопрос ведь еще в цене + поддержка, у многих я думаю бывали проблемы когда сервера с биллингом давали сбои и это вызывало немало хлопот. Для биллинга и т.д. по хорошему надо иметь отдельного человека который будет обеспечивать работу таких систем 24/7.

 

Но по части биллинга согласен. Ну а остальной софт, не имеющий прямого отношения к информации по финансам?

Link to post
Share on other sites

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

К тому же плюсы от использования такой схемы - минимальны. В основном на этапе внедрения.

 

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

 

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

 

А почему только на этапе внедрения? А как же поддержание софта в рабочем состоянии 24/7. Это ведь требует затрат в плане обеспечения отказоустойчивости железа, сервисов + постоянный мониторинг.

Link to post
Share on other sites

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

К тому же плюсы от использования такой схемы - минимальны. В основном на этапе внедрения.

 

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

 

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

 

А почему только на этапе внедрения? А как же поддержание софта в рабочем состоянии 24/7. Это ведь требует затрат в плане обеспечения отказоустойчивости железа, сервисов + постоянный мониторинг.

В плане железа любой оператор уже решает этот вопрос для ядра сети вне зависимости от биллинга.

 

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

Аналогично, кстати, и вопрос бекапа - админ знает что, куда и как часто бекапит. А если что не так - сам себе злобный буратино. Есть риск, что SaaS-провайдер понимает резервное копирование как зеркало на 2 диска в одном физическом корпусе, "а пожара быть не может потому как пожарники продали сертифицированный огетушитель". Утрирую, конечно.

 

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

Link to post
Share on other sites

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

К тому же плюсы от использования такой схемы - минимальны. В основном на этапе внедрения.

 

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

 

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

 

А почему только на этапе внедрения? А как же поддержание софта в рабочем состоянии 24/7. Это ведь требует затрат в плане обеспечения отказоустойчивости железа, сервисов + постоянный мониторинг.

В плане железа любой оператор уже решает этот вопрос для ядра сети вне зависимости от биллинга.

 

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

Аналогично, кстати, и вопрос бекапа - админ знает что, куда и как часто бекапит. А если что не так - сам себе злобный буратино. Есть риск, что SaaS-провайдер понимает резервное копирование как зеркало на 2 диска в одном физическом корпусе, "а пожара быть не может потому как пожарники продали сертифицированный огетушитель". Утрирую, конечно.

 

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

 

Договор? соглашение? технические регламенты.

 

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

Link to post
Share on other sites

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

 

Согласен. А как обстоят дела с сотрудниками которые по сути могу слить информацию по биллингу? В мелких и средних помоему этому вопросу мало кто уделяет внимание.

 

Вопрос ведь еще в цене + поддержка, у многих я думаю бывали проблемы когда сервера с биллингом давали сбои и это вызывало немало хлопот. Для биллинга и т.д. по хорошему надо иметь отдельного человека который будет обеспечивать работу таких систем 24/7.

 

Но по части биллинга согласен. Ну а остальной софт, не имеющий прямого отношения к информации по финансам?

Вопрос с сотрудниками решается внутри компании в контролируемой зоне, а как проконтролировать SaaS?

Для биллинга и т.д. по хорошему надо иметь 100% резерв по железу и бэкапам и с этим вполне справится штатный админ.

Но тут всплывает вопрос: а кто мешает непосредственно сервер с биллингом отдать на поддержку аутсорс?

Link to post
Share on other sites

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

 

Согласен. А как обстоят дела с сотрудниками которые по сути могу слить информацию по биллингу? В мелких и средних помоему этому вопросу мало кто уделяет внимание.

 

Вопрос ведь еще в цене + поддержка, у многих я думаю бывали проблемы когда сервера с биллингом давали сбои и это вызывало немало хлопот. Для биллинга и т.д. по хорошему надо иметь отдельного человека который будет обеспечивать работу таких систем 24/7.

 

Но по части биллинга согласен. Ну а остальной софт, не имеющий прямого отношения к информации по финансам?

Вопрос с сотрудниками решается внутри компании в контролируемой зоне, а как проконтролировать SaaS?

Для биллинга и т.д. по хорошему надо иметь 100% резерв по железу и бэкапам и с этим вполне справится штатный админ.

Но тут всплывает вопрос: а кто мешает непосредственно сервер с биллингом отдать на поддержку аутсорс?

 

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

 

Договор, всё как положено с печатями т.д.

Link to post
Share on other sites

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

 

Договор, всё как положено с печатями т.д.

Я собственно пояснил основные причины почему нет.

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

Edited by adeep
Link to post
Share on other sites

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

 

Договор, всё как положено с печатями т.д.

Я собственно пояснил основные причины почему нет.

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

 

С биллингом лично я бы дважды подумал, остальной софт. В идеале хотелось бы что бы всё своё. Но основная цель зарабатывать деньги, предоставлять сервис. Если это выгодно значит можно рассматривать.

 

Ну вот к примеру есть софт для рисования оптики, стоит он так 3к. Многие готовы заплатить сходу ннную сумму денег?

Link to post
Share on other sites

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

А если биллинг выпадет на 5 минут?

Link to post
Share on other sites

В плане железа любой оператор уже решает этот вопрос для ядра сети вне зависимости от биллинга.

 

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

Аналогично, кстати, и вопрос бекапа - админ знает что, куда и как часто бекапит. А если что не так - сам себе злобный буратино. Есть риск, что SaaS-провайдер понимает резервное копирование как зеркало на 2 диска в одном физическом корпусе, "а пожара быть не может потому как пожарники продали сертифицированный огетушитель". Утрирую, конечно.

 

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

Договор? соглашение? технические регламенты.

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

Link to post
Share on other sites
SaaS-провайдер в договоре обяжется компенсировать оператору прямые и косвенные убытки, полученные вследствие простоя?

конечно, в договоре только будет походу пунктик - стихійні лиха, треті сили... И туда можно будет списать васю тракториста порвавшего кабель или Ддос ...

Вобщем печально это все.

Link to post
Share on other sites
SaaS-провайдер в договоре обяжется компенсировать оператору прямые и косвенные убытки, полученные вследствие простоя?

конечно, в договоре только будет походу пунктик - стихійні лиха, треті сили... И туда можно будет списать васю тракториста порвавшего кабель или Ддос ...

Вобщем печально это все.

 

Печально конечно.

 

К примеру размещая свой сервер на площадке ДЦ мы находимся в аналогичной ситуации. На сервере находятся данные(возможно и важные) и как то все покупают, работают.

 

У нас на тех. площадке в ДЦ Германии клиенты размещают свои корпоративные сервера, и тоже можно сказать риски и т.д.

Link to post
Share on other sites

К примеру размещая свой сервер на площадке ДЦ мы находимся в аналогичной ситуации. На сервере находятся данные(возможно и важные) и как то все покупают, работают.

У нас на тех. площадке в ДЦ Германии клиенты размещают свои корпоративные сервера, и тоже можно сказать риски и т.д.

Вы опять путаете теплое с мягким. Клиент разместил свой физический сервер с тем софтом, который он знает. Это его осознанный выбор.

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

Link to post
Share on other sites
SaaS-провайдер в договоре обяжется компенсировать оператору прямые и косвенные убытки, полученные вследствие простоя?

конечно, в договоре только будет походу пунктик - стихійні лиха, треті сили... И туда можно будет списать васю тракториста порвавшего кабель или Ддос ...

Вобщем печально это все.

 

Печально конечно.

 

К примеру размещая свой сервер на площадке ДЦ мы находимся в аналогичной ситуации. На сервере находятся данные(возможно и важные) и как то все покупают, работают.

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

 

У нас на тех. площадке в ДЦ Германии клиенты размещают свои корпоративные сервера, и тоже можно сказать риски и т.д.

Может быть, они подняли ещё один дублирующий сервер в другом датацентре на другом континенте, реплицируют все сессии и готовы в течении 15 секунд откатиться на него?

А если они не готовы на это тратиться либо надеются на надёжность немецкого дата-центра, то они знают о существующем риске и сознательно на него идут, готовы нести ответственность.

 

Может, вам посмотреть в строну чего-то не mission critical? Там у SaaS шансов больше. "Не работает? Ой, яка халепа.... Ладно, пойду пока чаю попью".

 

ЗЫ

http://arstechnica.com/business/2012/03/bitcoins-worth-228000-stolen-from-customers-of-hacked-webhost/

http://aws.amazon.com/message/65648/

Link to post
Share on other sites
  • 2 weeks later...
SaaS-провайдер в договоре обяжется компенсировать оператору прямые и косвенные убытки, полученные вследствие простоя?

конечно, в договоре только будет походу пунктик - стихійні лиха, треті сили... И туда можно будет списать васю тракториста порвавшего кабель или Ддос ...

Вобщем печально это все.

 

Печально конечно.

 

К примеру размещая свой сервер на площадке ДЦ мы находимся в аналогичной ситуации. На сервере находятся данные(возможно и важные) и как то все покупают, работают.

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

 

У нас на тех. площадке в ДЦ Германии клиенты размещают свои корпоративные сервера, и тоже можно сказать риски и т.д.

Может быть, они подняли ещё один дублирующий сервер в другом датацентре на другом континенте, реплицируют все сессии и готовы в течении 15 секунд откатиться на него?

А если они не готовы на это тратиться либо надеются на надёжность немецкого дата-центра, то они знают о существующем риске и сознательно на него идут, готовы нести ответственность.

 

Может, вам посмотреть в строну чего-то не mission critical? Там у SaaS шансов больше. "Не работает? Ой, яка халепа.... Ладно, пойду пока чаю попью".

 

ЗЫ

http://arstechnica.c...hacked-webhost/

http://aws.amazon.com/message/65648/

 

Ну хорошо допустим с биллингом всё сложно. Но к примеру софт для мониторинга и анализа работы сети?

Link to post
Share on other sites

Ну хорошо допустим с биллингом всё сложно. Но к примеру софт для мониторинга и анализа работы сети?

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

Link to post
Share on other sites

Ну хорошо допустим с биллингом всё сложно. Но к примеру софт для мониторинга и анализа работы сети?

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

 

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

 

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

 

Интеграция любого решения требует правильного планирования.

 

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

Link to post
Share on other sites

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

Все эти абстрактные рассказы о "вебдваноль в облаке" хавают бизнеса. Здесь же сидят большей частью технари.

 

ЗЫ Может, что-то вроде учета заявок на подключение и обслуживание, координация и контроль работы монтажников, учет материалов и планирование их закупок? Как мысль навскидку.

При выпадении этого добра вам, конечно, моск выедят, но критических потерь не будет.

Link to post
Share on other sites

из известных мне примеров: у Ланета сервис технического форума rada.lanet.ua предоставляется вот этой службой http://copiny.com/

это именно облачный сервис

других примеров применительно к ISP не встречал.

upd: ну, еще у Воли почта предоставляется Яндексом, разве что....

Edited by andytg
Link to post
Share on other sites

Ну хорошо допустим с биллингом всё сложно. Но к примеру софт для мониторинга и анализа работы сети?

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

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

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

Link to post
Share on other sites

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

Все эти абстрактные рассказы о "вебдваноль в облаке" хавают бизнеса. Здесь же сидят большей частью технари.

 

ЗЫ Может, что-то вроде учета заявок на подключение и обслуживание, координация и контроль работы монтажников, учет материалов и планирование их закупок? Как мысль навскидку.

При выпадении этого добра вам, конечно, моск выедят, но критических потерь не будет.

 

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

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

 

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

 

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

Link to post
Share on other sites

из известных мне примеров: у Ланета сервис технического форума rada.lanet.ua предоставляется вот этой службой http://copiny.com/

это именно облачный сервис

других примеров применительно к ISP не встречал.

upd: ну, еще у Воли почта предоставляется Яндексом, разве что....

 

По этому и создал тему изучаю данный вопрос. Зерно ведь есть,

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
  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...