О структуре и свойствах современных пакетных сетей

В контексте данной статьи наиболее существенными представляются следующие особенности протокола Frame Relay:

• поддержка нескольких виртуальных соединений на один физический порт, множественные PVC;
• управление скоростью передачи: гарантированная скорость передачи (Committed Information Rate, CIR), форсированная скорость передачи (Excess Information Rate, EIR);
• поддержка уведомлений о насыщении сети.

3. Протокол ATM

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

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

Мы остановимся на следующих особенностях сетей ATM:

• ATM-сеть – это сеть с установлением соединений (connection-oriented);
• сети ATM – это коммутируемые сети.

3.1. Сети с установлением соединений

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

Сети с установлением соединений могут гарантировать определенное качество сервиса (Quality of Service, QoS). ATM-QoS включает в себя следующие параметры:

• допустимое количество потерянных пакетов;
• допустимое изменение интервалов между ячейками.

В результате, в сети может осуществляться одновременная передача различных видов трафика, зависящего от качества сервиса, например, звука, видео и данных.

3.2. Архитектура ATM

Архитектура (модель) ATM разработана организациями по стандартизации ANSI, ITU и ATM Forum. Данная модель состоит из трех уровней:

• физического;
• уровня ATM;
• уровня адаптации ATM.

Модель ATM проиллюстрирована на рис. 2. Ниже приводится более подробная информация о каждом из уровней.

3.2.1. Физический уровень

Стандарты ATM для физического уровня определяют, как получать биты из среды передачи, преобразовывать их в ячейки и посылать эти ячейки уровню ATM. Кроме того, они описывают, какие кабельные системы должны использоваться в сетях ATM и с какими скоростями может работать ATM при каждом типе кабеля. На сегодняшний день наиболее распространенные скорости составляют 25, 155 и 622 Мбит/с.

Скорость 25 Мбит/с поддерживается на:

• неэкранированной витой паре (UTP) категории 3 и выше;
• оптоволокне.

Скорость 155 Мбит/с обеспечивается на:

• UTP категории 5;
• экранированной витой паре (STP) типа 1;
• оптоволоконном кабеле.

Скорость 622 Мбит/с гарантируется только на оптоволоконном кабеле.

3.2.2. Уровень ATM

Стандарты для уровня ATM описывают механизмы:

• получения ячеек;
• формирования заголовков и посылки ячеек уровню адаптации ATM;
• установки соединения с требуемым качеством сервиса (QoS).

3.2.3. Уровень адаптации ATM и качество сервиса

В эталонной семиуровневой модели ISO/OSI стандарты для сетевого уровня определяют, как осуществляется маршрутизация паке-

тов и управление ими. На уровне адаптации ATM выполняются три аналогичные функции:

• форматируются пакеты;
• предоставляется информация для уровня

ATM, которая дает возможность устанавливать соединения с определенным качеством сервиса;

• предотвращаются «заторы».

Уровень адаптации ATM состоит из пяти протоколов, называемых протоколами AAL. Эти протоколы принимают ячейки с уровня ATM, формируют из них данные и передают эти данные на более высокий уровень. Когда протоколы AAL получают данные с более высокого уровня, они разбивают их на ячейки и передают их уровню ATM.

Уровень адаптации ATM определяет также четыре категории сервиса:

• постоянная скорость передачи (Constant Bit Rate, CBR);
• переменная скорость передачи (Variable Bit Rate, VBR);
• неопределенная скорость передачи (Unspecified Bit Rate, UBR);
• доступная скорость передачи (Available Bit Rate, ABR).

Эти категории используются для обеспечения различного качества сервиса для разных типов трафика.

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

Категория VBR существует в двух видах, которые используются для различных типов трафика:

• VBR реального времени (Real-Time VBR, RTVBR) применяют, когда требуется жесткая синхронизация между ячейками и поддержка чувствительного к задержкам трафика;
• VBR без требований реального времени (Non-Real-Time VBR, NRT-VBR) не нуждается в жесткой синхронизации между ячейками и поддерживает допускающий задержки трафик.

Поскольку VBR не резервирует полосу пропускания, канал используется более эффективно, чем в случае CBR. Однако, в отличие от CBR, VBR не может гарантировать качества сервиса.

Категория UBR применяется для трафика, который допускает задержки. Подобно VBR, UBR не резервирует полосы пропускания для виртуального канала. В результате один виртуальный канал может применяться для нескольких передач. Однако, поскольку UBR не гарантирует качества сервиса, то в сильно загруженных сетях UBR-трафик теряет большое число ячеек, что вызывает много повторных передач.

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

