Организация инфраструктуры для командной разработки


Содержание

Организация командной разработки интернет-проекта

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

Какой бы сплоченной и дружной ни была команда, работа над общим проектом — это почва для потенциального конфликта. А если в команде — конфликт, проект — обречен на провал. Лебедь, рак и щука — не сдвинут повозку с места. Самый распространенный рабочий конфликт начинается с претензии: «Вы вот тут вчера правили, и у нас вот там — отвалилось». А дальше все оскорбляются и начинают выяснять отношения, национальность, гражданство, вероисповедание, пол и возраст в то время, как работа — простаивает. Думаю, такая ситуация знакома каждому.

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

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

Каждый разработчик будет работать над проектом в своей локальной копии сайта, в отдельной ветке Git для каждой решаемой задачи. В конце дня каждый разработчик делает коммит в репозиторий, хранящийся на github.com и только один разработчик — ведущий, проверяет и объединяет ветки сначала на девелоперском сайте на сервере, а потом выкатывает полученный результат на продакшен. (По моему субъективному мнению, двоевластие на интернет-проекте — недопустимо. Даже если слияние веток и тестирование будет отнимать все рабочее время ведущего разработчика проекта — никто кроме него не должен вносить изменения на продакшен — сайт) В начале дня — разработчики обновляют свои репозитории с гитхаба.

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

Итак, мы имеем выделенный сервер, два настроенных виртуальных хоста и установленное серверное ПО git — это, как правило, могут сделать для нас сотрудники хостинга, на котором мы покупаем сервер.

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

Регистириуем корпоративный тариф на github.com Для системы, рассмотренной в данной статье, нам хватит тарифа за 25$ в месяц. Заводим приватный репозиторий, добавляем существующих пользователей githab к организации (или заводим новых пользователей) — это все делается очень прозрачно и удобно, поэтому не будем подробно заостряться на этом моменте.

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

Заходим по ssh на наш сервер под пользователем с правами на запись в папки сайтов, переходим в директорию, в которой мы намерены инициировать репозиторий.

Репозиторий можно инициировать непосредственно в папке сайта (тогда важно не забыть потом защитить папку .git в файле .htaccess от скачивания), а можно инициировать его в наддиректории (вариант, когда файлы каждого сайта лежат не сразу в директории www или директории dev, а в подкатологе, к примеру, dev/httpfiles, www/httpfiles А репозитории мы инициируем соответственно в директориях www и dev. Если сервер настраивается с нуля или если админу не лень перепрописать виртуальные хосты— этот вариант предпочтительнее).

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

Пример файла .gitignore для 1С-Битрикс для случая, когда репозиторий инициируется в директории сайта:

Пример файла .gitignore для 1С-Битрикс для случая, когда репозиторий инициируется в наддиректории:

То есть мы не будем контролировать изменения в папке бекапов (/bitrix/backup), папках кеша (/bitrix/cache, /bitrix/managed_cache, /bitrix/managed_flags, /bitrix/stack_cache), папках с заданиями крону (/bitrix/crontab), папке с логами (/logs), папке с загрузками (/upload).
Папку с загрузками /upload на всех девелоперских копиях сайта, расположенных на одном с ним сервере, имеет смысл делать симлинком на папку /upload продакшен-сайта.

Символическую ссылку в директории /dev/ — корневой директории девелоперского сайта создаем командой

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

Файл /bitrix/php_interface/dbconn.php содержит индивидуальные для каждого виртуального хоста настройки (в частности настройки соединения с БД), поэтому этот файл мы добавляем в исключения git.

Файл /urlrewrite.php — это файл с правилами обработки ЧПУ адресов Битрикс — он может быть перезаписан (сортируется внутри) самим движком, поэтому исключим и его.

Файлы .gitignore и .htaccess тоже должны лежать в исключениях. В исключения так же стоит добавить файлы логов, текстовые файлы, xml-файлы – все то, что не относится непосредственно к программному коду.

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

email можно вписать любой, но с email вида bitrix@имя.сайта легче идентифицировать ключ на гитхабе.

Переходим на github.com/settings/ssh и добавляем новый ключ — данные самого ключа берём из файла /path/to/.ssh/id_rsa.pub

Инициируем репозиторий в директории основного сайта (или в наддиректории):
переходим в /path/to/www/ и выполняем команды:

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

Теперь клонируем репозиторий в директорию девелоперского сайта:

После этого в директории девелоперского сайта создадим символическую ссылку на папку upload как было описано выше. Затем стандартными средства Битрикс сделаем бекап БД основного сайта, и развернем его на девелоперском — файл, хранящий подключение к БД при этом создастся для дев сайта автоматически.

Теперь аналогичным образом можно создать клоны репозитория на локальных машинах разработчиков. Для этого им необходимо поставить любой комплект ПО git на свою локальную машину (командная Git строка идет в любом комплекте), запустить командную строку, сгенерировать ключ, добавить его на гитхаб, клонировать репозиторий в директорию виртуального хоста на локальной машине, а папку upload просто слить с основного сайта, накатить дамп БД с основного сайта.

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

Варианты IT-инфраструктуры организации

Несмотря на поговорку, дым без огня всё-таки бывает, но виртуальная среда без материального оборудования — никогда. Методы виртуализации помогают использовать оборудование эффективнее и удобнее.

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

Что требуется организации

Компьютерное оборудование редко требуется конечным потребителям само по себе. Оно нужно им для решения конкретных прикладных задач: учёта каких-то данных, обработки изображений или видеофайлов, инженерных или научных расчётов и т. д.

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

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

Что обеспечивает ЦОД

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

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

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

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

Конечно, ещё требуется обеспечить сетевое соединение оборудования, размещённого в ЦОД’е, с интернетом, но эту задачу на практике может решить как владелец ЦОД’а, так и арендатор места или оборудования.

Варианты инфраструктуры

Итак, с учётом сказанного рассмотрим, какие варианты получения вычислительных ресурсов есть у конечного потребителя.

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

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

Квази-ЦОД

