что такое сетевая доступность

Высокая доступность проектов. Что такое «пять девяток» и где их взять?

Высокая доступность — это то, что любят демонстрировать в цифрах. Все уже привыкли к маркетинговым ходам и доступность в 99% кажется просто фантастически высокой. Лишь малая часть клиентов понимают, что доступность 98- 99% это очень плохая, местами никуда не годная цифра.

Посмотрите на эти цифры и вы поймете, чем доступность в 90% отличается от доступности в 99,999%:

ДоступностьВремя простоя в месяцВремя простоя в год
90%3 дня37 дней
98%14,6 часов7,3 дня
99%7,3 часа3,7 дней
99,8%1,5 часа18 часов
99,9%44 минуты8.8 часов
99,99%4.4 минуты53 минуты
99,999%26 сек5,3 минуты

Посмотрев на таблицу выше вы понимаете, что датацентр, гарантирующий сетевую доступность в 99% может позволить себе 7 часов простоя в месяц. Представьте себе такую ситуацию: весь день в датацентре что-то чинят, ваш сайт недоступен, вы несете убытки, а предъявить претензии датацентру не можете — даже при этой ситуации он обеспечит обещанную доступность.

Я считаю сетевую доступность 99% плохой. Предпочитаю датацентры, обеспечивающие не менее 99,9% сетевой доступности.

Наверное, существуют интернет-проекты, которые могут пережить и 37 дней простоя в год (больше месяца!). Но всё-таки большинство интернет-магазинов, порталов и сайтов ( в особенности тех, чьи транзакции проходят через сайт) не могут себе позволить такой роскоши, как даже 18 часов в год. Репутацию восстановить сложно всегда, а если она теряется по причинам “у системного администратора выходной” это и вовсе обидно.

“Пять девяток” — вот, что такое высокая доступность

Термин “пять девяток” означает доступность 99,999% и встречается в маркетинговой литературе не реже, чем в технической. Считается, что сайт или система с уровнем доступности «пять девяток» — это и есть высокая доступность.

что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступностьВысокая доступность нужна всем

Из таблицы видно, что 99,999% доступности — это всего 5,3 минуты простоя в год. Но даже те датацентры, которые гарантируют 100% доступность нередко пускаются на маркетинговые ухищрения.
Например, вычитают время регламентного обслуживания из времени доступности. К примеру, дата-центр обещает доступность 99.99%, но в момент, когда проводит плановые работы по замене чего-нибудь пишет “проводятся регламентные работы в течение 2 часов” и не считает это за недоступность. Отсюда вывод — читайте соглашение об уровне обслуживания (SLA) внимательно.

Если вы хотите обеспечить максимально высокую доступность вашему сайту на одном единственном сервере, выбирайте датацентр с хорошей ГАРАНТИРОВАННОЙ SLA (соглашением об уровне обслуживания) доступностью.

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

Кроме того, ваш админ должен отслеживать работу сервиса и быстро реагировать на недоступность.

Немного о том, из чего складывается высокая доступность

Доступность может быть сетевая и сервиса.

Сетевая доступность — это когда ваш сервер доступен по сети.
Доступность сервиса — это когда ваш сервер может обслуживать клиентов.

Доступность сервиса не может быть лучше сетевой доступности, если вы не используете альтернативных подключений (со своей сетевой доступностью).

Доступность сервиса зависит от:

Недоступность складывается из:

И месячную (кроме случаев поломки железа) и уж тем более годовую доступность 99,8% можно обеспечить в хорошем ДЦ на одном сервере без дополнительных мер обеспечения отказоустойчивости. Доступность 99,9% уже требует некоторого везения.

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

Источник

SLA на облако: как читать и на что обратить внимание

что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступность

Сегодня хочу поговорить о том, как читать Service Level Agreement в договоре на облачные сервисы. SLA – это норма: клиенты требуют его на этапе запроса, провайдеры указывают заветные девятки во всех материалах. Отрицать не буду – без SLA плохо, но какие зоны ответственности затрагивает соглашение, не всегда понятно. Попробуем разобраться, что же это такое и когда бежать к провайдеру, размахивая договором, а когда искать проблему на месте.

Простой пример: у клиента перестает работать ВМ, клиент сразу думает, что проблема в инфраструктуре. И смотрит, что же там в SLA по поводу доступности. А может, на самом деле зависла ОС, клиентская сеть лагает, — предположить можно всё что угодно. Если проблема внутри ОС, то провайдер ресурсов тут не поможет.

Если мы не администрируем клиентские виртуальные машины, то и приложения внутри для нас – черный ящик. При этом самые частые отказы находятся как раз на стороне приложения. Может случиться что угодно: переполнятся диски, учетные записи заблокируются, DNS откажет, компоненты приложения перестанут взаимодействовать из-за неправильных настроек. А может оказаться, что системное время выставлено неверно или установилось ненужное обновление. Такие проблемы не являются нарушением SLA и решаются на стороне клиента. Так когда же он действует?

SLA – что это такое и для чего

SLA – это своего рода гарантийный талон на услугу. Но это не просто пункт с девятками в основном договоре. Это развернутое приложение, в котором фиксируются все параметры оказываемой услуги. Правильно составленное приложение страхует и клиента, и сервис-провайдера.

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

В хорошем SLA на виртуальную инфраструктуру должны быть:

Доступность

Доступность – это те самые девятки, которые чаще всего выдаются за SLA. Проценты доступности переводятся в минуты и часы недоступности сервиса в месяц или год.

ДоступностьПростой в месяцПростой в год
99%7 час. 18 мин. 17,5 сек.3 дня 15 час. 39 мин. 29.5 сек.
99,9%43 мин. 49,7 сек.8 час. 45 мин. 57 сек.
99,95%21 мин. 54,9 сек.4 часа 22 мин. 58,5 сек.
99,982%7 мин. 53,4 сек.1 час 34 мин. 40,3 сек.

Все варианты можно посмотреть здесь.
Казалось бы, всё понятно, в чем же подвох?

Месяц или год. Не зря я наверху выбрал две колонки – месяц и год. Когда видите заветные девятки в SLA, обратите внимание, к какому периоду они относятся. Чаще всего провайдеры говорят о месяце. То есть при доступности 99% мы получаем 7 с лишним часов даунтайма в месяц, а не в год. Уточняйте этот момент, чтобы потом не было разочарований.

Девятки и инфраструктура. Если вам необходим определенный уровень отказоустойчивости сервиса, то и виртуальная инфраструктура должна быть построена таким образом, чтобы эту доступность обеспечивать. Так, для достижения уровня доступности 99,95% вам, как минимум, понадобится кластер active-passive. Если вы хотите перешагнуть за 99,982% (уровень доступности в дата-центрах Tier III), вам нужно строить систему, распределенную по нескольким ЦОД.

Выбирая конфигурацию виртуальной инфраструктуры, ответьте себе на вопрос: нужны ли вам пять девяток? Девятки не должны быть самоцелью. Во-первых, чем больше девяток, тем дороже для вас будет стоить система. Каждая следующая честная девятка будет добавлять нолик справа к стоимости! Во-вторых, не каждый сервис требует геораспределенного кластера.

Если вы выбираете облачные ресурсы, определитесь, какую задачу вы решаете сейчас: строите тестовую среду или холодный резерв или размещаете критические сервисы – интернет-магазин, платежную систему или CRM.

Совокупная доступность. Если ваше приложение имеет доступность 99,5%, облако имеет доступность 99,95%, а дата-центр, где оно развернуто, – 99,982%, то на выходе вы будете иметь доступность не выше 99,5%. Так как доступность всего сервиса не может быть выше доступности самого слабого его звена. Помните об этом при выборе сервиса и не пытайтесь лечить перелом подорожником. Защищенный геораспределенный кластер не спасет падающее через день приложение.

