Skip to content

Instantly share code, notes, and snippets.

@vorlon001
Created May 31, 2024 05:36
Show Gist options
  • Select an option

  • Save vorlon001/51f23e2df898de05fc9cb93b7aeb3e61 to your computer and use it in GitHub Desktop.

Select an option

Save vorlon001/51f23e2df898de05fc9cb93b7aeb3e61 to your computer and use it in GitHub Desktop.
SLI, SLO и SLA. В чем разница? RPO и RTO: Различия в показателях резервного копирования?

SLI — Service Level Indicator

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

Это наша мера успеха.

«Наш сайт был доступен 99% времени за прошлый месяц» — это SLI. Внезапно, это не SLA, как многие привыкли говорить.

SLO — Service Level Objective

Это наша цель. Числовое значение, которого мы хотим достичь и не проваливаться ниже этой границы. Измеряем через SLI. Задает уровень ожиданий от сервиса. Например, SLO = среднее время отклика должно быть ≤100ms

«Мы стремимся, чтобы наш сайт был доступен 99% времени» — это SLO.

SLA — Service Level Agreement

Отвечает на вопрос «Что случится если SLO не соблюдаются?».

Это явный или неявный контракт с клиентами или пользователями системы в котором описаны последствия несоответствия SLO.

«Будет предоставлена компенсация в случае, если наш сайт будет доступен менее 99% времени» — это SLA

Зачастую используются внутренние SLO, более жесткие, чем те, что мы показываем пользователям. Например, мы утверждаем, что система доступна 99,9% времени, а инженерная команда стремится обеспечивать 99,99%, таким образом появляется некий буфер перед штрафами по SLA.

Помните, что SLI — это измерение, SLO — это цель, а SLA — это обязательство.

Цель инженера по SRE — обеспечить надёжную работу системы. Он занимается тем же, что раньше входило в задачи системного администратора, — решает инфраструктурные проблемы.

Что такое MTTR?

MTTR - среднее время восстановления. Этот показатель измеряет среднее время, необходимое для восстановления работы системы или сервиса после возникновения сбоя. MTTR важен, поскольку он позволяет оценить, насколько быстро ИТ-команды могут восстановить работу после сбоя или отказа.

MTTR рассчитывается путем деления общего времени простоя на количество инцидентов, произошедших за этот период времени. Например, если система была недоступна в течение 10 часов из-за сбоя, и за этот период времени произошло два инцидента, то MTTR будет равен 5 часам (10 часов / 2 инцидента = 5 часов).

Что такое MTTD?

MTTD - среднее время обнаружения. Этот показатель измеряет среднее количество времени, необходимое для обнаружения сбоя или простоя. MTTD важен, поскольку он позволяет оценить, насколько быстро ИТ-команды могут выявлять проблемы и реагировать на них. Чем меньше MTTD, тем быстрее ИТ-команды смогут реагировать на проблемы и тем меньшее влияние эти проблемы окажут на клиентов.

MTTD рассчитывается путем деления общего времени между возникновением сбоя и его обнаружением на количество инцидентов за этот период времени. Например, если сбой произошел в 12:00 и был обнаружен в 12:30, и за этот период времени произошло два инцидента, MTTD будет равен 15 минутам (30 минут / 2 инцидента = 15 минут).

RPO и RTO: Различия в показателях резервного копирования

Показатели точки восстановления (RPO — Recovery Point Objective) и времени восстановления (RTO — Recovery Time Objective) позволяют организации узнать, какой объем данных она может потерять и как долго её сервисы могут быть недоступны — это ключевые элементы плана резервного копирования и плана аварийного восстановления.

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

Что такое RTO?

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

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

RTO-время-восстановления

Что такое RPO?

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

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

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

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

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

url:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment