Стратегии архитектуры для определения целевых показателей надежности

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

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

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

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

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

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

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

• Целевые показатели восстановления соответствуют метрикам RTO, RPO, MTTR и MTBF, которые квалифицируют эффективность планов и тестирование для обеспечения непрерывности бизнес-процессов и аварийного восстановления.

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

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

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

Установка целей доступности

Общий SLO нагрузки отражает общее качество, включая все её зависимости. Зрелая формулировка SLO должна указывать общую бизнес-цель для этой нагрузки, а не просто совокупный показатель, составленный из этих зависимостей. Например, если клиенты ожидают 99,99 % доступности, общий SLO должен стремиться к этой цели, даже если одна часть достигает только 99,80%.

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

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

Архитекторы рабочих нагрузок принимают множество технических решений на основе SLO. SLO могут:

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

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

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

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

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

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

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

• Задержка измеряет время между инициированием запроса на операцию и тем, когда результат доступен или процесс завершен.

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

• Доступность измеряет время простоя с точки зрения клиентов.

• Пропускная способность измеряет минимальную скорость передачи данных в течение определенного периода времени. Пропускная способность измеряется как единица скорости данных, например транзакции в секунду (TPS) или запросы в секунду (RPS).

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

Определите границы SLO

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

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

Определение составных целевых объектов SLO

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

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

SLO включает измеримые SLI, которые определяют приемлемые показатели. SLI — это метрики с заданным пороговым значением, для которого можно настроить оповещение. Их можно собирать с платформы или приложения. Различные компоненты выдают соответствующие интерфейсы SLIs. При выборе SLI следует учитывать факторы, влияющие на SLO.

Например, чтобы вычислить SLO для потока, использующего API ответа и запроса, измерять задержку сервера и время обработки запросов. Пропускная способность и частота ошибок не применяются к средам непрерывных вычислений, таким как виртуальные машины (VM), группы масштабирования или пакетная служба Azure.

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

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

Оценка влияния соглашений об уровне обслуживания Майкрософт

Соглашение об уровне обслуживания (SLA) Майкрософт содержит сведения о доступности аспектов, доступность которых корпорация Майкрософт обязуется обеспечивать. Соглашения об уровне обслуживания не гарантируют предложение в целом. При оценке соглашений об уровне обслуживания важно хорошо понимать объём покрытия, предусмотренный для опубликованного процентиля.

Рассмотрим веб-приложения — функцию службы Служба приложений Azure. Эта функция считается доступной при возврате состояния 200 ОК в данном случае использования. В этом конкретном контексте и в течение данного периода не предусматривается гарантия, подкреплённая финансовыми обязательствами, в отношении доступности таких функций, как Easy Auth или переключение слотов. Следует считать, что области, прямо не указанные в соглашении, доступны лишь по мере возможности платформы.

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

Рассмотрим другой пример. Если Azure Front Door имеет 99,99 % доступности, проект должен соответствовать определенным критериям, опубликованным в соглашении. Например, ваша серверная часть должна включать хранилище, вам необходима операция GET, позволяющая получить файл размером не менее 50 КБ, и необходимо развернуть агентов в нескольких местах как минимум в пяти географически удалённых точках. Этот узкий вариант использования Azure Front Door не гарантирует такие функции, как кэширование, правила маршрутизации или брандмауэр веб-приложения. Эти аспекты не входят в сферу действия SLA.

Реализуйте мультирегиональные целевые объекты

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

Существует два основных варианта использования:

• Шаблон высокой доступности, при котором нагрузка распределяется между регионами для увеличения пропускной способности. Высокая доступность не привязывает пользователей рабочей нагрузки к какому-либо региону, а в SLO учитывается производительность всей системы.

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

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

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

Определение метрик восстановления

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

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

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

Мониторинг и визуализация целевых объектов

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

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

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

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

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

Изучите панели мониторинга Azure Monitor для системы визуализации.

Пример

Компания Contoso, Ltd. разрабатывает новый мобильный интерфейс для своей системы билетов на события. Вот высокоуровневая архитектура.

Логотип Grafana является товарным знаком соответствующей компании. Никакое подтверждение не подразумевается использованием этого знака.

Компоненты

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

• Azure Front Door — это единственная точка входа, которая предоставляет API, который клиенты используют для отправки запросов.

• Контейнеры приложений Azure — это среда, которой владеет команда, отвечающая за рабочую нагрузку, и которую она использует для выполнения бизнес-логики приложения.

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

