Рекомендации по определению целевых показателей надежности
Применимо к этой рекомендации Power Platform контрольного списка надежности, хорошо продуманной архитектуры:
| РЕ:04 | Определите целевые показатели надежности и восстановления для компонентов, потоков и всего решения. Визуализируйте цели, чтобы вести переговоры, достигать консенсуса, формировать ожидания и стимулировать действия для достижения идеального состояния. Используйте определенные цели для построения модели работоспособности. Модель работоспособности определяет, как выглядят различные состояния: работоспособное, неработоспособное и ухудшенное. |
|---|
В этом руководстве описаны рекомендации по определению целевых показателей доступности и восстановления для критических рабочих нагрузок. Целевые показатели надежности определяются в ходе семинаров с участием заинтересованных сторон.
Цели улучшаются посредством мониторинга и тестирования. Работайте с внутренними заинтересованными сторонами, чтобы установить реалистичные ожидания в отношении надежности. Это упражнение также поможет заинтересованным сторонам поддержать ваш выбор архитектурного проекта и понять, что вы проектируете так, чтобы наилучшим образом достичь согласованных вами целей.
Microsoft Power Platform обрабатывает большинство проблем доступности и надежности на уровне инфраструктуры для вас. Однако доступность создаваемых вами рабочих нагрузок — это общая ответственность. Важно понимать, что даже при Microsoftприверженности высокой доступности риск простоя системы никогда не равен нулю.
Рассмотрите возможность использования следующих показателей для количественной оценки бизнес-требований.
| Термин | Определение |
|---|---|
| Цели на уровне обслуживания (SLO) | Целевой процент, который отражает работоспособность компонента и уровень надежности. Чем выше уровень, тем надежнее компонент. Составной SLO представляет собой совокупную цель всей рабочей нагрузки и учитывает компонентные SLO. |
| Индикатор уровня обслуживания (SLI) | Метрика, создаваемая службой. Метрики SLI агрегируются для количественной оценки значения SLO. |
| Соглашение об уровне обслуживания (SLA) | Договорное соглашение между поставщиком услуг и заказчиком услуг. Соглашение определяет значения SLO. Невыполнение соглашения может иметь финансовые последствия для поставщика услуг. |
| Среднее время восстановления (MTTR) | Время, необходимое для восстановления компонента после обнаружения сбоя. |
| Среднее время наработки на отказ (MTBF) | Продолжительность, в течение которой рабочая нагрузка может выполнять ожидаемую функцию без перерыва, пока не произойдет сбой. |
| Целевое время восстановления (RTO) | Максимально приемлемое время, в течение которого приложение может быть недоступно после инцидента. |
| Целевая точка восстановления (RPO) | Максимально допустимый интервал потери данных во время инцидента. |
Определите целевые значения рабочей нагрузки для этих метрик в контексте пользовательских и системных потоков. Определите и оцените эти потоки по степени их критичности для ваших требований. Используйте эти значения для управления проектированием вашей рабочей нагрузки с точки зрения архитектуры, проверки, тестирования и операций по управлению инцидентами. Невыполнение целевых показателей повлияет на бизнес за пределы допустимого уровня.
Ключевые стратегии проектирования
Технические дискуссии не должны влиять на то, как вы определяете целевые показатели надежности для критически важных потоков. Вместо этого заинтересованным сторонам бизнеса следует сосредоточиться на своих требованиях и ожиданиях конечных пользователей рабочей нагрузки. Технические эксперты помогают заинтересованным сторонам присваивать реалистичные числовые значения, соответствующие этим требованиям. Обмениваясь информацией, технические эксперты способствуют обсуждению и согласованию возможных значений SLO.
Рассмотрим пример того, как сопоставить требования с измеримыми числовыми значениями. По оценкам заинтересованных сторон, для критического пользовательского потока час простоя в обычные рабочие часы приводит к потере X долларов ежемесячного дохода. Эта сумма в долларах сравнивается с расчетной стоимостью разработки потока, имеющего коэффициент SLO доступности 99,95 процента, а не 99,9 процента. Лица, принимающие решения, должны обсудить, перевешивает ли риск такой потери доходов дополнительные затраты и управленческое бремя, необходимое для защиты от нее.
Следуйте этому шаблону, изучая потоки и создавая полный список целей.
Помните, что целевые показатели надежности отличаются от целевых показателей производительности. Цели надежности сосредоточены на доступности и восстановлении. Чтобы установить целевые показатели надежности, начните с определения самых широких требований, а затем определите более конкретные показатели для удовлетворения требований высокого уровня.
Требования к надежности и восстановлению самого высокого уровня, а также коррелирующие показатели могут включать, например, доступность приложений на уровне 99,9 процента для всех регионов или целевое RTO в 5 часов для региона Северной и Южной Америки. Определение этих типов целей поможет вам определить, какие критические потоки участвуют в этих целях. Затем вы можете рассмотреть цели на уровне компонентов.
Метрики доступности
Целевые показатели доступности соответствуют метрикам SLO, SLA и SLI.
Показатели SLO и SLA
Метрики доступности коррелируют с показателями SLO, которые вы используете для определения соглашений SLA. SLO рабочей нагрузки определяет, сколько времени простоя допустимо в данный период; например, менее 1 часа в месяц. Чтобы убедиться, что вы можете достичь целевого показателя SLO, просмотрите Microsoft SLA для каждого компонента.
Чтобы установить свои показатели SLO, подумайте о следующем:
Нефункциональные требования вашей рабочей нагрузки (например, пиковая частота запросов, количество одновременных пользователей) в течение следующих 1–2 лет.
Доступные метрики того, что вы можете измерить за определенный период времени. Эти данные будут указывать, какие показатели SLI следует указать.
После того как вы соберете соглашения об уровне обслуживания для отдельных компонентов рабочей нагрузки, рассчитайте составное соглашение об уровне обслуживания. Составное соглашение об уровне обслуживания должно соответствовать целевому показателю SLO для рабочей нагрузки. Расчет составного соглашения об уровне обслуживания включает в себя несколько факторов, в зависимости от вашей архитектуры.
Определение правильных показателей 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 минуты |
Когда вы думаете о составных соглашениях об уровне обслуживания в контексте пользовательских и системных потоков, помните, что разные пользовательские и системные потоки имеют разные определения критичности. Учитывайте эти различия при составлении составных соглашений об уровне обслуживания. Некритические потоки могут содержать компоненты, которые следует исключить из расчетов, поскольку они не влияют на качество обслуживания клиентов, если они кратковременно недоступны.
Показатели SLI
Думайте о показателях SLI как о показателях уровня компонента, которые вносят вклад в показатель SLO. Наиболее значимыми показателями SLI являются те, которые влияют на ваши критические потоки с точки зрения ваших клиентов. Для многих потоков показатели SLI включают задержку, пропускную способность, частоту ошибок и доступность. Хороший показатель SLI поможет вам определить, когда показатель SLO может быть нарушен. По возможности сопоставляйте показатель SLI с конкретными клиентами.
Чтобы избежать сбора бесполезных метрик, ограничьте количество показателей SLI для каждого потока. Если возможно, стремитесь к использованию трех показателей SLI на поток.
Метрики восстановления
Целевые показатели восстановления соответствуют метрикам RTO, RPO, MTTR и MTBF. В отличие от целевых показателей доступности, целевые показатели восстановления для этих измерений не сильно зависят от Microsoft SLA. Microsoft публикует гарантии RTO и RPO только для некоторых продуктов, таких как SQL Database.
Определения реалистичных целей восстановления основаны на вашем анализе режимов сбоя, а также ваших планах и тестировании на непрерывность бизнеса и аварийное восстановление. Прежде чем завершить эту работу, обсудите желаемые цели с заинтересованными сторонами и убедитесь, что проект вашей архитектуры поддерживает цели восстановления, насколько вы понимаете. Четко сообщите заинтересованным сторонам, что любые части рабочей нагрузки, которые не прошли тщательную проверку показателей восстановления, не должны иметь гарантированных соглашений об уровне обслуживания. Убедитесь, что заинтересованные стороны понимают, что цели восстановления могут меняться со временем по мере обновления рабочих нагрузок. Рабочая нагрузка может усложниться по мере внедрения новых технологий для улучшения взаимодействия с пользователем. Эти изменения могут увеличить или уменьшить ваши показатели восстановления.
Заметка
MTBF может быть сложно определить и гарантировать. Платформы как услуга (PaaS) или программное обеспечение как услуга (SaaS) могут выйти из строя и восстановиться без какого-либо уведомления от поставщика облачных услуг, и этот процесс может быть для вас полностью прозрачным. Если вы определяете цели для этой метрики, охватывайте только те компоненты, которые находятся под вашим контролем.
Построение модели работоспособности
Используйте данные, собранные вами для целей надежности, чтобы построить модель работоспособности для каждой рабочей нагрузки и связанных с ней критических потоков. Модель работоспособности определяет работоспособное, ухудшенное и неработоспособное* состояния для потоков и рабочих нагрузок. Эти состояния обеспечивают соответствующую оперативную расстановку приоритетов. Эта модель также известна как модель светофора. В модели зеленый цвет соответствует работоспособному, желтый — деградированному, а красный — неработоспособному состоянию. Модель работоспособности гарантирует, что вы будете знать, когда состояние потока меняется с работоспособного на ухудшенное или неработоспособное.
То, как вы определяете работоспособное, деградированное и неработоспособное состояния, зависит от ваших целей надежности. Вот несколько примеров способов определения состояний:
Зеленое или работоспособное состояние указывает на то, что ключевые нефункциональные требования и цели полностью удовлетворены, и что ресурсы используются оптимально.
Желтое или деградированное состояние указывает на то, что один или несколько компонентов потока выдают предупреждение о достижении определенного порогового значения, но поток работает. Например, было обнаружено регулирование пропускной способности хранилища.
Красное или неработоспособное состояние указывает на то, что ухудшение сохраняется дольше, чем допустимо вашими целевыми показателями надежности, или что поток стал недоступен.
Заметка
Модель работоспособности не должна обрабатывать все сбои одинаково. Модель работоспособности должна различать временные и невременные неисправности. Следует четко различать ожидаемые временные, но устранимые сбои и истинное аварийное состояние.
Эта модель работает с использованием стратегии мониторинга и оповещения, которая разработана и действует на принципах постоянного улучшения. По мере развития ваших рабочих нагрузок ваши модели работоспособности должны меняться вместе с ними.
Подробные инструкции по настройке мониторинга и оповещений см. в руководстве по мониторингу работоспособности.
Визуализация
Чтобы ваши операционные группы и заинтересованные лица, заинтересованные в рабочей нагрузке, были в курсе состояния в режиме реального времени и общих тенденций модели работоспособности рабочей нагрузки, рассмотрите возможность создания панелей мониторинга в вашем решении для мониторинга. Обсудите решения по визуализации с заинтересованными сторонами, чтобы гарантировать, что вы предоставляете ту информацию, которую они ценят и которую легко использовать. Они также могут захотеть просматривать созданные отчеты еженедельно, ежемесячно или ежеквартально.
Возможности в Power Platform
Power Platform Соглашения об уровне обслуживания предусматривают Microsoft обязательства по времени безотказной работы и подключению. Разные службы имеют разные соглашения об уровне обслуживания, а иногда и SKU внутри службы имеют разные соглашения об уровне обслуживания. Дополнительные сведения см. в разделе Соглашения об уровнях обслуживания для веб-служб.
Соглашение об уровне обслуживания Power Platform включает процедуры получения кредита на обслуживание в случае невыполнения соглашения об уровне обслуживания, а также определения доступности для каждой службы. Этот аспект SLA действует как политика обеспечения соблюдения.
Microsoft Business Applications предоставляет возможности обеспечения непрерывности бизнеса и аварийного восстановления (BCDR) для всех производственных сред в Dynamics 365 и Power Platform приложениях SaaS. Узнайте, как Microsoft обеспечить устойчивость ваших производственных данных во время региональных сбоев.
Согласованность внутри организации
Cloud Adoption Framework предоставляет рекомендации для показателей SLO и SLI, связанных с мониторингом в масштабах организации.
Дополнительную информацию см. в разделе Показатели SLO облачного мониторинга.
Контрольный список надежности
Обратитесь к полному набору рекомендаций.