Бонарь Юрий 13 Опубликовано: 2012-05-16 11:32:35 Share Опубликовано: 2012-05-16 11:32:35 Хочу немного поинтересоватся у владельцев, сотрудников и всех желающих высказать своё мнение по теме использованиее SaaS в работе и обслуживании ISP провайдера. Програмное обеспечение для учёта, анализа, статистики, биллинга и т.д. всё что в целом может использоватся провайдерами телеком услуг. Рассматирваете ли Вы подобную модель использование програмного обеспечения? есть недоверие? и тому подобное. Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2012-05-16 12:01:45 Share Опубліковано: 2012-05-16 12:01:45 Основная проблема использования удаленного биллинга - это вынесение коммерческой и персональной информации за пределы контролируемой зоны оператора. Мало кто согласится на это. Ссылка на сообщение Поделиться на других сайтах
Setevoy 127 Опубліковано: 2012-05-16 12:05:09 Share Опубліковано: 2012-05-16 12:05:09 Основная проблема использования удаленного биллинга - это вынесение коммерческой и персональной информации за пределы контролируемой зоны оператора. Мало кто согласится на это. К тому же плюсы от использования такой схемы - минимальны. В основном на этапе внедрения. В непровайдерском SaaS может стать весомым уменьшение затрат на поддержку. Но у провайдера в любом случае должен быть штатный админ. Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-05-16 12:43:29 Автор Share Опубліковано: 2012-05-16 12:43:29 Основная проблема использования удаленного биллинга - это вынесение коммерческой и персональной информации за пределы контролируемой зоны оператора. Мало кто согласится на это. Согласен. А как обстоят дела с сотрудниками которые по сути могу слить информацию по биллингу? В мелких и средних помоему этому вопросу мало кто уделяет внимание. Вопрос ведь еще в цене + поддержка, у многих я думаю бывали проблемы когда сервера с биллингом давали сбои и это вызывало немало хлопот. Для биллинга и т.д. по хорошему надо иметь отдельного человека который будет обеспечивать работу таких систем 24/7. Но по части биллинга согласен. Ну а остальной софт, не имеющий прямого отношения к информации по финансам? Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-05-16 12:48:38 Автор Share Опубліковано: 2012-05-16 12:48:38 Основная проблема использования удаленного биллинга - это вынесение коммерческой и персональной информации за пределы контролируемой зоны оператора. Мало кто согласится на это. К тому же плюсы от использования такой схемы - минимальны. В основном на этапе внедрения. В непровайдерском SaaS может стать весомым уменьшение затрат на поддержку. Но у провайдера в любом случае должен быть штатный админ. Админ должен быть однозначно. Но любой софт надо регулярно обновлять и расширять функционал что бы соответствовать потребностям. А почему только на этапе внедрения? А как же поддержание софта в рабочем состоянии 24/7. Это ведь требует затрат в плане обеспечения отказоустойчивости железа, сервисов + постоянный мониторинг. Ссылка на сообщение Поделиться на других сайтах
Setevoy 127 Опубліковано: 2012-05-16 13:29:40 Share Опубліковано: 2012-05-16 13:29:40 Основная проблема использования удаленного биллинга - это вынесение коммерческой и персональной информации за пределы контролируемой зоны оператора. Мало кто согласится на это. К тому же плюсы от использования такой схемы - минимальны. В основном на этапе внедрения. В непровайдерском SaaS может стать весомым уменьшение затрат на поддержку. Но у провайдера в любом случае должен быть штатный админ. Админ должен быть однозначно. Но любой софт надо регулярно обновлять и расширять функционал что бы соответствовать потребностям. А почему только на этапе внедрения? А как же поддержание софта в рабочем состоянии 24/7. Это ведь требует затрат в плане обеспечения отказоустойчивости железа, сервисов + постоянный мониторинг. В плане железа любой оператор уже решает этот вопрос для ядра сети вне зависимости от биллинга. В плане стабильности работы софта - в случае собственного админа можно хоть как-то риски оценить (уровень знаний, возможность позвонить ему среди ночи либо выделенный ночной админ итд). В случае SaaS остаётся только верить красивым рекламным буклетам. Аналогично, кстати, и вопрос бекапа - админ знает что, куда и как часто бекапит. А если что не так - сам себе злобный буратино. Есть риск, что SaaS-провайдер понимает резервное копирование как зеркало на 2 диска в одном физическом корпусе, "а пожара быть не может потому как пожарники продали сертифицированный огетушитель". Утрирую, конечно. В случае багов софта, допущенных разработчиками - фиксить их должны разработчики. А они что в SaaS, что в традиционном биллинге одинаковы - со своими авралами и обеденными перерывами. Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-05-16 14:04:07 Автор Share Опубліковано: 2012-05-16 14:04:07 Основная проблема использования удаленного биллинга - это вынесение коммерческой и персональной информации за пределы контролируемой зоны оператора. Мало кто согласится на это. К тому же плюсы от использования такой схемы - минимальны. В основном на этапе внедрения. В непровайдерском SaaS может стать весомым уменьшение затрат на поддержку. Но у провайдера в любом случае должен быть штатный админ. Админ должен быть однозначно. Но любой софт надо регулярно обновлять и расширять функционал что бы соответствовать потребностям. А почему только на этапе внедрения? А как же поддержание софта в рабочем состоянии 24/7. Это ведь требует затрат в плане обеспечения отказоустойчивости железа, сервисов + постоянный мониторинг. В плане железа любой оператор уже решает этот вопрос для ядра сети вне зависимости от биллинга. В плане стабильности работы софта - в случае собственного админа можно хоть как-то риски оценить (уровень знаний, возможность позвонить ему среди ночи либо выделенный ночной админ итд). В случае SaaS остаётся только верить красивым рекламным буклетам. Аналогично, кстати, и вопрос бекапа - админ знает что, куда и как часто бекапит. А если что не так - сам себе злобный буратино. Есть риск, что SaaS-провайдер понимает резервное копирование как зеркало на 2 диска в одном физическом корпусе, "а пожара быть не может потому как пожарники продали сертифицированный огетушитель". Утрирую, конечно. В случае багов софта, допущенных разработчиками - фиксить их должны разработчики. А они что в SaaS, что в традиционном биллинге одинаковы - со своими авралами и обеденными перерывами. Договор? соглашение? технические регламенты. или всё же это реалии нашего рынка где все боятся и недоверяют друг-другу? ))) Каналы покупаем(полагаемся на рекламные буклеты + отзывы и т.д.), сотрудника на работу берем доверяем часть коммерческой информации которая по сути может легко утекать куда угодно. Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2012-05-16 14:10:05 Share Опубліковано: 2012-05-16 14:10:05 Основная проблема использования удаленного биллинга - это вынесение коммерческой и персональной информации за пределы контролируемой зоны оператора. Мало кто согласится на это. Согласен. А как обстоят дела с сотрудниками которые по сути могу слить информацию по биллингу? В мелких и средних помоему этому вопросу мало кто уделяет внимание. Вопрос ведь еще в цене + поддержка, у многих я думаю бывали проблемы когда сервера с биллингом давали сбои и это вызывало немало хлопот. Для биллинга и т.д. по хорошему надо иметь отдельного человека который будет обеспечивать работу таких систем 24/7. Но по части биллинга согласен. Ну а остальной софт, не имеющий прямого отношения к информации по финансам? Вопрос с сотрудниками решается внутри компании в контролируемой зоне, а как проконтролировать SaaS? Для биллинга и т.д. по хорошему надо иметь 100% резерв по железу и бэкапам и с этим вполне справится штатный админ. Но тут всплывает вопрос: а кто мешает непосредственно сервер с биллингом отдать на поддержку аутсорс? Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-05-16 14:37:20 Автор Share Опубліковано: 2012-05-16 14:37:20 Основная проблема использования удаленного биллинга - это вынесение коммерческой и персональной информации за пределы контролируемой зоны оператора. Мало кто согласится на это. Согласен. А как обстоят дела с сотрудниками которые по сути могу слить информацию по биллингу? В мелких и средних помоему этому вопросу мало кто уделяет внимание. Вопрос ведь еще в цене + поддержка, у многих я думаю бывали проблемы когда сервера с биллингом давали сбои и это вызывало немало хлопот. Для биллинга и т.д. по хорошему надо иметь отдельного человека который будет обеспечивать работу таких систем 24/7. Но по части биллинга согласен. Ну а остальной софт, не имеющий прямого отношения к информации по финансам? Вопрос с сотрудниками решается внутри компании в контролируемой зоне, а как проконтролировать SaaS? Для биллинга и т.д. по хорошему надо иметь 100% резерв по железу и бэкапам и с этим вполне справится штатный админ. Но тут всплывает вопрос: а кто мешает непосредственно сервер с биллингом отдать на поддержку аутсорс? Идея SaaS улучшение качества сервиса провайдера, уменьшение затрат на обслуживание. На практике всё конечно бывает по разному. Договор, всё как положено с печатями т.д. Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2012-05-16 14:46:05 Share Опубліковано: 2012-05-16 14:46:05 (відредаговано) Идея SaaS улучшение качества сервиса провайдера, уменьшение затрат на обслуживание. На практике всё конечно бывает по разному. Договор, всё как положено с печатями т.д. Я собственно пояснил основные причины почему нет. В данных условиях SaaS приемлем только, если все железо находится внутри компании и никакие данные не передаются за пределы ее. Вы пойдете на такие условия? Відредаговано 2012-05-16 14:47:34 adeep Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-05-16 15:41:59 Автор Share Опубліковано: 2012-05-16 15:41:59 Идея SaaS улучшение качества сервиса провайдера, уменьшение затрат на обслуживание. На практике всё конечно бывает по разному. Договор, всё как положено с печатями т.д. Я собственно пояснил основные причины почему нет. В данных условиях SaaS приемлем только, если все железо находится внутри компании и никакие данные не передаются за пределы ее. Вы пойдете на такие условия? С биллингом лично я бы дважды подумал, остальной софт. В идеале хотелось бы что бы всё своё. Но основная цель зарабатывать деньги, предоставлять сервис. Если это выгодно значит можно рассматривать. Ну вот к примеру есть софт для рисования оптики, стоит он так 3к. Многие готовы заплатить сходу ннную сумму денег? Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2012-05-16 15:50:13 Share Опубліковано: 2012-05-16 15:50:13 Вы же различайте критические сервисы и пользовательские. Оттого что софт для рисования будет недоступен полчаса максимум работы на кабеле на полчаса приостановятся и то не факт. А если биллинг выпадет на 5 минут? Ссылка на сообщение Поделиться на других сайтах
Setevoy 127 Опубліковано: 2012-05-16 19:24:28 Share Опубліковано: 2012-05-16 19:24:28 В плане железа любой оператор уже решает этот вопрос для ядра сети вне зависимости от биллинга. В плане стабильности работы софта - в случае собственного админа можно хоть как-то риски оценить (уровень знаний, возможность позвонить ему среди ночи либо выделенный ночной админ итд). В случае SaaS остаётся только верить красивым рекламным буклетам. Аналогично, кстати, и вопрос бекапа - админ знает что, куда и как часто бекапит. А если что не так - сам себе злобный буратино. Есть риск, что SaaS-провайдер понимает резервное копирование как зеркало на 2 диска в одном физическом корпусе, "а пожара быть не может потому как пожарники продали сертифицированный огетушитель". Утрирую, конечно. В случае багов софта, допущенных разработчиками - фиксить их должны разработчики. А они что в SaaS, что в традиционном биллинге одинаковы - со своими авралами и обеденными перерывами. Договор? соглашение? технические регламенты. SaaS-провайдер в договоре обяжется компенсировать оператору прямые и косвенные убытки, полученные вследствие простоя? Ссылка на сообщение Поделиться на других сайтах
martin 170 Опубліковано: 2012-05-17 07:48:21 Share Опубліковано: 2012-05-17 07:48:21 SaaS-провайдер в договоре обяжется компенсировать оператору прямые и косвенные убытки, полученные вследствие простоя? конечно, в договоре только будет походу пунктик - стихійні лиха, треті сили... И туда можно будет списать васю тракториста порвавшего кабель или Ддос ... Вобщем печально это все. Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-05-17 12:24:54 Автор Share Опубліковано: 2012-05-17 12:24:54 SaaS-провайдер в договоре обяжется компенсировать оператору прямые и косвенные убытки, полученные вследствие простоя? конечно, в договоре только будет походу пунктик - стихійні лиха, треті сили... И туда можно будет списать васю тракториста порвавшего кабель или Ддос ... Вобщем печально это все. Печально конечно. К примеру размещая свой сервер на площадке ДЦ мы находимся в аналогичной ситуации. На сервере находятся данные(возможно и важные) и как то все покупают, работают. У нас на тех. площадке в ДЦ Германии клиенты размещают свои корпоративные сервера, и тоже можно сказать риски и т.д. Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2012-05-17 13:26:04 Share Опубліковано: 2012-05-17 13:26:04 К примеру размещая свой сервер на площадке ДЦ мы находимся в аналогичной ситуации. На сервере находятся данные(возможно и важные) и как то все покупают, работают. У нас на тех. площадке в ДЦ Германии клиенты размещают свои корпоративные сервера, и тоже можно сказать риски и т.д. Вы опять путаете теплое с мягким. Клиент разместил свой физический сервер с тем софтом, который он знает. Это его осознанный выбор. Вы предлагаете клиенту разместить его информацию у себя в черном ящике. Это совершенно разные риски. Ссылка на сообщение Поделиться на других сайтах
Setevoy 127 Опубліковано: 2012-05-17 13:34:16 Share Опубліковано: 2012-05-17 13:34:16 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/ Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-05-31 20:26:01 Автор Share Опубліковано: 2012-05-31 20:26:01 SaaS-провайдер в договоре обяжется компенсировать оператору прямые и косвенные убытки, полученные вследствие простоя? конечно, в договоре только будет походу пунктик - стихійні лиха, треті сили... И туда можно будет списать васю тракториста порвавшего кабель или Ддос ... Вобщем печально это все. Печально конечно. К примеру размещая свой сервер на площадке ДЦ мы находимся в аналогичной ситуации. На сервере находятся данные(возможно и важные) и как то все покупают, работают. Большая проблема при использовании SaaS - нарваться на провайдера, у которого планирование доступности и резервирования сводится к "как-то же все работают...". У нас на тех. площадке в ДЦ Германии клиенты размещают свои корпоративные сервера, и тоже можно сказать риски и т.д. Может быть, они подняли ещё один дублирующий сервер в другом датацентре на другом континенте, реплицируют все сессии и готовы в течении 15 секунд откатиться на него? А если они не готовы на это тратиться либо надеются на надёжность немецкого дата-центра, то они знают о существующем риске и сознательно на него идут, готовы нести ответственность. Может, вам посмотреть в строну чего-то не mission critical? Там у SaaS шансов больше. "Не работает? Ой, яка халепа.... Ладно, пойду пока чаю попью". ЗЫ http://arstechnica.c...hacked-webhost/ http://aws.amazon.com/message/65648/ Ну хорошо допустим с биллингом всё сложно. Но к примеру софт для мониторинга и анализа работы сети? Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2012-06-01 06:59:59 Share Опубліковано: 2012-06-01 06:59:59 Ну хорошо допустим с биллингом всё сложно. Но к примеру софт для мониторинга и анализа работы сети? Как вы себе представляете мониторинг и анализ работы сети, отвязанный от работы сети? Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-06-01 08:25:41 Автор Share Опубліковано: 2012-06-01 08:25:41 Ну хорошо допустим с биллингом всё сложно. Но к примеру софт для мониторинга и анализа работы сети? Как вы себе представляете мониторинг и анализ работы сети, отвязанный от работы сети? Всё относительно, проблем никто не исключает. Если у Вас умер сервер с cacti, nagios вы же однозначно не увидите всей картины что вобще случилось и мониторинг Ваш будет неработоспособный. Я думаю Вы и сами знаете проблемы которые могут случится и при которых никакой мониторинг не спасет. Интеграция любого решения требует правильного планирования. Рынок требует повышения качества предоставляемых услуг, оперативная работа с клиентами, снижение стоимости обслуживания и эксплуатации, быстрая адаптация под изменение рынка и потребностей клиентов. Ссылка на сообщение Поделиться на других сайтах
Setevoy 127 Опубліковано: 2012-06-01 10:11:41 Share Опубліковано: 2012-06-01 10:11:41 Рынок требует повышения качества предоставляемых услуг, оперативная работа с клиентами, снижение стоимости обслуживания и эксплуатации, быстрая адаптация под изменение рынка и потребностей клиентов. Все эти абстрактные рассказы о "вебдваноль в облаке" хавают бизнеса. Здесь же сидят большей частью технари. ЗЫ Может, что-то вроде учета заявок на подключение и обслуживание, координация и контроль работы монтажников, учет материалов и планирование их закупок? Как мысль навскидку. При выпадении этого добра вам, конечно, моск выедят, но критических потерь не будет. Ссылка на сообщение Поделиться на других сайтах
zaborovsky 359 Опубліковано: 2012-06-01 11:28:00 Share Опубліковано: 2012-06-01 11:28:00 (відредаговано) из известных мне примеров: у Ланета сервис технического форума rada.lanet.ua предоставляется вот этой службой http://copiny.com/ это именно облачный сервис других примеров применительно к ISP не встречал. upd: ну, еще у Воли почта предоставляется Яндексом, разве что.... Відредаговано 2012-06-01 11:30:15 andytg Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2012-06-01 11:45:53 Share Опубліковано: 2012-06-01 11:45:53 Ну хорошо допустим с биллингом всё сложно. Но к примеру софт для мониторинга и анализа работы сети? Как вы себе представляете мониторинг и анализ работы сети, отвязанный от работы сети? Всё относительно, проблем никто не исключает. Если у Вас умер сервер с cacti, nagios вы же однозначно не увидите всей картины что вобще случилось и мониторинг Ваш будет неработоспособный. Вам же говорят - откажитесь от идеи внешней облачности критических структур. Биллинг, мониторинг и обеспечение сети относятся именно к ним. Если их и загонять в облако, то это облако должно быть внутренним (= внутри компании) и закрытым. Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-06-01 14:01:00 Автор Share Опубліковано: 2012-06-01 14:01:00 Рынок требует повышения качества предоставляемых услуг, оперативная работа с клиентами, снижение стоимости обслуживания и эксплуатации, быстрая адаптация под изменение рынка и потребностей клиентов. Все эти абстрактные рассказы о "вебдваноль в облаке" хавают бизнеса. Здесь же сидят большей частью технари. ЗЫ Может, что-то вроде учета заявок на подключение и обслуживание, координация и контроль работы монтажников, учет материалов и планирование их закупок? Как мысль навскидку. При выпадении этого добра вам, конечно, моск выедят, но критических потерь не будет. Тоесть покупать канал или транспорт это нормально? рисков нету? и моск никто не будет кушать из за проблем? То что сгорит БП на сервере и в течении какого либо времени сервисы будут лежать и работа фирмы встанет это тоже нормально? Давайте рассматривать чем в ответственности представители SaaS сервива отличаются от сотрудника Вашей компании который допустим может что либо повердить? Может всё же дело в доверии нашего рынка к подобного рода решениям? или просто не готовность нашего рынка? Ссылка на сообщение Поделиться на других сайтах
Бонарь Юрий 13 Опубліковано: 2012-06-01 14:10:51 Автор Share Опубліковано: 2012-06-01 14:10:51 из известных мне примеров: у Ланета сервис технического форума rada.lanet.ua предоставляется вот этой службой http://copiny.com/ это именно облачный сервис других примеров применительно к ISP не встречал. upd: ну, еще у Воли почта предоставляется Яндексом, разве что.... По этому и создал тему изучаю данный вопрос. Зерно ведь есть, Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас