extracted_text:
Лекция № 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

file_name: 10. Развёртывание новой сети. Состав группы разработки. Определение коммерческих требований.doc

alt: Лекция № 10 Развёртывание новой сети

alt: Особое внимание следует обратить на: 1

alt: Достоинства и недостатки одно ранговой модели: ·

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

alt: Несмотря на это, использование тестовой лаборатории позволяет убедиться , что все собранные воедино компоненты сети взаимодействуют именно так, как предполагалось

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

alt: В приведенном ниже списке перечисле ны типичные недостатки проекта, которым по той или иной причине не уделяется должное внимание, поэтому перед представлением заключительного отчета руководству…

alt: Чес тно говоря, существуют различные мнения относительно необходимости включения этого этапа в процесс разработки, поскольку он не оказывает непосредственного влияния на завершение проекта

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

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


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

title: Решение задач в 1 классе