По мере роста организации и увеличения числа используемых серверов может возникнуть желание завести свой собственный мини-ЦОД — «серверную» в отдельном помещении. В нём потребуется обеспечить надёжное бесперебойное электропитание и кондиционирование воздуха.

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

Сегодня создавать свой «домашний» ЦОД с нуля — затея крайне неразумная.

Собственный ЦОД

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

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

Провайдерский ЦОД

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

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

Компьютерное облако


Оборудование в ЦОД’е можно использовать напрямую, так сказать, материально. А можно развернуть на нём виртуальную среду, которую и принято называть компьютерным облаком.

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

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

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

Заключение

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

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

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

Техническая команда для разработки сложного проекта

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

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

Состав команды и роли участников

Специализация Загрузка Обязанности
Руководитель проекта 50% Промежуточное звено между командой и клиентом. Переводит пожелания клиента на язык программистов и наоборот. Координирует скорость и качество выполнения работы. На начальном этапе разрабатывает техническое задание, включающее мокапы будущего проекта. Как правило, менеджер студии, разработавший ТЗ проекта, в дальнейшем управляет разработкой.
Back-end разработчик 100% Отвечает за серверную часть проекта. Как правило, в студийных командах разработки является старшим программистом на проекте.
Front-end разработчик 100% Отвечает за внешнюю часть проекта: верстку, клиентское программирование, оптимизацию производительности.
Мобильный разработчик 100% Разработка под мобильные платформы (iOS, Android, Windows Phone), если проект подразумевает наличие мобильной части.
Дизайнер 20%..50% Занимается созданием фирменного стиля, проектированием и отрисовкой интерфейсов на основе мокапов из основного ТЗ проекта. Дизайнеры студии используют облегченный подход к дизайну, обоснованному сложностью проектов и интерфейсов. Минимум цветов и украшательства, максимум простоты и скорости работы.
Тестировщик 10%..50% Подключается по необходимости по завершению релиза и перед запуском релиза на широкую аудиторию. Для полноты тестирования мы подключаем от 2-3 тестировщика на проект.
Системный администратор 10% Настраивает серверы, резервное копирование и средства безопасности на сервере.
Контент-менеджер или журналист 50%..100% Подбирает или пишет материалы соответственно тематике проекта и плану продвижения.
Маркетолог 50%..100% Ищет каналы привлечения пользователей проекта, формирует первичные каналы продвижения, занимается поиском партнеров.

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

Чаще всего мы делаем разработку сложных веб-проектов. Оптимальный состав команды для разработки веб-проекта:

  • Руководитель проекта (менеджер).
  • Back-end разработчик.
  • Front-end разработчик.
  • Дизайнер.
  • Тестировщики.
  • Системный администратор.

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

Масштабирование

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

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

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

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

Работа технических команд студии строится таким образом, чтобы максимально сократить расходы клиента.

Риски и их устранение

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

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

Типовые технические риски стартапа:

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

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

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

Организация инфраструктуры для командной разработки

СПОСОБЫ ОРГАНИЗАЦИИ КОМАНДНОЙ РАБОТЫ НАД ПРОЕКТАМИ

Караваев Вадим Юрьевич

студент 4 курса кафедры «Автоматизированных систем управления» Московского государственного университета приборостроения и информатики, филиал, РФ, г. Ставрополь

Авакян Тамара Ашотовна

научный руководитель, доцент кафедры «Автоматизированных систем управления» Московского государственного университета приборостроения и информатики, филиал, РФ, г. Ставрополь

При работе над достаточно крупными проектами с участием нескольких человек, неизбежно встает вопрос об организации эффективного рабочего процесса. Стоит сказать о некоторых характеристиках проекта, о котором упоминается в статье: тип — онлайн игра, два модуля — клиентская часть на Unity Engine, и серверная часть на NET. Framework 4.5, в общей сложности 20 тысяч строк кода на C#, несколько сотен графических файлов в различных форматах, несколько десятков звуковых файлов и большое количество других типов данных.

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

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

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

· Возможность контролировать кто, когда и с какой целью внес изменения в проект — каждое или несколько изменений в проекте фиксируется определенным образом. Эта фиксация называется коммит. Каждый коммит хранит в себе информацию о том, какие файлы были изменены с предыдущей версии, когда и кем была совершена фиксация, а так же сообщение фиксации, введенное разработчиком (Рисунок 1). Это сообщение обычно хранит краткую информацию о том, какая работа была произведена с момента предыдущей фиксации. Типичные сообщения коммитов — «добавлен модуль управления базой данных», «багфиксы в основном модуле сервера», «улучшена производительность парсера JSON» и т. д.

Рисунок 1. Список коммитов проекта

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

· Простое и быстрое резервное сохранение данных на сервере. И снова, за счет того что на сервер передается только дельта, а это сравнительно небольшое количество информации по сравнению с общим объемом проекта, возникает выигрыш в количестве передаваемых данных, и как следствие времени на такие передачи.

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

Примеры систем контроля версий — Git, Team Foundation Server, Mercury, SVN. На сегодняшний момент самой распространенной является Git (Рисунок 2). Проект был начат Линусом Торвальдсом, и изначально предназначался для управления разработкой ядра Linux, где и зарекомендовал себя надежной системой отлично подходящей для контроля разработки даже самых крупных проектов [3, с. 123].

Рисунок 2. Консоль управления Git

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

Хранение удаленных репозиториев, решает проблему с хранением и резервированием исходных данных. Даже если проект хранился в единственном экземпляре у одного из разработчиков и был вследствие непредвиденных обстоятельств утерян, копия этого проекта всегда будет находиться на удаленном сервере. Также можно организовать хранение репозиториев на локальном сервере при помощи соответствующих программных средств. Например, если сервер находится под управлением ОС семейства Windows, хорошим выбором является Bonobo Git Server.

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

Трекер задач — система для отслеживания задач возникающих в проекте (Рисунок 3). В трекере можно создавать записи, включающая в себя следующую информацию о задачах — название, описание, кто создал задачу, кому адресовано ее выполнение, тип, приоритет задачи (trivial, minor, major, critical, blocker). Обычно задачи могут предлагаться всеми участниками проекта, однако утверждать их к обязательному исполнению вправе только руководитель. Задачи с наибольшим приоритетом должны выполняться в первую очередь. Довольно часто трекер задач так же совмещает в себе функции багтрекера, в таком случае задаче присваивает тип bug. Задачи типа bug с приоритетом critical и выше, обычно решаются без утверждения руководителя.

Рисунок 3. Список задач на Bitbucket

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

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

4. Документация по коду. Даже если в команде всего один программист, код обязательным образом должен быть хорошо прокомментирован. Однако комментариев не должно быть слишком много, это тормозит рабочий процесс, и, как это не парадоксально, часто даже затрудняет чтение кода. Общее правило таково — один комментарий на блок из нескольких строк кода выполняющих определенную функцию. Число таких строк от 5до 20. Для комментирования методов и типов, в языке C# имеется механизм XML-комментирования. При компиляции проекта все комментарии выполненные таким образом собираются в отдельный XML-файл, а в IDE такой файл будет использован для средств Intellisense [1, с. 278]. Также на основе этого XML-файла в последующем можно будет сгенерировать отдельный файл документации при помощи сторонних программных средств, например Sandcastle. Сгенерированная документация может быть в форматах DOC, PDF, CHM, Html страниц.

5. Грамотная структура проекта. Исходники проекта должны быть грамотно структурированы. Общепринятым стандартом для проектов на Unity является следующая структура папок: Textures — для файлов текстур, Scripts — для файлов исходных кодов, Interface — для графических файлов интерфейса, Models — для 3D моделей, Sprites — для 2D спрайтов, Sounds — для звуков в игре, Music — для саундтрека, Extras — для подключаемых плагинов и остальных типов данных [2]. Все файлы проекта должны иметь английские названия, так как английский язык давно стал стандартом де-факто в среде разработчиков. Такой подход позволяет свободно ориентироваться в проекте носителю любого языка, и на корню решает все проблемы с кодировкой при использовании любых инструментальных средств.

1.Рихтер Д. CLR via C#. Программирование на платформе Microsoft .NET Framework 4.5 на языке C#. 4-е изд. СПб.: Питер, 2015. — 896 с.: ил.

2.Руководство Unity // Официальный сайт Unity Engine [Электронный ресурс] — Режим доступа. — URL: http://docs.unity3d.com/ru/current/Manual/UnityManualRestructured.html (дата обращения 03.03.2015).


3.Чакон С. Pro Git. 2-е изд. New York.: Apress, 2014. — 456 с.

Сетевая инфраструктура: основные сведения, объекты и проектирование

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

Программные приложения и услуги

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

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

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

Пространственная протяженность сетей

Часто сети различаются по пространственной протяженности. Так обычно называют LAN (Local Area Network) — это локальная сеть, которая включает в себя множество компьютеров и периферийных устройств внутри здания. Однако на практике бывает, что такая сеть может принимать довольно большое количество пользователей. Независимо от ее размера, сеть всегда будет называться локальной сетью, даже если она является общедоступной и частной. С другой стороны, если сеть охватывает сравнительно большую географическую область, она называется глобальной сетью (WAN).

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

Наиболее широко используется стандартное решение Ethernet. В то же время передача предпочтительно выполняется электрически через соответствующие кабели с витой парой (кабель CAT 5 или выше), но он также может быть выполнен оптически через волоконно-оптический кабель и кабель из волокна (полимерные оптические волокна, POF).

В настоящее время Ethernet достигает скорость передачи данных 100 Гбит/с, что соответствует общей пропускной способности данных не более 12,5 ГБ/с, стандарты для 200 Гбит/с и 400 Гбит/с . В зависимости от расстояния до моста и требуемой скорости соединения Ethernet могут быть установлены с помощью медных кабелей (витая пара категории 3 с витой парой категории 8) или с помощью оптических соединительных линий.

Процесс строительства IT-инфраструктуры

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

  1. Анализ бизнес- и технических требований.
  2. Проектирование логической архитектуры.
  3. Проектирование архитектуры развертывания.
  4. Внедрение развертывания.
  5. Управление развертыванием.

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

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

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

  1. Архитектура развертывания.
  2. Спецификация реализации.
  3. Детальная спецификация дизайна.
  4. План установки.
  5. Дополнительные планы.

Процесс развертывания сети

Для планирования развертывания необходимо сначала проанализировать бизнес-требования и технические требования заказчика. Они должны содержать следующие разделы:

  1. Определение целей развертывания.
  2. Определение целей проекта.

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

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

  1. Бизнес-требования.
  2. Технические требования.
  3. Финансовые требования.
  4. Соглашения об уровне обслуживания (SLA).

Компоненты службы и уровни обслуживания

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

Многоуровневая архитектура, будь то одноуровневая или двухуровневая, обеспечивает ряд преимуществ. Ее компоненты находятся на клиентских компьютерах конечных пользователей. Уровень доступа компонентов состоят из интерфейсных служб от Messaging Server (MMP и MTA):

  1. Сервер календаря.
  2. Мгновенный обмен сообщениями (Instant Messaging Proxy).
  3. Сервер портала (SRA и Core).
  4. Access Manager для аутентификации и корпоративный каталог, который предоставляет адресную книгу.
  5. Сеть хранения данных (SAN)«Облако» представляет собой физическое хранилище данных.

Определение ресурсоемкости проекта

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

  1. Физические линии связи, такие как длина кабеля, класс и т. д.
  2. Коммуникационные линии, такие как аналоговые, ISDN, VPN, T3 и т. д., а также доступная пропускная способность и латентность между сайтами.
  3. Информация о сервере, включая имена хостов, IP-адреса, сервер доменных имен (DNS) для членства в домене.
  4. Расположение устройств в сети, в том числе концентраторы, выключатели, модемы, маршрутизаторы, мосты, прокси-серверы.
  5. Количество пользователей на каждом сайте, включая мобильных пользователей.

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

Компоненты сетевой инфраструктуры

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

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

  1. Маршрутизаторы и коммутаторы.
  2. Брандмауэры.
  3. Балансиры нагрузки.
  4. Сеть хранения данных (SAN) DNS.

Технические требования к сети

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

  1. Может ли DNS-сервер справляется с дополнительной нагрузкой?
  2. Каков график работы персонала поддержки? 24-часовая, семидневная (24 х 7) поддержка может быть доступна только на определенных сайтах. Более простая архитектура с меньшим количеством серверов будет проще поддерживать.
  3. Существует ли достаточная емкость в операциях и группах технической поддержки для облегчения эксплуатации сетевой инфраструктуры?
  4. Могут ли операции и группы технической поддержки справляться с повышенной нагрузкой во время фазы развертывания?
  5. Нужно ли обеспечить избыточность сетевых сервисов?
  6. Требуется ли ограничить доступность данных на хостах уровня доступа?
  7. Нужно ли упрощение настройки конечного пользователя?
  8. Планируется ли уменьшение сетевого HTTP-трафика?

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

Выбор оборудования

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

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

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

  1. Дерево информации каталога LDAP.
  2. Сервер каталогов (Access Manager).
  3. Сервер обмена сообщениями.


Управление доступом к брандмауэру

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

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

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

Внутренняя сеть

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

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

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

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

Создание систем безопасности

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

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

Пять шагов по разработке стратегии безопасности включают:

  1. Определение того, что нужно защитить. Например, этот список может включать в себя оборудование, программное обеспечение, данные, людей, документацию, сетевую инфраструктуру или репутацию организации.
  2. Определение того, от кого нужно защититься. Например, от неавторизованных пользователей, спамеров или атак на отказ в обслуживании.
  3. Оценку возможных угроз для системы.
  4. Реализацию мер, которые будут эффективно защищать активы.
  5. Дополнительные накладные расходы при настройке SSL-соединения, которые смогут снизить нагрузку на развертывание сообщений.

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

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

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

Мероприятия по управлению сетевой инфраструктурой предприятия включают:

  1. Службы облачной оценки.
  2. Планирование мощности и производительности.
  3. Консолидацию и виртуализацию центров обработки данных.
  4. Интегрированные решения Hyper Converged.
  5. Управление сервером и сетью. Управление ИТ-услугами, поддержку и программное обеспечение.

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

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

6 ключевых ролей в команде разработки программного обеспечения

22 Сентября, 2020

Имидж профессионалов IT сферы в массовой культуре кардинально изменился за последние годы. Абсурдные стереотипы ушли в прошлое, а программисты стали настоящей элитой 2010-х.

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

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

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

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

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

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

Но между целями клиента и функциями приложения лежит целая пропасть. Следовательно, бизнес-аналитик (сокращенно БA) должен точно определить, что хочет заказчик и что ему нужно.

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

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

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

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

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

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

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

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

Это тот человек, от которого идет большая часть креативности в проекте. Главная ответственность UI/UX дизайнера заключается в создании приятного интерфейса и отличного пользовательского опыта.

Дизайнер использует вайрфреймы, созданные клиентом или бизнес-аналитиком, чтобы “нарисовать” мокапы и создать дизайн интерфейса мобильного приложения (UI) согласно действующим гайдлайнам и трендам. Он также планирует пользовательский опыт, который сделает продукт удобным для использования.

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

Клиенту удобно видеть модель приложения, а программистам прототип просто необходим, чтобы написать код. Это как дизайн-проект комнаты для профессионалов, которые будут её декорировать — необходимо видеть, что должно получиться в результате работы. Наши дизайнеры в Smartum Pro также предоставляют графические элементы для магазинов приложений, мокапы и логотипы.

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

Существуют различные уровни в команде разработчиков программного обеспечения, включающие junior, middle и senior уровни, которые зависят от опыта работы и уровня экспертизы.

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

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

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

Специалист по маркетингу

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

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

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

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

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

Разработка инфраструктуры корпоративной сети

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 12.01.2014
Размер файла 490,4 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже


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

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

Разработка инфраструктуры корпоративной сети

1. Анализ требований ТЗ

Корпорация имеет главный офис (здание А) и два филиала:

производство продукции Manufacture (M) — здание B;

Структура подразделений корпорации CorpXYZ

Функциональные службы корпорации в головном здании А расположены следующим образом:

1 этаж. Подразделения корпорации:

отдел кадров и подготовки специалистов Human Resource (HR);

отдел маркетинга Marketing (M);

служба информационных технологий и технической поддержки Information Technologies (IT).

2 этаж. Подразделения:

руководство корпорацией Executive (E);

бухгалтерия Accounting (Acc);

отдел экономики и планирования Business (Bus).

На 3, 4, и 5 этажах расположено проектное отделение, при этом:

3 этаж. Проектный отдел Project 1 (P1);

4 этаж. Проектный отдел Project 2 (P2);

5 этаж. Проектный отдел Project 3 (P3).

Каждый проектный отдел имеет свой конфиденциальный сервер приложений.

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

В одноэтажном здании В филиала производятся изделия двух типов, одно из них на площадях М1, другое — на площадях М2. Кроме того, имеется автоматизированный склад готовой продукции Production (P). Филиал Manufacture (M) (здание В) расположен в другом городе, удаленном на значительное расстояние, и соединен с главным офисом каналом Т1. Филиал Research (здание С) связывается с главным офисом через Internet c использованием SitetoSite VPN IPSec. В двухэтажном здании С отдел Research занимает два этажа, при этом на 1 этаже расположена рабочая группа Research 1 (R1), на 2 этаже группа Research 2 (R2).

В каждом офисе имеются небольшие ЛВС, которые будут объединены в единую корпоративную сеть. В качестве рабочих станций используются компьютеры с установленными ОС WinXP Prof, W2000 Prof, MS Vista. В ближайшие 12-18 месяцев планируется переход части клиентов отдела маркетинга и руководства корпорацией на новые ОС семейства MS Win7. Руководство компании решило принять в качестве базовой сетевой операционной системы MS Windows Server 2008 и готово использовать избыточное сетевое оборудование.