• Приватный канал Azure обеспечивает частное подключение между развертываниями Azure Front Door и контейнерными приложениями. Управляемый экземпляр SQL также предоставляется приложению через частную конечную точку.

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

Вычисление составного SLO

• SLO доступности Azure: Финансовые обязательства, предусмотренные SLA Azure, служат косвенным показателем надежности платформы.

  Компонент Azure	Применимое соглашение об уровне обслуживания	Не покрывается SLA	Скорректированный SLO
  Azure Front Door	99,99% для успешных операций HTTP GET	Кэширование, обработчик правил	99.98%
  Контейнерные приложения	99,95% для развернутых приложений, доступных через встроенный ingress	Автоматическое масштабирование, возможности хранилища токенов	99,95 %
  Управляемый экземпляр SQL	99,99% на основе подключения к экземпляру SQL Server	Производительность, хранение данных	99,80 %
  Приватный канал	99,99 % исходя из полных минут, когда сеть частного конечного узла не принимала трафик или когда трафик не передавался между конечной точкой и службой Приватный канал	Отдельные неудачи длительностью менее одной минуты	99,99 %

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

  Есть также и более тонкие факторы. Например, команда снижает значение SLO для Управляемый экземпляр SQL до 99,80 %, чтобы учесть возможные сбои при операциях с данными, таких как изменение схемы и создание резервных копий.

  Команда определяет составной показатель SLO, рассчитывая влияние отдельных скорректированных значений SLO. Это значение равно 99,72%.

  Существуют и другие факторы, влияющие на них. Архитектура использует сетевые компоненты Azure, такие как виртуальные сети и группы безопасности сети (NSG), которые не имеют опубликованного соглашение об уровне обслуживания. Команда, отвечающая за рабочую нагрузку, принимает решение учитывать эти факторы исходя из доступности 99,99 % для каждого компонента.

  Составной SLO на основе прогнозируемой доступности платформы: 99,68% в месяц.

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

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

  Комплексный SLO на основе доступности кода и данных: 99,86% в месяц.

• SLO для конфигурации ресурсов и приложений: Команда признает, что облачные ресурсы и код приложения должны быть правильно настроены. Эта цель включает настройку правил автомасштабирования, настройку правил NSG и выбор подходящего размера SKU. Чтобы учесть ошибки конфигурации, они бюджетируют 10 минут ежемесячного простоя, что составляет около 99,98 % доступности.

  Составной показатель уровня обслуживания (SLO) по доступности конфигурации: 99,95% в месяц.

• Операционный SLO: команда, отвечающая за рабочую нагрузку, формирует эффективную культуру DevOps, следуя принципам Well-Architected Framework в области операционного совершенства. Они развертывают облачные ресурсы, конфигурацию и код каждого спринта.

  Команда считает, что развертывания представляют собой риск, поскольку они могут дестабилизировать работающую систему. В результате обновлений сертификатов TLS, изменений DNS или ошибок инструментов могут возникнуть ошибки. Команда также рассматривает потенциальные простои, вызванные аварийными исправлениями. Они бюджетируют в общей сложности 20 минут ежемесячного простоя, что составляет примерно 99,95 % доступности.

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

  Составной SLO на основе доступности операций: 99,95% в месяц.

• SLO для внешних зависимостей: Команда рассматривает Управляемый экземпляр SQL как основную зависимость, чья доступность на уровне 99,80 % уже учтена в общей доступности платформы. Другие внешние зависимости не рассматриваются.

  Составной SLO на основе внешних зависимостей: неприменимо.

Определить общий результат составного SLO

Совокупный целевой показатель SLO установлен на уровне 99,45%, что соответствует примерно четырём часам простоя в месяц.

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

Настройте SLA для рабочей нагрузки

Соглашение об уровне обслуживания для рабочей нагрузки составляет 99,90 % доступности в месяц.

Юридический и финансовый отделы команды, отвечающей за рабочую нагрузку, устанавливают для неё SLA на уровне 99,90 % ежемесячной доступности, что превышает целевой показатель SLO в 99,45 %. Они делают это решение после того, как они анализируют финансовые выплаты и прогнозируемый рост клиентов на основе привлекательного соглашения об уровне обслуживания. Соглашение об уровне обслуживания охватывает два основных потока пользователей и включает рекомендации по производительности, а не только доступность. Это осознанный риск, на который идёт бизнес-команда в интересах бизнеса, и инженерная команда осведомлена об этом обязательстве.

Настройка SLO правильности

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

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

моделирование работоспособности для рабочих нагрузок

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

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