CBR, VBR, UBR, и ABR включают в себя следующие параметры качества сервиса (QoS):

• коэффициент потерь ячеек (Cell Loss Ratio) определяет, какой процент высокоприоритетных ячеек может быть потерян за время передачи;
• задержка передачи ячейки (Cell Transfer Delay) определяет время (или среднее время), требуемое для доставки ячейки адресату;
• вариации задержек при передаче ячеек (Cell Delay Variation, CDV), большая величина CDV приводит к прерыванию аудиои видеосигналов.

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

4. Современные аспекты IP-сетей 4.1. Требования к IP-сетям

Протокол IP является фактическим стандартом при построении корпоративных сетей передачи данных. На повестке дня – создание единых, «конвергированных» сетей, обеспечивающих передачу данных, голоса и видео.

К конвергенции подталкивают следующие обстоятельства:

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

Для достижения поставленных целей необходимо решить ряд проблем.

При транспортировке IP-пакетов их порядок, вообще говоря, может нарушаться, что недопустимо в случае передачи голосового потока данных. Помимо сохранения порядка, требуется также минимизировать задержки пакетов и колебания длительности задержек.

Для обеспечения приемлемого голосового потока время задержки должно составлять менее 300-600 мс.

Задержки могут возникать на следующих этапах:

• подготовка (кодирование и/или сжатие) и отправка голосового потока;
• передача по сети;
• декодирование на принимающей стороне.

Перечисленные этапы показаны на рис. 3. При передаче аудиопотока необходимо контролировать величину задержки на каждом из них.

4.2. Пути изменения структуры и свойств IP-сетей

Ключевыми характеристиками сети при передаче аудиои видеопотоков являются пропускная способность и качество сервиса.

Наращивание полосы пропускания может происходить за счет перехода на более высокоскоростные интерфейсы и/или технологии. Обычно такое решение является дорогостоящим, так как требует закупки нового сетевого оборудования. Кроме того, оно (решение), как правило, оказывается краткосрочным, поскольку расширенная полоса пропускания быстро «съедается» новыми сетевыми приложениями.

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

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

Для реализации механизмов QoS в заголовке IP-пакета предусмотрено поле типа сервиса размером 8 бит (Type of Service, ToS, см. также [1]), которое задает характер обработки пакета в процессе транспортировки последнего.

Можно управлять следующими параметрами:

• приоритет;
• величина задержек;
• уровень надежности;
• пропускная способность;
• надежность.

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

Распределение разрядов в поле типа сервиса представлено в табл. 1, а назначение различных комбинаций – в табл. 2.

4.3. Механизмы обеспечения качества сервиса

Качество сервиса в IP-сетях определяется следующими параметрами:

• готовность (service availability): надежность соединения пользователя с информационным сервисом;
• задержка (delay): интервал времени между отправлением и получением пакета;
• вариация задержки (delay variation): допустимый интервал между пакетами в потоке;
• пропускная способность (throughput): допустимая пиковая загруженность сети;
• коэффициент потери пакетов (packet loss rate).

Существуют следующие механизмы, используемые для обеспечения заданного качества сервиса в IP-сетях:

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

Существует две архитектуры IP-QoS, утвержденные комитетом IETF:

• архитектура с интеграцией сервисов (Integrated Service Architecture, Int-Serv);
• архитектура с дифференциацией сервисов (Differentiated Services Framework, Diff-Serv).

4.3.1. Архитектура QoS Int-Serv

В основе архитектуры Int-Serv (см. [2]) лежит протокол резервирования ресурсов – RSVP (Resource ReSerVation Protocol). Данный протокол позволяет зарезервировать определенную долю сетевых ресурсов, необходимую информационному потоку, на протяжении всего маршрута от станции отправителя до станции получателя. Более подробное описание RSVP дается в следующем разделе. Здесь же мы ограничимся аналогией с коммутируемыми виртуальными соединениями ATM (ATM SVC).

4.3.2. Архитектура QoS Diff-Serv

Идея архитектуры с дифференциацией сервисов (см. [3]) состоит в минимизации служебного трафика, чтобы исключить задержки, возникающие в Int-Serv на начальном этапе взаимодействия.

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

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

Для маркировки пакетов используется поле типа сервиса (ToS), которое в данной архитектуре называется DS (Differentiated Services). Базируясь на значении поля DS, транзитный маршрутизатор помещает IP-пакет в очередь, соответствующую заданному приоритету. Движение внутри каждой очереди обеспечивается механизмом управления, ключевыми функциями которого являются распределение пропускной способности канала связи и правила обработки в случае накопления пакетов.

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

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

Дифференциация сервисов – это относительно новый подход и далеко не все удалось стандартизовать. Основные проблемы состоят в отсутствии:

• стандарта на поле DS;
• утвержденного количества классов обслуживания и их описания;
• механизма эффективной агрегации потоков (на уровне транзитных маршрутизаторов);
• решений по интерпретации с технологией ATM;
• механизма управления.

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

Пункт три более критичен. Хотя на сегодня, исходя из статистики, количество IP-трафика, требующего определенного качества сер-

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

По поводу пункта 4 отметим, что хотя вопросы обеспечения качества сервиса в ATM стандартизированы, вопрос трансляции IP QoS в ATM QoS остается открытым.

Отсутствие стандартных средств управления, несомненно, является критически важной проблемой.

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

4.4. Протокол RSVP

Протокол резервирования ресурсов (RSVP – Resource ReSerVation Protocol) – это протокол «точка-точка». Подобно ICMP и IGMP, он является протоколом управления и функционирует в совокупности с протоколами маршрутизации.

Основными компонентами RSVP являются:

• отправитель;
• получатель;
• маршрутизаторы и хосты, находящиеся на пути от получателя к отправителю;
• потоки (совокупность IP-пакетов, посылаемых отправителем одному или более получателям, с соответствующим потоку идентификатором – FlowLabel).

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

В ответ получатель рассылает заявки на резервирование ресурсов всем узлам, находящимся на выбранном маршруте. Данная заявка содержит в себе, помимо IP-адреса отправителя и получателя, поля FlowSpec, AdmissionControl и PolicyControl. Поле AdmissionControl содержит информацию о возможности отправителя предоставить требуемое качество сервиса, а поле PolicyControl характеризует права получателя на проведение операции резервирования QoS. Если оба поля (AdmissionControl и PolicyControl) установлены верно, узел, получающий данную заявку, резервирует требуемые ресурсы.

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

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

Таким образом, механизм RSVP выглядит следующим образом:

• отправитель посылает PathMessage-сообщение получателю;
• получатель получает PathMessage;
• получатель посылает заявку на резервирование QoS на маршрутизаторы между отправителем и получателем;
• каждый маршрутизатор, получив заявку, проверяет поля AdmissionControl и PolicyControl и в случае их достоверности резервирует требуемый QoS;
• отправитель получает уведомление о резервировании QoS;
• отправитель начинает передачу потока пакетов.

Рассмотрим пример (см. рис. 5). Пусть станция-отправитель подключена по технологии Fast Ethernet (100 Мбит/с), получатель A – по технологии ATM (155 Мбит/с), получатель B – по технологии Token Ring (16 Мбит/с).

Допустим, требуемая полоса пропускания составляет 30 Мбит/с. В этом случае получатель A может запрашивать полную пропускную способность – 30 Мбит/с, а получатель B вынужден использовать сжатие данных, в результате чего экономится часть полосы пропускания.

Передача между отправителем и получателями осуществляется до тех пор, пока выполняются характеристики QoS, заданные в поле FlowSpec.

Действия, выполняемые в рамках RSVP отправителем, получателем и промежуточными маршрутизаторами, показаны на рис. 6.

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

• Масштабируемость. Одновременная активность большого количества потоков с высокой пропускной способностью может вызвать перегрузку маршрутизаторов, что влечет блокировку или задержку передачи других критичных данных. Пока IETF не предлагает стандартных механизмов разрешения этой проблемы. Рекомендуется не использовать RSVP на магистральных маршрутизаторах (ограничиваясь периферией сети).
• Безопасность. Следующая сложность, связанная с использованием RSVP, – несанкционированный захват или сокрытие сетевых ресурсов. Такая ситуация возможна в случае, если злоумышленник прослушивает сеть с целью перехвата сообщений PathMessage. В IETF разрабатывается документ RSVP Cryptographic Authentication для обеспечения криптозащиты передаваемых служебных данных; в будущем он, вероятно, обеспечит кардинальное решение. Пока рекомендуется контролировать и протоколировать изменения в служебной информации, особое внимание уделяя полю FlowSpec (спецификатор IP-потока, см. [1] и [4]).
• Политика управления. Протокол RSVP предусматривает и описывает транспортную политику. В то же время в RSVP не описана политика управления. Не определены механизмы того, кто может (должен) осуществлять резервирование, а также средства проверки подлинности. Для решения данной проблемы в рамках комитета по RSVP создана специальная рабочая группа. Решение по поддержке политики безопасности подразумевает использование сервера авторизации, к которому осуществляются запросы при резервировании ресурсов на маршрутизаторе. На момент написания статьи деятельность рабочей группы не была закончена.

