Программа создания сетевой тестовой лаборатории

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

Подобно чудовищу, созданному доктором Франкенштейном, сетевые тестовые лаборатории часто формируются по принципу «часть — отсюда, часть — оттуда», и поступать так приходится от безысходности — как говорится, голь на выдумки хитра. Например, сервер Solaris компании Sun Microsystems, на котором ранее размещалась теперь уже устаревшая база данных, способен выступать в качестве «мозгового центра» лаборатории. В течение одного месяца лаборатория может использоваться для тестирования нового приложения управления отношениями с потребителями (Customer Relationship Management, CRM), которое необходимо представителям отдела продаж для выполнения своих показателей; следующие 30 дней сервер применяется при проверке системы передачи голоса по сетям IP (Voice over IP, VoIP) — таких трансформаций достаточно, чтобы у сотрудников лаборатории головы пошли кругом от проблем конфигурации.

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

Создание, модернизация и поддержка сетевой тестовой лаборатории нередко оказывается весьма непростым делом. Работа тяжкая, но кто-то должен ее выполнять, если компании хочет, чтобы сеть функционировала и оставалась современной. «Свыше 80% простоев сети происходят из-за ошибок, которых можно было бы избежать при более тщательном тестировании», — считает Джон Пол, директор по маркетингу служб провайдеров услуг в компании Cisco Systems.

Хотя тестовая лаборатория никогда не станет «объезженной лошадкой», выбор правильной стратегии и тактики позволяет усмирить этого мустанга. В данной статье мы рассмотрим некоторые вопросы, продукты и услуги, способные помочь менеджерам создавать и модернизировать свои тестовые лаборатории.

ОРГАНИЗАЦИОННЫЕ ШАГИ

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

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

Стефанус предлагает задействовать производственные системы в качестве рычага при организации работы тестовой лаборатории и инициации тестирования. К примеру, он рекомендует включить в техническое задание (Request for Proposals, RFP) пункт, в соответствии с которым продукт или услуга конкретного производителя должна пройти испытания в лаборатории прежде, чем приобретаемое решение будет оплачено. Этот шаг гарантирует техническую поддержку со стороны производителя и заставит его бесплатно предоставить оборудование и программное обеспечение для тестирования.

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

МЕСТОНАХОЖДЕНИЕ

Нейл Андерсон, директор подразделения передовых тестовых программ компании Spirent Communications, занимающейся оснащением тестовых лабораторий, в том числе в университетах и на выставках — например NetWorld+Interop (N+I), — советует со всей ответственностью отнестись к вопросу о помещении и местонахождении лаборатории. Андерсон подчеркнул, что при выборе для лаборатории анализатора протоколов или генератора трафика приходится рассматривать различные факторы, не связанные с тестами. Географическое положение может оказаться критически важным, особенно если предполагается тестировать передовые технологии.

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

Как подчеркнул Нед Эндлер, менеджер по ИТ и глава тестового подразделения исследовательской и консалтинговой компании Enterprise Management Associates (EMA), вопрос о физической защите лаборатории следует рассматривать на этапе проектирования. «Вряд ли вы согласитесь, чтобы любой человек мог случайно забрести в помещение лаборатории, — заметил он, — и выключить основной компонент оборудования, которое в данный момент тестируется». Вполне возможно, что сетевую тестовую лабораторию следует создавать за пределами производства или пересмотреть порядок доступа в помещения тестовой лаборатории и использовать для этого устройства аутентификации на основе биометрических технологий — модули считывания отпечатков пальцев или сканеры отпечатков ладони (см. статью Дж. Карра «Биометрические устройства новой волны» в декабрьском номере «Журнала сетевых решений/LAN» за 2001 г.).

Эд Карней, вице-президент по инжинирингу программы Networked Test Solutions Integration Test Engineering (NSITE) компании Cisco, считает, что электропитание — еще один важный фактор, который следует учесть при проектировании лаборатории. NSITE оказывает техническую поддержку провайдерам услуг — основным заказчикам компании.

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

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

Еще один важный инфраструктурный вопрос связан с тем, каким образом проложить кабель в лаборатории. Нередко постоянная кабельная проводка, к примеру от коммутационных панелей к основным серверам, проложена под фальш-полом и никому не мешает. С другой стороны, если кабель придется снимать, переносить и устанавливать обратно при изменении конфигурации лаборатории, например для соединения тестируемых устройств, то он должен быть подвешен на стойках. Андерсон считает, что коммутационные панели — это наиболее важный компонент любой хорошей тестовой лаборатории: «Чем больше способов автоматизации ваших коммутационных панелей, тем лучше они сконструированы, поэтому вы сможете эффективнее работать с центральной консоли и из центрального зала», — объяснил он.

ОТРАЖЕНИЕ, ОТРАЖЕНИЕ

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

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

Как отметил Пол, руководящий консалтинговым подразделением Cisco, которое обслуживает провайдеров услуг связи, его компания, к примеру, потратила свыше 250 млн долларов на воссоздание телефонного узла (Central Office, CO) провайдера услуг в своей лаборатории. Однако очень немногие предприятия могут позволить себе выделять столь значительные средства на тестирование.

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

Конечно, большинству лабораторий приходится искать компромисс в том, что касается количества каждого из устанавливаемых в них компонентов. По словам Раштона, менеджеры по ИТ могут добиться этого за счет использования в лаборатории модульной архитектуры, когда основные элементы производственной сети объединены в компактную среду, своего рода «островок». «Нецелесообразно создавать точную копию каждого устройства в сети, поскольку тестовая лаборатория окажется поистине гигантской», — считает он. Вместо этого следует формировать модульную тестовую среду с базовой сетью, которая максимально точно моделирует производственные системы. Аппаратное обеспечение, приложения и службы в этой части лаборатории будут модифицироваться лишь изредка и только после изменения производственной сети.

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

Лейрд Лидер, президент компании Telnet, дистрибьютора аппаратного обеспечения для тестирования систем связи, считает, что самым важным при таком подходе становится вопрос о гибкости аппаратного обеспечения тестовой лаборатории, особенно с учетом экономической ситуации в отрасли. Он отметил, что год назад менеджеры, тестирующие высокоскоростные сетевые соединения, могли приобрести интерфейсы OC-48 и OC-192 по отдельности. Теперь компании предпочитают покупать один компонент аппаратного обеспечения, способный работать с несколькими технологиями.

По словам Брента Мелсона, главного технического архитектора лаборатории National Software Testing Labs (NSTL), при попытке смоделировать производственную сеть возникает еще одна проблема, связанная с воспроизведением корпоративных ресурсов, где размещаются используемые приложениями данные. NSTL — независимая организация, специализирующаяся на тестировании ИТ для поставщиков и пользователей, в том числе производительности, совместимости, простоты использования и функциональности.

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

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

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

ОТДЕЛЕНИЕ ОТ ЯДРА

Тестируемые по сценарию модульной тестовой лаборатории отдельные технологии и приложения объединяются как независимые фрагменты вокруг общего ядра. Этот метод позволяет анализировать необходимые приложения VoIP или новые службы ATM с эмулированным ядром сети без непосредственного влияния конфигурации или производительности сети.

Примером фрагментарного подхода, по мнению Андерсона, может служить деятельность N+I iLabs. Специалисты по сетевым операциям в N+I сначала создают базовую сеть, а затем связывают с ядром две или три структуры, в которых реализованы передовые технологии: беспроводная система, сеть хранения и др. На большинстве предприятий все эти фрагменты физически находятся в одном месте, поскольку очень немногие компании могут позволить себе организовать несколько тестовых лабораторий. Однако провайдеры услуг зачастую создают тестовые островки для конкретных технологий в тех регионах, где они обладают практическим опытом в соответствующих областях. Такие распределенные тестовые среды дают дополнительные преимущества, позволяющие оснастить лабораторию оборудованием, управляемым удаленно. «Чем шире возможности настольной системы инженера, тем лучше. Фактически, благодаря корректному дистанционному управлению удаленные сотрудники смогут выполнять любые операции в лаборатории», — заметил Лидер.

О СОСТАВЕ ЛАБОРАТОРИИ

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

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

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

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

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

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

ТЕСТ ДРУГОГО ЦВЕТА

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

Пять-шесть лет назад около двух третей проблем в сетях связи возникали на физическом уровне и на уровне MAC (на уровнях первом и втором, соответственно) модели OSI, а оставшаяся треть — на более высоких уровнях. Это соотношение меняется по мере роста стабильности сетевых устройств: интерфейсных плат, мостов и маршрутизаторов — и теперь свыше половины проблем связано с вопросами более высокого уровня.

