Рекомендации по определению целевых показателей надежности

Применяется к этой рекомендации по контрольным спискам надежности платформы Azure Well-Architected:

RE:04

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

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

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

Рассмотрите возможность использования следующих метрик для количественной оценки бизнес-требований.

Термин	Определение
Цель уровня обслуживания (SLO)	Целевой показатель в процентах, представляющий работоспособность компонента и уровень надежности. Чем выше уровень, тем надежнее компонент. Составное SLO представляет совокупный целевой объект всей рабочей нагрузки и учитывается для SLO компонентов.
Индикатор уровня обслуживания (SLI)	Метрика, выдаваемая службой. Метрики SLI агрегируются для количественной оценки значения SLO.
Соглашение об уровне обслуживания	Договорное соглашение между поставщиком услуг и клиентом службы. Соглашение определяет SLO. Несоблюдение соглашения может иметь финансовые последствия для поставщика услуг.
Среднее время восстановления (MTTR)	Время, затраченное на восстановление компонента после обнаружения сбоя.
Среднее время между сбоями (MTBF)	Продолжительность, в течение которой рабочая нагрузка может выполнять ожидаемую функцию без прерывания, пока она не завершается ошибкой.
Целевое время восстановления (RTO)	Это максимально допустимое время, в течение которого приложение может быть недоступно после инцидента.
Целевая точка восстановления (RPO)	Максимально допустимая продолжительность потери данных во время инцидента.

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

Ключевые стратегии проектирования

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

Рассмотрим пример сопоставления требований с измеримыми числовыми значениями. Заинтересованные лица подсчитали, что для критически важного потока пользователей час простоя в течение обычного рабочего времени приводит к потере X долларов ежемесячного дохода. Эта сумма в долларах сравнивается с предполагаемой стоимостью проектирования потока, который имеет доступность SLO 99,95 процента, а не 99,9 процента. Лица, принимающие решения, должны обсудить, перевешивает ли риск потери доходов дополнительные затраты и бремя управления, необходимые для защиты от него. Следуйте этому шаблону при изучении потоков и создании полного списка целевых объектов.

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

Требования к надежности и восстановлению самого высокого уровня, а также коррелированные метрики могут включать, например, доступность приложения 99,9 % для всех регионов или целевое RTO в 5 часов для региона Северной и Южной Америки. Определение этих типов целевых объектов помогает определить, какие критические потоки участвуют в этих целевых объектах. Затем можно рассмотреть целевые объекты на уровне компонентов.

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

Метрики доступности

Соглашения об уровне обслуживания и соглашения об уровне обслуживания

Метрики доступности коррелируют с SLO, которые используются для определения соглашений об уровне обслуживания. SLO рабочей нагрузки определяет допустимое время простоя в данный период, например менее 1 часа в месяц. Чтобы убедиться, что вы можете достичь целевого показателя SLO, ознакомьтесь с соглашениями об уровне обслуживания Майкрософт для каждого компонента. Обратите внимание на то, сколько избыточности необходимо для соблюдения высоких соглашений об уровне обслуживания. Например, корпорация Майкрософт гарантирует более высокие соглашения об уровне обслуживания для развертываний Azure Cosmos DB в нескольких регионах, чем для развертываний в одном регионе.

Примечание

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

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

Примечание

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

Составные соглашения об уровне обслуживания включают несколько служб, поддерживающих приложение, с разными уровнями доступности. Например, рассмотрим веб-приложение Служба приложений Azure, которое выполняет запись в базу данных Azure SQL. Гипотетически эти соглашения об уровне обслуживания могут быть следующими:

• Служба приложений веб-приложений = 99,95 процента
• База данных SQL = 99,99 процента

Какое максимальное время простоя можно ожидать для этого приложения? Если какая-либо из служб завершается ошибкой, приложение также прекращает работу. Вероятность сбоя каждой службы независима, поэтому составное соглашение об уровне обслуживания для этого приложения составляет 99,95 процента × 99,99 процента = 99,94 процента. Это значение ниже, чем отдельные соглашения об уровне обслуживания. Этот вывод неудивительно, так как приложение, использующее несколько служб, имеет больше потенциальных точек отказа.

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

В такой архитектуре приложение по-прежнему доступно, даже если ему не удается подключиться к базе данных. Однако он завершается ошибкой, если база данных и очередь завершаются сбоем одновременно. Ожидаемый процент времени одновременного сбоя составляет 0,0001 × 0,001, поэтому ниже приведено составное соглашение об уровне обслуживания для этого объединенного пути:

База данных или очередь = 1,0 − (0,0001 × 0,001) = 99,99999 %

Общее составное соглашение об уровне обслуживания:

Веб-приложение и (база данных или очередь) = 99,95 процента × 99,99999 процента = ~99,95 процента

Этот подход обеспечивает компромиссы:

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

Для развертываний с несколькими регионами составное соглашение об уровне обслуживания рассчитывается следующим образом:

• N — составное соглашение об уровне обслуживания для приложения, развернутого в одном регионе.

• R — количество регионов, в которых развернуто приложение.

Ожидаемая вероятность сбоя приложения во всех регионах одновременно составляет ((1 – N) ^ R). Например, если гипотетическое соглашение об уровне обслуживания для одного региона составляет 99,95 %, выполните следующие действия.

