Высокая доступность

Высокая доступность ( HA ) — это характеристика системы, целью которой является обеспечение согласованного уровня эксплуатационной производительности, обычно времени безотказной работы , в течение более длительного, чем обычно, периода. ^[1]

Модернизация привела к увеличению зависимости от этих систем. Например, больницам и центрам обработки данных требуется высокая доступность своих систем для выполнения повседневных задач. Доступность означает способность сообщества пользователей получать услугу или товар, получать доступ к системе, отправлять новую работу, обновлять или изменять существующую работу или собирать результаты предыдущей работы. Если пользователь не может получить доступ к системе, она, с точки зрения пользователя, недоступна . ^[2] Обычно термин «время простоя» используется для обозначения периодов, когда система недоступна.

Устойчивость

Высокая доступность — это свойство сети устойчивости , способность «обеспечивать и поддерживать приемлемый уровень обслуживания в условиях сбоев и проблем нормальной работы». ^[3] Угрозы и проблемы для услуг могут варьироваться от простой неправильной конфигурации до крупномасштабных стихийных бедствий до целенаправленных атак. ^[4] Таким образом, устойчивость сети затрагивает очень широкий круг тем. Чтобы повысить устойчивость конкретной сети связи, необходимо идентифицировать возможные проблемы и риски, а также определить соответствующие показатели устойчивости для защищаемой услуги. ^[5]

Важность устойчивости сети постоянно возрастает, поскольку сети связи становятся фундаментальным компонентом работы критически важных инфраструктур. ^[6] Следовательно, недавние усилия сосредоточены на интерпретации и повышении устойчивости сетей и вычислений с помощью приложений для критически важных инфраструктур. ^[7] В качестве примера можно рассматривать в качестве цели устойчивости предоставление услуг по сети, а не услуг самой сети. Это может потребовать скоординированного реагирования как со стороны сети, так и со стороны служб, работающих поверх сети. ^[8]

Эти услуги включают в себя:

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

Устойчивость и выживаемость взаимозаменяемы в зависимости от конкретного контекста данного исследования. ^[9]

Принципы

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

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

Плановые и внеплановые простои

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

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

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

Процентный расчет

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

Доступность %	Время простоя в год ^{[примечание 1]}	Время простоя в квартал	Время простоя в месяц	Время простоя в неделю	Время простоя в день (24 часа)
90% («одна девятка»)	36,53 дня	9,13 дней	73,05 часов	16.80 часов	2,40 часа
95% («один девять пять»)	18,26 дней	4,56 дней	36,53 часа	8.40 часов	1,20 часа
97% («один девять семь»)	10,96 дней	2,74 дня	21,92 часа	5,04 часа	43,20 минут
98% («один девять восемь»)	7,31 дней	43,86 часов	14,61 часов	3,36 часа	28,80 минут
99% («две девятки»)	3,65 дней	21,9 часов	7,31 часов	1,68 часа	14.40 минут
99,5% («две девятки пять»)	1,83 дня	10,98 часов	3,65 часа	50,40 минут	7,20 минут
99,8% («две девятки восемь»)	17,53 часа	4,38 часа	87,66 минут	20,16 минут	2,88 минуты
99,9% («три девятки»)	8,77 часов	2,19 часов	43,83 минуты	10,08 минут	1,44 минуты
99,95% («три девятки пять»)	4,38 часа	65,7 минут	21,92 минуты	5,04 минуты	43,20 секунды
99,99% («четыре девятки»)	52,60 минут	13,15 минут	4,38 минуты	1,01 минуты	8,64 секунды
99,995% («четыре девятки пять»)	26.30 минут	6,57 минут	2,19 минуты	30,24 секунды	4,32 секунды
99,999% («пять девяток»)	5,26 минут	1,31 минуты	26,30 секунды	6,05 секунды	864,00 миллисекунды
99,9999% («шесть девяток»)	31,56 секунды	7,89 секунды	2,63 секунды	604,80 миллисекунды	86,40 миллисекунд
99,99999% («семь девяток»)	3,16 секунды	0,79 секунды	262,98 миллисекунды	60,48 миллисекунды	8,64 миллисекунды
99,999999% («восемь девяток»)	315,58 миллисекунды	78,89 миллисекунд	26,30 миллисекунд	6,05 миллисекунды	864,00 микросекунды
99,9999999% («девять девяток»)	31,56 миллисекунды	7,89 миллисекунды	2,63 миллисекунды	604,80 микросекунд	86,40 микросекунд
99,99999999% («десять девяток»)	3,16 миллисекунды	788,40 микросекунд	262,80 микросекунд	60,48 микросекунд	8,64 микросекунды
99,999999999% («одиннадцать девяток»)	315,58 микросекунд	78,84 микросекунды	26,28 микросекунд	6,05 микросекунд	864,00 наносекунд
99,9999999999% («двенадцать девяток»)	31,56 микросекунды	7,88 микросекунд	2,63 микросекунды	604,81 наносекунды	86,40 наносекунд

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

