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

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

RE:04

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

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

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

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

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

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

Основные стратегии проектирования

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

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

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

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

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

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

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

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

SLO можно определить с точки зрения различных метрик, таких как доступность, время отклика, пропускная способность, скорость успешности и другие. Например, SLO для веб-службы может быть доступно пользователям 99,9% времени в течение заданного месяца или что он будет отвечать на 95% запросов в пределах 500 миллисекундах.

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

Примечание.

Соглашения об уровне обслуживания службы Майкрософт не являются платформенными соглашениями об уровне обслуживания или соглашениями об уровне обслуживания

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

Примечание.

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

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

Примечание.

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

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

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

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

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

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

База данных или очередь = 1.0 – (0,0001 × 0,001) = 99,999999 процента

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

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

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

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

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

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

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

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

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

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

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

Значения SLA

В следующей таблице определены общие значения 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. Как правило, рабочие нагрузки внутреннего использования могут иметь гораздо менее строгие соглашения об уровне обслуживания доступности, чем рабочие нагрузки, доступные для клиентов.

SlIs

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

Упрощение функций Azure

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

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

Дополнительные ссылки

• Рекомендации по моделированию работоспособности с критически важными рекомендациями по архитектуре платформы: моделирование работоспособности и наблюдаемость критически важных рабочих нагрузок в Azure

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

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

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