Доступность программы что это

Содержание

Пять вещей, которые каждый юрист должен знать о цифровой доступности

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

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

У вас есть сайт? Отправить письмо? Разделить документы? Подписать контракты? Думаете о фирменном мобильном приложении?

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

У вас есть клиенты с веб-сайтами, приложениями и информацией? Или технологии, уникальные для их полей (#HealthIT? #FinTech? #MedTech? #RetailTech?) Ваши клиенты также должны знать о доступности.

Что такое цифровая доступность?

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

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Цифровая доступность означает, что люди с ограниченными возможностями могут использовать технологию

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

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

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

Эта доступность включает в себя веб-сайты и мобильные приложения, закодированные и предназначенные для международных стандартов доступности, чаще всего это Руководство по доступности веб-контента (WCAG) 2.0 уровня AA. Но хороших методов кодирования недостаточно. Также необходимы процедуры обеспечения качества, испытания, направленные на предотвращение и диагностику барьеров доступности, бизнес-процесс, который их устраняет, протоколы обслуживания клиентов и обучение персонала.

Доступность — это не один и не сделанный аспект любого бизнеса, включая юридическую фирму. Это постоянное обязательство, которое лучше всего подходит для культуры доступности. У многих компаний есть это, и они начинают говорить об этом.

20. Доступность интерфейсов – Дмитрий Батогов

Такие организации, как Microsoft, Capital One и BBC, рассказывают о культуре доступности; признавая, что доступность не только хороша для людей с ограниченными возможностями, но и для бизнеса.

Требования к цветовому контрасту и инструменты навигации облегчают чтение доступного веб-сайта для всех, включая рекламщиков с плохим зрением. Подписи помогают всем тысячам проверяющих устройств в шумной среде. Доступность улучшает SEO. Эти факторы и другие факторы способствуют повышению осведомленности о ценности культуры доступности.

Доступность — это проблема для юристов и клиентов — во всех областях практики

Юристы нуждаются в знакомстве с цифровой доступностью как для своих юридических фирм, так и для клиентов, которых они представляют. В каждом секторе экономики крупные и малые организации имеют веб-сайты и мобильные приложения. Их работникам нужны технологии для выполнения своей работы. Если люди с ограниченными возможностями не могут взаимодействовать с этим контентом, ваши клиенты могут столкнуться с законом (не говоря уже о потерянных клиентах, потерянных талантах).

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

И цифровая доступность — это не только приложения и веб-сайты. Цифровые устройства всех видов могут использоваться инвалидами при разработке с учетом принципов доступности.

Например, киоски все чаще предоставляют услуги в сфере финансов, розничной торговли, здравоохранения и государственного сектора. Доступны ли средства контроля для всадника на инвалидных колясках? Есть ли конфиденциальный аудиовыход и тактильный контроль для слепых пользователей? Адвокаты по вопросам инвалидности используют закон, чтобы обеспечить доступность цифровых услуг через киоски для всех. Последние события обсуждаются в доступности киосков: Закон уделяет внимание.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Не покупайте неприятности; Покупайте доступность

Юристы пишут контракты; для себя и своих клиентов. Независимо от того, покупаете ли адвокатские конторы технологии или консультируете клиентов по покупкам технологий, создавайте доступность как в запросах предложений, так и в заключительных контрактах. Определите доступность, которую вы или ваш клиент ожидаете, и укажите, как она будет протестирована, и как будут устранены барьеры после высыхания чернил. Относитесь к доступности, как и к любому другому сроку контракта: серьезно и с последствиями для нарушения.

Доступность — конфиденциальность

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

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

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

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

Доступность как гражданское право: судьи взвешивают

Не случайно я поставил юридические проблемы в этом пятичастном списке. Да, доступность — это гражданское право инвалидов в соответствии с Законом об инвалидах США и другими федеральными, государственными и местными законодательными и нормативными актами. Но понимание закона является лишь одним из аспектов успешной программы доступности.

Слишком большое внимание к рискам и юридическим обязательствам может помешать творчеству и преимуществам, которые предлагает доступность организациям крупным и малым. (Все ингредиенты для успешной инициативы доступности были рассмотрены в презентации, которую я сделал с Microsoft на недавней конференции по доступности, озаглавленной «Пребывание в правовой форме: готовим доступность в вашей организации»).

Что такое доступность услуг

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

Определение

Доступность – способность ИТ-услуги или системы, в некоторых случаях ее компонентов, выполнять свои функции по запросу в определенный период времени. У каждого предприятия свое представление о доступности, которая ему необходима, а также о ее стоимости.

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

Надежность;
Обслуживаемость;
Сопровождаемость;
Производительность;
Безопасность.

Управление доступностью

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

Процесс управления доступностью включает следующие виды деятельности:

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

Связанные термины

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

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

Коэффициент доступности

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

Коэффициент доступности услуги = (согласованное время предоставления услуги – общее время перерывов в предоставлении) / согласованное время предоставления услуги * 100%.

Максимально возможное значение данного коэффициента равно 99,9%. Например, при работе услуги 24 часа 7 дней в неделю при максимальной доступности общее время перерывов в месяц будет составлять не более 4,3 минут.

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

Выводы

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

Источник: www.itexpert.ru

Alex tools

Инженеры-программисты стремятся создавать надежные системы. Надежная система — это система, которая неизменно удовлетворяет потребности пользователя всякий раз, когда он стремится удовлетворить эту потребность. Ключевым компонентом этой надежности является доступность (Availability).

Под доступностью полезно понимать отказоустойчивость системы. Если система достаточно устойчива, чтобы обрабатывать отказы в сети, базе данных, серверах и т. д., то ее обычно можно рассматривать как отказоустойчивую систему (fault-tolerant system), что делает ее доступной.

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

Количественная оценка доступности

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

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

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

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

SLA

Чтобы сделать онлайн-услуги конкурентоспособными и соответствовать ожиданиям рынка, поставщики онлайн-услуг обычно предлагают соглашения об уровне обслуживания/гарантии. Это набор показателей гарантированного уровня обслуживания. 99,999% времени безотказной работы является одним из таких показателей и часто предлагается в рамках премиальных подписок.

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

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

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

Проектирование системы высокой доступности

При проектировании системы высокой доступности (HA, high availability) вам необходимо уменьшить или устранить «единые точки отказа». Единственная точка отказа — это элемент в системе, который является единственным элементом, который может вызвать нежелательную потерю доступности.

Вы устраняете единые точки отказа, создавая в системе «избыточность». Избыточность — это в основном создание одной или нескольких альтернатив (т. е. резервных копий) элемента, который имеет решающее значение для высокой доступности.

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

Следовательно, вам необходимо понять и разобрать вашу систему на все ее части. Определите, какие из них могут вызвать единичные точки отказа, какие из них не терпят таких отказов, а какие части могут их терпеть. Поскольку разработка высокой доступности (HA) требует компромиссов, некоторые из этих компромиссов могут быть дорогостоящими с точки зрения времени, денег и ресурсов.

Основы дизайна систем: хранилище
Основы дизайна систем: задержка
Основы дизайна систем: пропускная способность

Источник: alextoolsblog.blogspot.com

Работа приложений в облаке. Надёжность и доступность.

Идея написания этой статьи пришла после общения с одним из крупных заказчиков — коллега поведал историю выбора для своей компании провайдера облачных услуг IaaS.

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

Владимир Курилов, компания «Онланта».

Так разговор дошёл до показателей надёжности. И вёлся он вокруг сравнения уровней доступности ЦОДов, в которых располагались облака. Достаточно быстро выяснилось, что только двое кандидатов располагают ЦОДами с уровнем доступности 99,98%. Выбор был сделан в пользу зарубежного провайдера облачных услуг — победила цена. Коллега объяснил всё просто, — «Какой смысл платить больше за те же самые показатели надёжности?»

Учитывая существование различных вариантов, давайте определимся с трактованием термина «Доступность» в рамках данной статьи. Определим доступность как время работоспособности системы в определённом интервале времени, выраженное в процентах к этому интервалу. Или в классическом виде: «Свойство объекта выполнять требуемую функцию при заданных условиях в течение заданного интервала времени». Что, в общем, ближе к уже достаточно устоявшемуся понятию «Готовность» системы.

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

Прошёл год и теперь Коллега арендует мощности в другом облаке, где доступность одного из ЦОДов ниже вышеприведённой, а время простоев существенно уменьшилось. Как можно этого добиться и что важно при оценке надёжности работы облачных решений, а что не очень важно? Какие есть возможности экономии, снижения рисков переплаты «за красивые цифры», а не за фактическую надёжность? Как выделить критичные параметры облачных сервисов для надёжности работы Вашего приложения?

Ответы на эти вопросы я и попробую сформулировать далее.

Надёжность приложения — из чего она складывается в облаке

Надёжность сервиса приложения

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

От чего зависит работоспособность приложения и, как надёжность приложения связана с доступностью ЦОДа?

Приложение базируется на программной платформе, которая, в свою очередь, располагается на инфраструктурной платформе, использующая инженерную платформу, см. Рис. В совокупности представленные четыре уровня обеспечивают предоставление «Сервиса Приложения».

Рис. Упрощённый пример расчёта доступности Сервиса Приложения

Как видно из рисунка мы имеем дело с системой последовательных элементов, где отказ любого элемента приводит к отказу системы в целом.

Доступность такой системы (As) определяется как произведение показателей доступности всех элементов:

Где: As – Суммарная доступность, доступность всей системы,
Ai – доступность каждого последовательно соединённого компонента.
As = 0,99995 0,99995 0,993 0998 ≈ 0,99091 или 99,091

Как видим, доступность Сервиса Приложения имеет значение, далёкое от доступности инженерной платформы ЦОДа. Можно пересчитать цифры доступности в значения простоя системы. Получается, несмотря на допустимый годовой простой инженерной платформы, в 1 час. 45 мин., для сервиса приложения годовой простой составит 86 ч. 22 мин.

Надёжность сетевого приложения

Следовательно, при выборе сервис-провайдеров правильно было бы ориентироваться на совокупную доступность сервисов приложений? К сожалению, тут не всё так просто.

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

Один из вариантов реализации применения специализированных библиотек компанией Microsoft — Transient Fault Handling Application Block (см. http://msdn.microsoft.com/en-us/library/hh680934(v=pandp.50).aspx).

Надёжность программной платформы

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

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

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

Надёжность инфраструктурной платформы

Эта составляющая надёжности полностью зависит от сервис-провайдера и должна оцениваться Вами наравне с доступностью инженерной платформы ЦОДа. Необходимо запросить этот параметр у провайдера, поскольку как правило он не указывается в маркетинговых материалах. При этом необходимо получить разъяснения — как этот параметр рассчитывался.

Хотя надо иметь в виду, что такие данные не все сервис-провайдеры захотят представить, поскольку из расчёта становится понятна структурная схема инфраструктурного решения и используемое оборудование — а это определённое ноу-хау.

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

Сетевую инфраструктуры;
Сеть хранения данных;
Вычислительную инфраструктуру.

Теперь у Вас есть возможность максимально достоверно определить доступность Вашего сервиса приложения. 90% СП в России, исходя из нашего опыта, имеют суммарную доступность не выше 99%. А это риск простоев до 87 часов в год. Это нормальные показатели доступности, если у Вас нет критических для бизнеса приложений, часовой простой которых приносит Вам миллионные убытки.

А если часовая остановка сродни катастрофе для Вашего бизнеса, то для Вас есть оставшиеся 10%, СП, предоставляющие сервис корпоративного уровня с доступностью Сервиса приложения на уровне 99,99%. О том, какими способами это достигается в следующем разделе.

Решения, обеспечивающие высокую доступность сервиса приложения

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

Системы, которые мы ранее обсуждали, имели последовательную структуру. Доступность, которую мы посчитали выше как произведение отдельных элементов — это технический предел, обеспечиваемый подобными системами. На деле в силу появления различных дополнительных факторов доступность ещё ниже. Помните вначале статьи рассказ про секундное отключение электричества и пять часов простоя?

Есть ли возможность повысить доступность приложения, если параметры доступности конкретного ЦОДа заданы и изменить их нельзя?

Вот, например, два подхода, которые позволяют это сделать:

Географически распределённый кластер высокой доступности;
Восстановление обработки в географически удалённом резервном центре обработки данных (Disaster recovery).

Рис. Структурная схема географически распределённого кластера высокой доступности

Рис. Структурная схема для восстановления обработки в географически удалённом резервном центре обработки данных

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

В обоих случаях необходимо говорить о географической удалённости ЦОДов, чтобы максимально избежать возможности взаимосвязанных ресурсов. Например, использования одних и тех же подстанций, обеспечивающих электропитание ЦОДов. Можно вспомнить отключение электричества на юго-востоке г. Москва в мае 2008 года из-за пожара на Чагинской подстанции, New York 2003 год. Поэтому резервный ЦОД должен располагаться подальше от основного.

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

Принципиальное отличие параллельной системы в том, что надёжность растёт с увеличением параллельных элементов системы. Расчёт доступности системы, состоящей из параллельных элементов, можно производить по формуле:

calc (1).png

Где: As – Суммарная доступность, доступность всей системы,
Ai – доступность каждого параллельно соединённого компонента.

Для примера, рассчитаем систему географически распределённого кластера высокой доступности из двух ЦОДов с доступностью = 99%, каждый.

As = 1-(1-0,99)*(1-0,99)= 0,9999 или 99,99

Т.е., два не самых надёжных ЦОДа могут обеспечить доступность на уровне mission-critical систем.

Определить доступность сервиса приложения в варианте восстановления обработки в географически удалённом резервном центре обработки данных с 15 минутным интервалом синхронизации для случая единичного сбоя рассчитывается так: надо запросить время восстановления сервиса приложения, гарантируемое СП; далее считаем процент от годового интервала — и результат вычитаем из единицы. Получаем доступность после первого сбоя. Например, для системы с 15 минутным интервалом синхронизации:

Общее количество часов в году 365*24=8760
Гарантированное время простоя = Время максимального простоя
15 минут или 0,25 часа, что составляет ≈ 0,003 от годового времени

Т.е. каждый сбой будет иметь вес в 0,003%. Таким образом, система до сбоя система имеет доступность, равную 100%, после первого сбоя, 99,997%, после второго сбоя 99,994%. Посчитаем тоже самое для системы с часовым интервалом синхронизации:

Гарантированное время восстановления = Время максимального простоя = 1 час, что составляет ≈ 0,01 от годового времени

Каждый сбой будет иметь вес в 0,01%. Таким образом, система до сбоя система имеет доступность, равную 100%, после первого сбоя, 99,99%, после второго сбоя 99,98%. Дальше, приверженцы теории вероятности могут поупражняться в оценке вероятности наступления первого, второго, третьего сбоев. Результат убедит, что влияние этого фактора ничтожно мало на получаемые результаты. Это позволяет мне рекомендовать предложенную методику для оценки доступности сервисов для Ваших приложений в облаке.

Резюмируя вышесказанное.

В заключение можно рекомендовать следующую модель определения подходящего сервис-провайдера:

Начните с оценки бизнес-критичности приложения, планируемого к размещению в облаке. Оцените стоимость простоя приложения. Сколько Вам будет обходиться отсутствие сервиса приложения?
Отсюда оцените допустимое значение простоя в день, в год. Посчитайте критическую доступность сервиса приложения.
Сопоставьте возможные потери от простоя с ценами СП, которые предлагают приемлемую для ваших приложений доступность.
При выборе СП, отдавайте предпочтение тому, кто может обеспечить не только текущий уровень доступности, но и как дополнительный сервис/услугу предоставить улучшение доступности. Особенно если Ваш бизнес растёт и развивается.
И оставайтесь практиками. Берите то, что дают пощупать = потестировать. Теория без практики, не очень полезна для бизнеса.

Источник: onlanta.ru