Высокая доступность — это то, что любят демонстрировать в цифрах. Все уже привыкли к маркетинговым ходам и доступность в 99% кажется просто фантастически высокой. Лишь малая часть клиентов понимают, что доступность 98- 99% это очень плохая, местами никуда не годная цифра.

Посмотрите на эти цифры и вы поймете, чем доступность в 90% отличается от доступности в 99,999%:

Доступность	Время простоя в месяц	Время простоя в год
90%	3 дня	37 дней
98%	14,6 часов	7,3 дня
99%	7,3 часа	3,7 дней
99,8%	1,5 часа	18 часов
99,9%	44 минуты	8.8 часов
99,99%	4.4 минуты	53 минуты
99,999%	26 сек	5,3 минуты

Посмотрев на таблицу выше вы понимаете, что датацентр, гарантирующий сетевую доступность в 99% может позволить себе 7 часов простоя в месяц. Представьте себе такую ситуацию: весь день в датацентре что-то чинят, ваш сайт недоступен, вы несете убытки, а предъявить претензии датацентру не можете — даже при этой ситуации он обеспечит обещанную доступность.

Я считаю сетевую доступность 99% плохой. Предпочитаю датацентры, обеспечивающие не менее 99,9% сетевой доступности.

Наверное, существуют интернет-проекты, которые могут пережить и 37 дней простоя в год (больше месяца!). Но всё-таки большинство интернет-магазинов, порталов и сайтов (в особенности тех, чьи транзакции проходят через сайт) не могут себе позволить такой роскоши, как даже 18 часов в год. Репутацию восстановить сложно всегда, а если она теряется по причинам “у системного администратора выходной” это и вовсе обидно.

“Пять девяток” — вот, что такое высокая доступность

Термин “пять девяток” означает доступность 99,999% и встречается в маркетинговой литературе не реже, чем в технической. Считается, что сайт или система с уровнем доступности «пять девяток» — это и есть высокая доступность.

Высокая доступность нужна всем

Из таблицы видно, что 99,999% доступности — это всего 5,3 минуты простоя в год. Но даже те датацентры, которые гарантируют 100% доступность нередко пускаются на маркетинговые ухищрения.
Например, вычитают время регламентного обслуживания из времени доступности. К примеру, дата-центр обещает доступность 99.99%, но в момент, когда проводит плановые работы по замене чего-нибудь пишет “проводятся регламентные работы в течение 2 часов” и не считает это за недоступность. Отсюда вывод — читайте соглашение об уровне обслуживания (SLA) внимательно.

Если вы хотите обеспечить максимально высокую доступность вашему сайту на одном единственном сервере, выбирайте датацентр с хорошей ГАРАНТИРОВАННОЙ SLA (соглашением об уровне обслуживания) доступностью.

Обратите внимание! В SLA должно быть гарантировано время замены неисправного железа. И, в идеале, время реакции на проблему.

Кроме того, ваш админ должен отслеживать работу сервиса и быстро реагировать на недоступность.

Немного о том, из чего складывается высокая доступность

Доступность может быть сетевая и сервиса.

Сетевая доступность — это когда ваш сервер доступен по сети.
Доступность сервиса — это когда ваш сервер может обслуживать клиентов.

Доступность сервиса не может быть лучше сетевой доступности, если вы не используете альтернативных подключений (со своей сетевой доступностью).

Доступность сервиса зависит от:

• сетевой доступности вашего сервера
• скорости реакции вашего админа на проблему
• скорости реакции поддержки дата-центра на проблему
• скорости замены неисправного железа в дата-центре

Недоступность складывается из:

• проблем сетевой доступности
• проблем с “железом”
• проблем с нагрузкой на сервере (“тормозит”, не справляется)
• программных ошибок (“косяки” программистов)

И месячную (кроме случаев поломки железа) и уж тем более годовую доступность 99,8% можно обеспечить в хорошем ДЦ на одном сервере без дополнительных мер обеспечения отказоустойчивости. Доступность 99,9% уже требует некоторого везения.

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

Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.

Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности .

Предисловие

В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.

• Отказоустойчивость (Fault Tolerance, FT) - способность системы к дальнейшей работе после выхода из строя какого-либо её элемента.
• Кластер - группа серверов (вычислительных единиц), объединенных каналами связи.
• Отказоустойчивый кластер (Fault Tolerant Cluster, FTC) - кластер, отказ сервера в котором не приводит к полной неработоспособности всего кластера. Задачи вышедшей из строя машины распределяются между одной или несколькими оставшимися нодами в автоматическом режиме.
• Непрерывная доступность (Continuous Availability, CA) - пользователь может в любой момент воспользоваться сервисом, перерывов в предоставлении не происходит. Сколько времени прошло с момента отказа узла не имеет значения.
• Высокая доступность (High Availability, HA) - в случае выхода из строя узла пользователь какое-то время не будет получать услугу, однако восстановление системы произойдёт автоматически; время простоя минимизируется.
• КНД - кластер непрерывной доступности, CA-кластер.
• КВД - кластер высокой доступности, HA-кластер.

Пусть требуется развернуть кластер из 10 узлов, где на каждой ноде запускаются виртуальные машины. Стоит задача защитить виртуальные машины от сбоев оборудования. Для увеличения вычислительной плотности стоек принято решение использовать двухпроцессорные серверы.

На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.

Continuous availability / непрерывная доступность

Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.

Аппаратный способ представляет собой “раздвоенный” сервер: все компоненты дублированы, а вычисления выполняются одновременно и независимо. За синхронность отвечает узел, который в числе прочего сверяет результаты с половинок. В случае несоответствия выполняется поиск причины и попытка коррекции ошибки. Если ошибка не корректируется, то неисправный модуль отключается.
На Хабре недавно была на тему аппаратных CA-серверов. Описываемый в материале производитель гарантирует, что годовое время простоя не более 32 секунд. Так вот, для того чтобы добиться таких результатов, надо приобрести оборудование. Российский партнёр компании Stratus сообщил, что стоимость CA-сервера с двумя процессорами на каждый синхронизированный модуль составляет порядка $160 000 в зависимости от комплектации. Итого на кластер потребуется $1 600 000.

Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности - от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.

В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:

• На физическом хосте должен быть процессор:
  • Intel архитектуры Sandy Bridge (или новее). Avoton не поддерживается.
  • AMD Bulldozer (или новее).
• Машины, на которых используется Fault Tolerance, должны быть объединены в 10-гигабитную сеть с низкими задержками. Компания VMware настоятельно рекомендует выделенную сеть.
• Не более 4 виртуальных процессоров на ВМ.
• Не более 8 виртуальных процессоров на физический хост.
• Не более 4 виртуальных машин на физический хост.
• Невозможно использовать снэпшоты виртуальных машин.
• Невозможно использовать Storage vMotion.

Полный список ограничений и несовместимостей есть .
Экспериментально установлено, что технология Fault Tolerance от VMware значительно “тормозит” виртуальную машину. В ходе исследования vmgu.ru после включения FT производительность ВМ при работе с базой данных упала на 47%.

Лицензирование vSphere привязано к физическим процессорам. Цена начинается с $1750 за лицензию + $550 за годовую подписку и техподдержку. Также для автоматизации управления кластером требуется приобрести VMware vCenter Server, который стоит от $8000. Поскольку для обеспечения непрерывной доступности используется схема 2N, для того чтобы работали 10 нод с виртуальными машинами, нужно дополнительно приобрести 10 дублирующих серверов и лицензии к ним. Итого стоимость программной части кластера составит 2 *(10 + 10)*(1750 + 550)+ 8000 =$100 000.

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

Стоит упомянуть и о тех продуктах, разработка которых остановилась.

Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.

Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.

Первый - Kemari , продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.

Второй - Micro Checkpointing , основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.

Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.

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

High availability / высокая доступность

В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.

В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.

Таким образом, кластер высокой доступности делится на два подкластера:

• Вычислительный. К нему относятся ноды, на которых непосредственно запущены виртуальные машины
• Кластер хранилища. Тут находятся диски, которые используются нодами вычислительного подкластера.

На данный момент для реализации КВД с виртуальными машинами на нодах есть следующие инструменты:

• Heartbeat версии 1.х в связке с DRBD;
• Pacemaker;
• VMware vSphere;
• Proxmox VE;
• XenServer;
• Openstack;
• oVirt;
• Red Hat Enterprise Virtualization;
• Windows Server Failover Clustering в связке с серверной ролью “Hyper-V”;
• VMmanager Cloud.

Познакомим вас с особенностями нашего продукта VMmanager Cloud.

VMmanager Cloud

Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.

В упрощённой форме алгоритм такой:

1. Происходит поиск узла кластера с наименьшим количеством виртуальных машин.
2. Выполняется запрос хватает ли свободной оперативной памяти для размещения текущей ВМ в списке.
3. Если памяти для распределяемой машины достаточно, то VMmanager отдаёт команду на создание виртуальной машины на этом узле.
4. Если памяти не хватает, то выполняется поиск на серверах, которые несут на себе большее количество виртуальных машин.

Мы провели тестирование на многих конфигурациях железа, опросили существующих пользователей VMmanager Cloud и на основании полученных данных сделали вывод, что для распределения и возобновления работы всех ВМ с отказавшего узла требуется от 45 до 90 секунд в зависимости от быстродействия оборудования.

Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.

VMmanager Cloud поддерживает следующие типы хранилищ: файловая система, LVM, Network LVM, iSCSI и Ceph . В контексте КВД используются последние три.

При использовании вечной лицензии стоимость программной части кластера из десяти “боевых” узлов и одного резервного составит €3520 или $3865 на сегодняшний день (лицензия стоит €320 за ноду независимо от количества процессоров на ней). В лицензию входит год бесплатных обновлений, а со второго года они будут предоставляться в рамках пакета обновлений стоимостью €880 в год за весь кластер.

Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.

FirstByte

Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:

1. Возможность предоставления виртуальных машин на KVM;
2. Наличие интеграции с Ceph;
3. Наличие интеграции с биллингом подходящим для предоставления имеющихся услуг;
4. Доступная стоимость лицензий;
5. Наличие поддержки производителя.

В итоге лучше всего по требованиям подошел VMmanager Cloud.

Отличительные черты кластера:

• Передача данных основана на технологии Ethernet и построена на оборудовании Cisco.
• За маршрутизацию отвечает Cisco ASR9001; в кластере используется порядка 50000 IPv6 адресов.
• Скорость линка между вычислительными нодами и коммутаторами 10 Гбит/с.
• Между коммутаторами и нодами хранилища скорость обмена данными 20 Гбит/с, используется агрегирование двух каналов по 10 Гбит/с.
• Между стойками с нодами хранилища есть отдельный 20-гигабитный линк, используемый для репликации.
• В узлах хранилища установлены SAS-диски в связке с SSD-накопителями.
• Тип хранилища - Ceph.

В общем виде система выглядит так:

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

FirstVDS

Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.

К использованию VMmanager Cloud компания пришла из следующих соображений:

1. Большой опыт работы с продуктами ISPsystem.
2. Наличие интеграции с BILLmanager по умолчанию.
3. Отличное качество техподдержки продуктов.
4. Поддержка Ceph.

Кластер имеет следующие особенности:

• Передача данных основана на сети Infiniband со скоростью соединения 56 Гбит/с;
• Infiniband-сеть построена на оборудовании Mellanox;
• В узлах хранилища установлены SSD-носители;
• Используемый тип хранилища - Ceph.

Общая схема выглядит так:

В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.

Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.

Эпилог

Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки - не обойтись без кластера непрерывной доступности.

Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.

Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости - избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать - резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя. Добавить метки

Определения

Всем известно , что в Microsoft Exchange DAG означает « Database Availability Group » — «Группа Доступности Базы данных».

База данных — потому что уровень высокой доступности сервера почтовых ящиков Exchange 2010 , определяется базой данных , а не сервером , именно база данных является той единицей , которая может перемещаться между несколькими серверами в пределах группы доступности баз данных в случае сбоя. Этот принцип известен как мобильность базы данных.

Группа — потому что сфера наличия определяется серверами почтовых ящиков в группе обеспечения доступности баз, которые объединены в отказоустойчивый кластер и работают вместе как группа .

Доступность — этот термин , кажется, наименее очевидным и наиболее запутанным . Как ни странно, этот термин имеет прямое математическое определение и играет важную роль в понимании принципов проектирования Exchange в целом .

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

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

Математически это может быть измерено путем подсчета количества времени, когда система доступна («Время работы «) в течение некоторого большого статистически репрезентативного периода (обычно года ), и разделив его на общую длину периода . Используя широко принятые сроки среднее время между отказами (MTBF — Mean Time Between Failures) и среднее время обслуживания (MTTR — Mean Time To Repair) — представляем доступность системы / время работы между отказами, время простоя системы в течение любого данного отказа , — доступность может быть выражена как фракция:

Противоположная математическая характеристика будет вероятность отказа :

Доступность часто выражается как «количество девяток «, в соответствии со следующей таблицей :

Уровень доступности	Значение доступности	Вероятность отказа	Допустимое время простоя в год
Две девятки	99%	1%	5256 минут = 3.65 дня
Три девятки	99.9%	0.1%	525.6 минут = 8.76 часов
Четыре девятки	99.99%	0.01%	52.56 минут
Пять девяток	99.999%	0.001%	5.26 минут

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

Влияние зависимостей на доступность

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

Для данной базы данных почтовых ящиков , следующие компоненты можно считать, как критические зависимости :
дисковая подсистема базы данных / система хранения — например A1 ;
сервер почтовых ящиков (как аппаратные, так и программные компоненты ) — A2 ;
сервер клиентского доступа (аппаратное и программное обеспечение компонентов ) — помним, что в Exchange 2010 все клиенты подключаются к базе данных почтовых ящиков только через Client Access Server (Сервер с ролью клиентского доступа), и давайте предположим, что CAS установлен отдельно от сервера почтовых ящиков — A3 ;
сетевое подключение между клиентами и Client Access Server, и между сервером клиентского доступа и сервером почтовых ящиков — A4 ;
электроэнергия в центре обработки данных , где расположены серверы и системы хранения — A5.

Этот список можно было бы продолжить … Например , Active Directory и DNS также представляют критическую зависимость для Exchange. Кроме того , в дополнение к чисто технологическим зависимостям , на доступность оказывает влияние таких факторов, как человеческая ошибка , неправильное выполнение стандартных операций обслуживания, отсутствие координации команды техподдержки. Все это может привести к неработоспособности . Мы не будем пытаться компилировать любой исчерпывающий перечень зависимостей , а вместо этого сосредоточимся на том, как они влияют на общую доступность услуг .

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

Например, если подбросить три монеты , вероятность выпадения «орла» для всех трех монет (1/2) * (1/2) * (1/2) = 1/8 .

Важно понимать, что , значение доступности не может быть больше чем 1 (или 100% ), и в результате доступность сервиса является продуктом доступности индивидуальных компонентов , значение доступности которых не может быть больше , чем самый низкий из составляющих зависимость доступности.

Это можно проиллюстрировать на примере , представленном в следующей таблице (цифры примерны):

Критическая зависимость	Вероятность отказа	Уровень доступности
Сервер почтовых ящиков и система хранения	5%	95%
Сервер клиентского доступа	1%	99%
Сеть	0.5%	99.5%
Питание	0.1%	99.9%
	6.51383%	95% x 99% x 99.5% x 99.9% = 93.48617%

Из этого примера , можно увидеть, как критически важные зависимости влияют на доступность сервиса. Даже для базы данных почтовых ящиков , которая никогда не выходит из строя (не будет повреждена , никогда не получит никаких вирусных инфекции и т.д.) , доступность до сих пор остается ниже 93,5 %!

Заключение : Большое количество сервисных зависимостей уменьшается доступность .

Все, что мы сделаем для уменьшения количества или воздействия зависимостей положительно скажется на общей доступности сервиса . Например , мы могли бы улучшить ситуацию путем упрощения и обеспечения управления серверами и оптимизации оперативных процедур . С технической стороны , мы можем попробовать уменьшить количество сервисных зависимостей , сделав наш дизайн проще — например , устраняя сложные системы хранения на основе SAN , волоконных коммутаторов , контроллеров массива , и даже RAID контроллеров и заменив его простым DAS с минимумом движущихся частей .
Снижение сервисных зависимостей само по себе не может быть достаточно, чтобы довести доступность до желаемого уровня . Еще один очень эффективный способ увеличить доступность и свести к минимуму воздействие критических зависимостей обслуживания заключается в привлечении различных методов резервирования , таких как использование двух источников питания , объединение сетевых карт , подключение серверов к нескольким сетевым коммутаторам , используя RAID для операционной системы , развертывания аппаратных балансировщиков для серверов клиентского доступа и нескольких копий баз данных почтовых ящиков . Но как именно увеличение избыточности позволяет достигнуть высокой доступности ? Давайте более подробно рассмотрим балансировку нагрузки и несколько копий базы данных в качестве важных примеров .

Как влияет резервирование на доступность

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

Как определено ранее , вероятность отказа для любого данного экземпляра Р = 1 — А. Все экземпляры статистически независимы друг от друга , что означает, что работоспособность или выход из строя любого из них не влияет на доступность в других случаях . Например , выход из строя данной копии базы данных не влияет на вероятность отказа для другой копии этой базы данных (возможен логичный нюанс , когда поврежденная копия распространит изменения на другие экземпляры, но давайте игнорировать этот фактор — в конце концов, всегда можно воспользоваться отстроченной копией базы данных или вариантом восстановления средствами традиционного резервного копирования ).

Опять используя ту же теорему теории вероятностей , вероятность отказа набора n независимых компонентов является продуктом вероятностей для каждого компонента . Так как все компоненты здесь идентичные (различные экземпляры того же объекта ):

Очевидно, как P < 1, P n меньше P , что означает, что вероятность отказа уменьшается , и соответственно , доступность увеличивается :

Рассмотрим некоторый реальный пример из жизни для ясности . Скажем , что мы устанавливаем несколько копий базы данных почтовых ящиков ; каждая копия размещается на одном диске SATA . По статистике, процент неудач SATA дисков составляет ~ 5 % в течение года , что дает нам 5 % вероятность отказа : P = 0,05 (что означает наличие 95% : A = 0,95 ). Как изменится доступность по мере добавления копии базы данных ? Посмотрим на следующей таблице :

Количество копий	Вероятность отказа	Уровень доступности
1	P 1 = P = 5%	A 1 = 1 – P 1 = 95%
2	P 2 = P 2 = 0.25%	A 2 = 1 – P 2 = 99.75%
3	P 3 = P 3 = 0.0125%	A 3 = 1 – P 3 = 99.9875%
4	P 4 = P 4 = 0.000625%	A 4 = 1 – P 4 = 99.9994%

Впечатляет ? В принципе, каждый дополнительный экземпляр базы данных на SATA диск вводит коэффициент умножения 5% или 1/20 , так что вероятность отказа становится в 20 раз ниже, с каждой копии (и, соответственно , доступность увеличивается) . Мы можем видеть, что даже на самых ненадежных дисках SATA , внедряя всего 4 копии баз данных приносит нам доступность базы данных в пять девяток .
Это уже очень хорошо , но можем ли сделать еще лучше? Можем ли мы увеличить доступность еще , не делая архитектурных изменений (например, при добавлении еще одной копии базы данных )?

На самом деле , можем. Если нам улучшить индивидуальную доступность любого компонента зависимости, он будет фактором повышения общей доступности сервиса , и приведет к гораздо более сильному эффекту, чем от добавления избыточного компонента . Например , одним из возможных способов сделать это , является использование Nearline SAS диски вместо дисков SATA . Диски Nearline SAS имеют годовой уровень отказов ~ 2,75 % вместо ~ 5 % для SATA . Это уменьшит вероятность отказа для компонента хранения и , следовательно, увеличит общую доступность сервиса . Достаточно сравнить эффект от добавления нескольких копий базы данных :
5% Коэффициент AFR = 1/20 = умножение каждого нового экземпляра делает повреждение базы данных в 20 раз реже .
2,75 % AFR = 1/36 коэффициент умножения = каждый новый экземпляр делает повреждение базы данных в 36 раз реже .

Это значительное влияние на доступность базы данных, что также объясняет указания использовать концепцию собственной защиты данных Exchange — Exchange Native Data Protection, которая объясняет, что несколько копий базы данных может быть заменой для традиционных резервных копий , если развернуто достаточное количество (три или больше).

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

Критическая зависимость	Вероятность отказа	Уровень доступности
Сервер почтовых ящиков и хранилище (4 копии)	5% ^ 4 = 0.000625%	99.999375%
Сервер клиентского доступа (4 сервера, развернутых отдельно)	1% ^ 4 = 0.000001%	99.999999%
Сеть	0.5%	99.5%
Питание	0.1%	99.9%
Общее значение (зависит от всех указанных компонентов)	0.6%	99.399878%

Мы можете видеть, что как только мы развернули 4 сервера клиентского доступа и 4 копии баз данных , вероятность отказа от общего обслуживания уменьшилась более чем в 10 раз (с 6,5% до 0,6% ) и, соответственно, доступность услуг увеличилась с 93,5 % до гораздо более приличного значения 99,4 %!

Вывод: Добавление избыточности для зависимостей повышает доступность .

Соединим вместе

Возникает интересный вопрос от предыдущих выводов . Мы проанализировали два различных фактора, влияющих на общую доступность услуг двумя различными способами и нашли два четких вывода :
добавление больше системных зависимостей уменьшается доступность
добавление избыточности в системных зависимостях увеличивает доступность
Что произойдет, если соединить в решение оба фактора? Какие тенденции сильнее?
Рассмотрим следующий сценарий :
Мы используем два сервера почтовых ящиков в группе DAG с двумя копиями базы данных почтовых ящиков (один экземпляр на каждом сервере ), и мы используем два сервера клиентского доступа в массиве с балансировкой нагрузки . (Для простоты мы будем рассматривать только наличие базы данных почтовых ящиков для клиентских подключений , не рассматривая роль транспортного сервера-концентратора и единой системы обмена сообщениями ) . Если предположить, что каждый сервер имеет свою индивидуальную вероятность отказа P , будет ли наличие такой системы лучше или хуже , чем от одного развернутого автономного сервера Exchange с обеими ролями сервера почтовых ящиков и клиентского доступа ?

В первом сценарии , серверы почтовых ящиков являются независимыми и станут недоступны , только если оба сервера выйдут из строя. Вероятность выхода из строя набора из двух серверов почтовых ящиков будет P × P = P 2 . Соответственно , его доступность будет A MBX = 1 – P 2 . Следуя той же логике , служба CAS будет недоступна только , если оба сервера клиентского доступа выйдут из строя, поэтому вероятность отказа для набора из двух серверов клиентского доступа будет снова P × P = P 2 и, соответственно, его доступность будет A CAS = 1 – P 2 .
В этом случае , как мы уже поняли, два сервера почтовых ящиков или два сервера клиентского доступа являются примерами избыточных компонентов системы .
Продолжаем этот сценарий . Для того, чтобы вся система была доступна , оба набора серверов (набор серверов почтовых ящиков и набор серверов клиентского доступа ) должны быть доступны одновременно . Не выходят из строя одновременно , но доступны одновременно , потому что теперь они представляют системные зависимости , а не избыточные компоненты . Это означает, что в целом доступность службы является продуктом доступности каждого набора :

Конечно, второй вариант значительно проще, так как существует только один сервер и рассмотреть его доступность просто A = 1 – P .
Так что теперь мы рассчитали значения доступности для обоих сценариев. Значение которого выше , (1-P 2 ) 2 или 1-P ?

Если построить графики обеих функций , мы увидим следующее поведение :

Мы видим, что для малого значения Р, наличие комплексной системы из 4 серверов выше, чем от наличия одного сервера. Нет ничего удивительного, это то, что мы ожидали, не так ли? Тем не менее, при Р ~ 0,618 — два участка пересекают, и при больших значениях P единая система сервера на самом деле имеет более высокую доступность. Конечно, вероятнее было бы ожидать, что значение Р должно быть очень близко к нулю в реальной жизни. Однако, если мы планируем создать собственное решение из очень ненадежных компонентов, вероятно, решение в виде одного сервера будет лучше.

Влияние точек отказа

К сожалению, сценарии развертывания, описанные выше, в реальной жизни встречаются редко. Например, как повлияет на изменение доступности при условии развертывания сервера с несколькими ролями? Мы заметили, что в приведенном выше примере, сочетание ролей сервера эффективно снижает количество служебных зависимостей, так что, вероятно, все будет хорошо? А что произойдет, если мы разместим две копии базы данных из одной базы данных на одном массиве SAN или DAS? Что делать, если все серверы почтовых ящиков подключены к одному коммутатору сети? Что делать, если у нас есть все вышеперечисленное и многое другое?

Все эти ситуации сталкивают нас с понятием точки отказа. В приведенных выше примерах серверного оборудования или массив SAN или сетевой коммутатор представляют собой точки отказа. Точка отказа ломает независимость или избыточность компонентов, что он сочетает — например, выход из строя компонентов серверного оборудования в сервере с сочетанием ролей означает, что все роли на этом сервере станут недоступны; соответственно, отказ диска или массива SAN означает, что все копии баз данных, размещенных на данном диске или массиве становятся недоступными.

Но наличие точки отказа не обязательно плохо. Важным отличием является то, что компоненты, составляющие точку отказа — отличаются от зависимостей системы или избыточных компонентов системы. Рассмотрим два из приведенных выше примеров, чтобы понять эту разницу.

Сценарий сервера с мультиролями

Давайте сравним наличие двух различных систем:
1.Роли сервера почтовых ящиков и сервера клиентского доступа, размещенные на том же сервере, который имеет вероятность аппаратных сбоев P;
2.Те же роли размещены на двух отдельных серверов, каждый из которых имеет одинаковую вероятность отказа оборудования.

В первом случае, аппаратные средства одного сервера представляют собой точку отказа. Это означает, что все размещенные роли либо доступны, либо недоступны. Это просто, в целом доступность такой системы A = 1 – P.

Во втором случае, в целом сервис будет доступен только тогда, когда оба сервера доступны независимо (потому как каждая роль представляет собой критическую зависимость). Поэтому, основываясь на теории вероятностей, его наличие будет A × A = A2.

Опять же, как А <1, это означает, что A2 < А, так во втором случае доступность будет ниже.

Судя по всему, мы можем добавить другие роли сервера Exchange (Hub Transport, и единой системы обмена сообщениями при необходимости) по тому же сценарию, не нарушая эту логику.

Вывод: Размещение ролей сервера Exchange на сервере с мультиролью повышает общую доступность услуг.

Сценарий общего хранилища

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

1.Две копии баз данных, размещенных на одном и том же хранилище (массив SAN или DAS), который имеет вероятность отказа P;
2.Те же копии баз данных, размещенные на двух отдельных системах хранения данных, каждая из которых имеет одинаковую вероятность отказа.

В первом случае, общее хранилище представляет собой точку отказа. Как и в предыдущем сценарии, это означает, что обе копии базы данных доступны или недоступны одновременно, так что общий уровень доступности снова A = 1 – P.

Во втором случае, в целом служба будет доступна, если по крайней мере одна система доступна и недоступна только если обе системы выйдут из строя. Системы хранения являются независимыми. Поэтому, вероятность отказа для общего обслуживания P × P = P2 и, соответственно, общая доступность услуг является A = 1 – P2.

Опять же, если P < 1, то это означает, что Р2 <Р, и, следовательно, 1 – P2 > 1 – P. Это означает, что уровень доступности во втором случае гораздо выше.

Вывод: Размещение копий одной базы данных на одной и той же системе хранения уменьшает общую доступность услуг.

Так в чем же разница между этими двумя сценариями, почему введение точек отказа увеличивает доступность в первом случае и снижает доступность в другом?

Это потому, что точка отказа в первом случае сочетает обслуживание зависимостей, эффективно уменьшая их количество и, следовательно, повышает уровень доступности, в то время как точка отказа во втором случае сочетает избыточные компоненты, эффективно уменьшая избыточность и поэтому доступность ухудшается.

Все эти понятия и выводы могут быть, представлены в следующем виде:

Выводы

Архитектура Exchange 2010 предоставляет мощные возможности для добавления избыточности (например, развертывание нескольких копий базы данных или несколько серверов клиентского доступа в массиве CAS ) и уменьшения количества системных зависимостей (путем объединения ролей сервера Exchange или с помощью простой архитектуры хранения без чрезмерного количества критических компонентов ). Простые правила и формулы , представленные в этой статье позволяют рассчитать влияние на стоимость доступности от развертывания дополнительных копий баз данных или из сочетания ролей сервера Exchange. Также можно рассчитать влияние точек отказа. Реальная жизнь редко вписывается в простые базовые сценарии , и понадобятся гораздо более сложные расчеты , чтобы получить разумные оценки уровня доступности реальных систем ; это можно облегчить и просто измерить уровень доступности статистически и проверить , отвечает ли он требованиям SLA . Тем не менее, понимание факторов, влияющих на доступность вместе с сложностью технического решения должно помочь спроектировать решение правильно и достичь значительного увеличения общего уровня доступности служб даже для самых взыскательных бизнес-требований .

Последнее время я все больше укрепляюсь в давно блуждающей в моей голове и довольно еретической мысли: классический показатель доступности малопригоден для измерения и оценки доступности ИТ-услуг в реальном мире. И в ряде случаев от него можно легко отказаться. Эти случаи касаются в первую очередь измерения доступности услуг типа « » (фактически речь идет об ИТ-доступности бизнес-процессов). Попробую обосновать и буду рад услышать возражения.

Полагаю, всем читателям портала знакома формула:

Availability = (AST — DT)/AST ,

где AST - согласованное время предоставления услуги, DT - сумма простоев за период.

А также, вероятно, знакомы сложности ее применения:

Первая сложность связана с обсуждением показателя. Доступность определена как 99,9%. Вроде неплохо. Но 0,1% в год равен почти 9 часам. А в месяц - это почти 45 минут. А в неделю - чуть более 10 минут. Так какие 99,9% имел в виду заказчик? А сервис-провайдер?

Однако значительно более существенен следующий нюанс: показатель довольно неточно отражает негативное влияние на бизнес. Что если все без малого 9 часов за год случились разом? Или услуга становилась недоступна потребителям по две минуты, но 15 раз за один день? Как это будет выражено в процентах?.. Поэтому, например, ITIL вводит такие показатели, как MTRS, MTBF, MTBSI.

Однако предлагаю вернуться в начало координат и задаться вопросом, а зачем мы вообще вводим показатели доступности? Почему бизнес предъявляет требования к доступности услуг? Почему сервис-провайдер должен обеспечивать высокую доступность и отчитываться по ее фактическим значениям? Ответ прост: бизнес несет потери вследствие простоев ИТ-услуг. Значит, идеальным для бизнеса показателем доступности, вероятно, была бы метрика «Потери вследствие простоев ИТ-услуг»?

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

• более прозрачно транслировать требования доступности бизнес-процессов к ИТ-инфраструктуре;
• более обоснованно принимать решения по мерам, направленным на повышение надежности и отказоустойчивости ИТ-систем;
• более обоснованно оценивать успешность мер по итогам их реализации.

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

От чего зависят потери бизнеса вследствие простоев?

1. Чем меньше за отчетный период услуга была в uptime, тем больше потери. Введем показатель «Суммарное время простоев».
2. Чем дольше разовый простой, тем больше потери. Нередко потери не являются постоянной во времени величиной и зависят от длительности прерывания экспоненциально. В первый отрезок времени ущерб складывается из несовершенных транзакций, потерь продуктивности персонала и затрат на восстановление, но с определенного момента длительный простой угрожает бизнесу штрафами, санкциями, уроном репутации и так далее. Введем показатель «Максимальный разовый простой».
3. Ряд бизнес-процессов, напротив, «чувствительны» не к единичным длительным простоям, а к частым прерываниям. Это особенно важный фактор для процессов, в рамках которых происходят длительные вычисления, которые в случае прерывания требуется перезапускать. Таким образом, должно быть обеспечено как можно меньшее количество прерываний за период. Введем показатель «Количество нарушений».

Альтернативной (или дополнительной) метрикой, отражающей тот же аспект, но с акцентом на периоде спокойной работы пользователей, может быть показатель «Минимальная (или средняя) продолжительность работы без нарушений».

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

При этом не обязательно для каждой ИТ-услуги использовать все три (или четыре) метрики. В зависимости от того, чувствителен ли бизнес к частым нарушениям данной ИТ-услуги или, напротив, для него критичны длительные разовые нарушения, часть показателей могут быть опущены или включены в расчет с меньшим весом.

От представленных метрик можно легко перейти к известным MTRS, MTBF, MTBSI и, конечно, классическому показателю доступности. Но, на мой взгляд, предложенный набор скажет заказчику и сервис-провайдеру несколько больше о бизнес-влиянии нарушений ИТ-доступности. Или нет?

Отчаянно нуждаюсь в возражениях. Почему от классического показателя доступности услуги, выраженной в процентах, ни в коем случае нельзя отказываться? Есть ли такой показатель в ваших отчетах? О чем и кому он говорит?

Соглашение об уровне сервиса – документ, описывающий уровень оказания услуг, ожидаемый клиентом от поставщика, основанный на показателях, применимых к данному сервису, и устанавливающий ответственность поставщика, если согласованные показатели не достигаются.

Грубо говоря, если у вас отключают интернет дома, то в конце концов вы плюнете и пойдете на прогулку, в кино или кабак, в лучшем случае надеясь на перерасчет.

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

Здесь может быть лирическое отступление про резервирование каналов и т.д., но у нас перед глазами есть пример – здание комплекса Москва-Сити, в котором пару лет назад неожиданным образом и основной, и резервный канал оказались от одного провайдера. А беда, как известно, не приходит одна. В итоге дважды на 7-8 часов (в рабочее время) оказывались без связи компании из рейтинга «Fortune 500».
Поэтому особо дотошные юридические службы компаний, чей бизнес особо чувствителен к качеству связи, стараются исчислять размер ущерба компании не только стоимостью не потреблённых сервисов, но и выгодой, упущенной клиентом вследствие простоя связи.

Отправные точки

Вот некоторые показатели, в том или ином составе встречающиеся в операторских документах:

ASR (Answer Seizure Ratio) - параметр, определяющий качество телефонного соединения в заданном направлении. ASR рассчитывается как процентное отношение числа установленных в результате вызовов телефонных соединений к общему количеству совершенных вызовов в заданном направлении.
PDD (Post Dial Delay) - параметр, определяющий период времени (в секундах), прошедший с момента вызова до момента установления телефонного соединения.
Коэффициент доступности Услуги - отношение времени перерыва в предоставлении услуг к общему времени, когда услуга должна предоставляться.

Коэффициент потери пакетов информации - отношение правильно принятых пакетов данных к общему количеству пакетов, которые были переданы по сети за определенный промежуток времени.
Временные задержки при передаче пакетов информации - промежуток времени, необходимого для передачи пакета информации между двумя сетевыми устройствами.
Достоверность передачи информации - отношение количества ошибочно переданных пакетов данных к общему числу переданных пакетов данных.
Периоды проведения работ, время оповещения абонентов и время восстановления сервисов.
Иными словами, доступность услуги 99,99% говорит о том, что оператор гарантирует не более 4,3 минут простоя связи в месяц, 99,9% - что услуга может не оказываться 43,2 минуты, а 99% - что перерыв может длиться более 7 часов. В некоторых практиках встречается разграничение доступности сети и предполагается меньшее значение параметра – в нерабочее время. На разные типы услуг (классы трафика) также предусмотрены разные значения показателей. Например, для голоса важнее всего показатель задержки – он должен быть минимальным. А скорость для него нужна невысокая, плюс часть пакетов можно терять без потери качества (примерно до 1% в зависимости от кодека). Для передачи данных на первое место выходит скорость, и потери пакетов должны стремиться к нулю.

Мировые стандарты

В западной практике принято приводить официальный отчет о параметрах сети за последний год. Вот, например, показатели для интернет-канала за май нескольких небезызвестных брендов.

Задержка передачи сигнала (Latency, ms)

	Sprintnet		Verizon		Cable&Wireless		NTT
	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт
Европа	18.9	45	15.178	30	17.6	35.0	24.00	35
США	36.91	55	42.851	45	45.9	65.0	45.83	60
Азия	83.78	105	100.640	125	48.3	90.0	47.34	95
Европа-Азия	207.63	270	-	-	174.1	310.0	260.23	300
Европа-США	74.53	95	78.784	90	78.7	90.0	71.57	90

Потеря пакетов (Packet Loss, %)

	Sprintnet		Verizon		Cable&Wireless		NTT
	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт
Европа	0	0.3%	0.025%	0.5%	0	0.2%	0	0.3%
США	0.01%	0.3%	0.019%	0.5%	0.1%	0.2%	0	0.3%
Азия	0	0.3%	0.004%	1%	0	0.2%	0	0.3%
Европа-Азия	0	0.3%	-	-	0	0.2%	0	0.3%
Европа-США	0	0.3%	0	0.5%	0.1%	0.2%	0	0.3%

Джиттер (вариация задержки, jitter, ms)

	Sprintnet		Verizon		Cable&Wireless		NTT
	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт
Европа	0.0017	2	0.026	1	-	-	0	0.5
США	0.0007	2	0.058	1	-	-	0	0.5
Азия	0.0201	2	-	-	-	-	0	0.5
Европа-Азия	0.0001	2	-	-	-	-	0	0.5
Европа-США	0.0001	2	-	-	-	-	0	0.5

Сумма компенсации зависит от ежемесячных платежей клиента и варьируется от провайдера к провайдеру. В случае, когда показатель доступности сети превышает порог, указанный в SLA, Verizon компенсирует абоненту суточный платеж за каждый час недоступности сервиса. Если в каком-либо месяце SLA по показателю задержки передачи сигнала не выполнен, то полагается компенсация в размере суточной абонентской платы.

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

В случае недоступности сервиса по вине NTT, оператор устанавливает для себя рамки для выявления и решения проблемы в 15 минут – по истечению которых клиенту возмещают от 1/30 до 7/30 от ежемесячного платежа. Если SLA не соответствует скорость задержки сигнала, клиент может рассчитывать на возврат суточного платежа единоразово.

Наши реалии

В Российском бизнесе трепетно к SLA относятся преимущественно международные бренды. В то же время для столичных клиентов само словосочетание тоже стало знакомым, и даже средние компании порой интересуются этим документом. Здесь хочется отметить, что соглашение об уровне сервиса не заменяет и не отменяет стандартные пункты об ответственности оператора в договоре оказания услуг, а также нормы, установленные законодательством, и подзаконные акты (например, ФЗ «О Связи», Приказ №92 «Об утверждении Норм на электрические параметры основных цифровых каналов и трактов магистральной и внутризоновых первичных сетей ВСС России» и т.д.), которым мы все свято следуем.

В практике Гарс Телеком, в случае возникновения каких-либо «факапов», споры урегулируются в рамках процедуры обработки трабл-тикетов и времени восстановления сервисов. Аварии, повлекшие неработоспособность услуги, должны ликвидироваться от 4 до 72 часов (в зависимости от причины). В случае превышения заданных параметров – абоненту компенсируется каждый дополнительный час простоя, а при достижении оператором пороговых значений – процент компенсации увеличивается.

Из интересных кейсов можно вспомнить магазин музыкальных инструментов, который обвинял нас (оператора) в падении продаж пианино (какое-то время не работал телефон). Тут опять же можно сравнивать с продвинутым клиентоориентированным западом, но лучше обратиться к российской глубинке, где не то что об SLA – вообще понятия «время восстановления сервисов» не существует. В лучшем случае – время реакции – 48 часов. За примерами даже не нужно далеко ходить – 15 км от Санкт-Петербурга – и местный оператор отнекивается от какой-либо ответственности. Говорить за всех региональных операторов было бы некрасиво, но, к сожалению, это скорее правило, чем исключение.

Какие выводы нужно сделать из этих историй

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