Не доступностью единой

Доступность для ИТ-сервисов – главный параметр. Но и при стопроцентном аптайме виртуальная машина может жестко тупить из-за сетевых задержек, недостаточного количества IOPS, высокой latency СХД и прочих проблем. Поэтому в правильном SLA должны быть все качественные метрики по инфраструктуре. На что смотреть и к чему стремиться?

секунды. Поэтому норма для этого параметра – в пределах от 0 до 1%. Как и в случае с сетевой задержкой, уточните у провайдера, где заканчивается его ответственность.

В SLA также следует прописать способы измерения и мониторинга по каждому параметру. Например, так:

что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступность

Запросы, инциденты и технические работы

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

Решение инцидентов. Все возможные поломки не предугадать. Но типовые причины недоступности сервиса должны быть прописаны в SLA. Еще раз отмечу, что соглашение затрагивает только неполадки на стороне провайдера и не распространяется на ошибки внутри ВМ. Все инциденты делятся по приоритетам, в зависимости от того, ведут они к полной недоступности сервиса или к частичной деградации. На каждый приоритет определяется максимальный срок устранения.

Если используете разные типы дисков, не забудьте прописать инциденты по каждому из них:

что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступность

Пример инцидентов первого приоритета.

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

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

Кроме того, SLA может ограничивать число заявок, которое вы можете открыть у провайдера в месяц.

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

Мы делим запросы на три типа, которые отличаются по характеру работ и времени исполнения:

Проведение регламентных работ и уведомление. Инфраструктура – это живой организм. Ее нужно обслуживать: апгрейдить, накатывать критические обновления, проводить плановые работы (например, обновлять прошивку на серверах). Не все работы можно сделать без остановки сервиса. Поэтому в SLA фиксируется порядок уведомления о таких работах, время проведения работ и возможное время перерыва в сервисе. Проверяйте, чтобы срок уведомления о плановых работах был достаточным и было зафиксировано максимальное время остановки сервиса.

У нас это выглядит так:

что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступность

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

Если в SLA есть все описанные выше пункты, то вы получаете сервис с прозрачными гарантиями и уровнем доступности. Врать в SLA невыгодно, так как от штрафов отбрехаться не получится. Но и подогнать под SLA поломки из-за косных приложений или неправильной настройки ВМ не удастся.

Если есть вопросы, традиционно жду в комментариях. Здорового вам облака!

Источник

Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA

Сегодня я постараюсь разъяснить, что такое концепция доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т.д. Надеюсь, что эта статья будет полезна читателям при составлении экономического обоснования на внедрение соответствующих программных и\или аппаратных решений, а также соглашений об уровне обслуживания (SLA) – а кому-то поможет сделать эти документы более убедительными.
Для начала в качестве «узелков на память» сформулирую два постулата, с которыми многие, уверен, довольно хорошо знакомы:

что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступность

Начнем «от печки», то есть с прямой линии вдоль оси времени, где:

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

что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступность

Из такого графика уже видно, что стоимость простоя сервиса растет со временем: чем дольше не работает система, тем больше денег теряет компания.

Тоже самое и со стоимостью потерь данных: чем больше мы их (в исторической перспективе) теряем, тем дороже такая потеря обойдется компании. И да, эти графики в живой природе не симметричны.

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

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

что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступность

Как видно из графика, чем меньше показатели RPO и RTO при потере данных, чем меньшее время простоя сервиса обеспечивает решение по защите, тем дороже такая защита стоит.

Определим точки безубыточности решения по защите

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

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

