====== Применение инженерии надёжности к инфраструктуре ЦОД ======

<WRAP box round>
Раздел описывает методологию оценки надёжности инженерной инфраструктуры ЦОД, задачи анализа отказов, подходы к оптимизации архитектуры и порядок использования результатов на всех стадиях жизненного цикла объекта.
</WRAP>

===== Цели и назначение инженерии надёжности =====

Инженерия надёжности предназначена для:

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

<WRAP info>
Основная цель — достижение требуемой частоты отказов инфраструктуры (обычно ниже 0,001 отказа/год) при минимально необходимом уровне резервирования.
</WRAP>

===== Основные трудности при проектировании надёжного ЦОД =====

  * Избыточное резервирование отдельных типов оборудования.  
  * Невыявленные одиночные точки отказа.  
  * Несогласованные уровни надёжности подсистем (электроснабжение, охлаждение, ДГУ, сети, мониторинг).  
  * Недостаточный учёт поведения систем в деградированных режимах.  
  * Недостаточная точность данных об отказах оборудования.  

===== Роль оценки надёжности в проектировании =====

Оценка надёжности используется:

  * на стадии концепции;
  * на стадии базового проекта;
  * на стадии детального проекта;
  * при модернизации или реконструкции ЦОД.

Она позволяет:

  * подтвердить достижение проектных целей по надёжности;
  * выявить слабые элементы;
  * определить ключевые мероприятия по улучшению архитектуры;
  * оптимизировать уровни резервирования.

===== Сравнение методов анализа отказов =====

<WRAP info>
Условные обозначения уровней применимости:  
**++ высокая**, **+ средняя**, **− низкая**, **— не применяется**.
</WRAP>

^ Метод ^ Время создания модели ^ Подходит для больших систем ^ Точность результата ^ Идентификация слабых мест ^ Понимание логики ^ Применимость ПО ^ Краткое описание ^
| Упрощённая FMECA | ++ | – | – | ++ | ++ | ++ | Быстрая оценка на ранних стадиях, идентификация одиночных отказов |
| Полная FMECA | + | + | + | ++ | ++ | ++ | Детальный анализ всех режимов отказов |
| Дерево отказов (FTA) | – | + | ++ | ++ | + | + | Логические комбинации отказов, поиск корневых причин |
| Дерево событий (ETA) | — | ++ | ++ | ++ | ++ | ++ | Прослеживание сценариев развития событий |
| Марковские модели | — | ++ | ++ | – | — | — | Точные вероятностные модели с состояниями и переходами |
| Стохастическая симуляция | — | ++ | ++ | — | — | — | Статистическое моделирование сложных систем |

===== Пример применения оценки надёжности =====

В ходе базового проектирования сравниваются несколько вариантов архитектуры:

  * отсутствие резервирования;
  * резервирование UPS;
  * резервирование UPS + генераторов;
  * резервирование по узлам MV/LV;
  * высокие уровни резервирования нескольких подсистем одновременно.

Каждый вариант анализируется на предмет:

  * частоты отказов;
  * недоступности (часов/год);
  * природы слабых мест (длительное отсутствие питания от utility, отказ переключателей, отказ UPS и др.);
  * вклада каждого компонента в общую вероятность отказа.

<WRAP important>
На каждом шаге проектной итерации weak points меняются — оценка надёжности обязательна на каждом изменении архитектуры.
</WRAP>

===== Функциональная модель ЦОД =====

Функции инфраструктуры ЦОД включают:

  * F1 — обеспечение ИТ-процесса:  
    - электроснабжение ИТ-нагрузки;  
    - охлаждение;  
    - резервное электроснабжение;  
    - работа в тяжёлых климатических условиях;  
    - обеспечение физической безопасности;  
    - поддержание непрерывности процессов.
  * F2 — безопасность персонала.  
  * F3 — предотвращение загрязнения окружающей среды.

