====== Риски на этапе проектирования ======

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

===== Формирование технической концепции =====
Исходные бизнес-требования (ТЗ) на этом этапе преобразуются в **основу проектных решений** — документ, описывающий принципиальные технические допущения, конфигурацию инженерных систем, уровни резервирования и отказоустойчивости.  
Эта основа должна обновляться по мере уточнения решений и служить связующим звеном между проектированием, строительством и эксплуатацией.

<WRAP info>
- Документ должен описывать не только конфигурацию систем, но и **логику работы ЦОДа**, включая принципы резервирования, приоритеты нагрузки и допущения по обслуживанию.  
- Это обеспечивает прозрачность для всех участников проекта и облегчает ввод в эксплуатацию.
</WRAP>

===== Оценка надёжности и отказоустойчивости =====
Для анализа риска отказов применяются базовые параметры:
  * **MTBF** — среднее время между отказами (Mean Time Between Failures);  
  * **MTTR** — среднее время восстановления (Mean Time To Repair).  

Доступность системы определяется соотношением этих величин:

<WRAP center>
$$
Доступность = \frac{MTBF}{MTBF + MTTR}
$$
</WRAP>

Например, если оборудование недоступно 9 часов за 2 года:
<WRAP center>
$$
Доступность = \frac{(2 \times 365 \times 24) - 9}{2 \times 365 \times 24} = 0{,}9995
$$
</WRAP>

Для систем ЦОД этот показатель стремится к «девяткам» — 99,9 %, 99,99 % и выше.  
Однако высокая доступность не всегда означает низкий риск: даже кратковременный отказ может повлечь значительные убытки.

===== Анализ структуры отказов =====
Для минимизации риска проект должен учитывать взаимодействие подсистем и их уязвимости. Используются методы:
  * анализ одиночных точек отказа (**SPOF**);  
  * построение деревьев отказов (**FTA**);  
  * анализ видов и последствий отказов (**FMEA/FMECA**).

<WRAP center>
$$
R = e^{-\lambda t}
$$
</WRAP>

где  
λ — частота отказов,  
t — время работы,  
R — вероятность безотказной работы (надёжность).

Если система имеет резервирование N+1, надёжность определяется как:
<WRAP center>
$$
R_{параллельная} = 1 - (1 - R)^2
$$
</WRAP>

<WRAP tip>
- Повышение резервирования увеличивает надёжность, но одновременно усложняет систему.  
- Сложность сама по себе становится источником новых рисков, связанных с управлением и человеческим фактором.
</WRAP>

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

<WRAP important>
- Система 2N считается минимальным требованием для исключения единичных точек отказа, однако при неправильной интеграции может потерять отказоустойчивость.  
- Каждый новый уровень сложности должен сопровождаться повышением уровня обучения персонала.
</WRAP>

===== Комиссионные испытания =====
Перед вводом ЦОДа в эксплуатацию проектные решения должны быть проверены на соответствие целям надёжности.  
Этап **комиссионных испытаний (commissioning)** позволяет выявить ошибки монтажа, проверить сценарии работы при отказах и подтвердить работоспособность всех систем.

<WRAP tip>
- Планирование испытаний следует начинать уже на этапе проектирования.  
- Необходимо назначить ответственного за проведение и документацию испытаний.  
- Испытания должны моделировать реальные аварийные сценарии и режимы переключения.
</WRAP>

===== Ключевые идеи =====
<WRAP tip>
- Этап проектирования формирует основу надёжности всего ЦОДа.  
- Ключевая задача — баланс между резервированием, сложностью и управляемостью.  
- Анализ SPOF, FTA и FMEA позволяет выявить и минимизировать уязвимости на ранней стадии.  
- Комиссионные испытания — обязательный элемент подтверждения проектных решений.  
- Надёжность системы зависит не только от оборудования, но и от компетентности персонала.
</WRAP>