На самом деле, если мы построим такие графики, ориентируясь на данные из реальной жизни, то получим несколько иную картину. В частности, график стоимости решения по защите будет иметь вид не сплошной линии, а множества точек. Различные защитные решения не выстраиваются вплотную друг за другом вдоль графика, а представляют собой отдельные точки, ведь каждое имеет свои «координаты»: стоимость (обозначенная вендором-производителем данного решения) и время обеспечения этим решением соответствующих потерь данных (RPO) и скорости восстановления работоспособности (RTO).

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

Получается, что наши точки безубыточности – уже не точки, а области:
что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступность

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

Рассматриваем различные классы решений

Обратите внимание, до сего момента я говорил про «защиту», но не оговаривал, что это за защита конкретно: резервное копирование, кластер, какие-то еще виды защиты? Тут стоит сказать, что системы защиты бывают разные, и их можно классифицировать.

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

что такое сетевая доступность. Смотреть фото что такое сетевая доступность. Смотреть картинку что такое сетевая доступность. Картинка про что такое сетевая доступность. Фото что такое сетевая доступность

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

Например, сейчас многие решения по резервному копированию используют технологию запуска сервиса из резервной копии. Время обеспечения доступности при использовании такой технологии — в среднем

2-5 минут на одну ВМ. И такие показатели находятся в рамках RTO для реплик или даже кластеров.

Немного о кластерах

Кластеры, как и DR-решения (и вообще практически все решения по защите от потерь данных или восстановлению работоспособности) имеют свои значения по скорости восстановления данных и объемам данных, которые теряются. Потому они также связаны со своими показателями RTO/RPO.

Говоря, например, про HA-кластер (HA – High Availability), имеем в виду, что его RTO равно времени переключения. Допустим, MSCS для двух нод переключает СУБД за 30 секунд. Значит, целевое RTO, которое можно обеспечить этим видом кластера — от 30 секунд.

А если рассмотреть VMware HA, которое отработает за 2 минуты (с учетом старта виртуальной машины, ее гостевой ОС и приложений)? Значит, такое решение подходит для приложений с целевым значением RTO от 2 минут.

Где же потери для HA-кластера (и соответственно, обеспечение RPO), спросите вы? Когда сервис поднимается, есть вероятность небольших потерь данных. Например, если СУБД проверит состояние базы данных и может откатить своё состояние на некорректно проведенную транзакцию. Или если файловая система вернется к некорректно сохраненной версии файла, и т.д., и т.п.

Вывод: не всегда стоит строить одинаковые решения одно поверх другого, например, HA над HA. Это только излишне усложнит инфраструктуру, усложнит (и удорожает) поддержку работы таких систем.

К предыдущим примерам двух HA. Определите, какое реальное значение RTO необходимо обеспечить для приложения? Для значений больше 2 минут нет смысла стоить еще и HA-кластер для сервисов внутри ВМ.

Обратим внимание еще на ряд факторов:

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

Что при этом дает совместное использование VMware vSphere HA? Быстрое восстановление уровня защиты. Если просто выключился один сервер с одной нодой MS Exchange, то вначале отработает DAG, переключив сервисы на другую ноду, а затем HA VMware загрузит сбойный сервер на другом плече своего кластера. И система готова к работе. (Хотя в этом примере я бы рассматривал применение виртуализации не только для одной функции только кластера, но и для всех остальных преимуществ самой платформы).

Говорим и пишем правильно! Или еще раз про RTO и RPO

Хочу сделать на этом акцент, поскольку я сам периодически совершаю ошибку, потому и остерегаю от этого вас:

RTO ≠ скорость восстановления!
RPO ≠ количество потерянных данных!

RTO и RPO – это целевые значения для информационных систем (ИС), максимальные рамки, в которые мы должны уложиться. И эти целевые значения нам, ИТ-специалистам, сообщает бизнес, точнее, бизнес-владельцы соответствующей ИС, но не наоборот.

То есть:
Нельзя сказать, что RTO функции Instant Recovery – 2 минуты.
Нельзя считать, что резервное копирование раз в сутки и есть RPO 24 часа.
Всё идет в обратную сторону, то есть от бизнеса, и конкретно для RTO будет озвучиваться так:

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

