Системы с высокой доступностью

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

Как правило в обеспечении надежности эксплуатируемой организацией системы стоит начинать с потребностей самой организации. Для этого нужно структурировать ее цели и потери которые могут вызвать отказы системы, их масштабы и показатели. Обычно цели организации определяются через уже установленные стандарты business continuity и через управление рисками, но эта тема вне серии статей. Клаус Шмидт в книге “High availability and disaster recovery. Concepts, design, implementation” предлагает следующую классификацию для описания ущерба организации в случае отказа:

Наиболее очевидная цена сбоя и простоя системы и вероятно наиболее затратная - уменьшение пользовательской продуктивности. Фактическая цена простоя зависит от того на какую пользовательскую деятельность сбой повлиял и какое количество пользователей он затронул. Простой пример:

И так имеем следующий список затрат. Простой в работе для разработчиков и тестировщиков:

$50 * 8 часов * 2 дня * 30 человек = $24000

Сверхурочные для администраторов:

$50 * 16 часа * 2(коэффициент за сверхурочные) = $1600

Недополученная выручка:

$21000 * 3 дня = $63000

Пример крайне поверхностный и окончательный подсчет ущерба от сбоя зависит от правил учета затрат в организации и текущих планов по выручке. Если план включал не только те три разрабатываемые фичи, тогда имеет смысл использовать cost of delay показатель и для более отдаленных релизов. Но не стоит все затраты, понесенные во время сбоя, списывать на его ликвидацию.

Кроме выше изложенных потерь к последствиям сбоя можно отнести:

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

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

Источник: https://www.ecessa.com/blog/downtime-costs/

Собственно формула расчет доступности:
A = MTBF / (MTBF + MTTR)
A - собственно сам показательно доступности
MTBF - mean time between failures (среднее время между отказами)
MTTR - maximum time to resolve (максимальное время восстановления)

Для удобства A умножают на 100, чтобы получить процент бесперебойной работы, именно из этого показателя формируется всем известная “доступность” по количеству девяток. На всякий случай таблица с ними для 24х7 сервисов:

При эксплуатации системы и расчете доступности не всегда имеется в виду, что система эксплуатируется круглосуточно и весь год. Поэтому если кто-то декларирует доступность в несколько девяток следует уточнить в каких временных интервалах и как декларируют графики обслуживания системы для клиентов. Обычно в секции Service Level Agreement (SLA) оговаривается время когда именно эта сама доступность измеряется. Чаще всего используют привычные многим обозначения с HxD, где H - количество рабочих часов в сутках, D - количество рабочих суток в неделе. Типичные варианты:

Теперь сводная таблица:

При таком подходе в оценке доступности системы необходимо отметить следующее:

При обсуждении SLA имеет смысл обсуждать и фиксировать в договоренностях не абстрактные девятки процента доступности сервисов, а фактические (то есть абсолютные) показатели доступности сервисов в рабочие часы, чтобы избежать недопониманий и ложных ожиданий в будущем. Также не стоит недооценивать трудности достижения показателей высокой доступности таких как 99.99%, 53 минуты простоя в год должны означать, что организация имеет возможность обработать даже самый катастрофический сбой в системе менее чем за 1 час.

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