4.5. Пример поддержки качества сервиса – маршрутизаторы компании Bay Networks

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

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

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

• 3Com;
• Bay (Nortel) Networks;
• CEFRIEL/Politecnico di Milano;
• Cisco Systems;
• Extreme Networks;
• Fore Systems;
• Furukawa Electric;
• IBM.

Характерным примером реализации архитектуры с дифференциацией сервисов является разработка компании Bay Networks (ныне входящей в компанию Nortel Networks) – программное обеспечение для маршрутизаторов BayRS, версии 13.20. Специалистам компании удалось обеспечить простой и стандартный подход к приоритезации приложений и управлению полосой пропускания.

Согласно утверждению Michael J. Hopey (сетевой аналитик университета Нью-Брунсвика), сделанному по результатам тестирования ПО BayRS 13.20, последнее обеспечивает такие услуги, как видео (H.323), и позволяет ограничивать полосу пропускания для обычных, неприоритетных приложений.

Дифференциация сервисов позволяет сетевым администраторам централизовать управление правилами и определять уровни обслуживания на базе приложений, пользователей или групп, распределяя полосу пропускания при помощи программных функций приоритезации очередей BayRS. Более того, чтобы гарантировать, что передача файлов и общий трафик (обращения к Web-серверам) не вызовут перегрузки по полосе пропускания, BayRS 13.20 может автоматически изменять уровни обслуживания в зависимости от времени суток.

Классы обслуживания трафика определяются в поле IP заголовка, именуемом байтом DSCP (Differentiated Services Code Point). Идентифицированные таким образом пакеты сохраняют приоритет по всей сети. Маршрутизаторы, на которых работает ПО BayRS 13.20, могут просматривать и устанавливать или сбрасывать байт DSCP в зависимости от правил, определенных для пользователя или приложений.

Еще одна функция, поддерживаемая в ПО BayRS 13.20 и играющая важную роль в сетевом администрировании, – это протокол COPS (Common Open Policy Services, проект IETF). Реализация этого протокола в продуктах Nortel Networks упрощает контроль правил, обеспечивая стандартный механизм связи маршрутизаторов BayRS и централизованных серверов правил.

Программное обеспечение BayRS функционирует на платформах BayStack Access Node (AN) и Access Node Hub (ANH), BayStack Access Remote Node (ARN), BayStack Access Stack Node (ASN), Backbone Node (BN).

Кроме перечисленных функций, программное обеспечение BayRS 13.20 предоставляет новые возможности многоадресной передачи, обеспечивая поддержку стандартного режима PIM-SM (Protocol Independent Multicasting – Sparse Mode), а также широкого спектра других новых функций для предприятий и поставщиков услуг.

5. Заключение

Мы рассмотрели два основных механизма обеспечения заданного качества сервиса в IP-сетях, имеющих различные области применения, разную степень новизны и ... собственные проблемы на стадиях реализации и эксплуатации. Слабая стандартизация данных механизмов не позволяет реализовывать сети с требуемым качеством сервиса на оборудовании различных производителей. Какое оборудование выбрать, какие механизмы QoS оно должно поддерживать – вот вопросы, с которыми сталкиваются владельцы и проектировщики сетей.

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

6. Литература

1. Галатенко В., Макстенек М., Трифаленков И. Сетевые протоколы нового поколения. – Jet Info, 1998, 7-8.

2. Braden R., Clark D., Shenker S. Integrated Services in the Internet Architecture: an Overview. – RFC 1633, 1994. ftp://ftp.isi.edu/innotes/rfc1633.txt.

3. Braden R. (Ed.), Zhang L., Berson S., Herzog S., Jamin S. Resource ReSerVation Protocol (RSVP). Version 1. Functional Specification. – RFC 2205, 1997. ftp://ftp.isi.edu/in-notes/rfc2205.txt.

4. Виняр Д. Анализ современных методов маршрутизации. – Jet Info, 1998, 2-3.

Техническое обслуживание современных информационных систем: проблемы и подходы

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

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

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

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

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

2. Задачи, решаемые техническим обслуживанием

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

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

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

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

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

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

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

3. С чего начать

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

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

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

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

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

4. Что взять на себя, а к чему привлечь партнеров

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

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

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

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

5. Как выбрать сервисную организацию

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

щих не только отдельные элементы, но и информационные системы в целом.

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

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

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

6. Заключение

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