Какую бы статистику не приводили вендоры по надежности своих решений, какие бы гарантии они не давали, железо всё равно будет выходить из строя. При работе некритичных приложений, где допустимое время простоя может достигать несколько часов, вполне допустимо иметь запасное оборудование в холодном резерве, а также набор программного обеспечения для быстрого развертывания системы «с нуля». Для этого поможет качественно организованные библиотеки DHS и DSL (Definitive Hardware Store и Definitive Software List), которые позволяют иметь в готовности протестированное аппаратное обеспечение и полный комплект системного и прикладного ПО.
Для критических информационных систем такого решения будет недостаточно. Если разговор идет про планируемую доступность более 99,9%, то здесь необходимо рассчитывать на то, сбой аппаратной компоненты не должен приводить к прерыванию предоставления бизнес-сервиса. В этом случае рассматриваются решения следующих типов:
Кластеризация вида «fault tolerance». В этом случае информационная система должна поддерживать технологию одновременной обработки информации на нескольких узлах. В случае выхода из строя одного из них система продолжает работу, и вышедший из строя компонент моно заменить без прерывания работы.
На практике подобные решения не всегда срабатывают. Какова бы ни была кластерная система, она всегда будет иметь хотя бы один компонент, который будет общим для всех параллельных узлов кластера.
Несмотря на то, что кластерные системы являются теоретически лучшим решением, обеспечивающим самую высокую доступность критических информационных систем, на практике в настоящее время чаще применяются другие методы.
Системы в «горячем резерве». Технически данное решение похоже на кластер «fault tolerance», с той разницей, что обработка ведется на одном узле системы. В случае аппаратного сбоя происходит перевод обработки на резервный узел. Основная задача работы системы «горячего резерва» — снижение времени переключения между узлами. Чаще всего эта задача сводится к изменению адресов и старту/останову отдельных служб, и может измеряться минутами.
В случае возникновения сбоев с частотой 4-5 раз в год, и временем переключения до 10 минут, можно говорить о реальных возможностях добиться доступности «четыре девятки» (99,99%), при которой подразумевается простой не более 50 минут в год.
И, наконец, третий вариант — это современные облачные технологии. В данном случае происходит, фактически, та же самая кластеризация, но на более низком уровне инфраструктуры. Фактически, аппаратной остается только серверная стойка, и все остальные компоненты, включая дисковые массивы и сервера, переводятся в виртуальное пространство.
Современные облачные технологии  уже вплотную подошли к состоянию, при котором реальная работа виртуальных серверов «размазана» по нескольким физическим серверам. В этом случае выход из строя любого компонента оборудования никак не скажется на работе виртуального сервера. Развитие «частных облаков» показывает интерес к данной технологии в рамках крупных предприятий.
Таким образом, повышение надежности аппаратного обеспечения сводится к решению следующих задач:

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

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

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

• Логические ошибки в коде;
• Генерация внепланового объема данных (логи, history, быстрое расширение объемов данных);
• Особенности поведения программного обеспечения при высокой нагрузке.

Данные проблемы решаются отдельными комплексами мер:

• Функциональное и нагрузочное тестирование кода прикладного ПО;
• Установка мониторинга слежения за объемами доступной памяти;
• Формализация процедур внедрения новых версий ПО в продуктивную среду.

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