Несколько групп сотрудников работают в Европе в своих домашних офисах SOHO, подключающихся к главному офису по каналам VPN. Максимальное число компьютеров в SOHO не более 5. Кроме того, имеется небольшой штат сотрудников корпорации, которые соединяются с главным офисом по Internet.

Схема расположения корпорации CorpXYZ

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

Базовой технологией сети является Ethernet по стандарту 100/1000BASE-T и FDDI.

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

Для внешних IP_интернет адресов корпорации в целом (головное здание и филиалы) используется следующий диапазон адресов (Public_IP) 225.46.11.0/24.

Для диапазона внутренних адресов (Private_IP) используются:

— для головного здания А диапазон адресов 10.101.0.0/16,

— для здания В адреса 172.22.40.0/22,

— для здания С адреса 192.168.88.0/21,

Исходные числовые данные курсовой работы приведены в таблицах 1, 2, 3, 4, 5 и 6.

В таблице 1 задано поэтажное расположение рабочих групп и количество рабочих станций трёх проектных отделов в здании А.

Распределение рабочих групп в здании А

Число рабочих групп (комнат)

Число раб. станций в гр., не более

Число рабочих групп

Число раб. ст. в группе, не более

Число рабочих. групп

Число раб. станций.

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

Распределение рабочих групп в здании В

Число рабочих групп (комнат)

Число раб. станций в группе, не более

В таблице 3 заданы поэтажное число групп и рабочих станций в здании С филиала Research

Распределение рабочих групп в здании С

Число рабочих групп (комнат)

Число рабочих станций в группе, не более

Число раб. групп

Число раб. станций, не более

В таблице 4 представлены данные общекорпоративных служб.

Распределение общекорпоративных служб

Human Resource, IT gr., Sales Manag.

Число рабочих групп (комнат)

Число рабочих станций в группе, не более

Число раб. станций

Число раб. ст. в раб. гр.


Также необходимо детально проработать реализацию соответствующих частей WLAN/EAP-2 инфраструктуры корпоративной сети с использованием оборудования DLink, включая его настройку, а так же конфигурирование серверов WS2008 и операционных систем рабочих станций пользователей.

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

— в качестве службы каталогов корпоративной сети использовать Active Directory;

— предоставить доступ к размещенным в головном офисе Web, FTPи MX серверам корпорации CorpPAA как пользователям Интернета, так и пользователям внутренней корпоративной сети (intranet) в любое время в любой день недели;

— изолировать корпоративную сеть от Интернета, Web, FTPи MX серверов;

— изолировать внутреннее пространство имен;

— защитить все данные, пересылаемые между головным офисом и филиалом Research;

— каждое подразделение должно иметь свой конфиденциальный сервер приложений;

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

— обеспечить защиту конфиденциальных данных при пересылке через Интернет с использованием VPN;

— обеспечить защищенные подключения к корпоративной сети удаленных пользователей по телефонным линиям ADSL;

— обеспечить защиту беспроводных сетей WLAN;

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

— обеспечить проведение аудита и видеоконференций (*);

— предусмотреть меры по снижению сетевого трафика, вызываемого потоковыми аудио и видеоконференциями (*);

— выполнить оценку стоимости закупки сетевого оборудования, включая стоимость сопутствующих программных продуктов (ПО);

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

2. Проектирование логической структуры сети

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

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

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

— обеспечение маршрутизации, качества обслуживания и безопасности сети;

— агрегирование адресов;

— переход от одной технологии к другой (например, от 100Base-TX к 1000Base-T);

— объединение полос пропускания низкоскоростных каналов доступа в высокоскоростные магистральные каналы.

Уровень доступа управляет доступом пользователей и рабочих групп к ресурсам объединенной сети. Основной задачей уровня доступа является создание точек входа / выхода пользователей в сеть. Уровень выполняет следующие функции:

— продолжение (начиная с уровня распределения) управления доступом и политиками сети;

— создание отдельных доменов коллизий (сегментация);

— подключение рабочих групп к уровню распределения;

— уровень доступа использует технологию коммутируемых локальных сетей.

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

При выборе технологии построения локальной сети необходимо учитывать то, что во многих случаях проектируемая сеть должна быть приспособлена к имеющейся кабельной системе. Согласно ТЗ на данный момент в зданиях компании существует кабельная система, состоящая из UTP-5 (для технологии 100BASE-TX). Эта система должна быть использована для соединения сетевой розетки на рабочем месте сотрудника и коммутатора на этаже. Стандарт EIA/TIA-568 допускает использование в вертикальной подсистеме многомодового оптоволоконного кабеля (62.5/125 мкм). Для обеспечения возможности будущего роста проектируемой сети в вертикальной подсистеме целесообразно применение технологии 1000Base-SX. Для данного стандарта дальность прохождения сигнала без повторителя достигает 500 м, что для проектируемой сети будет вполне достаточно. Использование в вертикальной подсистеме 10-гигабитного Ethernet является нецелесообразным, поскольку при этом значительно увеличивается стоимость оборудования, и, кроме того, такая скорость будет излишней.

Таким образом, будем реализовывать такую структуру сети, при которой на каждом этаже будет располагаться стек коммутаторов уровня доступа. Поскольку на некоторых этажах располагается несколько отделов, то необходимо использовать технологию VLAN. Для объединения горизонтальных подсистем этажей будем использовать гигабитный коммутатор, поддерживающий технологию 1000BASE-SX. Для повышения надежности на уровне распределения будем использовать резервирование коммутаторов. Связь будет осуществляться по принципу «каждый с каждым». Поскольку при данной организации в сети могут возникнуть кольца, следует использовать протокол STP.

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

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

3. Распределение VLAN’ов

Для управления устройствами

Для внешних серверов

Отдел маркетинга (1 группа)

Отдел маркетинга (2 группа)

Отдел информ. технологий

Проектный отдел 1

Проектный отдел 2

