Лекция № 10 Развёртывание новой сети. Состав группы разработки. Определение коммерческих требований. Определение сетевой модели. Принятие окончательных решений. Разработка стандартов. Разработка мероприятий восстановления работоспособности. Система мониторинга сети. Обучение пользователей

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

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

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

Итак, для организации компьютерной сети необходимо:

Ø    Располагать средствами для установления соединений между двумя или более «клиентами»

Ø    Выбрать единый язык общения клиентов сети

Ø    Определить  «этикет» диалога:  Кто инициирует передачу данных по сети?  Кто отвечает  на запрос?

Ø    Каким образом обрабатываются ошибки?

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

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

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

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

1.1        Состав группы разработки

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

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

Руководитель проекта

Ø   Связывается с руководством организации для решения вопросов оплаты и отчетности

Ø   Ставит перед членами группы конкретные задачи и сроки их выполнения

Ø   Устанавливает стандарты для проекта

Ø   Решает спорные вопросы, которые могут препятствовать дальнейшей реализации проекта

Ø   Проводит встречи специалистов проекта и обладает всей информацией по проекту

        Коммерческий директор проекта

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

Ø   Доводит до сведения разработчиков пожелания пользователей

Ø   Знакомит разработчиков с историей и принципами организации работы компании

Ø   Проверяет эффективность работы сети перед ее предоставлением пользователям

        Ответственный за работу сети

Ø   Координирую все действия, связанные с планированием сетевой инфраструктуры и архитектуры

Ø   Убеждается в выполнении работы, проверяя соответствие сетевой топологии предъявляемым требованиям

Ø   Связывается с производителями оборудования для получения необходимой информации

Ø   Устанавливает стандарты для будущего расширения сети

        Ответственный за работу оборудования

Ø   Проводит настройку оборудования в соответствии с требованиями

Ø   Связывается с производителями оборудования для получения необходимой информации

Ø   Устанавливает стандарты для будущего расширения системы

        Ответственный за работу приложений

Ø   Отвечает за выбор программного обеспечения пользователей

Ø   Проверяет соответствие уровня аппаратных средств задействованному программному обеспечению

Ø   Оптимизирует сетевое оборудование для обработки трафика программного обеспечения

Ответственный за безопасность и надежность функционирования

Ø   Определяет необходимый уровень физической и сетевой зашиты информации компании

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

Ø   Определяю уровень отказоустойчивости и резервирования в соответствии с требованиями компании

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

Ответственный за обучение

Ø   Определяю уровни знаний пользователей

Ø   Разрабатывает способы повышения квалификации пользователей различных уровней

Ø   Рассматривает вопросы, препятствующие дальнейшему обучению пользователей

Ø   Отвечает за обучение пользователей и проверяет их знания в соответствии со специальной программой обучения

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

1.2        Определение коммерческих требований

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

1.  Коммерческие цели

Ø  Чем занимается организация?

Ø  Для чего, по мнению руководящего персонала, будет использоваться данная сеть?

Ø  Какие подразделения/отделы особенно сильно затронет развертывание сети?

2.  Будущий рост

Ø  Насколько быстро расширяется организация?

Ø  Планируется ли в ближайшее время создание новых подразделений или отделов''

Ø  Какой видит компанию через один тол или пять лет ее руководство?

3.  Требования пользователей и групп

Ø  Как появление сети повлияет на производительность работы пользователей?

Ø  Смогут ли пользователи с помощью сети добиться повышения по службе?

Ø  Какой тип и объем ресурсов должен быть доступен для каждой конкретной группы?

4.  Безопасность

Ø  Каковы уровни защиты данных в организации?

Ø  Следует ли устанавливать различные уровни защиты при работе с внешними источниками ин­формации?

Ø  Каков уровень физической защиты организации?

5.  Отказоустойчивость

Ø  Значительно ли повлияет на работу организации сбой всей системы?

Ø  Каково максимальное время восстановления работоспособности сети в случае отказа?

Ø  Насколько важны аспекты отказоустойчивости и резервирования?

6.  Существующая сетевая архитектура

Ø  Развернута ли в данной организации сеть?

Ø  Возможна ли дальнейшая модернизация развернутой сети?

Ø  Каковы последствия модернизации сети?

7.  Управление

Ø  Сколько времени и усилий необходимо для поддержания работоспособности сети?

Ø  Каким образом организация собирается управлять работой сети?

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

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

1.3        Разбиение сети

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

1.4        Создание логической структуры

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

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

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

1.5        Создание физической структуры

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

Ø   Сколько пользователей подключено к каждому узлу? Каким образом?

Ø   Занимает ли каждый узел несколько этажей?

Ø   Где будет расположено центральное оборудование каждою сетевого узла?

Ø   Какие требования предъявляются к источникам питания каждого узла?

Ø   Нужно ли использовать бесперебойные источники питания и резервные генераторы?

Ø   Где будут расположены рабочие станции пользователей?

Ø   Какой вид доступа к внешним устройствам (принтерам, модемам, сканерам) необходим пользователям?

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

1.6        Определение сетевой модели

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

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

Ø    Распределенная среда (среда "мэйнфрейма"). Эта модель была самой первой и остается популярной по сей день. Все ресурсы сети такой модели располагаются на сервере, который отвечает за управление и хранение всех данных компании. Каждый пользователь сети для запуска процессов на сервере обращается к нему со своею видеотерми­нала или бездисковой рабочей станции. Основные достоинства и недостатки данной среды:

·   Сервер является наиболее уязвимым компонентом к отказам сети

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

·  Снижение производительности сети при перегрузке сервера

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

·  Несложное управление вопросами безопасности физического доступа к серверу

Ø Среда клиент/сервер

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

·  Необходимость более тщательного по сравнению с другими моделями планирования

·  Возможность функционирования рабочих станций даже при отсутствии сервера

·  Необходимость в случае модернизации сети наращивания производительности не только сер­вера, но и рабочей станции

·  Недостаточная безопасность данных, которые хранятся на рабочих станциях

·  Возможность расширения до уровня промышленной сети

Ø   Одноранговая среда

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

·        Рабочим станциям предоставлен доступ ко всем ресурсам

·        Привлекательное отношение стоимость/эффективность, причиной чего является отсутствие вы­ деленною сервера

·        Отсутствие централизованного управления и обеспечения безопасности

·        Невозможность преобразования в большую сеть

·        Возможность сбоя всей сети после выхода из строя отдельной рабочей станции

Ø    Среда, развернутая на базе World Wide Web

Эта относительно новая модель получила широкое распространение благодаря резкому всплеску по­пулярности Internet в последние пять лет. Ее структура напоминает среду мэйнфрейма, в которой центральный сервер предоставляет пользователям свои "'страницы" информации дли просмотра и взаимодействия с ними. Каждый пользователь такой сети может использовать эти страницы либо на своей локальной машине, либо на сервере. Основные достоинства и недостатки этой среды:

·        Заманчивое соотношение стоимость/эффективность и в случае использования с целью объединении локальной и глобальной сети

·        Возможность инсталляции и обновления версий приложений без необходимости непосредствен­ного взаимодействия с рабочими станциями клиентов

·        Наиболее уязвимым к отказам звеном сети является Web-сервер

·        Необходимость поддержки нескольких платформ

·        Недостаточно надежное обеспечение безопасности из-за возможности внешнего доступа к сети

·        Возможность развертывания в средах с низкой пропускной способностью или большим трафиком

·        Возможность интеграции с  Internet

1.7        Принятие окончательных решений

Добравшись до заключительного этапа процесса разработки, следует уделить особое внимание рассмотрению следующих трех аспектов.

Во-первых, нужно выбрать сетевые приложения.

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

В-третьих, определить требова­ния программного обеспечения к аппаратному обеспечению.

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

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

Ø  Простоту инсталляции и конфигурации

Ø  Простоту использования

Ø  Доступный уровень технической поддержки

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

Ø  Возможность работы данного приложения под управлением различных сетевых операционных систем

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

Ø  Стоимость и схема лицензирования

Ø  Простота инсталляции и конфигурации

Ø  Простота использования

Ø  Минимум усилий для обслуживания

Ø  Доступный уровень технической поддержки

Ø  Поддержка аппаратных средств

Ø  Возможность последующей модернизации

Ø  Уровень поддержки независимых разработчиков

Ø  Возможности обучения системных администраторов

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

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

Ø   Требования к аппаратным средствам сервера

Ø   Требования к аппаратным средствам рабочей станции

Ø   Требования к периферийным устройствам (принтеры, модемы, сканеры и т.д.)

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

Если аппаратные средства сервера зависят от выбранной сетевой ОС, оборудование рабочих станций определяется приложениями, которые планируется на них запускать. Рекомендуется при выборе оборудо­вания рабочей станции основательно протестировать совместимость различных ее компонентов и попытаться найти основные недостатки в работе данной настольной системы. Если выбор сделан, рекомендуется сразу же связаться с производителями аппаратных средств сервера для получения сведений о совместимо­сти их оборудования с различными компонентами сети. Обычно оборудование делится на три категории:

