Шаблон ТЗ на СПД

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

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

Кафедра «Информационные технологии и автоматизированные системы»

Курсовой проект

По дисциплине: «Проектирование вычислительных систем и сетей»

«Шаблон ТЗ на СПД»

Выполнил: Студент гр. ЭВТ - 16 - 1бзу

Морозов Илья Сергеевич

Проверил: к.т.н., профессор

Масич Григорий Фёдорович

Пермь, 2019

Содержание

связь модернизация оборудование

Введение

1 Общие положения

2 Этап Аудита КСПД

2.1 Сроки начала и окончания работ

2.2 Назначение и цели проведения Аудита

2.2.1 Цели и задачи Аудита

2.2.3 Критерии достижения цели

2.2.4 Назначение Аудита

2.2.5 Объем Аудита

2.3 Этапы проведения Аудита

2.4 Состав и содержание работ Аудита

2.5 Требования к документации

2.6 Мероприятия по устранению рисков и модернизации КСПД

3 Проектирование Системы

3.1 Основные положения

3.2 Требования к системе в целом

3.2.1 Требования к структуре системы

3.2.1.1 Функциональная структура Системы

3.2.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы

3.2.1.3 Требования к совместимости со смежными системами

3.2.1.4 Требования к выбору поставщиков оборудования

3.2.1.5 Требования к режимам функционирования системы

3.2.1.6 Требования по диагностированию системы

3.2.1.7 Перспективы развития, модернизации системы

3.2.2 Дополнительные требования

3.2.2.1 Дополнительные требования к подсистеме коммутации

3.2.3 Требования к внешним каналам связи

3.2.3.1 Требования к системе обработки заявок

3.2.3.2 Требования к мониторингу внешних каналов связи

3.2.3.3 Требования к резервированию внешних каналов связи

3.3 Требования к функциям базовых подсистем

3.3.1 Требования к функциям подсистемы коммутации

3.4 Требования к видам обеспечения

3.4.1 Требования к информационному обеспечению

3.4.1.1 Требования к информационному обмену между компонентами системы

3.4.1.2 Требования к информационной совместимости со смежными системами

3.4.1.3 Требования к доступности ресурсов между подсистемами

3.4.1.4 Требования к защите данных от разрушений при авариях и сбоях, в том числе в электропитании системы

3.5 Требования к проектной документации

3.6 Требования к надежности

3.7 Требования к безопасности

3.8 Требования к эргономике и технической эстетике

3.9 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению

3.10 Требования к защите информации от несанкционированного доступа

3.11 Требования по сохранности информации при авариях

3.12 Требования к защите от влияния внешних воздействий

3.13 Требования к стандартизации и унификации

Заключение

Список литературы



Введение

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

Сеть передачи данных (СПД) - совокупность оконечных устройств (терминалов) связи, объединённых каналами передачи данных и коммутирующими устройствами (узлами сети).

Выделяют следующие основные виды СПД:

· Телефонные сети - сети, в которых оконечными устройствами являются телефоны.

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



1 Общие положения

Полное наименование системы: (Например: Катастрофоустойчивая многоконтурная распределенная сеть передачи данных ООО «Аэроэкспресс»)

Сокращенное наименование: (Например: Корпоративная сеть передачи данных. Далее - КСПД)

Заказчик: (Например: ООО «Аэроэкспресс»)

Исполнитель: (Например: Открытый конкурс)

Настоящее техническое задание (далее в тексте - ТЗ) определяет требования к проектированию и эксплуатации КСПД.

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



2 Этап Аудита КСПД

Стоит учитывать, что не все приведенные пункты данного раздела могут быть задействованы в конкретном ТЗ, так как являются лишь шаблоном.

2.1 Сроки начала и окончания работ

Дата начала работ:

Дата окончания работ:

2.2 Назначение и цели проведения Аудита

2.2.1 Цели и задачи Аудита

Целями аудита является изучение имеющейся сетевой инфраструктуры Заказчика, равно как и исследование потребностей Заказчика в ресурсах КСПД.

