При сбое легко договориться: пусть продукт хотя бы частично работает. Гораздо труднее ответить, что именно означает «работает». Показать человеку каталог оборудования ещё можно. Подтвердить бронь на основании вчерашнего остатка — уже совсем другое обещание.
Graceful degradation, управляемая деградация, сохраняет полезную часть продукта при ограничениях. Это требует заранее определить доступные операции, качество данных и поведение интерфейса. Просто скрыть сообщение об ошибке недостаточно: пользователь может уйти с уверенностью, что система выполнила то, чего на самом деле не было.
Второстепенность зависит от конкретного действия
Возьмём условный сервис аренды оборудования. Персональные рекомендации можно убрать, а каталогу позволить работать. Но поиск не обязательно второстепенен: для клиента без прямой ссылки он может быть единственным способом найти нужную модель. Универсальный список «всё это отключаем первым» быстро оказывается бесполезным.
Нужен разбор пользовательских путей. Что необходимо для просмотра, что — для расчёта стоимости, что — для подтверждения брони? Какие сведения можно показать с оговоркой, а без каких действие запрещено? У этих вопросов разные ответы даже внутри одного экрана.
Иногда ограниченный режим позволяет только читать уже подтверждённые документы. Иногда можно сохранить черновик новой заявки, не обещая исполнения. Если критическое действие нельзя выполнить корректно, понятный отказ остаётся нормальным результатом. Неполная доступность лучше полной остановки лишь там, где оставшаяся функция действительно полезна и не вводит человека в заблуждение.
В интерфейсе должны различаться неизвестность и отсутствие
Сервис не получил данные о доступности. Показать ноль свободных единиц — значит сообщить неподтверждённый факт. Показать «доступность сейчас не проверена» — честно обозначить состояние. Для решений клиента это принципиальная разница.
То же относится к кэшу. Дата последнего успешного обновления должна означать свежесть исходных данных, а не время, когда их повторно положили в локальное хранилище. Прочитанная секунду назад копия может содержать вчерашний результат. Для описания оборудования это допустимо, для обещанной цены или подтверждения резерва — не всегда.
Ограничения стоит объяснять рядом с действием: что доступно, что сохранено и чего ещё не произошло. Одной общей полосы «технические работы» часто мало. Пользователь, получивший номер заявки, должен понимать, является ли это подтверждением брони или только подтверждением приёма обращения.
Отдельный режим интерфейса и информирование пользователей входят в рекомендации Azure по graceful degradation. Но конкретное содержание уведомления зависит от обещания самого продукта.
Запасной путь тоже нуждается в мощности
Если недоступен быстрый поиск, можно попробовать запрашивать основную базу напрямую. Для одного клиента решение сработает. Для всех клиентов сразу оно может перегрузить базу, которой пользуется и подтверждение броней. Так запасной путь превращает неудобство в более серьёзный отказ.
Поэтому надо проверять не только правильность альтернативного ответа, но и его стоимость при массовом включении. Иногда безопаснее вернуть сокращённый заранее подготовленный набор данных, чем запускать более тяжёлую замену основного механизма. Риски редко используемых запасных реализаций разобраны в Amazon Builders’ Library.
Скрыть блок на странице тоже мало, если сервер продолжает вычислять его содержимое. Ограниченный режим должен действительно убирать ненужные обращения и расходы ресурсов. Изоляция ресурсов помогает защитить оставшуюся работу; сама надпись «упрощённый режим» ничего не изолирует.
Некоторые проверки отключать нельзя
Недоступность проверки прав не даёт основания показывать закрытые документы всем подряд. Невозможность проверить остаток не разрешает подтверждать один и тот же предмет нескольким клиентам. Упрощать следует функциональность, а не незаметно отменять правила доступа и корректности.
Если продукт умеет принимать отложенные заявки, они должны надёжно сохраняться с идентификатором, статусом и условиями дальнейшей обработки. Очередь при этом ограничена. Бесконечное обещание «сделаем позже» создаёт обязательства быстрее, чем компания сможет их выполнить после восстановления.
Нужно также решить, когда истекает смысл заявки и как пользователь её отменяет. Например, запрос на аренду к уже прошедшему времени нельзя автоматически превратить в подтверждённую бронь только потому, что зависимость наконец заработала. Восстановление требует проверки актуального состояния, а не механического воспроизведения всех накопленных команд.
Как включать режим и как из него выходить
Часть ограничений можно включать автоматически по устойчивому признаку сбоя. Другие меняют условия обслуживания настолько, что требуют решения ответственного за продукт или инцидент. Полномочия, условия включения и способ ручного управления нужно определить до аварии.
Сам переключатель не должен зависеть исключительно от того компонента, который он призван обойти. Если отказ общего сервиса конфигурации одновременно лишает возможности включить ограниченный режим, запасной сценарий доступен только в хорошие дни. Стоит предусмотреть безопасное локальное поведение при недоступности управляющей системы.
Возвращение тоже лучше делать контролируемо. Если одновременно открыть полную функциональность и выпустить весь накопленный поток, зависимость может снова перестать справляться. Отдельно проверяют восстановление интерактивной работы, постепенную обработку отложенных заявок и повторную сверку статусов. У режима должен быть владелец: иначе временно отключённая функция способна остаться выключенной надолго.
Во время ограниченного режима измеряйте затронутые пользовательские сценарии отдельно. Успешная загрузка страницы не означает доступность её основного действия. Если эта разница пропадёт из отчётности, команда сможет месяцами показывать хорошую доступность сервиса, в котором часть клиентов не получает нужный результат.
Проверка на обычном рабочем сценарии
Попросите сотрудника выполнить задачу при отключённой зависимости: найти оборудование, открыть существующую бронь, сохранить новое обращение. Дайте ему только тот интерфейс, который увидит клиент, без подсказок инженера. Сможет ли он правильно объяснить, что уже подтверждено, а что ждёт проверки?
Затем восстановите зависимость и проследите судьбу отложенных действий. Проверка закончена, когда понятны результат для клиента, неисполненные обязательства и оставшиеся ограничения, а не когда на техническом дашборде исчезла последняя красная лампочка.