Øпредназначенное для средних пользователей,

Øпродвинутых пользователей,

Øразработчиков.

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

Ø    Будет ли в определенный момент времени системе не хватать локальных ресурсов (например, оперативной или дисковой памяти)?

Ø    Какова относительная стоимость системы по сравнению с другими системами  этого уровня?

Ø    Насколько легко модернизировать или отремонтировать компоненты данной машины?

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

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

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

1.8        Создание тестовой лаборатории

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

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

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

1.9        Оценка пропускной способности

После выбора окончательной конфигурации аппаратных средств сети необходимо (особенно в больших сетях) оценить пропускную способность. Это позволит определить масштабируемость сети и выяснить, в каких ее частях для равномерного распределения нагрузки следует разместить сетевые устройства типа маршрутизаторов, мостов и шлюзов. Для эффективною решения этой задачи подключите к тестовой лаборатории анализатор протокола (protocol sniffer). Запуск на рабочих станциях различных сетевых приложений (сначала по отдельности, а затем вместе) позволит определить предварительные требования к времени передачи пакетов и пропускной способности. Анализируя результаты измерений, можно получить ответы на следующие вопросы:

Ø Каков размер пакетов данных?

Ø Изменяется или остается постоянным трафик каждого из приложений?

Ø Влияет ли работа одного приложения на эффективность другого?

Ø Влияют ли какие-нибудь из операции одного приложения на производительность передачи пакетов?

Ø Сколько пользователей будет запускать данное приложение, и как их количество повлияет на работу всей сети?

Ø Как часто будет запускаться данное приложение (один раз в неделю, в день, в час)?

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

1.10   Выбор аппаратных средств установления соединений

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

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

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

Ø Мосты следует использовать в тех случаях, когда протоколы не поддерживают инкапсуляцию или туннелирование кадров.

Ø Мосты обладают лучшими соотношениями цена/эффективность и цена/скорость.

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

Ø Маршрутизаторы эффективнее осуществляют широковещательную передачу  данных.

Ø Маршрутизаторы являются более ''интеллектуальными'" и в состоянии самостоятельно изменять раз­меры пакетов данных.

1.11   Документация

Вы наверняка заметили, что на протяжении всей главы делался значительный акцент на необходимос­ти создания документации и зарисовки схем сетевых структур. Только после выполнения всех описанных выше действий процесс разработки сети можно считать полностью законченным. Конечная цель такой разработки заключается как в удовлетворении требований пользователей, так и в принятии соответствую­щих решений относительно поддержки, производительности и надежности работы сети. Теперь самое вре­мя собрать нее экспериментальные данные и документацию и создать коммерческое предложение, с помощью которого руководители проекта смогут отчитаться перед директорами компании об удовлетворении требо­ваний и достижении ожидаемых результатов. Просмотрите еще раз все страницы документации. Есть ли желание после всего изученного что-нибудь изменить в структуре сети? Существуют ли какие-нибудь аль­тернативные решения, позволяющие удовлетворить вес предъявляемые требования и получить при этом лучшее соотношение цена/эффективность? Перед составлением окончательного варианта документации следует еще раз вернуться назад и проверить правильность выбора компонентов и структуры сети. Лучше сейчас потратить некоторое время на пересмотр проекта, чем уже после начала работ понять, что устраня­ются далеко не все проблемы пользователей. Создавая документацию, необходимо по каждому пункту да­вать краткие объяснения о том, какие альтернативы существовали и почему было выбрано то или иное решение. В большинстве организаций, прежде чем выделить средства на реализацию того или иного проек­та, руководство компании подробно расспрашивает руководителя проекта о том, как было принято опти­мальное решение. Убедитесь в том, что ответственный менеджер проекта располагает всей информацией, которая позволит ему отстоять точку зрения команды разработчиков.

В документацию должны входить следующие сведения:

Ø Детальное описание требований пользователей

Ø Логическая схема

Ø Физическая схема

Ø Технические требовании к выбранным приложениям (связаны с требованиями пользователей)

Ø Технические требования к выбранной сетевой операционной системе

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

Ø Технические требования к протоколам и физической среде передачи

Ø Данные о тестировании приложений и их характеристиках

Ø Логическая схема с линиями сетевых соединений

1.12   Определение стоимости и времени реализации проекта

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

Ø Может ли персонал, обслуживающий удаленный узел, самостоятельно инсталлировать приложения?

