Что такое доступность системы
Доступность системы
Смотреть что такое «Доступность системы» в других словарях:
доступность системы — 3.3 доступность системы: Вероятность получения потребителем в рабочей зоне достоверной информации о своем местоположении в заданный момент времени и с требуемой точностью. Выражается в процентах времени на определенном временном интервале, в… … Словарь-справочник терминов нормативно-технической документации
доступность — 2.4 доступность (availability): Свойство объекта находиться в состоянии готовности и используемости по запросу авторизованного логического объекта. [ИСО/МЭК 7498 2] Источник … Словарь-справочник терминов нормативно-технической документации
Доступность — (туристический словарь) уровень затрат на преодоление препятствий. Доступность информации (ресурсов информационной системы) избежание временного или постоянного сокрытия информации от пользователей, получивших права доступа.… … Википедия
доступность информации [ресурсов информационной системы] — Состояние информации [ресурсов информационной системы], при котором субъекты, имеющие права доступа, могут реализовать их беспрепятственно [1]. Примечание К правам доступа относятся право на чтение, изменение, копирование, уничтожение информации … Справочник технического переводчика
Системы дифференциальной коррекции — (Дополнения глобальных навигационных спутниковых систем, англ. GNSS Augmentation) методы улучшения характеристик работы навигационной системы, такие, как точность, надежность и доступность, через интеграцию внешних данных в процессе… … Википедия
Доступность радионавигационной системы — Доступность (эксплуатационная готовность) это способность радионавигационной системы обеспечить проведение навигационных определений в заданный момент времени в определенной зоне действия. Источник: Приказ Минпромторга РФ от 02.09.2008 N 118 Об … Официальная терминология
Доступность информации — Статья описывает одно из основополагающих понятий теории информационной безопасности. Содержание 1 Область использования 2 Определения понятия … Википедия
Доступность информационных активов организации банковской системы — 3.34. Доступность информационных активов: Свойство ИБ организации банковской системы Российской Федерации, состоящее в том, что информационные активы предоставляются авторизованному пользователю, причем в виде и месте, необходимых пользователю, и … Официальная терминология
доступность (информации — 3.1.9 доступность (информации [ресурсов автоматизированной информационной системы]): Состояние информации [ресурсов автоматизированной информационной системы], при котором субъекты, имеющие право доступа, могут реализовать их беспрепятственно.… … Словарь-справочник терминов нормативно-технической документации
доступность А — 2.3.1 доступность А: Готовность спутников в рабочей зоне системы на любом 24 часовом интервале, в течение которого с 95 % ной вероятностью прогнозируемая погрешность местоопределения меньше порогового значения для любой точки рабочей зоны системы … Словарь-справочник терминов нормативно-технической документации
доступность системы
3.3 доступность системы: Вероятность получения потребителем в рабочей зоне достоверной информации о своем местоположении в заданный момент времени и с требуемой точностью. Выражается в процентах времени на определенном временном интервале, в течение которого обеспечиваются заданные условия.
3.1.3 доступность системы: Вероятность получения потребителем в рабочей зоне достоверной информации о своем местоположении в заданный момент времени и с требуемой точностью. Выражается в процентах времени на определенном временном интервале, в течение которого обеспечиваются заданные условия.
3.1.3 доступность системы: Вероятность получения потребителем в рабочей зоне достоверной информации о своем местоположении в заданный момент времени и с требуемой точностью. Выражается в процентах времени на определенном временном интервале, в течение которого обеспечиваются заданные условия.
Полезное
Смотреть что такое «доступность системы» в других словарях:
Доступность системы — [system availability, accessibility] см. Механизм обслуживания … Экономико-математический словарь
доступность — 2.4 доступность (availability): Свойство объекта находиться в состоянии готовности и используемости по запросу авторизованного логического объекта. [ИСО/МЭК 7498 2] Источник … Словарь-справочник терминов нормативно-технической документации
Доступность — (туристический словарь) уровень затрат на преодоление препятствий. Доступность информации (ресурсов информационной системы) избежание временного или постоянного сокрытия информации от пользователей, получивших права доступа.… … Википедия
доступность информации [ресурсов информационной системы] — Состояние информации [ресурсов информационной системы], при котором субъекты, имеющие права доступа, могут реализовать их беспрепятственно [1]. Примечание К правам доступа относятся право на чтение, изменение, копирование, уничтожение информации … Справочник технического переводчика
Системы дифференциальной коррекции — (Дополнения глобальных навигационных спутниковых систем, англ. GNSS Augmentation) методы улучшения характеристик работы навигационной системы, такие, как точность, надежность и доступность, через интеграцию внешних данных в процессе… … Википедия
Доступность радионавигационной системы — Доступность (эксплуатационная готовность) это способность радионавигационной системы обеспечить проведение навигационных определений в заданный момент времени в определенной зоне действия. Источник: Приказ Минпромторга РФ от 02.09.2008 N 118 Об … Официальная терминология
Доступность информации — Статья описывает одно из основополагающих понятий теории информационной безопасности. Содержание 1 Область использования 2 Определения понятия … Википедия
Доступность информационных активов организации банковской системы — 3.34. Доступность информационных активов: Свойство ИБ организации банковской системы Российской Федерации, состоящее в том, что информационные активы предоставляются авторизованному пользователю, причем в виде и месте, необходимых пользователю, и … Официальная терминология
доступность (информации — 3.1.9 доступность (информации [ресурсов автоматизированной информационной системы]): Состояние информации [ресурсов автоматизированной информационной системы], при котором субъекты, имеющие право доступа, могут реализовать их беспрепятственно.… … Словарь-справочник терминов нормативно-технической документации
доступность А — 2.3.1 доступность А: Готовность спутников в рабочей зоне системы на любом 24 часовом интервале, в течение которого с 95 % ной вероятностью прогнозируемая погрешность местоопределения меньше порогового значения для любой точки рабочей зоны системы … Словарь-справочник терминов нормативно-технической документации
Доступность ИТ-сервисов как ключевой бизнес показатель, и причем тут арбуз
Но есть у этого благородного начинания серьезное препятствие (философскую проблему “Можно ли все свести к числу” оставим для другой, профильной площадки и антиутопий типа “Черного зеркала”). В бизнесе метрик очень и очень много, а в ИТ их страсть сколько. В результате объем данных растет, количество наблюдаемых параметров также увеличивается. Мы начинаем делить метрики на ключевые и второстепенные, на метрики для бизнеса и метрики для “технарей”. Мы теряем фокус и вместо прозрачности получаем несвязный набор тысяч показателей. Погружаясь в свои метрики, сотрудники теряют из вида ключевую цель организации: решать “боли” своих клиентов, делать их жизнь лучше и получать за это вознаграждение. В результате мы получаем то, что принято называть “эффектом арбуза”, когда кожура “зеленых” метрик скрывает “красную и накаленную” сердцевину нашего бизнеса: удовлетворенность клиентов.
Идеальная метрика
Впервые я с этим столкнулся в самом начале своей карьеры. Тогда я работал сетевым инженером в региональном операторе связи, и в мои обязанности входила обработка метрик из системы мониторинга для подготовки KPI-отчета по техническому блоку. За основу брались данные о том, “пингуется” или нет узел связи (без привязки количества абонентов, которые от него зависят). Но в жизни качество предоставляемых провайдером услуг измеряется далеко не прохождением ICMP-пакетов от сервера мониторинга до коммутатора в подъезде, тем более, когда эти коммутаторы находятся в своем “стерильном VLAN-е”. Этого, наверное, не знали, но смогли прочувствовать на себе абоненты, особенно, нового в то время сервиса: IPTV через multicast. Зависающие картинки на телевизорах абонентов никак не коррелировали с прекрасной зеленой картинкой, подаваемой на стол руководства, и премиальным фондом. Результатом стала проваленная маркетинговая кампания по продвижению IPTV и немного пошатнувшаяся репутация. А дальше по цепочке: пересмотр KPI для инженеров с включением в него кучи новых метрик (в том числе и с бизнес уклоном), весовых коэффициентов, которые было просто невозможно рассчитать, и на которые было сложно повлиять. И вишенка на торте: восприятие сотрудниками KPI в качестве репрессивного инструмента сокращения зарплаты, и полная неэффективность его регуляторной функции. Я думаю, что у вас будет много подобных примеров из практики, особенно если коснуться такой острой темы как KPI и SLA. Вообще тема KPI, особенно в IT, заслуживает отдельного остросюжетного романа.
Я вспомнил описанную выше историю, когда практически одновременно несколько корпоративных заказчиков обратились с проблемой непрозрачного расчета SLA и KPI своих ИТ-подразделений. Стоит пояснить, что сейчас я работаю над продуктом зонтичного мониторинга для оперативного обнаружения и устранения сбоев в ИТ, и нашим продуктом пользуется ряд очень крупных клиентов из разных сфер: от госуправления и финтеха до СМИ и авиакомпаний.
В итоге мы сошлись во мнении, что одним из выходов является создание единой синтетической (интегральной) метрики, понятной всем сторонам. По крайней мере, введение такой метрики позволит снизить цифровой шум и, что немаловажно, задаст нашей ИТ-службе некий ориентир для принятия правильных для бизнеса решений. А еще, совсем идеально, если эта метрика позволяла бы непредвзято оценивать, на какой области нашего ИТ-окружения нам следует сосредоточить внимание (здравствуй, бюджетное планирование и портфель проектов). Таким образом, эта идеальная синтетическая метрика должна удовлетворять следующим условиям:
Бизнес-ориентация. Метрика должна отражать работу нашего ИТ-окружения не с позиции работоспособности какого-либо сервера, а с позиции того, насколько это важно нашим клиентам;
Понятность. Метрику можно однозначно интерпретировать как техническим специалистам, так и бизнесу.
Декомпозируемость. По результатам можно провести анализ, разложить нашу единую синтетическую метрику на компоненты/факторы и выделить наиболее критический. В идеальном случае на выходе получить root cause анализ.
В итоге было предложено два варианта реализации: 1) метрика доступности сервиса/объекта (Service Availability); 2) карта здоровья (Health Map). Карта здоровья в итоге оказалась более сложной как в реализации, так и в аналитическом сопровождении, и была определена как перспективная целевая схема, и на время ее доработки был выбран более простой и привычный подход с оценкой доступности сервиса, о котором и пойдет дальше речь.
Особенности реализации
При построении отчета необходимо прежде всего определить список аварийных ситуаций или их совокупности, которые свидетельствуют о нарушении работы сервиса. Определить также такие дополнительные параметры (при необходимости), как:
Время работы сервиса. Например, нам важно, чтобы услуга была доступна только в дневные часы и только по праздникам;
Учитываем или нет согласованные сервисные окна.
Вдобавок стоит учесть подтверждение аварийных ситуаций инженерами (если мы им доверяем, и такой механизм у нас есть). Потому что системы мониторинга имеют свойство иногда ошибаться.
Собственно методика
Итак, вначале рассчитаем доступность для одной КЕ. К этому этапу мы уже настроили все фильтры и определились с параметрами нашего расчета.
Для расчета доступности за период SA (Service Availability) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t), которая в каждый момент времени принимает одно из четырех значений:
Значение (0) говорит о том, что в конкретный момент времени на КЕ не зафиксированы проблемы, отвечающие фильтру;
Значение (N), что КЕ находится в необслуживаемом состоянии;
Значение (S), что КЕ находится в согласованном сервисном режиме.
В результате мы получим следующие показатели:
Расчет доступности за период для одиночной КЕ SA (Service Availability) осуществляется по формуле:
SA =timeWorkingOK / (timeWorkingOK+timeWorkingProblem) * 100%
Рис.1 Пример возможного распределения интервалов времени при расчете SA (Service Availability) для одной КЕ Рис. 2 Пример влияния RTO на расчет функции fProblem(t)
Для группового расчета доступности за период SAG (Service Availability Group) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t) для каждой КЕ, входящей в группу. Далее наложить получившиеся функции fProblem(t) по каждой КЕ друг на друга, исходя из определенных правил (см. Табл. 1)
Alex tools
Основы дизайна систем: доступность системы
Под доступностью полезно понимать отказоустойчивость системы. Если система достаточно устойчива, чтобы обрабатывать отказы в сети, базе данных, серверах и т. д., то ее обычно можно рассматривать как отказоустойчивую систему (fault-tolerant system), что делает ее доступной.
Количественная оценка доступности
Чтобы количественно оценить доступность системы, мы вычисляем процент времени, в течение которого основные функции и операции системы доступны (время безотказной работы) в заданном временном окне.
Наиболее критически важные для бизнеса системы должны иметь почти идеальную доступность. Системы, которые поддерживают очень изменчивые потребности и нагрузки с резкими пиками и минимумами, могут обойтись немного более низкой доступностью в непиковое время.
Все зависит от использования и характера системы. Но в целом, даже вещи, которые имеют низкие, но постоянные требования или подразумеваемую гарантию того, что система работает «по запросу», должны иметь высокую доступность.
Другой вид доступности можно понять в контексте массовых покупок в электронной коммерции, таких как Черная пятница или распродажа в Киберпонедельник. В эти дни спрос будет стремительно расти, и миллионы будут пытаться получить доступ к сделкам одновременно. Для этого потребуется чрезвычайно надежная система с высокой доступностью, способная выдержать эти нагрузки.
Так что время безотказной работы чрезвычайно важно для успеха. Стоит помнить, что показатели коммерческой доступности рассчитываются на основе годовой доступности, поэтому время простоя 0,1% (т.е. доступность 99,9%) составляет 8,77 часа в год!
В современном мире это неприемлемо для крупномасштабных или критически важных услуг. Вот почему в наши дни «пять девяток» считается идеальным стандартом доступности, потому что это означает простоя чуть более 5 минут в год.
Чтобы сделать онлайн-услуги конкурентоспособными и соответствовать ожиданиям рынка, поставщики онлайн-услуг обычно предлагают соглашения об уровне обслуживания/гарантии. Это набор показателей гарантированного уровня обслуживания. 99,999% времени безотказной работы является одним из таких показателей и часто предлагается в рамках премиальных подписок.
В случае поставщиков баз данных и облачных сервисов это может быть предложено даже на пробном или бесплатном уровнях, если основное использование клиентом этого продукта оправдывает ожидание такой метрики.
Во многих случаях невыполнение SLA дает клиенту право на кредит или другую форму компенсации за невыполнение поставщиком этих гарантий.
SLA являются важной частью общих коммерческих и технических соображений при проектировании системы. Особенно важно учитывать, действительно ли доступность является ключевым требованием для части системы и для каких частей требуется высокая доступность.
Проектирование системы высокой доступности
Итак, если вашему приложению требуется, чтобы пользователи прошли проверку подлинности для его использования, и есть только одна служба проверки подлинности и серверная часть, и это не удается, то, поскольку это единственная точка отказа, ваша система больше не может использоваться. Имея две или более служб, которые могут обрабатывать аутентификацию, вы добавляете избыточность и устраняете (или уменьшаете) единые точки отказа.
Следовательно, вам необходимо понять и разобрать вашу систему на все ее части. Определите, какие из них могут вызвать единичные точки отказа, какие из них не терпят таких отказов, а какие части могут их терпеть. Поскольку разработка высокой доступности (HA) требует компромиссов, некоторые из этих компромиссов могут быть дорогостоящими с точки зрения времени, денег и ресурсов.
Обеспечение доступности данных и сервисов: показатели 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) для конкретной ИС в части обеспечения доступности её сервисов и данных в случае возникновения сбоя. А подписывается соответствующее соглашение, как я говорил выше, между владельцем ИС (заказчиком услуги), и вами, ИТ-отделом (поставщиком услуги).