План непрерывности для SaaS: когда чужой сервис - ваша опора
SaaS ускоряет бизнес, но не отменяет обязанность готовиться к сбоям. Как думать о зависимостях от внешних сервисов.
За последние несколько лет компании перевели значительную часть своей операционной инфраструктуры на сторонние сервисы. CRM, финансовый учёт, коммуникации, управление проектами, хранение файлов, электронная почта - всё это теперь нередко работает на чужих серверах, по подписке, под чужим управлением.
Это рациональное решение. SaaS позволяет не заниматься инфраструктурой, не нанимать администраторов, не беспокоиться об обновлениях. Порог входа снижается, скорость развёртывания растёт.
Но у этого выбора есть обратная сторона, которую легко игнорировать, пока всё работает.
Что такое операционная зависимость
Когда сотрудник не может начать рабочий день без доступа к конкретному сервису - это операционная зависимость. Когда бизнес-процесс останавливается, если недоступен внешний инструмент - это тоже она.
Сама по себе зависимость не проблема. Проблема - зависимость без осознания и без плана.
В большинстве компаний, с которыми я работаю, нет чёткого ответа на простой вопрос: "Если сегодня в 9 утра этот сервис станет недоступен на 8 часов - что происходит?" Иногда ответ - "ничего страшного, подождём". Иногда - "всё встанет". Чаще всего ответа нет вообще, и это само по себе показательно.
Почему SaaS-сбои происходят
Провайдеры SaaS - это компании. Они испытывают технические сбои. Они проводят обслуживание. Они меняют ценовую политику или прекращают работу продукта. Их могут купить - и тогда условия меняются. На них может воздействовать регулятор. Они могут потерять финансирование и закрыться.
Ни одно из этих событий не является экзотическим. Все они происходили с реальными продуктами, на которые полагались реальные компании.
Вопрос не в том, произойдёт ли что-то из этого с вашим провайдером. Вопрос в том, готова ли ваша компания к хотя бы одному из этих сценариев.
Как подходить к оценке рисков
Простая классификация зависимостей помогает расставить приоритеты.
Первый вопрос - критичность. Что произойдёт, если этот сервис будет недоступен? Варианты: небольшое неудобство, замедление работы, частичная остановка процесса, полная остановка процесса. Чем выше критичность - тем больше внимания требует эта зависимость.
Второй вопрос - длительность. Насколько долгий сбой допустим? Час? День? Неделя? Это определяет, насколько серьёзным должен быть план резервирования.
Третий вопрос - альтернатива. Есть ли ручной способ выполнить ту же работу? Есть ли конкурирующий продукт, на который можно переключиться? Или зависимость настолько глубокая, что альтернативы нет в обозримые сроки?
Что входит в план непрерывности для SaaS
Полноценный план не обязан быть сложным. Для большинства компаний достаточно нескольких компонентов.
Инвентаризация зависимостей: список всех внешних сервисов, которые используются в критических процессах. Не весь список подписок - только те, без которых бизнес-процессы останавливаются или серьёзно замедляются.
Резервные копии данных: убедиться, что данные, которые живут в SaaS-продукте, регулярно экспортируются и хранятся в месте, которое контролирует ваша компания. Это касается прежде всего CRM, финансовых систем, баз клиентов.
Процедура на случай недоступности: простой документ на одну страницу для каждого критического сервиса. Кто оповещает команду? Что делается вручную на время недоступности? Кто принимает решение об эскалации?
Пересмотр контрактов: проверить, что написано в SLA о целевом времени восстановления и об ответственности провайдера при сбое. Это редко даёт юридическую защиту в полном смысле - но помогает понять, на что рассчитывать.
Несколько вопросов для начала
Если тема кажется абстрактной, вот конкретные вопросы:
- Какие три внешних сервиса, если они исчезнут сегодня, остановят работу компании?
- Есть ли у вас свежая копия данных из каждого из них, которая хранится у вас, а не у провайдера?
- Знает ли ваша команда, что делать в первые два часа при недоступности каждого из них?
- Когда вы последний раз проверяли актуальность этих планов?
Готовность к сбоям - это не паранойя. Это часть ответственного управления компанией, которая зависит от инструментов, работающих не на её серверах.