Задачи могут быть следующими:

· Выполнение внешних требований (требования закона, стандарта и т.д.)

· Обеспечение работы нового технологического процесса (например, создаем интернет-магазин, организуем новый отдел, новый бизнес).

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

· Повышение качества работы: снижение количества ошибок, ускорение принятия решений.

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

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

2.2.2 Критерии достижения цели

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

2.2.3 Назначение Аудита

Актуализация технической документации по сетевой инфраструктуре. Снижение рисков и повышение отказоустойчивости всех компонентов сети. Принятие решения о модернизации сети (если требуется таковая) на основе отчетов и мероприятий.

2.2.4 Объем Аудита

Аудит покрывает все точки присутствия элементов имеющейся КСПД.

Общее количество территориально разнесенных площадок:

Общее ожидаемое количество серверных и кроссовых комнат: (точное количество подлежит уточнению в процессе аудита).

Общее ожидаемое количество узлов (активных элементов) в КСПД: (точное количество подлежит уточнению в процессе аудита).

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

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

2.3 Этапы проведения Аудита

Аудит делится на следующую строгую последовательность этапов:

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

· Разработка правил именования и нумерации компонентов КСПД.

· Ревизия кабельных линий КСПД

· Маркировка компонентов КСПД.

· Составление отчета о проделанных работах во время аудита

· Составление Технической документации

· Составление и выдача Технического заключения содержащее:

a. Список выявленных недостатков

b. Рекомендации по устранению выявленных недостатках и модернизации КСПД.

2.4 Состав и содержание работ Аудита

Аудит является комплексом работ по исследованию и описанию КСПД, результатом которого являются:

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

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

· Описание имеющейся SAN сети (включая СХД и системы резервного копирования). Схемы зонирования.

· Описание схемы, протоколов и параметров маршрутизации внутри контура КСПД.

· Описание имеющегося оборудования беспроводного доступа к ресурсам КСПД.

· Описание имеющейся системы мониторинга КСПД,

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

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

2.5 Требования к документации

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

В документации точно и полно должно быть отображено:

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

· Полный журнал активных устройств КСПД, включающий в себя:

a. Наименование устройства, согласно выбранной стратегии именования.

b. Наименование устройства согласно спецификации производителя.

c. Версии микропрограммы.

d. Набор лицензий микропрограммы.

e. Серийный номер устройства.

f. MAC адрес устройства (CPU mac).

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

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

· Схемы топологий КСПД первого, второго и третьего уровня модели взаимодействия открытых систем (OSI) - то есть физическую схему сети, логическую схему сети и схему организации маршрутизации сети.

· Схему движения основных (используемых всеми или абсолютным большинством конечных пользователей) сервисов в нотации потоков данных (data flow).

· Таблицe существующих виртуальных локальных сетей (VLAN) и их интерфейсов терминирования:

a. Подсеть

b. VLAN tag

c. Адрес шлюза

d. Устройство терминирования VLAN.

e. Имеющийся листы доступа на интерфейсах терминирования.

2.6 Мероприятия по устранению рисков и модернизации КСПД

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

· Выявление рисков во всех компонентах КСПД на основе анализа данных.

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

· На основании отчетов по аудиту инфраструктуры должно быть получено техническое задание, в котором будут приведены меры (технические решения) поэтапного устранения рисков:

a. в аспекте логических взаимодействий между устройствами;

b. в аспекте физических подключений.

4. План мероприятий по модернизации и развитию КСПД.



3 Проектирование Системы

Стоит учитывать, что не все приведенные пункты данного раздела могут быть задействованы в конкретном ТЗ, так как являются лишь шаблоном.

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

· Правила проектирования, строительства и эксплуатации волоконно-оптических линий связи на воздушных линиях электропередачи напряжением 0,4-35кВ

· Правила проектирования, строительства и эксплуатации волоконно-оптических линий связи на воздушных линиях электропередачи напряжением 110 кВ и выше

