Надёжность, устойчивость, доступность

> недостаточно написать что-то вроде «система должна обладать высокой доступностью», а нужно определить, что именно считается отказом?

Конечно. По хорошему нужно указать не только подробно критерий отказа, но и надежностную схему. Причем это скорее всего будут не последовательно - параллельные структуры, а модели типа марковской цепи. В идеале еще и метод тестирования (проверки) расписать. Однако такое редко встречается, обычно речь только о первой в противопоставлении: "менеджерская надежность" vs "инженерная надежность", как пример тут. Отказоустойчивость узлов. "Настоящий отказ" (FT) - это что-то сломалось и нужно а) переключить на резервный узел (если есть) и чинить сломанное (для восстанавливаемых элементов). Если мы говорим про "отказ в обслуживании" когда достаточно просто переждать пиковый поток запросов и далее система станет работать штатно, то тут "Ненастоящий отказ", хотя да система не выполняет функции. Видимо для этого нужно особый термин ввести. По аналогии: сбой — самовосстанавливающийся отказ. При "отказе в обслуживании" (Highload) иная природа отказа (недоступности) и восстановления - поэтому будут разные модели (далее их можно объединить). Хотя для пользователя (в конечном счете) не так важно: сервис недоступен, потому что сгорел сервер или сервер перегружен (или обслуживает более приоритетную нагрузку).