Пробуем разобраться что такое Graceful Degradation

Что такое Graceful Degradation?

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

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

Почему важна плавная деградация?

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

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

Реализация деградации

Давайте рассмотрим некоторые стратегии для реализации плавной деградации:

Обработка исключений

Надежная обработка исключений — это первый шаг к постепенной деградации. Всякий раз, когда возникает ошибка, ваше приложение должно быть способно перехватывать ее и реагировать соответствующим образом. Это может означать отображение удобного для пользователя сообщения об ошибке, попытку альтернативной операции или возврат в безопасное состояние. Вот краткий пример на PHP:

Фича флаги

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

Функция IsEnabled проверяет, включен ли данный флаг. В этом случае, если флаг enable не установлен, приложение не будет выполнять код «тяжелой операции» и вместо этого будет корректно деградировать.

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

Как пример:
Вы можете отключить функционал оставления вывода комментарев к товару, но оставить возможность добавить товар в корзину, и совершить оплату заказа.

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

Умная деградация

Это хорошо когда вы обрабатываете все возможные варианты и делаете фолбеки. Так же хорошо когда у вас есть кнопка которая в случае проблем отключает всю не очень критичную для вашего сервиса функциональность. Но здесь есть ряд проблем.

Первая

Если говорить про try catch, то далеко не все можно замокать. Например обновление профайла пользователя не замокать на бэке. Хотя это и не очень важная  функция в большинстве случаев. И в целом не контролируемый процесс.

Вторая

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

Третья

Если мы опять говорим про фичефлаги, то возникает вопрос что конкретно мы отключаем. Можно сделать 1 флаг который отключает все не критичное, но тогда в самых незначительных инцидентах обрубается все, что даже не нужно обрубать. А если делать много фичефлагов под разные ситуации, то нужно вспоминать, и не запутаться в выключаемых фичах, что может потребовать больше времени для координации.

Так какое решение?

А решение — это автоматическое управление деградацией. Да, задача не из легких, особенно если у вас микросервисвная архитектура в которой около 200 сервисов.

По сути это про умный фичефлаг. Он должен на основе данных из системы мониторинга управлять включением и отключением разного рода фитчефлага.

Это сложная и комплексная тема, я не буду описывать ее в данной статье, возможно сделаю это позже на какой нибудь конференции.

Но вот о чем вам стоит подумать:

  1. Флапы алертов. Что будете делать если алерты у вас флапают?
  2. Как будете делать процесс прозрачным и согласованным? Что будет если функционал на бэке отключится в одном сервисе, но не отключится в остальных, которе зависят от первого?
  3. Как вы будете измерять на сколько ваша система деградации эффективна
  4. Перед созданием такой системы, как понять на сколько у вас все плохо, и нужна ли вам такая система?
  5. Как контролировать уровни деградации