Проектный отдел 3

Отдел разработок 1

Отдел разработок 2

Каждый отдел будет выделен в отдельный VLAN. Таким образом мы ограничим широковещательные домены. Также введём специальный VLAN для управления устройствами. Номера VLAN c 4 по 100 зарезервированы для будущих нужд.

План распределения IP-адресов будет приведен далее.

Проектирование физической структуры сети

Описание структурированной кабельной сети


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


Размещение коммутационного оборудования на этажах


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


Требование к оборудованию и линиям связи


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

между пользователем и соответствующим коммутатором 2 уровня скорость передачи данных должна быть не ниже 100 Mbit/s, следовательно, на уровне доступа логично использовать линии связи стандарта 100Base-TX;

— между коммутатором уровня доступа и коммутатором уровня распределения (коммутатор 3 уровня) скорость передачи данных должна быть не ниже 1000 Mbit/s для обеспечения передачи большого сетевого трафика, в данном случае логично использовать оптические линии связи по стандарту 1000Base-LX;

— между коммутаторами уровня распределения и другими устройствами (маршрутизаторы, брандмауэры) также будет использована оптическая линия связи по стандарту 1000Base-LX;

— между зданием A и B, и между зданием А и интернет провайдером реализован канал T1;

— остальные линии реализованы посредством телефонных линий связи;


— в отделе маркетинга и на складе(Production) реализован беспроводной канал связи.

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

Выбор сетевого оборудования


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


При выборе конкретной модели будем руководствоваться следующими критериями.


— количество портов;


— скорость работы;


— поддерживаемые технологии;


— поддерживаемые типы кабелей.


4. Уровень доступа

Для уровня доступа используем коммутаторы DLink серии DES-3500. Управляемые коммутаторы этой серии обладают большим функционалом и позволяют решать все необходимые задачи для уровня доступа корпорации CorpPAA.

Коммутаторы серии 10/100 Мбит/с D-Link DES-3500 являются взаимно стекируемыми коммутаторами уровня доступа, поддерживающими технологию Single IP Management (SIM, управление через единый IP-адрес). Эти коммутаторы, имеющие 24 или 48 10/100BASE-TX портов и 2 комбо порта 1000BASE-T/SFP Gigabit Ethernet в стандартном корпусе для установки в стойку, разработаны для гибкого и безопасного сетевого подключения. Коммутаторы серии DES-3500 могут легко объединяться в стек и настраиваться вместе с любыми другими коммутаторами с поддержкой D-Link Single IP Management, включая коммутаторы 3-го уровня ядра сети, для построения части многоуровневой сети, структурированной с магистралью и централизованными быстродействующими серверами.

В основном, коммутаторы серии DES-3500 формируют стек сети уровня подразделения, предоставляя порты 10/100 Мбит/с и возможность организации гигабитного подключения к магистрали. Трафик, передаваемый между устройствами стека, проходит через интерфейсы Gigabit Ethernet с поддержкой полного дуплекса и обычные провода сети, позволяя избежать использования дорогостоящих и громоздких кабелей для стекирования. Отказ от использования этих кабелей позволяет устранить барьеры, связанные с их длиной и ограничениями методов стекирования. В стек могут быть объединены устройства, расположенные в любом месте сети, исключая возможность появления любой точки единственного отказа (single point of failure).

В стек можно легко объединить до 32-х коммутаторов, независимо от модели. Виртуальный стек поддерживает любые модели коммутаторов со встроенным Single IP Management. Это означает, что стек может быть расширен коммутаторами, включая коммутаторы 3-го уровня для ядра сети, коммутаторы на основе шасси или любые другие коммутаторы.

Серия DES-3500 обеспечивает расширенный набор функций безопасности для управления подключением и доступом пользователей. Этот набор включает Access Control Lists (ACL) на основе МАС-адресов, портов коммутатора, IP адресов и / или номеров портов TCP/UDP, аутентификацию пользователей 802.1х и контроль МАС-адресов. Помимо этого, DES-3500 обеспечивает централизованное управление административным доступом через TACACS+ и RADIUS. Вместе с контролем над сетевыми приложениями, эти функции безопасности обеспечивают не только авторизованный доступ пользователей, но и предотвращают распространение вредоносного трафика по сети.

Для повышения производительности и безопасности сети коммутаторы серии DES-3500 обеспечивает расширенную поддержку VLAN, включая GARP/GVRP, 802.1Q и асимметричные VLAN. Ассиметричные VLAN будут использоваться для доступа к конфиденциальным серверам отделов. Управление полосой пропускания позволяет установить лимит трафика для каждого порта, что дает возможность управлять объемом трафика на границе сети.

В серии DES-3500 для проектируемой сети будем использовать модели коммутаторов DES-3550 (48 портов 10/100BASE-TX, 2 комбо-порта 1000BASE-T/ MiniGBIC (SFP)) и DES-3526 (24 порта 10/100BASE-TX, 2 комбо-порта 1000BASE-T/ MiniGBIC (SFP)). Поскольку в проектируемой сети в вертикальной подсистеме будет использоваться технология 1000BASE-SX, в коммутаторы необходимо будет установить трансивер MiniGBIC DEM-311GT с 1 портом 1000BASE-SX для многомодового оптического кабеле.

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

План построения ИТ-инфраструктуры

Предпроектная стадия

  • Выбор решения.
  • Аудит инфраструктуры.
  • Разработка технико-экономического обоснования:
    • Анализ затрат и результатов проекта.
    • Обоснование деятельности.
    • Экономическое обоснование: расчеты финансовых показателей деятельности по результатам проекта.
    • Выводы и предложения – экономическая оценка целесообразности и перспектив внедрения проекта.
  • ИТ-стратегия.

Проектная деятельность

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

Постпроектная стадия

  • Полное покрытие всех часовых поясов, режим работы 24×7.
  • Обслуживание всей инфраструктуры заказчика или ее частей.
  • Решение задач на стыке производителей.
  • Поддержка через интернет, по круглосуточному телефону или электронной почте.