• Объединенное соглашение об уровне обслуживания для двух регионов = (1 − (1 – 0,9995) ^ 2) = 99,999975 %

• Объединенное соглашение об уровне обслуживания для четырех регионов = (1 − (1 − 0,9995) ^ 4) = 99,9999999 %

Определение соответствующих SLO требует времени и тщательного рассмотрения. Заинтересованные лица должны понимать, как ключевые клиенты используют приложение. Они также должны понимать допустимость надежности. Этот отзыв должен информировать целевые объекты.

Значения SLA

В следующей таблице определены общие значения SLA.

Соглашение об уровне обслуживания	Время простоя в неделю	Время простоя в месяц	Время простоя в год
99 %	1,68 часа	7,2 часа	3,65 дня
99,9 %	10,1 минуты	43,2 минуты	8,76 часа
99,95 %	5 минут	21,6 минуты	4,38 часа
99,99 %	1,01 минуты	4,32 минуты	52,56 минуты
99,999 %	6 секунд	25,9 секунды	5,26 минуты

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

Примечание

Рабочие нагрузки для клиентов и рабочие нагрузки для внутреннего использования имеют разные SLO. Как правило, рабочие нагрузки внутреннего использования могут иметь гораздо менее строгие SLO, чем рабочие нагрузки для клиентов.

SPI

Думайте о SLO как о метриках уровня компонентов, которые влияют на SLO. Наиболее важные SPI — это те, которые влияют на критические потоки с точки зрения ваших клиентов. Для многих потоков SPI включают задержку, пропускную способность, частоту ошибок и доступность. Хороший SLI помогает определить, когда SLO находится под угрозой нарушения. По возможности сопоставляйте SLI с конкретными клиентами.

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

Метрики восстановления

Целевые показатели восстановления соответствуют метрикам RTO, RPO, MTTR и MTBF. В отличие от целевых показателей доступности, целевые показатели восстановления для этих измерений не сильно зависят от соглашений об уровне обслуживания Майкрософт. Корпорация Майкрософт публикует гарантии RTO и RPO только для некоторых продуктов, таких как База данных SQL.

Определения реалистичных целевых объектов восстановления основаны на анализе режима сбоя , а также на планах и тестировании для обеспечения непрерывности бизнес-процессов и аварийного восстановления. Прежде чем завершить эту работу, обсудите желаемые цели с заинтересованными лицами и убедитесь, что архитектура поддерживает целевые показатели восстановления в лучшем понимании. Четко сообщите заинтересованным лицам, что все потоки или целые рабочие нагрузки, которые не тщательно протестированы на наличие метрик восстановления, не должны иметь гарантированных соглашений об уровне обслуживания. Убедитесь, что заинтересованные лица понимают, что целевые показатели восстановления могут меняться с течением времени по мере обновления рабочих нагрузок. Рабочая нагрузка может стать более сложной по мере добавления клиентов или внедрения новых технологий для улучшения взаимодействия с клиентами. Эти изменения могут увеличить или уменьшить метрики восстановления.

Примечание

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

При определении целевых объектов восстановления определите пороговые значения для инициации восстановления. Например, если веб-узел недоступен более 5 минут, новый узел автоматически добавляется в пул. Определите пороговые значения для всех компонентов с учетом того, что включает восстановление для конкретного компонента, включая влияние на другие компоненты и зависимости. Пороговые значения также должны учитывать временные сбои , чтобы не запускать действия по восстановлению слишком быстро. Документируйте и делитесь с заинтересованными лицами потенциальными рисками операций восстановления, такими как потеря данных или прерывание сеанса для клиентов.

Создание модели работоспособности

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

Способ определения состояния работоспособности, понижения и неработоспособности зависит от целевых показателей надежности. Ниже приведены некоторые примеры способов определения состояний:

• Зеленое или работоспособное состояние указывает, что ключевые нефункциональные требования и целевые показатели полностью удовлетворены, а ресурсы используются оптимально. Например, 95 процентов запросов обрабатываются в <=500 мс, при этом узел Служба Azure Kubernetes (AKS) используется в X процентах.

• Желтое или пониженное состояние означает, что один или несколько компонентов потока оповещают о достижении определенного порогового значения, но поток работает. Например, обнаружено регулирование хранилища.

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

Примечание

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

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

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

Визуализация

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

Упрощение поддержки Azure

Соглашения об уровне обслуживания Azure предоставляют обязательства Корпорации Майкрософт в отношении времени безотказной работы и подключения. Разные службы имеют разные соглашения об уровне обслуживания, а иногда номера SKU в службе имеют разные соглашения об уровне обслуживания. Дополнительные сведения см. в разделе Соглашения об уровне обслуживания для веб-службы.

Соглашение об уровне обслуживания Azure включает процедуры получения кредита на обслуживание, если соглашение об уровне обслуживания не соблюдается, а также определения доступности для каждой службы. Этот аспект SLA действует как политика принудительного применения.

Связанные ссылки

• Well-Architected Framework критически важное руководство по моделированию работоспособности: моделирование работоспособности и наблюдаемость критически важных рабочих нагрузок в Azure

Контрольный список надежности

Ознакомьтесь с полным набором рекомендаций.

Контрольный список надежности