Каковы хорошие способы гарантировать непрерывность бизнеса с продуктом SaaS?

Question

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

Вам, вероятно, известны соглашения об условном депонировании исходного кода для «термоусадочной» программы. Они предоставляют клиентам доступ к исходному коду и всей соответствующей документации всякий раз, когда у поставщика программного обеспечения возникают (финансовые) проблемы. Это явно не работает для SaaS, потому что клиенты не используют только исходный код, и клиенты, вероятно, не могут позволить себе не иметь возможности войти в систему CRM в течение пары недель, потому что поставщик SaaS обанкротился. В настоящее время я изучаю различные методы решения этой проблемы.

Знаете ли вы хорошие и практические решения для решения этой проблемы непрерывности? Или компании, которые уже предлагают хорошее решение?

Спасибо!

Answer 1

Я думаю, вам нужно различать два случая:

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

Вопрос, который вы задаете, обычно возникает в контексте компании, которая рассматривает возможность использования услуг SaaS.В этих случаях разумная компания (как часть плана обеспечения непрерывности бизнеса) должна (а) убедиться в финансовой жизнеспособности поставщика (интересно, что большинство людей, отвечающих на этот вопрос, считают это основным риском), и (б) обеспечитьСамо собой, что у поставщика имеется адекватный план обеспечения непрерывности бизнеса, который обеспечит обслуживание в случае возникновения всех основных рисков.(Например, если в центре обработки данных произошел пожар, и его необходимо временно отключить, есть ли альтернатива. Он находится в режиме горячего резервирования? Дублируются ли данные? Сколько данных может быть потеряно? Может ли сетевой трафик быть перенаправлен?.)

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

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

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

Одним из показателей, позволяющих следить за будущим, может быть требование поставщика провести аудит плана обеспечения непрерывности бизнеса в соответствии с признанным стандартом (например, BS-25999).Возможно, мы увидим, что стандарты непрерывности бизнеса будут распространяться так же, как стандарты ISO-9000, поскольку каждая компания выдвигает требования сертификации своим критически важным поставщикам.

Удачи с тезисом.Вы выбрали интересную тему.Вы также можете задать свой вопрос в группе Журнал аварийного восстановления на LinkedIn .Это единственная действительно активная дискуссионная площадка по вопросам непрерывности бизнеса, которую я нашел.

Answer 2

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

Answer 3

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

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

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

Answer 4

Хороший вопрос.В компании SaaS, в которой я работал, я был в команде, которая разработала набор инструментов для внутреннего использования группой хостинга для быстрого развертывания установки клиента.Развертывание клиента было сложной процедурой, включающей тестовые / производственные сайты с 7-10 серверами на каждом.У нас также были процедуры для ночных резервных копий данных клиентов.

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

Answer 5

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

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

Answer 6

Как клиент SaaS, я очень зависим от таких услуг, как выставление счетов, электронная почта и отслеживание программных ошибок.До тех пор, пока я не ответил на этот вопрос, я не очень задумывался: я могу выйти из контракта в любое время, почему они не могут?С другой стороны: мои данные должны быть защищены.Я спросил своих поставщиков (не ожидая ответа от gmail в ближайшее время :-) и в то же время принял меры для частого резервного копирования.

Страшно: никто из моих провайдеров на самом деле не объясняет, что происходит подробно в их условиях обслуживания.Где мне ожидать такую ​​информацию?Где разработчик разместит такой текст?

Answer 7

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

Answer 8

Ну, мы делаем SaaS, но я не уверен, что руководство имеет дело с преемственностью. Я считаю, что наиболее распространенным положением дел является то, что поставщик SaaS ограничивает свои услуги и обязательства по контракту, чтобы им даже не приходилось об этом думать.

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

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