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

[Бонарь Юрий]

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

 

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

 

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

[adeep]

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

[Setevoy]

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

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

 

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

[Бонарь Юрий]

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

 

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

 

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

 

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

[Бонарь Юрий]

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

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

 

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

 

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

 

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

[Setevoy]

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

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

 

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

 

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

 

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

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

 

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

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

 

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

[Бонарь Юрий]

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

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

 

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

 

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

 

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

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

 

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

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

 

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

 

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

 

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

[adeep]

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

 

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

 

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

 

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

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

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

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

[Бонарь Юрий]

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

 

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

 

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

 

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

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

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

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

 

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

 

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

[adeep]

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

 

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

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

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

Відредаговано 16 травня, 2012 adeep

[Бонарь Юрий]

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

 

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

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

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

 

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

 

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

[adeep]

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

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

[Setevoy]

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

 

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

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

 

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

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

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

[martin]

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

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

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

[Бонарь Юрий]

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

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

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

 

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

 

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

 

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

[adeep]

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

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

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

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

[Setevoy]

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/

[Бонарь Юрий]

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

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

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

 

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

 

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

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

 

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

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

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

 

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

 

ЗЫ

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

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

 

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

[adeep]

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

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

[Бонарь Юрий]

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

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

 

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

 

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

 

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

 

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

[Setevoy]

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

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

 

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

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

[zaborovsky]

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

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

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

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

Відредаговано 1 червня, 2012 andytg

[adeep]

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

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

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

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

[Бонарь Юрий]

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

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

 

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

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

 

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

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

 

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

 

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

[Бонарь Юрий]

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

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

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

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

 

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