Мнемоника пять на пять

Простое мнемоническое правило гласит, что 5 девяток допускают примерно 5 минут простоя в год. Варианты можно получить путем умножения или деления на 10: 4 девятки — это 50 минут, а 3 девятки — 500 минут. В обратном направлении 6 девяток — это 0,5 минуты (30 секунд), а 7 девяток — 3 секунды.

Трюк «Сила 10»

Еще один трюк с памятью для расчета допустимой продолжительности простоя для " $n$ -девятки" процент доступности - использовать формулу $8.64\times 10^{4-n}$ секунд в день.

Например, 90% («одна девятка») дает показатель степени $4-1=3$ , и, следовательно, разрешенное время простоя составляет $8.64\times 10^{3}$ секунд в день.

Также 99,999% («пять девяток») дает показатель степени $4-5=-1$ , и, следовательно, разрешенное время простоя составляет $8.64\times 10^{-1}$ секунд в день.

«Девятки»

Проценты определенного порядка иногда обозначаются количеством девяток или «классом девяток» в цифрах. Например, электричество, которое подается без перебоев ( отключения , отключения или скачки напряжения ) в 99,999% случаев, будет иметь надежность 5 девяток или пятый класс. ^[10] В частности, этот термин используется в отношении мэйнфреймов. ^[11]^[12] или корпоративные вычисления, часто в рамках соглашения об уровне обслуживания .

Точно так же проценты, оканчивающиеся на 5, имеют условные названия: традиционно количество девяток, затем «пять», поэтому 99,95% - это «три девятки пять», сокращенно 3N5. ^[13]^[14] Это вскользь называют «три с половиной девятки». ^[15] но это неверно: 5 — это коэффициент только 2, а 9 — коэффициент 10, поэтому 5 — это 0,3 девятки (по формуле ниже: $\log _{10}2\approx 0.3$ ): ^{[примечание 2]} Доступность 99,95% — это 3,3 девятки, а не 3,5 девятки. ^[16] Проще говоря, переход от доступности с 99,9% до доступности 99,95% — это коэффициент 2 (недоступность от 0,1% до 0,05%), а переход от доступности с 99,95% до 99,99% — это коэффициент 5 (недоступность от 0,05% до 0,01%), т.е. в два раза больше. ^{[примечание 3]}

Формулировка класса девяток $c$ системы на основании недоступности $x$ было бы

c:=\lfloor -\log _{10}x\rfloor

(см. Функции пола и потолка ).

Подобное измерение иногда используется для описания чистоты веществ.

В целом число девяток не часто используется сетевыми инженерами при моделировании и измерении доступности, поскольку его сложно применить в формуле. недоступность, выраженная как вероятность (например, 0,00001), или время простоя Чаще всего указывается в год. Наличие, указанное в виде девятки, часто встречается в маркетинговых документах. ^{[ нужна ссылка ]} Использование «девяток» было поставлено под сомнение, поскольку оно не отражает должным образом тот факт, что влияние недоступности варьируется в зависимости от времени ее возникновения. ^[17] Для большого количества девяток легче обрабатывать индекс «недоступности» (показатель времени простоя, а не времени безотказной работы). Например, именно поэтому в показателях битовых ошибок жесткого диска или канала передачи данных используется «недоступность», а не показатель доступности .

