Какие риски проверить владельцу сервиса на случай отключения от сервера
После сбоя Yandex Cloud автор разбирает риски владельца сервиса: отказ всей системы, долгое восстановление из копии и разрыв между SLA провайдера и обязательствами перед клиентами.
В тему прошлого поста, давайте обсудим, что подстраховать владельцу сервиса, если сервис отключат от сервера? Представьте: у клиентов не проходят платежи, поддержка отвечает на одни и те же вопросы, а команда пытается понять, когда всё заработает. И в этот момент кто-то спрашивает: «А что мы клиентам по договору обещали?»
После октябрьского сбоя Yandex Cloud я бы начала именно с этого вопроса. Вот какие риски стоит проверить, пока сервис работает.
1. Одна авария останавливает весь сервис
Сайт может открываться, а пользователи при этом не могут войти, оформить заказ или оплатить его. Для клиента сервис уже не работает. План «если что, поднимемся на соседней площадке» зависит еще и от того, дадут ли вам там нужные мощности. По сообщениям некоторых клиентов, получить оперативно сервер у соседнего провайдера в критический момент смогли не все.
Что сделать. Выпишите, от чего зависят вход, оплата и другие критичные функции. Проверьте, сможет ли резервная площадка запуститься, если основная недоступна вместе с панелью управления.
2. Копия есть, а восстановить сервис не получается
Допустим, база копируется раз в сутки. Если сбой случится вечером, при восстановлении из ночной копии можно потерять почти весь день заказов.
Что сделать. Закрепите во внутренних документах, кто делает копии и кто отвечает за восстановление. Потом попробуйте развернуть копию на отдельной площадке и засеките время до момента, когда снова можно, например, принять заказ.
3. Клиенту пообещали больше, чем может обеспечить сервис
Вы гарантировали восстановление за два часа. Поддержка провайдера обещала за два часа ответить. Разницу между этими обещаниями придется закрывать вам. И сам по себе сбой подрядчика не освобождает от обязательств перед клиентом. (см. ст. 401 и 403 ГК РФ.)
Что сделать. Сверьте клиентский договор с гарантиями провайдера. В договоре пропишите:
- какие функции охватывает гарантия и как считается простой;
- когда и по какому каналу вы сообщаете о сбое;
- как рассчитывается компенсация и что происходит при длительной недоступности;
- какой лимит ответственности действует в договоре с бизнесом.
С потребителями условия проверяем отдельно: их права защищены законом о защите прав потребителей. (см. ст. 15 ГК РФ и статья 16 Закона о защите прав потребителей).
4. Потери придется оплачивать из своего кармана
Срочный переезд, расходы на восстановление, перерасчеты клиентам. А по общему SLA серверных компаний предоставляет компенсацию в виде скидки на облачные услуги.
Что сделать. Прикиньте, сколько вам стоит час простоя, и сравните эту сумму со стоимостью резерва. Возможно, для отчетов достаточно восстановления к следующему утру, а для приема платежей резерв нужен уже сейчас. Заодно назначьте человека, который подаст запрос провайдеру, пока остальные заняты восстановлением. Это предусматриваем во внутренних документах компании.
5. Когда всё починили, выясняется, что доказательства не сохранили
На странице провайдера есть сообщение об аварии. А когда именно перестали проходить ваши платежи? Какие заказы отменились, а какие клиенты оформили позднее? Во сколько обошлось восстановление? Через неделю собирать это по чатам — отдельный квест.
Что сделать. Фиксируйте время сбоя, затронутые функции, обращения в поддержку и расходы. Заранее договоритесь, кто сообщает клиентам о проблеме и где они увидят обновления, если личный кабинет тоже недоступен. Лучше всего завести журнал инцидента и вести его, когда сбой уже случится. Чек-лист что собрать заранее и в процессе нужно будет прописать.
Некоторые компании проводят учения по подобным ситуациям. Чтобы понять как среагирует команда, где есть дыры в процессах. В критической ситуации команда будет знать что делать, это здорово сэкономит возможные убытки.
Если ваш сервис ляжет сегодня вечером, кто сможет переключить его на резерв и сколько времени это займет?