Деградация vs сбой

В чем разница между деградацией сервиса, перебоями в обслуживании и простоем сервиса и почему это имеет значение?

Оригинал: Degradation vs disruption

В контексте проектирования надежности есть три термина, которые связаны, но иногда используются неправильно.

Грубо говоря:

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

1. Доступность

Обычно сервис может выполнять несколько функций, например:

AWS включают в себя множество различных сервисов, таких как базы данных, очереди, IAM и т.д. Также есть некоторые другие функции, которые необходимы, такие как документация, условия предоставления услуг и другие (и некоторые из них требуются по закону), но не имеют никакого смысла без основных сервисов AWS. Не было бы документации, если бы не было сервисов AWS!

Основные функции - это те, которые движут бизнесом. Для GitHub это серверы git, для автомобиля - это возможность управлять автомобилем (и тормозами), а для блюда - съедобность! Сервис определяется основными функциями.

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

Например, в первые дни существования ChatGPT “Искусственный интеллект” не мог поддерживать беседу и случайным образом прерывался. Это - деградация сервиса, потому что, хотя это ухудшает пользовательский опыт, некоторые пользователи все еще могут пользоваться сайтом (или тот же пользователь, если он повторяет попытку).

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

Модели постепенного ухудшения (graceful degradation) (такие как fallback) могут временно переключаться на использование альтернативной стратегии сохранения обеспечения непрерывности бизнеса.

Когда ключевые функции полностью отключены, происходит перебой в обслуживании (disruption).

Например, во время сбоя в работе AWS S3, который произошел в 2017 году, все запросы GET, LIST, PUT и DELETE завершались неудачно, что сделало этот сервис полностью бесполезным. Это также повлияло на другие сервисы AWS, которые внутренне зависели от S3.

2. Уровень обслуживания

Если вы измеряете надежность с помощью SLI (например, задержку, частоту ошибок, свежесть данных и т.д.):

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

Однако, поскольку основные функции службы git остались нетронутыми, технически это не было сбоем в работе службы.

3. Радиус поражения

Одним из определяющих факторов, позволяющих провести различие между ухудшением качества обслуживания и перебоями в работе, является вопрос:

Кого затрагивает эта проблема?

Это только некоторые пользователи? Или сразу все? Это платные клиенты? Или бесплатные клиенты?

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

Например, многие облачные провайдеры используют разделение с использованием отдельных центров обработки данных (регионов), чтобы разделить риски и локализовать их. Если Microsoft Azure выйдет из строя в регионе Южной Индии (Ченнаи), это не повлияет на службы, работающие в других регионах.

Но если в это время проводится крупный матч по крикету, это потенциально может привести к массовому размещению бесплатной рекламы для AWS — причем далеко не позитивной!

Другой пример - когда проблема затрагивает только подгруппу клиентов:

4. Последствия

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

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

Одним из основных моментов при определении уровней обслуживания является смена перфекционистского мышления на признание того, что сложные системы постоянно дают сбои, поэтому давайте определим, что определяет сбой (SLI), а что является разумным ожиданием (SLO) и какой ценой (см. Правило 10x/9)

Отключение сервиса (Service Outage)

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

Однако слово "отключение" обычно имеет более драматическое значение и используется для обозначения более длительных и серьезных сбоев с тяжелыми последствиями. Например: штрафы за нарушение SLA, потери (продажи, выручка, пользователи и т.д.), или юридические последствия (несчастные случаи, травмы и т.д.).

Как долго и насколько серьезно? Это зависит от типа продукта, ожиданий клиента и склонности к риску:

Заключение

Обеспечение надежности направлено на предотвращение того, чтобы угрозы переросли в деградацию, а деградация - в нарушение работы.

Итак, деградация лучше, чем разрушение? У меня к вам вопрос:

Подумайте об интернет-магазине. Что из этого оказывает более негативное влияние на бизнес?

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

Иногда лучше нарушить работу сервиса, чем ухудшить его качество. Нюансы зависят от контекста, бизнес-модели, толерантности к риску и т.д.

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