Режим критичности и автоматические выключатели

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

Мы склонны ориентироваться на особенности и в первую очередь смотрим на успешное развитие нашего программного обеспечения. Это имеет прямое отношение к принципу Парето:

Было… обнаружено, что в целом 80% определенного программного обеспечения можно написать за 20% от общего выделенного времени. И наоборот, самые сложные 20% кода занимают 80% времени.

И одновременно:

… Microsoft отметила, что путем исправления 20% самых распространенных ошибок 80% связанных ошибок и сбоев в данной системе будут устранены.

Сейчас не сказано, что эти 20% первого утверждения полностью совпадают со вторым, но, по крайней мере, здесь есть корреляция. Те 20%, которые «нужно сделать правильно», отнимают 80% нашего времени и склонны к сокращению.

Один из этих ярлыков часто бывает рассчитан на неудачу. Мы часто забываем о том, что должно произойти, если наше решение не сработает так, как задумано. Это проблема, потому что, например, полное отключение стоит реальных денег (конверсий) и может серьезно ухудшить ваш общественный имидж и уровень удержания.

Режим критичности

Неудача может проявляться по-разному и по многим причинам. Это делает так, что вам нужно будет вытаскивать вилки из розетки на макроуровне. В случае интернет-магазина вы можете реализовать три уровня:

Критичность зеленый

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

Оранжевый критичность

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

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

Criticality Red

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

Это первая и самая простая реализация режима критичности. Для этого вам нужно создать:

  • выберите случайного облачного провайдера, отличного от того, на котором вы размещаете свои операции (вы захотите это, когда, например, вы случайно запустили терраформу, которая удалила жизненно важные операционные части вашей операции)
  • ежедневно планировать рекурсивную команду wget для вашей домашней страницы, которая записывает свой вывод в корзину хранилища
  • убедитесь, что wget отправляет заголовок при сканировании. Вроде x-criticality-mode: red.
  • сделайте первый проход по вашему решению и настройте интерактивную логику так, чтобы она не отображалась (без призывов к действию для добавления в корзину, без корзины и тому подобного).
  • настроить отображение баннера вверху страницы, чтобы проинформировать пользователя в случае предоставления заголовка.
  • Настройте балансировщик нагрузки на маршрутизацию - в зависимости от предпочтительного режима критичности - всего внешнего трафика к статической корзине. Каждый ответ должен быть снабжен заголовком без кеширования, который позволяет при необходимости быстро вернуться из этого режима.

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

Предохранители

Схема проектирования автоматического выключателя сводится к следующему:

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

Таким образом, вместо того, чтобы создавать все больше и больше соединений, которые не могут быть разрешены, приводя к отключению всего вашего стека (из-за тайм-аутов и нагромождения), вы начинаете заранее информировать пользователя о том, что функциональность не соответствует ожидаемой.

Это имеет некоторые последствия:

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

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

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

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

  • Каждая функция должна быть указана
  • На каком уровне критичности должна быть показана эта функция? (Зеленый = только при полной работоспособности, Оранжевый = критически важная функция, красный = можно сканировать и не имеет интерактивных функций (или удаляется при сканировании))
  • Каково целевое состояние функции? (Зеленый = функция работает нормально, оранжевый = запускает автоматический выключатель, красный = отключение функции от внешнего трафика).

Эта установка позволяет вам:

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