· Технология создания информационных систем с применением волоконно-оптических линий связи

· Кабельные линии объектов инфраструктуры железнодорожного транспорта

· Правила технической эксплуатации первичных сетей взаимоувязанной сети связи РФ

А также другие нормативные документы.

3.1 Основные положения

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

3.2 Требования к системе в целом

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

3.2.1 Требования к структуре системы

Этот пункт достаточно обширен, он должен дать общее представление об архитектуре системы. Могут быть приведены:

· Схема внутренней структуры и внешних, смежных систем

· Требования к элементам приведенной структуры

3.2.1.1 Функциональная структура Системы

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

По территориально-распределенному признаку Система должна разделяться на две составляющие:

· телекоммуникационную составляющую центрального узлового сегмента (далее по тексту ? ЦУС);

· телекоммуникационную составляющую регионального узлового сегмента (далее по тексту ? РУС).

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

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

Например:

Таблица 1 - Состав подсистем и их назначение

№	Название подсистемы	Назначение подсистемы
1	Подсистема коммутации	-формирование транспортной магистрали для передачи и обработки всех информационных потоков ОАО «Аэроэкспресс» для всех существующих и будущих систем; -обеспечение интеграции всех подсистем.
2	Подсистема межсетевого экранирования	-разделение Системы на отдельные защищенные и изолированные друг от друга сегменты сети (офисная, голосовая, кассовая и видео подсети); -обеспечение соответствующего уровня конфиденциальности, безопасности и степени защищенности от потенциальных угроз при обработке и передаче информационных потоков; -организация демилитаризованной зоны (далее - по тексту ДМЗ), содержащей общедоступные ресурсы для пользователей сети Интернет; -защита внутренних сегментов сети при взаимодействии с сетью Интернет.

Таблица 2 - Структура базовых подсистем

№	Подсистема	Части подсистемы	Уровни
1	Подсистема коммутации	Подсистема коммутации ЦУС	Уровень ядра
			Уровень серверной фермы
			Уровень доступа
			Уровень сопряжения с внешними сетями
		Подсистема коммутации РУС	Уровень доступа
			Уровень сопряжения с внешними сетями
2	Подсистема межсетевого экранирования	Подсистема межсетевого экранирования ЦУС	Нет



3.2.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы

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

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

3.2.1.3 Требования к совместимости со смежными системами

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

Следует привести следующие сведения:

· перечень передаваемых сведений, хотя бы общее описание, чтобы вообще понять, зачем мы интегрируемся с конкретной системой;

· описание протоколов (или ссылки на описание), особенно в случае присоединения устройств;

· структура локальных сетей;

· требуемая скорость передачи данных;

· применение мобильного интернета или WiFi;

· описание неавтоматизированных способов передачи данных.

Например:



Таблица 3 - Требования к интеграции и совместимости со смежными системами

№	Смежная система	Уровень взаимодействия	Требования	Средство связи
1	СКС	Пассивная физическая среда передачи данных	Обеспечение необходимого количества магистральных оптоволоконных каналов связи между этажами и телекоммуникационными помещениями для организации связи между устройствами коммутации	Технология 10 Gigabit Ethernet (стандарты IEEE 802.3ae)
			Обеспечение необходимого количества оптических и медных кроссов в телекоммуникационных помещениях для подключения сетевого оборудования и конечных узлов	Технологии Gigabit Ethernet, 10 Gigabit Ethernet (стандарты IEEE 802.3ab, 802.3ae, 802.3z)
			Организация сквозной нумерации серверных и кроссовых комнат, а также расположенных в них коммутационных шкафов и стоек	Средства маркировки коммутационных стоек
2	Система обеспечения электропита-нием	Обеспечиваю-щая система	Обеспечение гарантированного бесперебойного электропитания: (220 ± 20) В, 50 Гц	Технические средства электропитания
3	Система кондиционирования	Обеспечивающая система	Поддержание определенных параметров окружающей среды в телекоммуникационных помещениях для обеспечения работы технических средств, входящих в состав КСПД температура воздуха (20 ± 5)С, относительная влажность воздуха (60 ± 15) %.	Средства поддержания микроклиматических условий окружающей среды



3.2.1.4 Требования к выбору поставщиков оборудования

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

· Brocade Communications System.

· Cisco Systems Limited.

3.2.1.5 Требования к режимам функционирования системы

Режимы функционирования могут иметь несколько классификаций:

· по готовности к эксплуатации: штатный режим, аварийный режим, режим технического обслуживания.

· по готовности к эксплуатации частей системы: как должна функционировать система, если, например, недоступен один из компонентов системы

· по графику работы: 24/7 или пятидневка (от этого зависит как минимум работа технической поддержки);

· по возможности изменения системы

· по уровню доступа

· по степени автоматизации: автоматический или полуавтоматический режим, «режим советчика»;

· по возможному воздействию на систему: штатный, обучающий, тестовый режимы.

3.2.1.6 Требования по диагностированию системы

Диагностирование Системы должно выполняться посредством следующих средств:

· на программно-аппаратных комплексах, входящих в состав Системы, диагностика аппаратной части должна осуществляться средствами самодиагностики;

· на программно-аппаратных комплексах, входящих в состав Системы, диагностика аппаратной части может осуществляться с помощью внешних световых индикаторов;

· все программные и программно-аппаратные комплексы Системы должны иметь встроенные программные средства функциональной диагностики;

· все программные и программно-аппаратные комплексы Системы должны иметь механизмы сопряжения с внешними программными средствами диагностирования;

· для диагностики Системы в штатном режиме работы должны быть разработаны регламенты штатного обслуживания Системы в целом и регламенты штатного обслуживания входящих в нее подсистем;

· для диагностики Системы в аварийных ситуациях должны быть разработаны регламенты аварийного обслуживания Системы в целом и регламенты аварийного обслуживания входящих в нее подсистем;

· для диагностики подсистем должны быть разработаны Руководства администраторов по каждой подсистеме;

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

3.2.1.7 Перспективы развития, модернизации системы

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

В рамках эксплуатационной поддержки персоналом Система должна обладать следующими возможностями:

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

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

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

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

3.2.2 Дополнительные требования

3.2.2.1 Дополнительные требования к подсистеме коммутации

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

Например:



Таблица 4 - Дополнительные требования к подсистеме коммутации

Подсистемы	Уровни	№	Требование
Подсистема коммутации в целом	Все уровни	1	Должна строиться на базе существующей СКС
		2	Должна строиться по иерархическому принципу согласно функциям и задачам, выполняемым на каждом уровне
		3	Должна обеспечивать защищенное взаимодействие между центральным узловым сегментом и региональными узловыми сегментами посредством каналов связи, предоставляемых провайдером услуг
		4	Должна использовать технологию организации виртуальных локальных вычислительных сетей (ВЛВС) для разбиения сети на виртуальные логические сегменты
		5	Должна использовать технологии классификации трафика для обеспечения гарантированной полосы пропускания для кассовой и голосовой подсетей, а также возможности ограничения полосы пропускания для видео подсети