Нежелательные события (UE):

  * UE1 — потеря ИТ-процесса;  
  * UE2 — риски для безопасности;  
  * UE3 — экологические риски.

===== Декомпозиция UE1 (потеря ИТ-процесса) =====

Категории:

  * UE1.1 — недоступность более 4 часов (тяжёлое последствие).  
  * UE1.2 — недоступность менее 4 часов (управляемое последствие).  
  * UE1.3 — потеря данных.

Целевые показатели:

  * вероятность события UE1.1 < 1/100 за срок службы;  
  * частота < 3.8e–8 / час;  
  * нормируется через показатель R(t):  
    <WRAP center>  
    $$R(t) = e^{-\lambda t}$$  
    </WRAP>

===== Сбор данных для оценки надёжности =====

Основные категории данных:

==== 1. Технические данные ====
  * архитектура систем;
  * компоновка помещений;
  * параметры оборудования;
  * назначение и режимы работы.

==== 2. Анализ режимов работы ====
  * нормальные режимы;
  * деградированные режимы;
  * сценарии восстановления.

==== 3. Надёжность оборудования ====
  * интенсивность отказов λ;
  * распределения времени наработки;
  * типовые режимы отказов.

Источники:

  * статистика полевых отказов;
  * базы данных производителей;
  * NPERD, IEEE, EXIDA, EIReDA;
  * экспертные оценки.

==== 4. Техническое обслуживание ====
  * время диагностики;
  * время доставки запасных частей;
  * профилактические работы;
  * регламентные отключения.

<WRAP important>
Недостаток данных компенсируется допущениями — их необходимо фиксировать в отчёте и подтверждать испытаниями.
</WRAP>

===== Управление надёжностью на стадиях жизненного цикла =====

==== Предпроектная стадия ====
  * сбор исходных данных;
  * определение критичности ИТ-процессов;
  * предварительная идентификация UE;
  * разработка целей по надёжности.

==== Базовый проект ====
  * упрощённая FMECA;
  * проверка базовой архитектуры;
  * оценка корректности резервирования подсистем.

==== Детальный проект ====
  * детальная FMECA/FTA/ETA;
  * проверка всех режимов работы;
  * подтверждение выполнения целей по UE.

==== Производство и ПНР ====
  * подтверждение допущений;
  * испытания автоматических переключений, резервов, защиты.

==== Эксплуатация ====
  * регулярное обновление анализа надёжности;
  * учёт модернизаций и изменений архитектуры;
  * актуализация данных об отказах.

<WRAP important>
Надёжность деградирует, если разные системы проектируются независимыми подрядчиками и не проводится единая сквозная проверка межсистемных взаимодействий.
</WRAP>

===== Классификация Tier и её связь с надёжностью =====

==== Преимущества Tier ====

<WRAP info>
  * Понятная и распространённая классификация.  
  * Быстрая проверка уровня резервирования.  
  * Охват всех основных инженерных подсистем.  
</WRAP>

==== Ограничения Tier ====

<WRAP important>
  * Пессимизм в отношении utility вызывает лишнее резервирование.  
  * Большой разрыв между Tier III и Tier IV.  
  * Не учитываются деградированные режимы.  
  * Не учитываются особенности отказов отдельных компонентов.  
  * Не включает аспекты обслуживания оборудования.  
</WRAP>

===== Ключевые идеи =====

<WRAP tip>
  * Надёжность ЦОД — количественный инструмент оптимизации архитектуры.  
  * Основное назначение — обеспечить непрерывность ИТ-процесса при минимально достаточном резервировании.  
  * FMECA, FTA, ETA и стохастические подходы применяются в зависимости от сложности системы и цели анализа.  
  * Надёжность должна проверяться при каждом значимом изменении архитектуры.  
  * Недостающие данные допускаются, но обязаны быть компенсированы испытаниями и проверками.  
  * Tier — вспомогательный инструмент, но не заменяет полноценную инженерию надёжности.  
</WRAP>