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

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

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

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

Заметки с полей

Дорого не всегда значит качественно

Мне нравится, как новые клиенты рассказывают мне о своих стратегиях аварийного восстановления, если они у них есть. Как гордые родители, они с энтузиазмом сообщают, сколько денег тратят на защиту данных клиентов и обеспечение бесперебойной работы. У меня был один клиент, который слишком доверял одной компании с названием из трех букв, и его ежегодные расходы на лицензии на ПО и оборудование превышали шестизначную сумму (в долларах). Его ожидания были высоки, и руководство верило, что, если оно столько платит, значит все в порядке. Все спокойно спали по ночам. Когда я начал задавать вопросы, оказалось, что всё не так радужно, и, если вкратце, в течение нескольких недель мы сократили расходы до четырехзначной цифры и создали конфигурацию, которая действительно работала и использовала AWS. Частая проблема: клиент слишком доверяет аутсорсингу, предполагая, что компания с названием из трех букв делает намного больше, чем есть на самом деле. Вопрос аварийного восстановления сложен, и это не то, что можно просто передать на аутсорсинг и забыть.

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

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