Подсистема коммутации ЦУС	Все уровни	6	Должна строиться по иерархическому принципу с выделением уровня ядра, уровня серверной фермы, уровня доступа и уровня сопряжения с внешними сетями
		7	На всех уровнях должна обеспечивать резервирование основных компонент, узлов и соединений
		8	Должна эффективно и рационально использовать ресурсы существующей СКС
		9	Должна учитывать существующую топологию СКС при выделении уровней ядра, серверной фермы, доступа и сопряжения с внешними сетями
		10	Взаимодействие между уровнем ядра и уровнями серверной фермы и сопряжения с внешними сетями должно быть организовано на третьем уровне модели OSI
		11	Взаимодействие между уровнем ядра и уровнем доступа должно быть организовано на втором уровне модели OSI с использованием технологии стандарта IEEE 802.1q (VLAN Trunk)
		12	Для обеспечения отказоустойчивости и балансировки нагрузки между иерархическими уровнями на третьем уровне должен использоваться промышленный протокол динамической маршрутизации (OSPF либо EIGRP)
	Уровень ядра	13	Должен обеспечивать высокую степень отказоустойчивости и катастрофоустойчивости за счет: -полного резервирования всех узлов и соединений, с использованием основных и резервных компонент и каналов связи; -дублирования коммутационных устройств; -использования протоколов динамической маршрутизации; -разнесения физических устройств по разным центрам маршрутизации с географическим удалением.
		14	Связь между коммутационными устройствами уровня ядра должна быть организована как на 3 уровне модели OSI посредством протоколом динамической маршрутизации с использованием 2 независимых оптоволоконных каналов связи, так и на 2 уровне модели OSI по технологии Ether Channel с использованием 2 оптоволоконных каналов связи
		15	Физическое подключение по этим каналам связи должно осуществляться на скорости 10 Гбит/с
	Уровень серверной фермы	16	-Должен обеспечивать высокую степень отказоустойчивости за счет: -полного резервирования всех узлов и соединений, с использованием основных и резервных компонент и каналов связи; -дублирования коммутационных устройств; -использования протоколов динамической маршрутизации; -разнесения физических устройств по разным центрам маршрутизации с географическим удалением.
		17	Связь между устройствами коммутации серверной фермы должна осуществляться на 3 и 2 уровнях модели OSI по 2 независимым оптоволоконным каналам связи
		18	Физическое подключение по этим каналам связи должно осуществляться на скорости 10 Гбит/с
		19	Для обеспечения отказоустойчивости и балансировки нагрузки на 3 уровне модели OSI должен применяться протокол динамической маршрутизации.
		20	Должен обеспечивать достаточную плотность портов для подключения всего существующего серверного оборудования
		21	Должен обеспечивать возможность расширения числа портов без внесения существенных изменений в архитектуру решения
		22	Для обеспечения балансировки нагрузки и отказоустойчивости сервисов одного типа, запущенных на разных серверах объединенных в кластер, должна применяться технология балансировки нагрузки, реализованная техническими средствами, интегрированными в коммутационное оборудование
	Уровень доступа	23	Должен обеспечивать достаточную плотность портов для подключения всех существующих конечных узлов
		24	Должен обеспечивать возможность расширения числа портов без внесения существенных изменений в архитектуру решения
		25	Коммутационные устройства уровня доступа должны предусматривать возможность электропитания подключенных к ним конечных узлов по медным каналам связи непосредственно через порты, к которым они подключаются, по стандарту IEEE 802.3af - технология Power over Ethernet (PoE)
		26	Маршрутизация сетевого трафика уровня доступа должна осуществляться на коммутационных устройствах уровня ядра
	Уровень сопряжения с внешними сетями	27	Должен быть реализован на базе двух идентичных устройств межсетевого экранирования
		28	Для обеспечения динамической маршрутизации сетевого трафика на уровне сопряжения с внешними сетями должен применяться протокол динамической маршрутизации.
Подсистема коммутации РУС	Все уровни	29	Должна строиться по иерархическому принципу с выделением уровня доступа и уровня сопряжения с внешними сетями
	Уровень доступа	30	Маршрутизация сетевого трафика уровня доступа должна осуществляться на сетевых устройствах уровня сопряжения с внешними сетями
	Уровень сопряжения с внешними сетями	31	Должен быть реализован на базе устройства межсетевого экранирования или маршрутизатора. Допускается также использование коммутатора с функциями маршрутизации.

3.2.3 Требования к внешним каналам связи

3.2.3.1 Требования к системе обработки заявок

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

3.2.3.2 Требования к мониторингу внешних каналов связи

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

· Состояние канала связи;

· Загрузка канала связи в виде графика;

· Задержки на канале связи.

3.2.3.3 Требования к резервированию внешних каналов связи

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

3.3 Требования к функциям базовых подсистем

3.3.1 Требования к функциям подсистемы коммутации

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

