Требуются квалифицированные специалисты по управлению

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

Громкие рекламные заявления или тонкий лучик надежды?

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

Это правда. Он пытается продать средство управления на базе Web, устанавливаемое поверх платформы прецедентного управления сетью. Ну разумеется, в это средство интегрированы все самые лучшие приложения на Java от сторонних компаний; не забыты и объектно-ориентированные программы. Цель - создать готовое решение, обеспечивающее управление уровнями обслуживания в информационных системах, то есть выполнить ту задачу, которую только обещают решить производители разнообразных устройств диагностики кабельных систем и SNMP-мониторы устройств.

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

Выслушав все это, потенциальный покупатель может разве что выдавить: "Ну и что?"

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

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

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

Затасканные выражения

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

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

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

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

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

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

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

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

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

Некоторые пользователи связывают большие надежды с намерением лидеров в этой области рынка, компаний Computer Associates (CA) и Hewlett-Packard, включать облегченные версии своих управляющих платформ в комплект поставки систем и серверов многих производителей аппаратного обеспечения. "Если производители на это пойдут, будет просто замечательно, - говорит Уильям Орис, вице-президент крупной инвестиционной компании JP Morgan &Co. - Нам придется выполнять значительно меньший объем работ по интеграции".

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

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

Хорошие новости

И тут появляется управление сетями на базе Web. Много чернил было пролито, чтобы рассказать, как World Wide Web поможет добиться переносимости приложений. И это чистая правда, поскольку Web-браузеры и Web-приложения (особенно если они написаны на языке Java) могут работать на любой платформе. "Использование WWW, безусловно, позволяет добиться наивысшей масштабируемости и универсальности, - говорит Стефен Де Витт, вице-президент и главный управляющий по средствам управления сетями компании Cisco Systems. - Такой подход, наконец, избавляет нас от старой как мир, тошнотворной проблемы переноса приложений на все платформы, какие только существуют в мире".

Представители консультативных фирм согласно кивают. "Я убежден, что объединяющим началом систем управления, их точкой интеграции должно стать что-то типа Web, а отнюдь не управляющие платформы ", - считает Джон Мак-Коннелл, президент компании McConnell Consulting.

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

Эти данные чаще всего представляются в виде снабженных ссылками HTML-отчетов о параметрах работы системы. Однако все больше и больше компаний переходят на использование Web-интерфейса реального времени на базе языка Java, позволяющего управлять системой в диалоговом режиме, с использованием графического изображения объекта управления, которое в реальном времени отображает все происходящие изменения. "Нам нравится, как работает Web-интерфейс, - говорит Сандра Поттер, сетевой инженер из компании Air Products and Chemicals, использующая HP OpenView. - Он нам сильно помогает. Следующим шагом должно стать применение языка Java. Мы с нетерпением ждем, пока к этой деятельности присоединятся другие компании".

Г-жа Поттер не одинока. "Используя Java, мы сможем передавать информацию большему числу людей", - говорит Пол Эдмундс, старший сетевой аналитик компании Duke Power. По его словам, применение Java поможет снизить накладные расходные на управление по сравнению с интерфейсом на базе X Windows.

Предложены уже два стандарта на управление на базе Web: инициативный проект Web-based Enterprise Management (WBEM), поддерживаемый BMC Software, Cisco, Compaq Computer, Intel и Microsoft, и Java Management Applications Programming Interface (JMAPI), детище Sun Microsystems.

В проекте WBEM определяются три области действия стандартов. Во-первых, это HyperMedia Management Schema (HMMS), расширяемая модель данных для представления объектов управления. За время, прошедшее с момента объявления WBEM, HMMS трансформировалась в стандарт Common Information Model (CIM), разработанный комитетом Desktop Management Task Force (DMTF).

Другой компонент WBEM - HyperMedia Management Protocol (HMMP), протокол на базе HTTP, служащий для обмена данными между службами, приложениями и агентами, принимающими участие в управлении. Наконец, третья составная часть - это HyperMedia Object Manager (HMOM) объектный агент (object broker) на C++, обеспечивающий сведение воедино (pull together) всех необходимых для управления данных по заданию приложений управления. HMOM основан на разработанной компанией Microsoft технологии OLE.