Для базы данных, в случае сбоя СУБД, нужно обеспечить восстановление с допустимой потерей данных сроком не более 24 часов от момента сбоя. Значит, подойдет решение, которое обеспечит гарантированное восстановление базы из точек восстановления, производимых чаще, чем 1 раз в сутки. При этом отмечу, что резервное копирование раз в час, создающее 24 точки восстановления, дает больше гарантий восстановления, чем копирование раз в сутки, делающее только 1 точку.

А вот и практический пример

Казалось бы, можно рассуждать так:

«Применение функции Instant Recovery обеспечит технический процесс восстановления в 2 минуты. »

Но! При этом надо понимать еще несколько моментов:

Поэтому рассуждаем дальше:

«У меня настроен мониторинг для этого сервиса, и оповещение сработает и будет замечено за минуту-две (телефон с полученной СМС надо из кармана достать, или почтовый клиент с новым письмом надо открыть). Я сяду за компьютер, пингану сервис, попытаюсь открыть на нем консоль, посмотрю, что там с гипервизором и железом. Проведу первичную реанимацию (попробую перегрузить машину). На все это я потрачу порядка 15 минут. Если не помогут действия по быстрой реанимации — восстановлюсь из резервной копии. Но так как копироваться из бэкапа данные будут еще минут 15-20, то я воспользуюсь Instant VM Recovery за 2 минуты, а затем запущу онлайн перенос данных машины в продакшен.»

Как видим, в 5 минут мы вряд ли укладываемся.

Теперь подумаем, возможно, нужен HA-кластер со временем восстановления 2 минуты? Но и он не обеспечит нам защиту от всех типов сбоев: рестарт машины в BSoD вполне вероятен, диск ВМ — тоже точка отказа, и т.п. Следовательно нужна дополнительная защита. Значит, продолжаем наши рассуждения:

«В случае кластера я восстановлюсь за 2 минуты. А в дополнение я потрачу, как уже прикинул(а), 15+2 минут при восстановлении из резервной копии, всего 2+15+2=19 минут, и 11 минут ещё остаются в запасе.»

В итоге, ваш ответ бизнес-владельцу ИС будет таким:

«ОК. Я обеспечу RTO в 30 минут. Я включу этот сервис в кластер — для обеспечения 5 минутного RTO, и настрою резервное копирование — для защиты от сбоев с более серьёзными последствиями.»

Очень важно! Самый главный совет: после того, как вы согласовали с владельцем ИС конкретные целевые показатели, договорились – обязательно фиксируйте ваши договоренности с ним в письменном виде, подписывайте с ним соглашение об уровне обслуживания (SLA).

Почему мы называем это «концепцией доступности»?

Заметили, что я пишу постоянно «восстановление данных и восстановление работоспособности сервиса»? Чаще всего пишу вместе, в одном предложении. Это две связанные между собой вещи, которые почти всегда не могу жить друг без друга.

Мы восстановили работу сервиса, но при этом потеряли все его данные – это неприемлемо. Мы восстановили БД, но СУБД не запускается, прочитать данные не могут – это неприемлемо. Именно поэтому мы говорим о доступности и данных, и сервисов. Важны и RPO, и RTO – в совокупности они обеспечивают доступность и того, и другого.

Через 15 минут после сбоя восстановлен доступ к сервису с данными за весь предыдущий период работы (до 1 часа включительно) – это всё про общую доступность.

Вот такой вот дуализм 😉 Вместе дуальная пара RTO и RPO является важным показателем в том самом соглашении об уровне обслуживания (Service Level Agreement, или SLA) для конкретной ИС в части обеспечения доступности её сервисов и данных в случае возникновения сбоя. А подписывается соответствующее соглашение, как я говорил выше, между владельцем ИС (заказчиком услуги), и вами, ИТ-отделом (поставщиком услуги).

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *