Алгоритм вычисления среднего времени восстановления связи

Сбой в работе телекоммуникационной сети может быть вызван различными причинами: обрывом линий связи, выходом из строя маршрутизаторов, атаками хакеров и т. п. Обычно влияние первых двух причин исследуется в теории надежности, влияние третьей - в задачах информационной безопасности. Однако для пользователей услуг не имеет значения, вследствие чего пропадает связь. В рамках соглашения о качестве обслуживания (service level agriment (SLA)) абоненту должен быть гарантирован определенный, достаточно большой промежуток времени, в течение которого показатели качества обслуживания (quality of service (QoS)) не будут ниже заданных.

Простои, вызванные сбоями в работе сети, могут сопровождаться огромными потерями прибыли. Так, согласно [1] каждая минута перерыва в связи приводит к финансовым потерям биржи в $ 110 000.

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

В отечественной литературе [2-4] в качестве основных параметров, характеризующих надежность, рассматриваются время наработки на отказ Т н и время восстановления Т в . При этом, разумеется, речь идет о среднем времени.

В англоязычной литературе эквивалентом Т _н является аббревиатура MTTF (mean time to fault), а эквивалентом Т в - аббревиатура MTTR.

Возможны следующие варианты расшифровки аббревиатуры MTTR [5]:

• 1)    mean time to repair a problem;

• 2)    mean time to restore service;

• 3)    mean time to respond to trouble.

На русский язык данные варианты можно перевести следующим образом:

• 1)    среднее время до устранения "проблемы";

• 2)    среднее время до восстановления сервиса;

• 3)    среднее время до ликвидации аварии.

Заметим, что в англоязычных работах термин "проблема" как некоторая задача, требующая разрешения [6], упоминается достаточно часто. Так, для восстановления связи требуется решение сле- дующих "проблем": идентификации, диагностики, выбора способа решения задачи и, наконец, восстановления.

Используя параметры надежности Т н и Т в , можно вычислить коэффициент доступности услуг К д (коэффициент готовности К г ):

т

.

К =--н—

• ^д Т. + Т_в нв

Согласно [7] "коэффициент готовности (availability function) – вероятность того, что объект окажется в работоспособном состоянии в произвольный момент времени, кроме планируемых периодов, в течение которых применение объекта по назначению не предусматривается".

В качестве примера оценки значений Т н , Т в и К д приведем показатели надежности для аппаратуры, производимой фирмой "Huaway Technology" (см. таблицу). Соответствующие нормативы и способы оценки Т н и Т в приведены в [4, 7].

В паспорте на то или иное изделие обычно представлено только значение Т _н, которое позволяет судить о времени его работы до отказа, и не приводится значение Т в . Сравнивая информативность показателей Т н и Т в , следует заметить, что:

• –    для большинства пользователей услуг значение Т н может быть определено только косвенно; фиксировать запросы пользователей на восстановление значительно проще, поэтому значение Т _в определяется непосредственно;

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

• –    параметр Т н , гарантируемый поставщиком оборудования, не учитывает внешние сбои и ошибки операторов; однако согласно имеющимся данным большинство простоев web-сервисов обусловлено влиянием именно "человеческого фактора";

Основные характеристики надежности оборудования сети на базе оборудования фирмы "Huaway Technology"

Тип оборудования	Среднее время наработки на отказ (MTBF), ч	Среднее время восстановления (MTTR), ч	Коэффициент доступности
Мультиплексоры SDH OptiX 1500/2500/3500	1+0 Nonprotection Configuration: 120 300 1+1 Protection Configuration 516 000	≤ 1 ≤ 1	99,99917 99,99981
Мультиплексоры DWDM OptiX OSN 1800/3800	199 998	≤ 2	99,999
Базовая станция – BS CDMA: BTS3606E GSM: BTS3012, DBS3900	≥ 100 000 ≥108 000	≤ 1 ≤ 1	≥ 99,999 ≥ 99,9991
Контроллер BS – BSC CDMA-450 cBSC6600	140 815,91	≤ 0,5	0,9999974
HLR9820 GSM/CDMA	–	< 1	< 99,999
Контроллер BS – GSM900/ 1800: BSC6000	409 387	≤ 1	≥ 99,9998
ЦКП – GSM 900/1800 mSoftX 3000	≥ 367 920	≤ 1	0,9999972
ЦКП - GSM 900/1800 MSC/VLR	236 520	≤ 0,5	0,9999978
Сервер iManager M2000 IMT-MC-450	244 000	0,17	0,9999993

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

Следовательно, значение Т в более точно определяет реальную степень доступности различных услуг, чем значение Т н . Именно поэтому исследованию процесса минимизации среднего времени восстановления уделяется большое внимание [8-10].

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

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

Гарантия QoS со стороны поставщика обусловливает последовательность повторяющихся операций, целью которых являются обнаружение, классификация, установка приоритетов и реакция на сбой. За счет внедрения описанной далее методики операторы могут добиться уменьшения времени восстановления на 50 %, а расхода ресурсов – на 75 % [10].

Шаг 1. Обнаружение сбоя. Многие системы поддержки операции (OSS) применяют периодический опрос переменных баз данных системы управления (MIB). Для того чтобы время обнаружения сбоя составило менее 2 мин, необходимо через каждые 2 мин опрашивать все переменные со всех устройств в сети. При использовании этого подхода возникают проблемы, обусловленные чрезмерно большим массивом служебных данных, что требует увеличения времени между опросами: например, проверка статуса сетевых устройств через каждые 10 мин и Интернет-диагностика через каждые 8 ч. Однако это приводит к увеличению времени обнаружения сбоя вследствие задержек сообщений опроса, а также к потере информации о тех сбоях, которые заканчиваются быстрее, чем период опроса. Время, затрачиваемое на первый шаг, – среднее время обнаружения неисправности – обозначим t о . Затраты на решение данной задачи обозначим с о .

Шаг 2. Определение "живучести" проблемы (времени после устранения сбоя, в течение которого его влияние существенно) и характера сбоя (периодический или случайный). На этом шаге необходим компромисс: гарантия правильной классификации сбоя или дополнительная задержка времени отклика. Это время называется средним временем сохранения (живучестью) "проблемы" t ж . Затраты обозначим через с ж .

Шаг 3. Утверждение (валидация) наличия сбоя. Например, группа модемов внезапно "уходит в оффлайн". Необходимо определить, вызвано ли это сбоем на станции или отключением питания на другой стороне. Система мониторинга на станции или техник должны установить факт наличия той или иной проблемы. Время, необходимое для этого, называется средним временем валидации t _y). Затраты обозначим через с y .

Шаг 4. Определение влияния сбоя. Полная потеря того или иного сервиса восстанавливается значительно сложнее, чем снижение качества. Однако снижение качества некоторых, особенно чувствительных, сервисов, таких как VoIP, может рассматриваться как полная потеря сервиса. Каждый сбой, в зависимости от его характеристик, может оказывать различное влияние на разные услуги. Например, потеря 1 % пакетов в высокоскоростном транспортном потоке данных может остаться незамеченной, в то время как в случае передачи видео или голоса она может оказаться критической. Данный этап является ключевым при расстановке приоритетов, поскольку приоритет в восстановлении после того или иного сбоя устанавливается исходя из его влияния.

Шаг 5. Определение масштаба сбоя. Масштаб сбоя может выражаться, например, в количестве абонентов, попавших под влияние рассматриваемого сбоя. Несмотря на кажущуюся простоту, определение масштаба может вызывать определенные затруднения. Изменения в базе MIB или звонки от абонентов не дают полного представления о масштабе сбоя, поскольку часть пользователей не позвонят в сервис-центр, а некоторые могут даже не знать о сбое. Время, необходимое для корректного определения масштаба сбоя, обозначим t м .

Шаги 6, 7. Поиск источника проблемы (шаг 6) и точное определение места сбоя с последующей его изоляцией (шаг 7). В зависимости от степени полноты данных, полученных на первых пяти шагах, определение точного местоположения и изоляция сбоя могут стать весьма быстрыми или чрезвычайно долгими процессами. Какая-либо неточность, допущенная в первых пяти шагах, может привести к ошибочному определению местоположения сбоя и как следствие к изоляции исправного элемента системы. Описанные два шага выполняются за время t м.и (среднее время определения сбоя и его изоляции). Затраты на шаги 6 и 7 обозначим с м.и .

Шаг 8. Устранение сбоя. Изначально считается, что все запчасти доступны, а доступ в зону повреждения разрешен. Если основная причина сбоя не может быть устранена, то существует два пути: прямой путь и путь компенсации. Последний предполагает использование дополнительного оборудования на время ремонта с целью обеспечения непрерывности связи. В свою очередь в автоматических системах применяется схема прямого устранения сбоя, в соответствии с которой участок, где произошел сбой, временно отключается с целью уменьшения вреда от сбоя. Например, если помехи привели к снижению качества обслуживания всех клиентов узла, то лучше отключить 10 клиентов, чем вызвать недовольство 400. Время, затрачиваемое на шаг 8, обозначим через t в , а затраты - через с в .

Шаг 9. Проверка восстановления службы и перевод характеристик услуги в начальное состояние. На данном шаге необходимо подтвердить, что принятые меры восстановили уровень обслуживания. На это требуются время t _п.в (среднее время проверки восстановления службы после устранения сбоя)

и затраты, которые обозначим c п.в .

Суммируя описанные выше компоненты времени, получим выражение для определения T в :

Т в = t 0 + t ж + t y + t м.и + t в + t п.в .

Особое внимание следует уделить исследованию проблемы установки приоритетов. Несмотря на то что эта проблема описана лишь в шагах 4, 5, вследствие ограниченности ресурсов вопросы уста- новки приоритетов должны решаться на всех шагах.

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

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

Выполнение каждого шага требует определенных материальных ресурсов. Затраты на восстановление могут быть оценены по формуле

С в = с 0 + с ж + с y + с м.и + с в + с

п.в .

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

Данная задача относится к классу задач линейного программирования [11].

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