Практически каждый специалист по ИТ сталкивался с ситуацией, когда необходимо рассчитать готовность системы, а даных, мягко говоря, маловато. Сегодня мы расскажем о том, как сделать примерный, но вполне практический расчет.

Начнем с определений к основным понятиям. Во-первых, для понимания того, насколько «высокой» должна быть готовность для различных классов систем, необходимо понимать основые термины. В чем измеряется степень готовности системы?  

Степень готовности системы описывается через коэффициент готовности, при этом он является безразмерной величиной и не может быть больше 1

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

На самом деле полученный коэффициент отражает тот временной интервал, который система может «позволить себе» простаивать за период времени.

Как же можно посчитать этот коэффициент? Согласно ГОСТ 27.002-89 коэффициент готовности это «вероятность того, что объект окажется в работоспособном состоянии в произвольный момент времени, кроме планируемых периодов, в течение которых применение объекта по назначению не предусматривается»[1]. В свою очередь, работоспособное состояние по ГОСТ 27.002-89 - это «состояние объекта, при котором значения всех параметров, характеризующих способность выполнять заданные функции, соответствуют требованиям нормативно-технической и (или) конструкторской (проектной) документации»[2]. В общем случае это можно записать следующим образом:

, где

•  - коэффициент готовности системы (К_г)
• - суммарное время нахождения объекта в работоспособном состоянии
•   - суммарное время восстановления объекта

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

1. Составить архитектурную схему системы
2. Преобразовать ее в логическую
3. Разбить на модули с последовательным/параллельным соединением компонентов
4. Выполнить расчет готовности по модулям
5. Выполнить расчет готовности для системы в целом

Итак, продемонстрируем эти шаги.

Архитектурная схема системы представляет собой набор включенных в схему объектов (оборудования) вместе с их коммуникациями. Наглядно одна из схем, описывающей архитектуру системы показана на следующем рисунке:

Рис.1. Схема, отражающая архитектуру системы

На Рис.2 наглядно показан процесс преобразования из одного типа системы в другой.

Рис.2. Преобразование архитекурной схемы в логическую и разделение ее на модули

Обычно полагают, что чем выше готовность системы, тем лучше – вполне логично. Также обычно полагают, что если систему задублировать, то готовность системы будет выше вдвое.

Однако это не так. Логика данного суждения понятна: была одна система - стало две, в 2 раза больше элементов, а если одна упадет, вторая «поддержит» - значит и готовность системы должна стать в два раза больше.

Мы обещали не загромождать статью громоздкими выводами формул, поэтому приводим их ниже лишь для иллюстрации наших рассуждений. Главное, что при расчете учитывается, КАК внутри системы связаны объекты (оборудование). Для последовательного или параллельного соединения готовность считается по-разному, что в итоге существенно сказывается на окончательном результате для всей системы.

Вероятность безотказной работы системы рассчитывается как:

- для последовательного соединения

- для параллельного соединения

Для примера предположим, что коэффициент готовности отдельного сервера равен 0,99. В случае кластера коэффициент готовности системы будет, согласно формулам, составлять 0,9999:

Надо отметить, что готовность повысилась не в 2 раза, а на 2 порядка, т.е. стала лучше в 100 (!) раз.

Рассмотрим пример, который мы раньше приводили на Рис.1 . Предположим, для каждого элемента уже имеются значения К_г поэтому рассчитать коэффициент готовности для каждого модуля довольно просто:

Итоговое значение:

Также на основе указанных формул можно отметить, что:

Коэффициент готовности системы не может быть выше наименьшего коэффициента готовности среди компонентов данной системы в случае последовательного соединения.

При создании кластера коэффициент готовности системы повышается минимум в 10 раз при условии, что К_г элемента больше 0,9.

Итак, получен результат:

Вернемся к вопросу в начале статьи: что же означает это число? Ниже приведена таблица соответствия коэффициента готовности и времени простоя системы.

 

Коэффициент готовности	Время простоя
0,9	36,5 дня
0,99	3,65 дня
0,999	8,76 часа
0,9999	52,56 минуты
0,99999	5,256 минуты

Таблица 1. Соответствие коэффициента готовности и времени простоя

Итак, полученный результат коэффициента готовности из примера на картинке означает, что суммарное время простоя всей системы в год будет составлять 2,8 минуты. Если рассмотреть другой пример, описанный в этой статье, то наличие одного сервера с К_г= 0,99 означало простой системы на 3,65 дня, добавление еще одного сервера в кластер позволило снизить время простоя до 52 минут.

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

1. Сколько в деньгах потеряет бизнес при отсутствии поддержки от ИТ за определенное по расчетам время? Дело в том, что в зависимости от специфики производства/бизнеса, отсутствие поддержки может как очень сильно отразиться на бизнесе, так и почти совсем не повлиять. Например, для крупного телекоммуникационного провайдера или банка останов биллинговой системы мгновенно начинает приносить огромные убытки. А вот для некоторых производств ничего особенно «страшного» не произойдет – особенно там, где непосредственный производственный процесс контролируется людьми, а компьютерные системы лишь обрабатывают вторичную информацию.
2. Учесть косвенные потери (ущерб для имиджа, переход клиентов к конкурентам или отказ от сервисов и т.д.

Здесь надо четко понимать, решение о необходимом уровне готовности принимает бизнес, а не ИТ. Что это означает? Это означает, что в идеале, CIOпредставляет бизнес-руководителям таблицу, где отмечены следующие колонки:

• Коэффициент готовности (разные варианты или уровни)
• Времена простоя, соответствующие этим коэффициентам
• Сколько нужно денег для закупки – чтобы достичь того или иного уровня
• Пустая колонка, которую должен заполнить бизнес: сколько денег теряет бизнес при тех или иных временах простоя, с учетом косвенных потерь

Не надо забывать, что коэффициент готовности элемента инфраструктуры больше 0,999 встречается