За определение, поддержание актуальности и модификацию CIM отвечает DMTF, HMMP обсуждается в рамках Internet Engineering Task Force, а что касается HMOM, то Microsoft объявила, что за пример реализации этого стандарта (reference implementation) может быть принята разработка любой компании. К настоящему времени деятельность вокруг HMMP велась, мягко говоря, не слишком активно.

Ожидалось, что осенью 1997 г. производители уже начнут выпускать продукты на базе WBEM. Но не торопитесь потирать руки в радостном предвкушении. Среди представителей промышленности широко распространено мнение, что WBEM - это не более чем уловка, рассчитанная на то, чтобы "привязать" покупателей к изделиям Microsoft. Поэтому, скорее всего, производители ограничатся громкими заявлениями о поддержке WBEM, а сами станут подыскивать какие-нибудь независимые средства на базе Web и Java.

Кстати, о Java. Обращает на себя внимание тот факт, что в списке сторонников WBEM отсутствует Sun. Связано это с тем, что Sun и Microsoft не могут прийти к единому мнению относительно дальнейших путей развития средств управления на базе Web.

JMAPI - это часть программного окружения на базе Java под названием Solstice Workshop, разработанного компанией SunSoft и предназначенного для разработки программ управления сетями и системами на базе Web. О своей поддержке JMAPI объявили ряд сторонних производителей программного обеспечения, в частности, такие "заклятые друзья" как CA и Tivoli Systems (дочерняя компания IBM). Их привлекает возможность использования приложений под Java на различных платформах.

Поскольку в реальности Java никто не сомневается, можно ожидать, что производители сдержат свои обещания и начнут поставлять средства на базе JMAPI уже в начале 1998 г. По словам генерального директора Tivoli Фрэнка Мосса, его компания планирует начать поставки своей управляющей среды (framework) под названием Tivoli Management Environment (TME) на базе Java в середине 1998 г.

Tivoli была одной из первых, кто принял и начал всячески пропагандировать объектно-ориентированные программы для управления сетями масштаба предприятия. Эта компания даже занималась разработкой объектно-ориентированной технологии для злополучного проекта Distributed Management Environment, продвигавшегося Open Software Foundation. Но сейчас Tivoli признает, что будущее - за Web.

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

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

Все основные поставщики продуктов для межсетевого взаимодействия - Bay Networks, Cabletron Systems, Cisco, 3Com - в той или иной форме поддерживают управление на базе заранее сформулированной политики. Кроме того, изделия основных поставщиков сред управления сетями - CA, HP, Tivoli - позволяют формулировать политику слежения за техническим состоянием сетей и систем и их загрузкой.

Развитию средств управления сетями на базе политики могло бы значительно способствовать создание систем искусственного интеллекта; эта идея была чрезвычайно популярна в середине 80-х годов. Проблема была в том, что пользователей настолько обеспокоила мысль о том, что компьютеры будут управлять работой компьютеров же, что искусственный интеллект так и не появился. Поэтому сейчас специалисты по управлению сетями называют искусственным интеллектом средства для принятия решений на основе правил (rules-based intelligence) либо прецедентов (case-based reasoning); строго говоря, ни то, ни другое не является искусственным интеллектом.

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

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

Программы управления сетями и системами существуют в двух модификациях: модули знаний (knowledge module) и механизмы выводов (inference engine). В обеих модификациях требуется, чтобы правила, определяющие причинно-следственные связи, определялись заранее, производителями либо пользователями.

Модули знаний используются в наборе управляющих программ Patrol от BMC Software. Это - программные модули, представляющие собой загружаемые библиотеки экспертных знаний, где содержатся правила по поводу того, как Patrol должен управлять операционными системами, базами данных или приложениями. BMC сама определяет модули знаний для различных окружений, например, Lotus Notes, SAP R/3 или Oracle.

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

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

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

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

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

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

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

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

Громкие рекламные заявления или тонкий лучик надежды?