Ø Могут ли различные компоненты сети быть модернизированы без повторной инсталляции, которая  требует кратковременного отключения пользователей от сети?

Ø Насколько автоматизирован процесс инсталляции?

Ø Могут ли поставщики оборудования обеспечить совместимость своих продуктов с продуктами дру­гих разработчиков?

Ø Какое количество второстепенных инсталляций в день могут выполнить администраторы сети?

Ø В каких отделах инсталляция должна быть выполнена в первую очередь?

Ø К кому пользователи сети могут обращаться с возникающими вопросами?

Ø Какие дополнительные сотрудники должны быть привлечены для выполнения инсталляции в опре­деленный период времени?

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

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

1.13   Организация узла эксплуатационных испытаний

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

Ø Позволяет ли выбранная структура сети циркулировать данным в пределах одного отдела?

Ø Адекватно ли предложенные приложения заменят использовавшиеся ранее способы обработки данных?

Ø Какой уровень безопасности должен быть обеспечен для данных?

Ø Какие дополнительные преимущества, не учтенные на этапе разработки, были обнаружены в процессе испытаний?

Ø Насколько важны обрабатываемые данные?

Ø Каким образом повлияет на работу компании случайное уничтожение данных?

Ø Сколько времени необходимо на восстановление уничтоженных данных?

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

Ø Отвечает ли созданная система всем требованиям и ожиданиям?

Ø Какой уровень знаний необходим для работы в сети?

Ø Позволяет ли сеть эффективнее выполнять трудоемкие процессы, предоставляя таким образом больше времени на решение организационных вопросов?

Ø Существуют ли дополнительные рекомендации относительно работы в сети?

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

1.14   Разработка стандартов

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

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

v Аппаратные средства настольных систем:

Ø Производитель и модель системы (указать отдельно для рабочих станций обычных, продвинутых пользователей и разработчиков)

Ø Процессор

Ø Память

Ø Жесткие диски

Ø Монитор

Ø Сетевые адаптеры

v Аппаратные средства сервера

Ø Производитель и модель системы

Ø Процессор

Ø Память

Ø Жесткие диски (указать все способы резервирования: зеркальное отображение, дублирование, использование массивов RAID)

Ø Сетевые адаптеры

v Дополнительные периферийные устройства

Ø Изготовитель и модель периферийных систем

Ø Специфические настройки узла

Ø Используемые интерфейсы (последовательный, параллельный или другой)

v Программное обеспечение

Ø Поддерживаемая операционная система

Ø Требования к объему оперативной памяти

Ø Необходимое дисковое пространство на рабочей станции

Ø Необходимое дисковое пространство на сервере

Ø Специфические параметры настройки узла

v Работа с пользователями

Ø Соглашения о присвоении пользовательских имен

Ø Правила регистрации и удаления пользователей

v Управление информацией

Ø Оглашения о присвоении имен томов

Ø Структура каталогов (приложения, каталоги пользователей, каталоги отделов)

Ø Ограничения на размер каталогов (необязательно)

v Управление сетью

Ø Соглашения о присвоении имен серверов

Ø Сведения о маршрутизаторах и шлюзах

v Безопасность

Ø Ограничение доступа с помощью паролей

Ø Определение часов доступа

Ø Сценарии входа в сеть/привилегии различных отделов

Ø Учет (файлов, катало го и,  пользователей)

v Отслеживание/Разрешение проблем

Ø Соглашения о присвоении стандартных названий проблемам и способам их решении

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

Ø   Контактная информация поставщика оборудования

Ø   Условия контракта о поддержке (полезны при получении помощи от поставщика по телефону)

Ø   Дополнительные сведения о конфигурации системы (номера запросов на прерывание и каналов пря­мого доступа к памяти, диапазоны адресов виола/вывода)

Ø   Контактная информация сотрудников, отвечающих за поддержку оборудования (номера телефонов или пейджеров)

Ø   Средства восстановления (загрузочные диски, редакторы поврежденных секторов, определенные кон­фигурационные файлы сервера и т.п.).

1.15   Администрирование

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

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

Ø Как зарегистрировать новых пользователей?

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

Ø Какова структура томов на сервере?

Ø Какие каталоги расположены в отдельных томах?

Ø Как спланированы мероприятия резервирования?

Ø Существуют ли какие-либо особые требования к конфигурации узла?

Ø Каков уровень безопасности каждого каталога отдела или пользователя?

Ø Необходимо ли копировать данные на центральный сервер с целью резервирования их на случай сбоя в работе локального оборудования?

Ø Каким образом настраивается сервер?