Иногда юмористический термин «девять пятерок» (55,5555555%) используется для противопоставления «пяти девяткам» (99,999%), ^[18]^[19]^[20] хотя это не реальная цель, а скорее саркастическая ссылка на что-то, совершенно не достигающее какой-либо разумной цели.

Измерение и интерпретация

Измерение доступности подлежит определенной интерпретации. Система, которая проработала 365 дней в невисокосный год, могла быть омрачена сбоем сети, который длился 9 часов в период пиковой нагрузки; сообщество пользователей будет считать систему недоступной, тогда как системный администратор будет требовать 100% времени безотказной работы. Однако, учитывая истинное определение доступности, система будет доступна примерно на 99,9%, или трёх девятках (8751 час времени доступности из 8760 часов за невисокосный год). Кроме того, пользователи часто считают системы, испытывающие проблемы с производительностью, частично или полностью недоступными, даже если системы продолжают функционировать. Аналогичным образом, недоступность некоторых функций приложения может остаться незамеченной администраторами, но иметь разрушительные последствия для пользователей — истинная мера доступности является целостной.

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

Альтернативным показателем является среднее время наработки на отказ (MTBF).

Тесно связанные понятия

Время восстановления (или расчетное время ремонта (ETR), также известное как целевое время восстановления (RTO) тесно связано с доступностью, то есть общим временем, необходимым для запланированного простоя, или временем, необходимым для полного восстановления после незапланированного простоя. Еще один Показатель представляет собой среднее время восстановления (MTTR). Время восстановления может быть бесконечным в зависимости от конструкции системы и сбоев, т. е. полное восстановление невозможно. Одним из таких примеров является пожар или наводнение, которое разрушает центр обработки данных и его системы при отсутствии вторичной катастрофы. восстановления центр данных.

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

Соглашение об уровне обслуживания («SLA») формализует цели и требования организации к доступности.

Военные системы управления

Высокая доступность — одно из основных требований к системам управления беспилотными транспортными средствами и автономными морскими судами . Если система управления станет недоступной, наземная боевая машина (GCV) или противолодочное беспилотное судно непрерывного следования (ACTUV) будет потеряно.

Проектирование системы

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

Высокая доступность требует меньшего вмешательства человека для восстановления работы сложных систем; Причина этого в том, что наиболее распространенной причиной сбоев является человеческая ошибка. ^[21]

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

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

Активное резервирование используется в сложных системах для достижения высокой доступности без снижения производительности. Несколько элементов одного и того же типа включены в конструкцию, которая включает метод обнаружения сбоя и автоматической переконфигурации системы для обхода неисправных элементов с использованием схемы голосования. Это используется со сложными взаимосвязанными вычислительными системами. Интернет- маршрутизация основана на ранних работах Бирмана и Джозефа в этой области. ^[22] Активное резервирование может привести к более сложным режимам сбоя в системе, например, к постоянной реконфигурации системы из-за неправильной логики голосования.

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

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

Моделирование и симуляция используются для оценки теоретической надежности больших систем. Результаты такого рода модели используются для оценки различных вариантов дизайна. Создается модель всей системы, и модель усиливается за счет удаления компонентов. Моделирование избыточности включает критерии Nx. N представляет общее количество компонентов в системе. x — количество компонентов, используемых для нагрузки на систему. N-1 означает, что модель подвергается нагрузке путем оценки производительности со всеми возможными комбинациями, в которых один компонент неисправен. N-2 означает, что модель подвергается нагрузке путем оценки производительности со всеми возможными комбинациями, в которых два компонента выходят из строя одновременно.

Причины недоступности

Опрос академических экспертов по доступности, проведенный в 2010 году, выявил причины недоступности корпоративных ИТ-систем. Все причины относятся к несоблюдению передового опыта в каждой из следующих областей (в порядке важности): ^[23]

Мониторинг соответствующих компонентов
Требования и закупки
Операции
Предотвращение сетевых сбоев
Предотвращение внутренних сбоев приложений
Избежание сбоев внешних служб
Физическая среда
Резервирование сети
Техническое решение резервного копирования
Технологическое решение резервного копирования
Физическое местоположение
Резервирование инфраструктуры
Резервирование архитектуры хранения данных

Книга о самих факторах была опубликована в 2003 году. ^[24]

Затраты на недоступность

В отчете IBM Global Services за 1998 год было подсчитано, что недоступные системы обошлись американскому бизнесу в 4,54 миллиарда долларов в 1996 году из-за потери производительности и доходов. ^[25]

См. также

Примечания

^ Использование 365,25 дней в году; соответственно, четверть составляет ¼ этого значения (т. е. 91,3125 дней), а месяц — двенадцатую его часть (т. е. 30,4375 дней). Для единообразия все значения округлены до двух десятичных цифр.
^ см. в разделе «Математические совпадения, касающиеся основания 2» . Подробности об этом приближении
^ «Вдвое больше» в логарифмическом масштабе, что означает два коэффициента по 2: $\times 2\times 2<\times 5$

Ссылки

^ Роберт, Шелдон (апрель 2024 г.). «высокая доступность (HA)» . Техтаргет .
^ Флойд Пьедад, Майкл Хокинс (2001). Высокая доступность: проектирование, методы и процессы . Прентис Холл. ISBN 9780130962881 .
^ «Определения — ResiliNetsWiki» . resilinets.org .
^ «Вебархив ETHZ / Вебархив ETH» . webarchiv.ethz.ch .
^ Смит, Пол; Хатчисон, Дэвид; Стербенс, Джеймс П.Г.; Шёллер, Маркус; Фесси, Али; Каралиопулос, Меркурис; Лак, Чидунг; Платтнер, Бернхард (3 июля 2011 г.). «Устойчивость сети: системный подход» . Журнал коммуникаций IEEE . 49 (7): 88–97. дои : 10.1109/MCOM.2011.5936160 . S2CID 10246912 – через IEEE Xplore.
^ accesstel (9 июня 2022 г.). «операционная устойчивость | телекоммуникационные компании | доступтел | риск | кризис» . доступтел . Проверено 8 мая 2023 г.
^ «Проект CERCES — Центр устойчивых критических инфраструктур при Королевском технологическом институте KTH» . Архивировано из оригинала 19 октября 2018 года . Проверено 26 августа 2023 г.
^ Чжао, Пейюэ; Дан, Дьёрдь (3 декабря 2018 г.). «Подход к декомпозиции Бендерса для устойчивого размещения функций управления виртуальными процессами в мобильных периферийных облаках» . Транзакции IEEE по управлению сетями и услугами . 15 (4): 1460–1472. дои : 10.1109/TNSM.2018.2873178 . S2CID 56594760 – через IEEE Xplore.
^ Касте Дж., Салех Дж. Живучесть и отказоустойчивость космических аппаратов и космических сетей: основа для характеристики и анализа», Американский институт аэронавтики и астронавтики, Технический отчет AIAA 2008-7707. Конференция по сетевым протоколам (ICNP 2006) , Санта-Барбара, Калифорния, США, ноябрь 2006 г.
^ Конспект лекций М. Нестеренко, Кентский государственный университет.
^ Введение в новый мэйнфрейм: Крупномасштабные коммерческие вычисления. Глава 5. Доступность. Архивировано 4 марта 2016 г., в Wayback Machine IBM (2006).
^ Видео о ценности бизнеса IBM zEnterprise EC12 на youtube.com
^ Драгоценные металлы, Том 4 . Пергамон Пресс. 1981. с. страница 262 . ISBN 9780080253695 .
^ PVD для микроэлектроники: напыление в производстве полупроводников . 1998. с. 387 .
^ Мерфи, Найл Ричард; Бейер, Бетси; Петофф, Дженнифер; Джонс, Крис (2016). Проектирование надежности сайта: как Google управляет производственными системами . п. 38 .
^ Джош Депрез (23 апреля 2016 г.). «Девятки из девяток» . Архивировано из оригинала 4 сентября 2016 года . Проверено 31 мая 2016 г.
^ Эван Л. Маркус, Миф о девятках
^ Ньюман, Дэвид; Снайдер, Джоэл; Тайер, Родни (24 июня 2012 г.). «Плачущий волк: Ложные тревоги скрывают атаки» . Сетевой мир . Том. 19, нет. 25. с. 60 . Проверено 15 марта 2019 г. что приводит к сбоям и времени безотказной работы ближе к девяти пятёркам, чем к пяти девяткам.
^ Меткалф, Боб (2 апреля 2001 г.). «После 35 лет крестовых походов в области технологий Боб Меткалф уходит в закат» . ITмир . Проверено 15 марта 2019 г. и пять девяток (не девять пятерок) надежности ^{[ постоянная мертвая ссылка ]}
^ Пилигрим, Джим (20 октября 2010 г.). «Прощай, пять девяток» . Клирфилд, Инк . Проверено 15 марта 2019 г. но мне кажется мы приближаемся к 9-5 с (55,5555555%) по надежности сети, а не к 5-9 с
^ «Что такое простой сети?» . Сеть . Проверено 27 декабря 2023 г.
^ RFC 992
^ Ульрик Франке, Понтус Джонсон, Йохан Кениг, Лив Маркс фон Вюртемберг: Доступность корпоративных ИТ-систем - байесовская модель, основанная на экспертах, Proc. Четвертый международный семинар по качеству и ремонтопригодности программного обеспечения (WSQM 2010), Мадрид, [1] Архивировано 4 августа 2012 г., archive.today.
^ Маркус, Эван; Стерн, Хэл (2003). Проекты обеспечения высокой доступности (второе изд.). Индианаполис, Индиана: Джон Уайли и сыновья. ISBN 0-471-43026-9 .
^ IBM Global Services, Повышение доступности систем , IBM Global Services, 1998, [2] Архивировано 1 апреля 2011 г., на Wayback Machine.

Внешние ссылки

Конспекты лекций по корпоративным вычислениям. Архивировано 16 ноября 2013 г. в Wayback Machine . Тюбингенском университете
Конспекты лекций по разработке встраиваемых систем профессора Фила Купмана
Калькулятор времени безотказной работы (SLA)

[10] Использование 365,25 дней в году; соответственно, четверть составляет ¼ этого значения (т. е. 91,3125 дней), а месяц — двенадцатую его часть (т. е. 30,4375 дней). Для единообразия все значения округлены до двух десятичных цифр.

[17] см. в разделе «Математические совпадения, касающиеся основания 2» . Подробности об этом приближении

[19] «Вдвое больше» в логарифмическом масштабе, что означает два коэффициента по 2: $\times 2\times 2<\times 5$

[1] Роберт, Шелдон (апрель 2024 г.). «высокая доступность (HA)» . Техтаргет .

[2] Флойд Пьедад, Майкл Хокинс (2001). Высокая доступность: проектирование, методы и процессы . Прентис Холл. ISBN 9780130962881 .

[3] «Определения — ResiliNetsWiki» . resilinets.org .

[4] «Вебархив ETHZ / Вебархив ETH» . webarchiv.ethz.ch .

[5] Смит, Пол; Хатчисон, Дэвид; Стербенс, Джеймс П.Г.; Шёллер, Маркус; Фесси, Али; Каралиопулос, Меркурис; Лак, Чидунг; Платтнер, Бернхард (3 июля 2011 г.). «Устойчивость сети: системный подход» . Журнал коммуникаций IEEE . 49 (7): 88–97. дои : 10.1109/MCOM.2011.5936160 . S2CID 10246912 – через IEEE Xplore.

[6] sstel (9 июня 2022 г.). «операционная устойчивость | телекоммуникационные компании | доступтел | риск | кризис» . доступтел . Проверено 8 мая 2023 г.

[7] «Проект CERCES — Центр устойчивых критических инфраструктур при Королевском технологическом институте KTH» . Архивировано из оригинала 19 октября 2018 года . Проверено 26 августа 2023 г.

[8] Чжао, Пейюэ; Дан, Дьёрдь (3 декабря 2018 г.). «Подход к декомпозиции Бендерса для устойчивого размещения функций управления виртуальными процессами в мобильных периферийных облаках» . Транзакции IEEE по управлению сетями и услугами . 15 (4): 1460–1472. дои : 10.1109/TNSM.2018.2873178 . S2CID 56594760 – через IEEE Xplore.

[9] Касте Дж., Салех Дж. Живучесть и отказоустойчивость космических аппаратов и космических сетей: основа для характеристики и анализа», Американский институт аэронавтики и астронавтики, Технический отчет AIAA 2008-7707. Конференция по сетевым протоколам (ICNP 2006) , Санта-Барбара, Калифорния, США, ноябрь 2006 г.

[11] Конспект лекций М. Нестеренко, Кентский государственный университет.

[12] Введение в новый мэйнфрейм: Крупномасштабные коммерческие вычисления. Глава 5. Доступность. Архивировано 4 марта 2016 г., в Wayback Machine IBM (2006).

[13] Видео о ценности бизнеса IBM zEnterprise EC12 на youtube.com

[14] Драгоценные металлы, Том 4 . Пергамон Пресс. 1981. с. страница 262 . ISBN 9780080253695 .

[15] PVD для микроэлектроники: напыление в производстве полупроводников . 1998. с. 387 .

[16] Мерфи, Найл Ричард; Бейер, Бетси; Петофф, Дженнифер; Джонс, Крис (2016). Проектирование надежности сайта: как Google управляет производственными системами . п. 38 .

[18] Джош Депрез (23 апреля 2016 г.). «Девятки из девяток» . Архивировано из оригинала 4 сентября 2016 года . Проверено 31 мая 2016 г.

[20] Эван Л. Маркус, Миф о девятках

[21] Ньюман, Дэвид; Снайдер, Джоэл; Тайер, Родни (24 июня 2012 г.). «Плачущий волк: Ложные тревоги скрывают атаки» . Сетевой мир . Том. 19, нет. 25. с. 60 . Проверено 15 марта 2019 г. что приводит к сбоям и времени безотказной работы ближе к девяти пятёркам, чем к пяти девяткам.

[22] Меткалф, Боб (2 апреля 2001 г.). «После 35 лет крестовых походов в области технологий Боб Меткалф уходит в закат» . ITмир . Проверено 15 марта 2019 г. и пять девяток (не девять пятерок) надежности ^{[ постоянная мертвая ссылка ]}

[23] Пилигрим, Джим (20 октября 2010 г.). «Прощай, пять девяток» . Клирфилд, Инк . Проверено 15 марта 2019 г. но мне кажется мы приближаемся к 9-5 с (55,5555555%) по надежности сети, а не к 5-9 с

[humanerror-24] «Что такое простой сети?» . Сеть . Проверено 27 декабря 2023 г.

[25] RFC 992

[26] Ульрик Франке, Понтус Джонсон, Йохан Кениг, Лив Маркс фон Вюртемберг: Доступность корпоративных ИТ-систем - байесовская модель, основанная на экспертах, Proc. Четвертый международный семинар по качеству и ремонтопригодности программного обеспечения (WSQM 2010), Мадрид, [1] Архивировано 4 августа 2012 г., archive.today.

[27] Маркус, Эван; Стерн, Хэл (2003). Проекты обеспечения высокой доступности (второе изд.). Индианаполис, Индиана: Джон Уайли и сыновья. ISBN 0-471-43026-9 .

[28] IBM Global Services, Повышение доступности систем , IBM Global Services, 1998, [2] Архивировано 1 апреля 2011 г., на Wayback Machine.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[примечание 1]

[10]

[11]

[12]

[13]

[14]

[15]

[примечание 2]

[16]

[примечание 3]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]