ИТ-аутсорсинг службы эксплуатации:

  • Обеспечение доступности ИТ-услуг.
  • Онлайн-контроль работоспособности сервисов.
  • Администрирование и мониторинг инфраструктурных и прикладных сервисов.
  • Персональный технический менеджер.
  • Авторизованное ИТ-обучение от вендора.
  • Международные сертификаты для ИТ-специалистов и пользователей в центрах тестирования.
  • Авторские и адаптированные курсы.
  • Бизнес-тренинги.
  • Широкая сеть представительств по России и СНГ.

Сетевая инфраструктура: основные сведения, объекты и проектирование

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

Программные приложения и услуги

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

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

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

Пространственная протяженность сетей

Часто сети различаются по пространственной протяженности. Так обычно называют LAN (Local Area Network) — это локальная сеть, которая включает в себя множество компьютеров и периферийных устройств внутри здания. Однако на практике бывает, что такая сеть может принимать довольно большое количество пользователей. Независимо от ее размера, сеть всегда будет называться локальной сетью, даже если она является общедоступной и частной. С другой стороны, если сеть охватывает сравнительно большую географическую область, она называется глобальной сетью (WAN).

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

Наиболее широко используется стандартное решение Ethernet. В то же время передача предпочтительно выполняется электрически через соответствующие кабели с витой парой (кабель CAT 5 или выше), но он также может быть выполнен оптически через волоконно-оптический кабель и кабель из волокна (полимерные оптические волокна, POF).

В настоящее время Ethernet достигает скорость передачи данных 100 Гбит/с, что соответствует общей пропускной способности данных не более 12,5 ГБ/с, стандарты для 200 Гбит/с и 400 Гбит/с . В зависимости от расстояния до моста и требуемой скорости соединения Ethernet могут быть установлены с помощью медных кабелей (витая пара категории 3 с витой парой категории 8) или с помощью оптических соединительных линий.

Процесс строительства IT-инфраструктуры

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

  1. Анализ бизнес- и технических требований.
  2. Проектирование логической архитектуры.
  3. Проектирование архитектуры развертывания.
  4. Внедрение развертывания.
  5. Управление развертыванием.


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

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

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

  1. Архитектура развертывания.
  2. Спецификация реализации.
  3. Детальная спецификация дизайна.
  4. План установки.
  5. Дополнительные планы.

Процесс развертывания сети

Для планирования развертывания необходимо сначала проанализировать бизнес-требования и технические требования заказчика. Они должны содержать следующие разделы:

  1. Определение целей развертывания.
  2. Определение целей проекта.

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

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

  1. Бизнес-требования.
  2. Технические требования.
  3. Финансовые требования.
  4. Соглашения об уровне обслуживания (SLA).

Компоненты службы и уровни обслуживания

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

Многоуровневая архитектура, будь то одноуровневая или двухуровневая, обеспечивает ряд преимуществ. Ее компоненты находятся на клиентских компьютерах конечных пользователей. Уровень доступа компонентов состоят из интерфейсных служб от Messaging Server (MMP и MTA):

  1. Сервер календаря.
  2. Мгновенный обмен сообщениями (Instant Messaging Proxy).
  3. Сервер портала (SRA и Core).
  4. Access Manager для аутентификации и корпоративный каталог, который предоставляет адресную книгу.
  5. Сеть хранения данных (SAN)«Облако» представляет собой физическое хранилище данных.

Определение ресурсоемкости проекта

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

  1. Физические линии связи, такие как длина кабеля, класс и т. д.
  2. Коммуникационные линии, такие как аналоговые, ISDN, VPN, T3 и т. д., а также доступная пропускная способность и латентность между сайтами.
  3. Информация о сервере, включая имена хостов, IP-адреса, сервер доменных имен (DNS) для членства в домене.
  4. Расположение устройств в сети, в том числе концентраторы, выключатели, модемы, маршрутизаторы, мосты, прокси-серверы.
  5. Количество пользователей на каждом сайте, включая мобильных пользователей.

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

Компоненты сетевой инфраструктуры

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

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

  1. Маршрутизаторы и коммутаторы.
  2. Брандмауэры.
  3. Балансиры нагрузки.
  4. Сеть хранения данных (SAN) DNS.

Технические требования к сети

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

  1. Может ли DNS-сервер справляется с дополнительной нагрузкой?
  2. Каков график работы персонала поддержки? 24-часовая, семидневная (24 х 7) поддержка может быть доступна только на определенных сайтах. Более простая архитектура с меньшим количеством серверов будет проще поддерживать.
  3. Существует ли достаточная емкость в операциях и группах технической поддержки для облегчения эксплуатации сетевой инфраструктуры?
  4. Могут ли операции и группы технической поддержки справляться с повышенной нагрузкой во время фазы развертывания?
  5. Нужно ли обеспечить избыточность сетевых сервисов?
  6. Требуется ли ограничить доступность данных на хостах уровня доступа?
  7. Нужно ли упрощение настройки конечного пользователя?
  8. Планируется ли уменьшение сетевого HTTP-трафика?

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

Выбор оборудования

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

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

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

  1. Дерево информации каталога LDAP.
  2. Сервер каталогов (Access Manager).
  3. Сервер обмена сообщениями.

Управление доступом к брандмауэру

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

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

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

Внутренняя сеть

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

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

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

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

Создание систем безопасности

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

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

Пять шагов по разработке стратегии безопасности включают:

  1. Определение того, что нужно защитить. Например, этот список может включать в себя оборудование, программное обеспечение, данные, людей, документацию, сетевую инфраструктуру или репутацию организации.
  2. Определение того, от кого нужно защититься. Например, от неавторизованных пользователей, спамеров или атак на отказ в обслуживании.
  3. Оценку возможных угроз для системы.
  4. Реализацию мер, которые будут эффективно защищать активы.
  5. Дополнительные накладные расходы при настройке SSL-соединения, которые смогут снизить нагрузку на развертывание сообщений.


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

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

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