Подобная эволюция привела к быстрому появлению большого числа инструментальных средств мониторинга приложений. Среди них — инструментарий, предлагаемый компаниями Altaworks, Dirig Software, Mercury Interactive, Computer Associates и BMC Software. Эти производители, а также недавно появившиеся Shunra Software и Caw Networks предлагают приложения генерации трафика, что позволяет проверить системы в тестовой лаборатории с любой нагрузкой, эмулируя, по крайней мере, часть типов уровня трафика, с которыми работают крупные сети.

НЕКОТОРЫЕ ПРОБЛЕМЫ

По словам Джонатана Ренде, вице-президента по маркетингу продуктов отдела тестирования продуктов и услуг компании Mercury Interactive, проще всего свести на нет самые лучшие намерения службы сетевого тестирования, обращаясь с ними, как с грибами — оставлять в темноте до последнего момента, т. е. сообщать о развертывании нового аппаратного и программного обеспечения, когда для тестирования остается минимум времени. «Если относиться к тестовой лаборатории как к нелюбимому пасынку, — сказал он, — это неизбежно приведет к катастрофе». Лаборатория должна находиться в поле зрения высшего руководства, а ее сотрудники — обладать правом решающего голоса относительно того, когда новая система готова к развертыванию.

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

Тесты оказываются необъективными, если в лаборатории и в производственной среде используются разные версии аппаратного и программного обеспечения. «У пользователей возникнут проблемы с сетью, которую тестовая лаборатория не в состоянии воспроизвести из-за несвоевременного обновления программного обеспечения», — заметил Стефанус. Предприятиям приходится следить за тем, чтобы аппаратное и программное обеспечение отражало актуальное состояние производственной среды.

ЭКОНОМИЯ НА МЕЛОЧАХ — ПОТЕРИ В КРУПНОМ

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

Некоторые компании, занимающиеся электронным бизнесом, в том числе eBay и Toys «R» Us, пришли к выводу, что несерьезное отношение к тестированию может привести к катастрофе. «Компании сами создают себе неприятности, — заметил Базиль Харрис, вице-президент по маркетингу продуктов компании Segue, выпускающей программное обеспечение для тестирования приложений, — если недостаточно серьезно относятся к концепции тщательного, хорошо интегрированного и всеобъемлющего тестирования, которое необходимо выполнять до начала развертывания решений».

В качестве примера ситуации, когда испытаний не может быть слишком много, Харрис привел тестирование масштабируемости. Ошибка в приложении не появляется до тех пор, пока уровень нагрузки не становится достаточно большим. Здесь Харрис сослался на интерактивный брокерский сайт, который в условиях пиковой нагрузки кредитовал транзакции потребителей через неверный счет. При меньшем объеме трафика этой ошибки не возникало, но она проявилась, когда приходилось одновременно обрабатывать тысячи транзакций. «Когда это случилось, нам пришлось давать весьма тягостные объяснения клиентам», — сказал Харрис.

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

Рассматриваемые продукты

Ресурсы Internet

Материалы «Поиск и устранение неисправностей в протоколах маршрутизации IP» (Troubleshooting IP Routing Protocols), подготовленные Cisco Press, можно найти по адресу: http://www.ciscopress.com. В них описаны шаги, которые следует предпринять инженерам для решения различных вопросов, связанных с протоколом сетевой маршрутизации.

Статья, детально описывающая различные тестовые процедуры, под заголовком «Тестирование и анализ сетей следующего поколения» (Testing and Analyzing Next Generation Networks) опубликована по адресу: http://www.itpapers.com/cgi/PSummaryIT. pl?paperid=12329&scid=44.

Сайт Web консорциума International Engineering Consortium (IEC) содержит множество статей и руководств, предлагаемых производителями и посвященных, главным образом, сетевому тестированию. Руководства с этого сайта можно найти по адресу: http://www.iec.org/online/tutorials/.

В обширной статье М. Педмараджа под названием «Тестирование сетей» (Testing of Networks) серьезное внимание уделяется тестированию Signaling Systems 7 (SS7), Bluetooth, Dense Wavelength Division Multiplexing (DWDM), передаче голоса по сетям IP (VoIP) и сетям Gigabit Ethernet. Эти материалы можно найти по адресу: http://www.seas.smu.edu/~mpadmara/ Testing_of_Networks.htm.