Ø С чем связаны возможные сбои в работе сервера?

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

1.16   Разработка мероприятий восстановления работоспособности и поддержки сети

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

Ø Определение уровней важности всех приложений и систем (необходимый, жизненно важный, кри­тически важный)

Ø Составление описаний систем среды (электрическая, нагревание/охлаждение)

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

Ø Определение видов поддержки, предоставляемой группами

Ø Определение характеристик аппаратных средств (эта информация берется из документации)

Ø Оценка и составление плана действий на непредвиденные ситуации (простой,  замена, функциони­рование в автономном режиме)

Ø Выбор руководителя, которого в первую очередь следует извещать о сбое в работе сети

Ø Определение действий в нестандартных ситуациях (пожар, угроза взрыва бомбы, стихийное действие)

Ø Составление расписания отключений и тестирования критически важных систем

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

В правильно разработанных и настроенных сетях при появлении неисправности выполняются следую­щие действия:

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

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

1.17   Система мониторинга сети

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

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

Ø  Имя пользователя

Ø  Расположение пользователя

Ø  Отдел пользователя

Ø  Телефонный номер или другая контактная информация, по которой можно связаться с пользователем

Ø  Категория  проблемы (неисправность, вопрос, запрос)

Ø  Тип сбоя (программный или аппаратный)

Ø  Какие программные продукты связаны с возникшей проблемой

Ø  В чем заключается неисправность оборудования или проблема в работе приложения (не всегда определяется с первого взгляда)

Ø  Существовала ли эта проблема ранее

Ø  Может ли пользователь продолжать свою работу

Ø  Влияет ли данная проблема на работу других пользователей (возможность сбоя сетевого при­ложения)

Ø  Предлагаемый способ решения проблемы (заполняется при возвращении формы).

Ø  Сколько времени  займет решение проблемы

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

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

1.18   Реализация

Этот раздел связан с общением намного больше, чем все остальные. Можно провести аналогию между реализацией проекта и битвой. Цель битвы заключается в расположении сотрудников и оборудования в ключевых позициях, что позволит создать "линию поддержки информации". В качестве противоборствую­щей стороны выступает коллектив пользователей, чье недоверчивое отношение к новой технологии и тя­готение к устаревшим системам значительно усложняет процесс завоевания. Перед развертыванием войск и ресурсов необходимо тщательно продумать «план битвы», включающий следующие аспекты:

Ø Определение плана атаки (реализация проекта выполняется сразу же или разбивается на этапы).

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

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

Ø Согласованное движение армии (оплошность на любом этапе реализации может привести к краху всего проекта).

Ø Поддержка контакта с дивизиями (периодическая проверка функционирования отделов и узлов сети).

Ø Введение дополнительных резервов в области сопротивления (в случае возникновения проблемы следует быть готовым приобрести дополнительные ресурсы для ее решения).

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

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

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

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

1.19   Обучение пользователей

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

Ø   Описание и структура сети

Ø   Описание трех типов рабочих станций клиентов (предназначенных для обычных пользователей, продвинутых пользователей и разработчиков)

Ø   Ответы на наиболее часто задаваемые вопросы

Ø   Список специалистов отдела поддержки

Ø   Описание способа решения проблем или  вопросов с помощью системы мониторинга

Ø   Резюме  по каждому используемому приложению с краткой таблицей,  позволяющей пользователю немедленно начать работу с приложением

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

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

1.20   Анализ мнений пользователей

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

1.21   «Разбор полетов»

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

Ø Достиг ли проект  результата?

Ø Достиг ли проект ожидаемого успеха у пользователей (это иногда сильно отличается от первого пун­кта)?

Ø  Какими недостатками обладает завершенный проект?

Ø  Какие аспекты были недостаточно проработаны?

Ø  Понимала ли группа разработки цели проекта? (Необходимо ещё раз напомнить группе о целях для большей  концентрации внимания.)

Ø Были ли достигнуты  преимущества, не учитываемые на этапе разработки?

Задайте группе вопрос: «Если бы мы делали этот проект еще раз, зная то, что мы знаем сейчас, то чтобы мы изменили?» и позвольте ответить на него каждому члену группы. Ответ при этом должен рас­сматриваться с точки зрения специализации данного специалиста. После этого, посоветовавшись с груп­пой, определите, какие области применения следует улучшить во время будущей модернизации. Цель такого упражнения включается не только в анализе допущенных ошибок, но и в акцентировании внимания на основных факторах, ведущих к построению корректно функционирующей сети.

1.22   Резюме

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

Скачано с www.znanio.ru