Мероприятия по управлению сетевой инфраструктурой предприятия включают:

  1. Службы облачной оценки.
  2. Планирование мощности и производительности.
  3. Консолидацию и виртуализацию центров обработки данных.
  4. Интегрированные решения Hyper Converged.
  5. Управление сервером и сетью. Управление ИТ-услугами, поддержку и программное обеспечение.

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

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

Цели и принципы построения информационной инфраструктуры предприятия.

Информационная инфраструктура предприятия (ИТ инфраструктура) – это совокупность информационных технологий, аппаратных и программных средств, средств связи и телекоммуникаций на базе бизнес-процессов в организации.

Инфраструктура состоит из следующих составных частей:

компьютеры и серверы;

программное обеспечение серверов и рабочих станций;

данные и средства хранения данных;

оргтехника (принтеры, копиры, факс аппараты, сканеры);

сети передачи данных, телефонные сети;

активное и пассивное сетевое оборудование (маршрутизаторы, коммутаторы, структурированные кабельные сети);

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

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

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

Цели и принципы построения КСУП следующие. Корпоративная система предназначена для обеспечения эффективного функционирования объекта управления путем автоматизированного выполнения функций управления.

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

Основными классификационными признаками, определяющими вид КСУП, являются:

— сфера функционирования объекта управления (промышленность, строительство, транспорт, сельское хозяйство, непромышленная сфера и т.д.)

— вид управляемого процесса (технологический, организационный, экономический и т.д.);

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

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

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

Функции КСУП в общем случае включают в себя следующие элементы (действия):

— планирование и (или) прогнозирование;

— учет, контроль, анализ;

— координацию и (или) регулирование.

Необходимый состав элементов выбирают в зависимости от вида конкретной КСУП. Функции КСУП можно объединять в подсистемы по функциональному и другим признакам [12,13,17].

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

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

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

3. Обеспечение передовыми средствами коммуникаций персонала предприятия, партнеров и контрагентов в целях оперативного обмена информацией.

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

5. Управление логикой исполнения основных бизнес-процессов.

6. Поддержка решения задач на всех уровнях управления предприятием.

В соответствии с перечисленными требованиями можно выделить основные принципы, на которых должна строиться КСУП.

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

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

Интегрированность. Объединение всех программно-аппаратных средств предприятия в единую компьютерную сеть – центр системы коммуникаций [15,16].

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

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

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

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

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

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

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

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

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

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

— сформулированные миссия и стратегия субъекта экономики, стратегические цели и задачи;

— бизнес-архитектура в текущем (as is) и планируемом (to be) состоянии,

— системная архитектура в текущем (as is) и планируемом (to be) состоянии;

— планы мероприятий и проектов по переходу из текущего состояния в планируемое.

В стандарте ANSI/IEEE 1471-2000is дается следующее определение архитектуры: «фундаментальная организация системы, реализованная в ее компонентах, связях этих компонентов друг с другом и внешней средой и принципах, определяющих структуру и развитие системы». Архитектура предприятия представляет собой концепцию, помогающую организациям изучить собственную структуру и принципы работы. Архитектура предприятия предоставляет «карту» организации и средство прокладки на этой карте маршрута, определяющего изменения в бизнесе и технологиях. Архитектура предприятия обычно представляет собой комплексный набор моделей, описывающих структуру и функции предприятия. Важные сферы применения этих моделей — систематическое планирование и создание архитектуры ИТ, а также принятие стратегических решений. Отдельные модели в архитектуре предприятия упорядочены логически, что позволяет получить высокодетализированное описание предприятия, включая следующие элементы: цели и задачи; процессы и их организация; системы и данные; используемые технологии.

Одним из лучших примеров реализации управления бизнес-процессами предприятия, создания корпоративного портала и обмена данными является продукт SAP R/3.

SAP R/3 (SAP ERP) – это самый известный продукт компании — ERP-система SAP R/3, ориентированная на крупные и средние предприятия, разрабатываемая и продаваемая компанией с начала 1990-х годов. Создана в продолжение линеек RF (позднее идентифицированной как R/1) и R/2. Начиная с выпусков середины 2000-х годов название R/3 не используется; ядро ERP-системы, созданной в продолжение линейки, производитель называет SAP ERP ECC (англ. Enterprise Central Component).

Буква R из R/3 является начальной буквой слова «Realtime» и означает немедленную проводку и актуализацию данных, которые в рамках интеграции немедленно доступны всем заинтересованным отделам предприятия. Цифра 3 означает, что в системе реализована архитектура клиент/сервер приложений/система управления базами данных (трёхзвенная модель), в отличие от R/2, которая работала на мейнфреймах (больших ЭВМ).

Интеграционное программное обеспечение. Специалисты практики SAP обладают большим опытом разработки на базе платформы SAP NetWeaver и успешной реализации интеграционно-прикладных задач.

SAP NetWeaver реализует собственную концепцию SAP ESA (SAP Enterprise Service Architecture) по построению бизнес-приложений на основе сервис-ориентированной архитектуры. Эта концепция объединяет информационные технологии и бизнес-стратегии в единое целое. Благодаря этой концепции обеспечивается согласованность действий людей, информационных потоков и бизнес-процессов предприятия. Коммуникации участников процессов основываются на web-сервисах.

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

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

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

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

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

Управление бизнес-процессами.Решение управления бизнес-процессами ориентировано на проектирование и управление бизнес-процессами в разнородном ИТ-окружении. Решение предоставляет среду моделирования и визуализации бизнес-процессов.

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

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

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

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

Контрольные вопросы по теме 1:

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

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

3. Благодаря каким условиям реализация стратегии EIM может внести весомый вклад в достижение стратегических целей компании?

4. Какие аспекты построения информационных систем рассматривает информационно-технологическая архитектура предприятия?

5. В чём заключается проблема построения технологической инфраструктуры и инвестиций в инфраструктуру предприятия?

6. Каковы основные классификационные признаками определяющие вид корпоративной системы управления предприятием?

Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого.

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

Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰).

Цукерберг рекомендует:  Создаём видеоплеер для нашего сайта
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих