====== Инженерия надёжности инфраструктуры ЦОД ======
<WRAP box round>
Раздел посвящён инженерии надёжности (dependability engineering) применительно к критической инфраструктуре центров обработки данных. 
Рассматриваются:
  * фундаментальные понятия надёжности и доступности,
  * методы анализа отказов и уязвимостей,
  * практические подходы для проектирования, верификации и эксплуатации инженерных систем ЦОД на всех стадиях жизненного цикла — от концепции до сопровождения.

Цель раздела — дать структурированную методологию оценки и повышения надёжности систем, влияющих на основной процесс ЦОД: IT-услугу.
</WRAP>

<WRAP group gap>

<WRAP box round half column>
**Теоретические основы**
  * [[topics:29:theory|Основы и принципы теории надёжности]]
  * [[topics:29:fmea|Методы анализа отказов и их последствий]]
</WRAP>

<WRAP box round half column>
**Практика**
  * [[topics:29:application|Применение инженерии надёжности к инфраструктуре ЦОД]]
</WRAP>

</WRAP>

<WRAP box round>
**Роль инженерии надёжности в ЦОД**

Инфраструктура ЦОД состоит из взаимозависимых систем: электроснабжения, охлаждения, водоснабжения, систем безопасности, зданий, ИТ-операций.  
Отказ даже одного компонента может привести к деградации основной услуги (Loss of IT process).  
Инженерия надёжности позволяет:
  * выявлять слабые места структуры;
  * оценивать вероятности отказов и их комбинаций;
  * моделировать последствия;
  * обосновывать уровни резервирования (N+1, N+2, 2N);
  * выбирать адекватный Tier-уровень;
  * разрабатывать мероприятия по снижению рисков.
</WRAP>

<WRAP box round>
**Схема подхода к инженерии надёжности**

<mermaid>
flowchart LR
  classDef big font-size:32px,stroke-width:2px,padding:18px;

  A["1. Определение функций и критичных систем"]:::big --> 
  B["2. Сбор данных о надёжности"]:::big

  B --> 
  C["3. Методы анализа:<br/>FMEA / FTA / RBD / Марковские модели"]:::big

  C --> 
  D["4. Оценка вероятностей отказов<br/>и времени простоя"]:::big

  D --> 
  E["5. Разработка мероприятий:<br/>резервирование, тесты, процедуры"]:::big

  E --> 
  F["6. Внедрение, контроль<br/>и регулярный пересмотр"]:::big
</mermaid>

</WRAP>

<WRAP box round>
**Методы анализа надёжности**

^ Метод ^ Назначение ^ Преимущества ^ Ограничения ^
| FMEA | Идентификация отказов и их последствий | Простота, подходит на ранних стадиях | Не учитывает сложные комбинации |
| FTA (дерево отказов) | Логическая декомпозиция причины критического события | Позволяет анализировать редкие, критичные сценарии | Требует полной информации |
| RBD | Математическое моделирование надёжности через последовательные/параллельные блоки | Количественные расчёты, ясная структура | Плохо описывает динамику и временные состояния |
| Марковские модели | Моделирование вероятностных переходов между состояниями | Учитывают временную динамику, деградации, восстановления | Сложны, требуют данных и инструментов |
| Стохастическое моделирование | Монте-Карло оценка частоты UE и времени простоя | Максимальная точность | Очень ресурсоёмко |
</WRAP>

<WRAP box round>
**Ключевые параметры надёжности**

  * **MTBF (Mean Time Between Failures)** — среднее время между отказами.  
  * **MTTR (Mean Time To Repair)** — среднее время восстановления.  
  * **MDT (Mean Down Time)** — среднее время простоя с учётом логистики, диагностики и ТО.  
  * **Availability (A = MTBF / (MTBF + MDT))** — доступность системы.  
  * **Failure frequency λ** (1/год или 1/час) — частота отказов.  
  * **Dependability indexes** — показатели надёжности и доступности для критичных событий (UE).  
  * **Criticality** — серьёзность последствий отказа.  
</WRAP>


<WRAP box round>
**Типовые критичные события (UE) для ЦОД**

  * **UE1 — Loss of IT process** (потеря IT-услуги)  
  * **UE2 — Safety risk** (риск для персонала)  
  * **UE3 — Environment pollution** (экологические последствия)

UE могут дополнительно декомпозироваться по длительности и тяжести  
(например: *> 4h*, *< 4h*, *loss of data*).
</WRAP>


<WRAP box round>
**Основные вопросы при оценке надёжности ЦОД**

  * Определены ли функции инфраструктуры (F1…F7)?  
  * Выделены ли UE и цели по недоступности/частоте отказов?  
  * Собраны ли данные о надёжности оборудования (λ, MDT, MTTR)?  
  * Идентифицированы ли слабые места архитектуры (SPOF)?  
  * Применены ли корректные методы анализа (FMEA/FMECA, FTA, RBD, Markov)?  
  * Проверено ли соответствие Tier-требованиям?  
  * Учтены ли деградированные режимы, отказ автоматики, датчиков, SCADA?  
  * Учитываются ли common-mode failures (общие причины отказов)?  
  * Обновляется ли анализ на стадиях проектирования, монтажа и эксплуатации?  
</WRAP>


<WRAP box round>
**Результаты применения инженерии надёжности**

  * корректно подобранная схема резервирования (N+1, N+2, 2N);  
  * отсутствие скрытых SPOF;  
  * баланс стоимости и надёжности;  
  * соответствие Tier-требованиям;  
  * количественные показатели надёжности по каждому UE;  
  * единая методология для проектирования и эксплуатации.  
</WRAP>