Рекомендации по определению целевых показателей надежности
Применяется к этой рекомендации проверки надежности платформы Azure Well-Architected Framework:
| RE:04 | Определите целевые показатели надежности и восстановления для компонентов, потоков и общего решения. Визуализировать цели для согласования, достижения консенсуса, задания ожиданий и действий для достижения идеального состояния. Используйте определенные целевые объекты для создания модели работоспособности. Модель работоспособности определяет, как выглядят здоровые, деградированные и неработоспособные состояния. |
|---|
В этом руководстве описываются рекомендации по определению целевых метрик доступности и восстановления для критически важных рабочих нагрузок и потоков. Вы должны получить целевые показатели надежности из семинарских упражнений с заинтересованными лицами бизнеса. Затем укажите эти целевые объекты путем мониторинга и тестирования рабочих нагрузок.
Задайте реалистичные ожидания с внутренними заинтересованными лицами о надежности рабочей нагрузки. Затем они могут использовать договорные соглашения для общения этих ожиданий с клиентами. Реалистичные ожидания также помогают заинтересованным лицам понять и поддержать ваши архитектурные решения по проектированию и знать, что вы разрабатываете оптимальное соответствие целевым объектам, которые вы согласны.
Рекомендуется использовать следующие метрики для количественной оценки бизнес-требований.
| Термин | Определение |
|---|---|
| Цель уровня обслуживания (SLO) | Мера производительности и надежности рабочей нагрузки или приложения. SLO — это конкретный измеримый целевой объект, заданный для конкретных взаимодействий с клиентом. Это целевой объект, который вы устанавливаете для рабочей нагрузки или приложения на основе качества обслуживания, которую ваши клиенты ожидают получать. |
| Индикатор уровня обслуживания (SLI) | Количественное измерение определенного аспекта производительности службы. Вы можете использовать SLI для измерения соответствия рабочей нагрузки требованиям SLO. |
| Соглашение об уровне обслуживания (SLA) | Договорное соглашение между поставщиком услуг и клиентом службы. Неисполнение соглашения может иметь финансовые последствия для поставщика услуг. |
| Среднее время восстановления (MTTR) | Время, затраченное на восстановление компонента после обнаружения сбоя. |
| Среднее время между сбоем (MTBF) | Длительность, в течение которой рабочая нагрузка может выполнять ожидаемую функцию без прерывания, пока она не завершается ошибкой. |
| Целевое время восстановления (RTO) | Это максимально допустимое время, в течение которого приложение может быть недоступно после инцидента. |
| Целевая точка восстановления (RPO) | Максимальная допустимая длительность потери данных во время инцидента. |
Основные стратегии проектирования
Целевые показатели надежности представляют нужную цель качества рабочей нагрузки, как обещало пользователям и заинтересованным лицам бизнеса. Эта цель включает как доступность, так и возможность восстановления рабочей нагрузки. Помните, что целевые показатели надежности отличаются от целевых показателей производительности, но следует включать целевые показатели производительности в целевые показатели надежности. Рассмотрим следующие целевые показатели надежности:
Целевые показатели доступности определяют стандарты качества системы, которые будут оставаться доступными и функциональными. Если он не соответствует этим стандартам, система считается ненадежной. Используйте SLO, чтобы проверить, соответствует ли ваша система этим стандартам. Бизнес и технические заинтересованные стороны сотрудничают, чтобы настроить реалистичные соглашения об уровне обслуживания и рассмотреть такие факторы, как сравнительный анализ, взаимодействие с пользователем и профиль рабочей нагрузки.
Целевые показатели правильности гарантируют, что рабочая нагрузка правильно выполняет свои функции с согласованным качеством. Чтобы оценить правильность, вы можете оценить показатели рабочей нагрузки, чтобы объединить их в единую, целевую оценку.
Целевые показатели восстановления соответствуют метрикам RTO, RPO, MTTR и MTBF, которые квалифицируют эффективность планов и тестирование для обеспечения непрерывности бизнес-процессов и аварийного восстановления.
Чтобы задать целевые показатели надежности, заинтересованные лица бизнеса определяют широкие требования. Затем технические эксперты оценивают текущее состояние рабочей нагрузки и работают над достижением и обслуживанием целевых объектов с помощью мониторинга и оповещений. Обе стороны должны согласиться с реалистичными целями.
Определение и оценка потоков пользователей и систем в зависимости от их важности в бизнес-требованиях. Используйте эти оценки для руководства по проектированию, проверке, тестированию и управлению инцидентами рабочей нагрузки. Задайте целевые показатели надежности для этих потоков и понять, что не удалось удовлетворить эти целевые показатели, может значительно повлиять на ваш бизнес.
Компромисс. Возможно, у вас есть разрыв между техническими ограничениями вашей системы и его воздействием на бизнес, например пропускной способностью и транзакциями в секунду. Преодоление этого разрыва может быть жестким. Цель практического и экономичного решения вместо чрезмерного использования.
Установка целей доступности
Общий уровень обслуживания рабочей нагрузки отражает целостное качество, включая все его зависимости. Зрелое объявление SLO должно указывать общий бизнес-целевой объект для этой рабочей нагрузки, а не только составную часть этих зависимостей. Например, если клиенты ожидают 99,99 % доступности, общий SLO должен стремиться к этой цели, даже если одна часть достигает только 99,80%.
Заинтересованные лица оценивают взаимодействие с клиентами и рассматривают, как простой влияет на доход. Они сравнивают эту потерю с затратами на проектирование и эксплуатацию бизнес-потока. Затем лица, принимающие решения, решают, следует ли тратить больше денег на надежность, чтобы избежать потери доходов и сохранить свою репутацию.
Владельцы рабочих нагрузок используют финансовые цели для определения целей. Бизнес-требования сопоставляются с измеримыми метриками. Цель — определить набор факторов, влияющих на качество взаимодействия с клиентом.
Архитекторы рабочих нагрузок принимаются множество технических решений на основе SLO. Соглашения об уровне обслуживания могут:
В качестве критически важных входных данных в архитектурные решения при рассмотрении других зависимостей.
Предоставьте представление о работоспособности рабочей нагрузки в режиме реального времени и общие сведения о работоспособности рабочей нагрузки, чтобы обеспечить объективное обсуждение. Они также помогают команде рабочей нагрузки определять приоритеты усилий по повышению надежности и разработке новых функций.
Выступайте в качестве основного сигнала для операций развертывания, что приводит к автоматическому откату при возникновении проблем и обеспечивает проверку того, что изменения достигают ожидаемых улучшений в пользовательском интерфейсе.
Ускорьте исправление и восстановление, сосредоточив внимание на задачах, запустите автоматическое уведомление о проблемах клиентам и создайте доверие между командами в вашей организации.
Внимание
Необходимо знать разницу между соглашениями об уровне обслуживания и соглашениями об уровне обслуживания. Хотя соглашения об уровне обслуживания и соглашения об уровне обслуживания могут использовать или даже представлять аналогичные данные, их намерение отличается. Соглашение об уровне обслуживания является формальным контрактом между организацией и ее клиентами, и он имеет прямые финансовые и юридические последствия, если организация не сможет доставить свое обещание. Организации используют SLO для оценки того, находится ли потенциальный простой в допустимых ограничениях.
Соглашения об уровне обслуживания и соглашения об уровне обслуживания совместно используют деловые отношения и должны управляться независимо. Если соглашение об уровне обслуживания служит бизнес-тактикой, организация может намеренно установить ее на высокую ценность на основе целей владельца бизнеса. И наоборот, соглашения об уровне обслуживания могут быть выше. Рассмотрим критически важные рабочие нагрузки в качестве примера. Этот класс рабочей нагрузки не может позволить себе длительные простои, поскольку последствия, включая финансовые потери и даже угрозы безопасности человека, являются значительными. Поэтому SOS обычно нацелены на 99,999% времени простоя, обычно называют пятью девятью. Если соглашения об уровне обслуживания не соответствуют этим целям, организации должны быстро реагировать на устранение сбоев и предотвращать результаты неудачного соглашения об уровне обслуживания.
Пример в этой статье задает высокий уровень обслуживания для поддержки бизнес-целей.
Поставщики облачных платформ и технологий публикуют соглашения об уровне обслуживания на своих предложениях. Вы должны учитывать соглашения об уровне обслуживания в рамках вычисления SLO, но их не следует использовать так же, как и без понимания области охвата соглашения об уровне обслуживания. Дополнительные сведения см. в разделе "Оценка влияния соглашений об уровне обслуживания Майкрософт".
Рассмотрим распространенные соглашения об уровне обслуживания и влияющие факторы
Каждый SLO предназначен для определенного критерия качества. Рассмотрим эти общие соглашения об уровне обслуживания для надежности. Этот список не является исчерпывающим. Добавьте SLO на основе бизнес-требований.
Частота успешности измеряет успешность запросов и процессов относительно тех, которые возвращают ошибку или завершают задачу сбоем.
Задержка измеряет время между инициированием запроса на операцию и тем, когда результат доступен или процесс завершен.
Меры емкости одновременного использования, такие как количество ответов на основе регулирования.
Доступность измеряет время простоя с точки зрения клиентов.
Пропускная способность измеряет минимальную скорость передачи данных в течение определенного периода времени. Пропускная способность измеряется как единица скорости данных, например транзакции в секунду (TPS) или запросы в секунду (RPS).
Сведения о сценариях и допустимости рабочей нагрузки в Azure. Службы Azure и компоненты приложений влияют на SLO рабочей нагрузки. Объедините ответы из следующей таблицы, чтобы получить общее значение SLO. Используйте эти вопросы в качестве примеров для оценки служебной программы компонента рабочей нагрузки.
| Характеристики компонентов | Взаимодействие с пользователями | Другие факторы |
|---|---|---|
| — Предоставляет ли он API запросов или ответов? — У него есть API-интерфейсы запросов? — Это вычислительный компонент? — Это компонент обработки заданий? |
- Доступ к плоскости управления и плоскости управления для общедоступных служб Azure. - Доступ к плоскости данных, например создание, чтение, обновление и удаление (CRUD). |
— Включает ли процесс выпуска время простоя? - Какова вероятность появления ошибок? Если рабочая нагрузка интегрируется с другими системами, может потребоваться рассмотреть ошибки интеграции. — Как подпрограммные операции , такие как исправление, влияют на целевой объект доступности? Вы включили факторы зависимостей партнеров? - Достаточно ли персоналу для поддержки постоянного аварийного и аварийного резервного копирования по вызову? - Есть ли у приложения шумные соседи за пределами вашей области контроля, которые могут привести к сбоям? |
Определение области SLO
Вы можете задать уровни обслуживания на различных уровнях, например для каждого приложения, рабочей нагрузки или определенного потока в вашей системе. Настройте уровни уровней обслуживания, чтобы можно было настроить SLO на основе важности каждого компонента.
В решениях saaS для программного обеспечения измеряйте SLO для каждого клиента, чтобы оптимизировать взаимодействие с каждым клиентом. Клиенты могут иметь различные ресурсы инфраструктуры в своих сегментах. В таких случаях SLO на уровне системы, которая объединяет все ресурсы в сегментах клиентов, может не имеет смысла. Вместо этого измеряйте SLO, которые соответствуют конкретному контексту каждого клиента. Дополнительные сведения см. в моделях аренды для мультитенантного решения.
Определение составных целевых объектов SLO
Соглашения об уровне обслуживания должны измеряться и измеряться в окне наблюдаемости.
SlOs часто проценты, такие как 99,90%, но они также могут быть операторами. Используйте оба метода, чтобы получить числовое значение, включающее все факторы.
SLO состоит из измеримых slis, определяющих допустимые факторы. SlIs — это метрики с заданным пороговым значением, которое может быть оповещено. Их можно собирать с платформы или приложения. Различные компоненты выдают соответствующие интерфейсы SLIs. При выборе SLO следует учитывать факторы, влияющие на SLO.
Например, чтобы вычислить SLO для потока, использующего API ответа и запроса, измерять задержку сервера и время обработки запросов. Скорость пропускной способности и ошибок не применяется к непрерывным вычислительным средам, таким как виртуальные машины, масштабируемые наборы или пакетная служба Azure.
Для доступа на уровне управления рассмотрите частоту ошибок и задержку для ответов API и длительных операций, таких как создание ресурсов. Доступ к плоскости данных зависит от используемых API, каждый из которых имеет собственные целевые объекты SLO.
Хороший SLI показывает, когда вы можете нарушить SLO. Обычно это измеряется в процентилях. Ниже приведены некоторые часто используемые процентили и предполагаемое время несоответствия ожидаемой доступности.
| Цель | Несоответствие в неделю | Несоответствие в месяц | Несоответствие в год |
|---|---|---|---|
| 99 % | 1,68 часа | 7.20 часов | 3,65 дня |
| 99,90 % | 10.10 минут | 43.20 минут | 8,76 часа |
| 99,95 % | 5 мин | 21.60 минут | 4,38 часа |
| 99,99 % | 1,01 минуты | 4,32 минуты | 52,56 минуты |
| 99,999 % | 6 секунд | 25,90 секунды | 5,26 минуты |
Внимание
Составное значение SLO — это распределение продуктов, влияющих на факторы.
Пример составного SLO составляет 99,95% × 99,99999% = ~99,95%.
При создании составных SLO для разных потоков учитывайте их различную критичность и релевантность. Потоки могут иметь компоненты, которые вы считаете некритичными и пропущенными из вычислений. Вы можете оправдать свое упущение на основе того, влияет ли их краткое недоступность на опыт клиента. В некоторых случаях компонент может не соответствовать варианту использования, который вы рассматриваете для SLO. Эти компоненты также можно опустить из вычисления.
Тот же принцип применяется к операциям. Некоторые операции могут привести к рискам или повлиять на SLO, а другие — незначительными. Решение должно быть явным и основано на консенсусе.
Пример определения и измерения slOs и slIs см. в разделе "Пример ".
Оценка влияния соглашений об уровне обслуживания Майкрософт
Соглашение об уровне обслуживания Майкрософт предоставляет сведения о доступности областей, к которым корпорация Майкрософт фиксирует. Соглашения об уровне обслуживания не гарантируют предложение в целом. При оценке соглашений об уровне обслуживания у вас есть хорошее представление о охвате, предоставленном вокруг опубликованного процентиля.
Рассмотрим веб-приложения функцию службы приложение Azure. Эта функция считается доступной при возврате состояния 200 ОК в данном случае использования. В рамках этого конкретного контекста и времени она не охватывает финансовую гарантию на доступность таких функций, как простое переключение аутентификации или слота. Вы должны учитывать области, которые не упоминаются явно в соглашении, как доступны лучшими усилиями платформы.
Таким образом, если рабочая нагрузка зависит от слотов развертывания, вы не сможете получить SLO исключительно из Служба приложений соглашение об уровне обслуживания. Как команда рабочей нагрузки, необходимо хеджировать и прогнозировать доступность времени простоя. Однако это прогнозирование может быть неопределенным, поэтому тесное связывание SLO с соглашением об уровне обслуживания платформы может быть проблематичным.
Рассмотрим другой пример. Если Azure Front Door имеет 99,99 % доступности, проект должен соответствовать определенным критериям, опубликованным в соглашении. Например, серверная часть должна включать хранилище, требуется GET операция, которая может получить файл размером не менее 50 КБ, и необходимо развернуть агенты в нескольких местах по крайней мере в пяти географически различных расположениях. Этот узкий вариант использования Azure Front Door не гарантирует такие функции, как кэширование, правила маршрутизации или брандмауэр веб-приложения. Эти аспекты выходят за пределы области обслуживания.
Реализация целевых объектов с несколькими агрегатами
С точки зрения надежности многорегионное развертывание является реализацией принципа избыточности. Цель состоит в том, чтобы снизить риск регионального сбоя или снижения производительности. Эта стратегия, если она правильно разработана, может улучшить SLO, так как она добавляет дополнительный регион в целях отработки отказа.
Существует два основных варианта использования:
Шаблон высокой доступности, в котором распределяете нагрузку между регионами для большей емкости. Высокий уровень доступности не ограничивает пользователей рабочей нагрузки регионом, а производительность всей системы способствует SLO.
Шаблон переборки, в котором клиенты ограничиваются определенными регионами, чтобы сегментировать их. В таких случаях следует рассматривать многорегионные развертывания как отдельные развертывания или метки в каждом регионе. Измеряйте работоспособность каждой метки по отдельности с помощью интерфейсов SLIS, соответствующих рабочей нагрузке. Рассмотрите общий уровень обслуживания рабочей нагрузки на основе работоспособности каждой метки. Если вы можете выполнить отработку отказа между метками, общая рабочая нагрузка SLO выше, так как сбой в одной метке можно восстановить с помощью отработки отказа на другую метку.
Обратите внимание на то, сколько избыточности требуется обеспечить высокий уровень обслуживания. Например, Корпорация Майкрософт гарантирует более высокие соглашения об уровне обслуживания для многорегионных развертываний Azure Cosmos DB, чем гарантируется для развертываний в одном регионе.
Определение метрик восстановления
Определения для реалистичных целевых объектов восстановления, таких как RTO, RPO, MTTR и MTBF, зависят от анализа режима сбоя и планов и тестирования для обеспечения непрерывности бизнес-процессов и аварийного восстановления. При определении этих целевых объектов следует учитывать гарантии восстановления, предоставляемые платформой. Корпорация Майкрософт публикует гарантии RTO и RPO только для некоторых продуктов, таких как База данных SQL Azure.
Прежде чем завершить эту работу, обсудите желаемые цели с заинтересованными лицами и убедитесь, что архитектура поддерживает целевые показатели восстановления в лучшем понимании. Четко сообщает заинтересованным лицам, что все потоки или целые рабочие нагрузки, которые не тщательно протестированы для метрик восстановления, не должны гарантировать соглашения об уровне обслуживания. Убедитесь, что заинтересованные лица понимают, что целевые показатели восстановления могут меняться с течением времени по мере обновления рабочих нагрузок. Рабочая нагрузка может стать более сложной при добавлении клиентов или при внедрении новых технологий для улучшения взаимодействия с клиентами. Эти изменения могут увеличивать или уменьшать метрики восстановления.
Примечание.
MTBF может быть сложно определить и гарантировать. Платформа как услуга (PaaS) или модели SaaS могут завершиться сбоем и восстановиться без каких-либо уведомлений от поставщика облачных служб, и процесс может быть полностью прозрачным для вас или клиентов. Если вы определяете целевые объекты для этой метрики, охватывайте только компоненты, которые находятся под вашим контролем.
При определении целевых объектов восстановления определите пороговые значения для запуска восстановления. Например, если веб-узел недоступен более пяти минут, автоматически добавьте новый узел в пул. Определите пороговые значения для всех компонентов и рассмотрите возможность восстановления для определенного компонента, включая влияние на другие компоненты и зависимости. Пороговые значения также должны учитывать временные ошибки , чтобы не запускать действия восстановления слишком быстро. Задокументируйте и поделитесь с заинтересованными лицами потенциальными рисками, такими как потеря данных или прерывания сеанса для клиентов, операций восстановления.
Мониторинг и визуализация целевых объектов
Используйте собранные данные для целевых показателей надежности для создания модели работоспособности для каждой рабочей нагрузки и связанных критически важных потоков. Модель работоспособности определяет здоровые, деградированные и неработоспособные состояния для потоков и рабочих нагрузок. При изменении состояния модель должна оповещать ответственных сторон. Подробные рекомендации по проектированию и рекомендации см . в руководстве по моделированию работоспособности.
Чтобы обеспечить информирование групп операций и заинтересованных лиц рабочей нагрузки, создайте визуализацию, которая отражает состояние в режиме реального времени и общие тенденции модели работоспособности рабочей нагрузки. Обсудите решения визуализации с заинтересованными лицами, чтобы обеспечить доставку информации, которую они ценят, и это легко использовать. Они также могут видеть созданные отчеты еженедельно, ежемесячно или ежеквартально.
Упрощение функций Azure
Соглашения об уровне обслуживания Azure предоставляют обязательства Майкрософт по обеспечению доступности и подключения. Разные службы имеют разные соглашения об уровне обслуживания, а иногда продукты в службе имеют разные соглашения об уровне обслуживания. Дополнительные сведения см. в разделе об уровне обслуживания для веб-службы.
Соглашение об уровне обслуживания 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: соглашение об уровне обслуживания о финансовых обязательствах для Azure служит прокси-сервером для оценки надежности платформы.
Компонент Azure Применимое соглашение об уровне обслуживания Не распространяется соглашение об уровне обслуживания Скорректированный SLO Azure Front Door 99,99% для успешных операций HTTP GETКэширование, обработчик правил 99.98% Контейнеры приложений 99,95% на основе развернутых приложений, доступных встроенным входящего трафика Автоматическое масштабирование, возможности хранилища маркеров 99,95 % Управляемый экземпляр SQL 99,99% на основе подключения к экземпляру SQL Server Производительность, хранение данных 99,80 % Приватный канал 99,99% на основе целых минут, когда сеть частной конечной точки не принимает трафик или когда трафик не выполняется между конечной точкой и службой Приватный канал Отдельные неудачи длительностью менее одной минуты 99,99 % Корректировка основана на нескольких факторах, которые зависят от обещания рабочей нагрузки команде по их целям. Одним из факторов может быть уверенность в возможностях платформы на основе предыдущего опыта. Например, для контейнерных приложений и Приватный канал команда чувствует себя комфортно, принимая значение 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, следуя принципам хорошо спроектированной платформы для повышения эффективности работы. Они развертывают облачные ресурсы, конфигурацию и код каждого спринта.
Команда считает, что развертывания рискуют, так как они могут дестабилизировать запущенную систему. В результате обновлений сертификатов TLS, изменений DNS или ошибок инструментов могут возникнуть ошибки. Команда также рассматривает потенциальные простои, вызванные аварийными исправлениями. Они бюджетируют в общей сложности 20 минут ежемесячного простоя, что составляет примерно 99,95 % доступности.
Периоды обслуживания определяются периодами времени, в течение которых происходит обслуживание системы или обновления. API в основном не используется примерно на четыре часа каждый день. Чтобы снизить риск недоступности, команда может запланировать задачи обслуживания в течение этих менее активных часов. Этот подход приводит к более высокому SLO, но команда решает не включать период обслуживания в рамках своего SLO.
Составной SLO на основе доступности операций: 99,95% в месяц.
Внешние зависимости SLO: команда рассматривает Управляемый экземпляр SQL в качестве основной зависимости, которая уже имеет 99,80 % доступности в общей доступности платформы. Другие внешние зависимости не рассматриваются.
Составной SLO на основе внешних зависимостей: неприменимо.
Определение общего результата составного SLO
Общий составной целевой объект SLO устанавливается на 99,45%, что эквивалентно примерно четыре часа простоя в месяц.
Чтобы удовлетворить цель SLO всего в четыре часа недоступности в месяц, команда рабочей нагрузки устанавливает смену по вызову. Поддержка клиентов и мониторинг искусственных транзакций могут вызывать поддержку инженерии надежности сайта (SRE) для оперативного запуска действий по восстановлению для решения проблем SLO.
Настройка обслуживания рабочей нагрузки
Соглашение об уровне обслуживания для рабочей нагрузки составляет 99,90 % доступности в месяц.
Юридические и финансовые отделы рабочей нагрузки устанавливают соглашение об уровне обслуживания для рабочей нагрузки на уровне 99,90 % доступности в месяц, что превышает целевой показатель SLO 99,45 %. Они делают это решение после того, как они анализируют финансовые выплаты и прогнозируемый рост клиентов на основе привлекательного соглашения об уровне обслуживания. Соглашение об уровне обслуживания охватывает два основных потока пользователей и включает рекомендации по производительности, а не только доступность. Это вычисляемый риск, принятый бизнес-командой, чтобы воспользоваться бизнесом, и инженерная команда знает о приверженности.
Настройка SLO правильности
Основные потоки пользователей приложения должны быть доступны и удобны, или даже конкурентоспособно, реагировать. Команда задает время ответа SLO специально для API, за исключением времени обработки клиента и обхода сети Интернета. Они оценивают этот SLO только в периоды доступности. Они выбирают 75-й процентиль как целевой объект SLO, так и измерение производительности, которое фиксирует типичный интерфейс клиента и исключает худшие сценарии.
Дополнительные ссылки
Моделирование работоспособности и наблюдаемость критически важных рабочих нагрузок в Azure
Контрольный список надежности
Ознакомьтесь с полным набором рекомендаций.