Например:

Таблица 5 - Требования к функциям подсистемы коммутации

Подсистема	Уровни	№	Функция
Подсистема коммутации в целом	Все уровни	1	Формирование единой телекоммуникационной среды передачи данных для организации обмена информацией между подключенными к ней конечными узлами, серверами и сетевым оборудованием
		2	Использование существующей пассивной среды передачи данных для связи коммутационного оборудования
		3	Передача и обработка данных различных типов, включая аудио и видео данные
Подсистема коммутации ЦУС	Все уровни	4	Формирование единой транспортной системы для всех информационных сервисов, функционирующих на уровне ЦУС
		5	Передача и обработка данных посредством использования многоуровневой коммутационной платформы, состоящей из выделенных уровней ядра, серверной фермы, доступа и сопряжения с внешними сетями
		6	Сохранность информационного обмена при выходе из строя одного из узлов или компонент телекоммуникационной инфраструктуры
		7	Разделение сети на виртуальные логические сегменты
		8	Локализация информационного обмена между отдельными группами конечных узлов в пределах выделенных виртуальных сегментов сети
		9	Классификация и маркировка сетевого трафика
		10	Дифференцированное обслуживание сетевого трафика
		11	Приоритетное обслуживание сетевого трафика приложений, требующих доставки данных за гарантированное время
	Уровень ядра	12	Агрегация трафика от уровней серверной фермы, доступа и сопряжения с внешними сетями
		13	Маршрутизация сетевого трафика
		14	Осуществление связи с уровнями серверной фермы и доступа посредством оптоволоконных каналов связи на скорости 10 Гбит/с
		15	Осуществление связи с уровнем сопряжения с внешними сетями посредством медных каналов связи на скорости 1 Гбит/с
		16	Обеспечение высокого уровня отказоустойчивости всей подсистемы коммутации посредством резервирования всех основных компонент, узлов и соединений и использования протоколов динамической маршрутизации
	Уровень серверной фермы	17	Подключение серверного и сетевого оборудования, размещенного в центре обработки данных ЦУС
		18	Осуществление информационного взаимодействия между конечными узлами, подключенными к КСПД, и серверным оборудованием, размещенным в ЦОД
		19	Подключение серверов и сетевого оборудования к коммутационным устройствам по медным каналам связи на скорости 1 Гбит/с
		20	Резервирование подключения серверов, имеющих по два независимых сетевых интерфейса
		21	Подключение коммутационных устройств уровня серверной фермы к коммутационным устройствам уровня ядра посредством оптоволоконных каналов связи на скорости 10 Гбит/с с резервированием соединений
		22	Агрегация сетевого трафика от серверов
		23	Маршрутизация сетевого трафика
		24	Балансировка и распределение нагрузки между серверами, обеспечивающими однотипные сервисы, путем объединения в кластер
		25	Обеспечение непрерывности работы сервиса в случае выхода из строя одного из серверов в кластере
	Уровень доступа	26	Подключение конечных узлов ЦУС к коммутационным устройствам для организации информационного взаимодействия между собой и с другими конечными узлами, подключенными к КСПД
		27	Агрегация сетевого трафика от конечных узлов
		28	Подключение конечных узлов к коммутационным устройствам по медным каналам связи на скорости 1 Гбит/с
		29	Подключение коммутационных устройств уровня доступа к коммутационным устройствам уровня ядра посредством оптоволоконных каналов передачи данных на скорости 10 Гбит/с с резервированием соединений
		30	В случае необходимости, электропитание конечных узлов непосредственно через порты коммутационных устройств, к которым они подключаются, по медным каналам связи по стандарту IEEE 802.3af - технология Power over Ethernet
	Уровень сопряжения с внешними сетями	31	Сопряжение телекоммуникационной инфраструктуры с внешними общедоступными сетями передачи данных посредством средств межсетевого экранирования
		32	Маршрутизация сетевого трафика
		33	Организация ДМЗ
		34	Обеспечение высокого уровня отказоустойчивости средств межсетевого экранирования
		35	Подключение устройств межсетевого экранирования к коммутационным устройствам уровня ядра подсистемы коммутации по медным каналам связи на скорости 1 Гбит/с с резервированием соединений
Подсистема коммутации РУС	Все уровни	36	Организация среды единого транспорта для всех информационных сервисов, локализованных в пределах соответствующего РУС
		37	Передача и обработка данных посредством использования коммутационной платформы, состоящей из выделенных уровней доступа и сопряжения с внешними сетями
	Уровень доступа	38	Разделение сети на виртуальные логические сегменты
		39	Локализация информационного обмена между отдельными группами конечных узлов в пределах выделенных виртуальных логических сегментов сети
		40	Классификация и маркировка сетевого трафика
		41	Дифференцированное обслуживание сетевого трафика
		42	Приоритетное обслуживание сетевого трафика приложений, требующих доставки данных за гарантированное время
		43	Агрегация сетевого трафика конечных узлов
		44	Подключение до 48 интерфейсов сетевых устройств соответствующего РУС для информационного взаимодействия между собой и с другими конечными узлами, подключенными к КСПД
		45	Подключение конечных узлов к коммутационным устройствам по медным каналам связи на скорости 100 Мбит/с
	Уровень сопряжения с внешними сетями	46	Сопряжение ЛВС РУС с внешними общедоступными сетями передачи данных посредством средств межсетевого экранирования или маршрутизаторов
		47	Подключение устройств межсетевого экранирования к коммутационным устройствам уровня доступа подсистемы коммутации по медным каналам связи на скорости 100 Мбит/с
		48	Маршрутизация сетевого трафика
		49	В случае необходимости, сопряжение существующих ЛВС РУС с общедоступными сетями передачи данных с выделением ДМЗ



3.4 Требования к видам обеспечения

3.4.1 Требования к информационному обеспечению

3.4.1.1 Требования к информационному обмену между компонентами системы

Информационный обмен между компонентами Системы должен осуществляться посредством использования протоколов на основе открытых стандартов, входящих в состав стека протоколов TCP/IP.

3.4.1.2 Требования к информационной совместимости со смежными системами

Информационная совместимость со смежными системами должна обеспечиваться за счет использования протоколов на основе открытых стандартов, входящих в состав стека протоколов TCP/IP, при информационном обмене.

3.4.1.3 Требования к доступности ресурсов между подсистемами

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

3.4.1.4 Требования к защите данных от разрушений при авариях и сбоях, в том числе в электропитании системы

Защита данных от разрушений при авариях и сбоях, в том числе в электропитании Системы должна обеспечиваться за счет:

· дублирования / резервирования основных компонент;

· резервирования блоков питания технических средств;

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

· возможности «горячей» замены, вышедшего из строя модуля, в устройствах модульной конструкции;

· использования механизмов, обеспечивающих функциональную отказоустойчивость на программном уровне:

a. протоколы динамической маршрутизации;

b. кластеризация программно-аппаратных средств;

c. протоколы виртуального шлюза (HSRP, VRRP, GLBP);

d. организация логических связок физических интерфейсов на коммутирующем оборудовании (Ether Channel);

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

3.5 Требования к проектной документации

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

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

· Рекомендации по настройке активного оборудования, включая листинги файлов конфигурации для конкретизации способов реализации требования настоящего ТЗ.

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

· Информацию о присутствии поставщиков услуг связи на площадках Заказчика.

3.6 Требования к надежности

В тексте ГОСТа достаточно подробно описывается, что необходимо указывать в требованиях к надежности:

· состав и количественные значения показателей надежности для системы в целом или ее подсистем;

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

· требования к надежности технических средств и программного обеспечения;

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

Тем не менее, для понимания подхода к обеспечению надежности, заложенного в данном стандарте, следует изучить ГОСТы серии 27. Для начала стоит ознакомиться с терминологией: этого будет достаточно для понимания самого понятия надежности, как она измеряется и чем обеспечивается. Поэтому обращайтесь к ГОСТ 27.002-89. «Надежность в технике. Основные понятия. Термины и определения».

На выбор каких технических решений могут повлиять данные требования? Это и количество резервных мощностей (они бывают разными), и наличие технического персонала на местах, и применение не только источников бесперебойного питания, но и дизельгенераторов, а также подключение от двух независимых источников (присоединение к электросетям по I или II категории надежности).



3.7 Требования к безопасности

В данном подразделе описываются требования к технике безопасности при обращении с оборудованием (монтаже, пусконаладке и эксплуатации). Сейчас данные требования называются охраной труда и содержатся в ГОСТах 12-й серии (ССБТ -- система стандартов безопасности труда). В ТЗ достаточно привести перечень данных разделов, опять же, если кто-то собирается всерьез заниматься безопасностью.

3.8 Требования к эргономике и технической эстетике

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

3.9 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению

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



3.10 Требования к защите информации от несанкционированного доступа

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

1. Средства защиты, обеспечиваемые создаваемым программным продуктом:

· Требование по наличию пароля для пользователей, особенно для пользователей с ролью администратора.

· Реализация ролевой модели доступа.

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

· Вынесение программных компонентов, ответственных за взаимодействие с внешними системами, в демилитаризованную зону (DMZ).

· Обеспечение регистрации событий и действий пользователей.

2. Меры, обеспечиваемые системным администратором:

· Применение межсетевых экранов (файерволов).

· Документирование и мониторинг используемых служб и протоколов.

· Конфигурирование демилитаризованной зоны (DMZ).

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

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

· Настройка устройств беспроводного доступа: установка паролей и изменение настроек доступа, установленных по умолчанию.

· Установка обновлений, устраняющих выявленные уязвимости оборудования и программного обеспечения.

· Обеспечение безопасности при удаленном доступе в систему (например, использование VPN).

· Установка, обновление и мониторинг работы антивирусного программного обеспечения.

· Проведение периодического сканирования сети и сканирования после внесения важных изменений.

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

· Настройка ограничения доступа к базам данных.

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

· Настройка журналов регистрации событий.

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

3. Меры физической защиты:

· Ограничение доступа в критические помещения.

· Отключение сетевых разъемов в общедоступных местах.

· Установка камер видеонаблюдения за критически важными помещениями.

4. Общие организационные меры:

· Утверждение политики безопасности и проведение периодического обучения персонала правилам информационной безопасности.

· Внедрение процедуры реагирования на инциденты, связанные с нарушением безопасности.

· Проверка на вывод в экранных формах или отчеты конфиденциальных данных.

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

· Всесторонняя проверка принимаемых на работу сотрудников.

· Обеспечение безопасности со стороны организаций-поставщиков услуг, связанных с программным и аппаратным обеспечением.

3.11 Требования по сохранности информации при авариях

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

· потеря питания;

· выход из строя сервера;

· выход из строя устройства хранения (жесткого диска).

3.12 Требования к защите от влияния внешних воздействий

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



Заключение

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



Список литературы

1) ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

2) ГОСТ 2.103-68. Единая система конструкторской документации (ЕСКД). Стадии разработки (с Изменениями N 1, 2, с Поправкой).

3) ГОСТ 2.105-95 Единая система конструкторской документации (ЕСКД). Общие требования к текстовым документам (с Изменением N 1, с Поправками)

4) ГОСТ 2.301-68 Единая система конструкторской документации (ЕСКД). Форматы (с Изменениями N 1, 2, 3)

5) ГОСТ 6.10.4-84 Унифицированные системы документации. Придание юридической силы документам на машинном носителе и машинограмме, создаваемым средствами вычислительной техники. Основные положения

6) ГОСТ 19.201-78 Единая система программной документации (ЕСПД). Техническое задание. Требования к содержанию и оформлению (с Изменением N 1)

7) ГОСТ 27.002-89. Надежность в технике. Основные понятия. Термины и определения

Размещено на Allbest.ru

...