Узких мест с информационной точки зрения

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

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

• Оптимизация парка компьютеров, ЛОКАЛЬНО-ВЫЧИСЛИТЕЛЬНой СЕТИ (ЛВС), сетевого оборудования, орг. техники.
• Информационный аудит— оптимизация программного обеспечения и его легализация.
• Аудит информационных систем — выявление потребностей в недостающем оборудовании и ПО.
• Выведение из эксплуатации избыточного оборудовании и ПО, а также ПО с просроченными лицензиями.
• Сокращение потребляемого интернет-трафика за счёт его администрирования, а как следствие повышение производительности труда за счёт того, что сотрудники не тратят рабочее время на социальные сети и прочий развлекательный контент.
• Сокращение издержек на поддержание и обеспечение ИТ-инфраструктуры.
• Выявить слабые места антивирусной и информационной безопасности.
• Выдаются рекомендации по поддержанию на складе необходимого для бесперебойной работы предприятия, расходных материалов и частей.
• Аудит информационной безопасности.

Как провести ит аудит?

Аудит информационной безопасности:

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

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

Диагностика работы компьютерной сети, активного и пассивного оборудования:

• Диагностика потери пакетов внутри и снаружи.
• Тестирование скорости интернет-канала.
• Анализ настроек и политик безопасности активного оборудованияю.
• Оценка общего состояния компьютерной сети (ЛВС, СКС), качество её монтажа и соответствие его действующим нормам и правилам.

Диагностика работы серверного оборудования на программном и аппаратном уровне:

• Тестирование серверного оборудования.
• Аудит установленного ПО и его настроек.
• Анализ записей в журналах событий серверов.
• Тестирование источников бесперебойного питания на отказоустойчивость.
• Анализ настроек серверных служб.

Определение узких мест производительности серверов:

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

Анализ корректности пользовательских настроек (по выбору несколько рабочих станций);

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

Сколько стоит ИТ аудит?

Аудит ИТ — результат:

Заказчик получит аудиторское заключение, содержащие:

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

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

Определение «узких» мест с информационной точки зрения

Чтобы выявить «узкие места» АРМ в данном отделе был проведен анализ программного и аппаратного обеспечения.

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

-Процессор AMD ryzen;

-Оперативная память: 512 Мб

-Свободное пространство на диске: не менее 20 ГБ;

-Отсутствие прав доступа к определенным категориям ПО замедляет установку и обновление программных продуктов.

-Так же нет возможности сделать онлайн-заказ;

На тему «Улучшение сайта организации. Оформление онлайн заявки»

По данным опроса фонда «Общественное мнение» (ФОМ)*, 87% россиян считают, что в целом изобретение интернета принесло людям больше хорошего, чем плохого,10% затруднились ответить и только 3% считают, что в интернете больше плохого, чем хорошего.

В качестве положительных сторон интернета 60% опрошенных отметили — «много полезной и общедоступной информации», 31% — «широкие возможности общения между людьми», 8% — «развлечение, новые формы проведения досуга».

На другой вопрос, 53% респондентов, в целом, ответили, что их жизнь значительно изменится, если они вдруг лишатся возможности пользоваться интернетом.[3].

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

Рис.1 .Главная страница официального сайта ОАО «Контакт».

На их сайте присутствует меню: «Главная», «О заводе», «Продукция», «Строительство», «Контакты», «Статьи и новости». На сайте можно найти номер телефона каждого отдела, по которому можно связаться, e-mail -куда отправляют заявку на товары, режим на работы.

Всю информацию о компании можно найти на их сайте.

Изучив структуру сайта, я обнаружила, что на сайте не достает онлайн заявки, которая очень удобна, как для клиента, так и для пользователя. Онлайн заявку можно сделать с помощью языка программирования PHP. PHP (англ. PHP:HypertextPreprocessor — «PHP: препроцессоргипертекста»; первоначально PersonalHomePageTools — «Инструменты для создания персональных веб-страниц») — скриптовый язык общего назначения, интенсивно применяемый для разработки веб-приложений. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков, применяющихся для создания динамических веб-сайтов.[4].

Каждая страница веб-сайта это текстовый документ, который написан на языке программирования (HTML, XHTML, JAVA или другие). Эти текстовые файлы загружаются на ваш компьютер, обрабатываются браузером и отображаются на мониторе компьютера в виде страницы сайта. Язык программирования позволяет редактировать текст странички, добавлять ссылки, вставлять картинки, звуковые и видео файлы. Страницы сайтов могут быть как простыми наборами информации — тексты и картинки, так и сложными, с огромным количеством функций, которые управляются различными программами.

Онлайн- заявка будет выглядеть подобным образом.

Практика была пройдена в ОАО «Контакт» в отделе Сбыта резисторов. Завод занимается производством резисторов, резисторных блоков, автомобильной электроники, приборов климатконтроля и хозяйственных товаров.

АО «Контакт» предлагает товары народного потребления, товары для рыбалки, туризма и отдыха и прочие хозтовары. В ходе практики было:

1) изучена деятельность завода;

2) изучена организационная структура управления отдела Сбыта резисторов;

3) основные экономические показатели деятельности завода АО «Контакт»;

4) экономический анализ деятельности завода АО «Контакт»;

5) описан документооборот отдела Сбыта резисторов;

В результате, цель была достигнута, поставленные задачи — выполнены.

4. Wiki-учебник по веб-технологиям: PHP

5. Прикладная информатика (в экономике): Методические указания к прохождению производственной практики и оформлению отчетов для студентов специальности 080801.65 «Прикладная информатика (в экономике)» / Сост. Иванов О. Е., Швецов А. В. – Йошкар-Ола: Марийский государственный технический университет, 2011.

6. Уткин, В.Б. Информационные системы в экономике: Учебник для студентов высших учебных заведений / В.Б. Уткин, К.В. Балдин. — М.: ИЦ Академия, 2012. — 288c.

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

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

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

Как определить узкие места компании, которые не дают ей расти

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

Проблемы роста универсальны

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

«Организациям, столкнувшимся с ограничением, или «потолком» собственного роста, важно убрать эти ограничители, которые, зачастую, имеют искусственную природу и заключаются в особенностях работы самой организации. Каким образом это можно сделать? Мы, например, начинаем с диагностики, в ходе которой определяем наиболее актуальные проблемы организации («узкие места») и «точки роста», после чего помогаем убрать лишнее и внедрить необходимое», — говорит основатель Центра Деловых Инициатив Владимир Коровин.

Усилия попадают в «бутылочное горлышко»

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

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

Узкое место возникает там, где в силу неэффективности — технологии, процесса или работы конкретного человека – объем «на входе» превышает способность этого участка бизнес-процесса трансформировать его в собственные результаты. Елена Столповская, возглавляющая калининградский деловой клуб «Бизнес Парк», вспоминает о своем опыте «работы в рекламном агентстве, где «узкое место» был директор, который просчитывал заказы, выходящие за рамки стандартного прайса. Таких заказов было немало. Работать над усовершенствованием прайса руководитель не хотел. Потенциальный заказчик мог ждать день, два или три, пока ему озвучат стоимость. Таким образом, производительность узкого места всегда неадекватна спросу на результат, что неминуемо ухудшает общую картину операционной эффективности.

В рамках нашей услуги «Поиск и устранение проблем, мешающих развитию» мы найдем и «расширим» узкие места вашей компании

Точки роста или зоны проблем?

Компания может развиваться многими способами:

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

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

«Узкие места» в теории ограничений Голдратта

Процесс возникновения узких мест детально описан в знаменитой теории ограничений (Theory of Constraints — TCO). Ее создатель — израильский физик Элияху Голдратт. Свою теорию он раскрывает в рамках художественного бестселлера «Цель: процесс непрерывного совершенствования». Кстати, большим поклонником его теории является Джефф Безос – основатель компании Amazon. На одном из своих совещаний он посоветовал книгу к прочтению всем своим топ-менеджерам.

Джефф Безос

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

Как выявить узкое место в своей компании

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

• Принцип системного подхода.

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

• Принцип слабого звена.

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

Основатель сервиса заказа ремонтов PriceRemont Юрий Гольдберг: «Обычно, если фирма небольшая, сразу видны узкие места на входе. В ручном режиме я разбираю ситуацию за ситуацией, почему звонков или заявок на ремонт на сайте много, а итоговых заказов – мало».

Как решить проблему «узких мест»

• Собрать и проанализировать информацию о своих бизнес-процессах. Принцип здесь тот же, что и в основе составления и анализа карты операционной деятельности компании (operational flow chart). Каждый бизнес-процесс имеет вход и выход, потребляет разнообразные ресурсы (сырье, заготовки, время, информацию) и трансформирует их в результат.
• Взглянуть на свою компанию как на сетевую систему. Понять, какое звено в цепочке бизнес-процесса является первым по темпу работы, а какое – последним, как результаты работы одних звеньев отражаются на работе других.

В рамках нашей услуги «Поиск и устранение проблем, мешающих развитию» мы найдем и «расширим» узкие места вашей компании

Как расширить узкое место

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

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

Как обезвредить узкие места роста компании

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

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

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

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

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

О типовых проблемах, создающих ограничения для роста вы можете прочитать в нашем материале Как прекратить топтаться на месте: практика преодоления «потолка роста»

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

Появились вопросы? Пишите в комментариях.
Также вы можете задать вопрос нашему эксперту

© «Центр Деловых Инициатив», при полном или частичном копировании материала ссылка на первоисточник обязательна.

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

Отчет по производственной практике должен иметь следующую структуру:

1. Общая характеристика организации

1.1. История организации

1.2. Организационная структура управления организацией

1.3. Основные финансово-экономические показатели деятельности организации

2. Анализ существующей организации и технологии обработки информации в организации

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

2.2. Описание автоматизированных рабочих мест специалистов организации (отдела)

2.3. Анализ используемого в организации (отделе) программного и аппаратного обеспечения

2.4. Определение «узких» мест с информационной точки зрения

3. Научно-исследовательская работа студента (согласно выбранной теме)

Список используемых источников

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

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

Раздел 1.Общая характеристика организации.

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

Таблица 1 – Пример основных финансово-экономических показателей

Объем выпущенной продукции

Объем реализации продукции.

Себестоимость реализованной продукции

Стоимость основных фондов

Сумма налогов, уплаченных в бюджеты всех уровней и во внебюджетные фонды

Раздел 2. Анализ существующей организации и технологии обработки информации в организации.

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

Раздел 3. Научно-исследовательская работа (по выбранной теме).

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

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

Каждый раздел завершается выводами, а отчет – заключением.

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

Определение «узких» мест с информационной точки зрения

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

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

Сквимминговое оборудование — это технические средства дублирования банковских карт (само собой, такое дублирование противозаконно) с помощью вмонтированных в банкоматы устройств. Так вот: только лишь клиенты Сбербанка и только в России потеряли на сквимминге 900 000 000 рублей.

Сбербанк России сегодня — это 80 000 000 банковских карт на территории России, а для их обслуживания установлено 68 000 устройств самообслуживания. За весь 2013 год здесь было зафиксировано 496 случаев установки сквиммингового оборудования, однако в 2014 году уже имеется 1286 подобных фактов. И рост явно даже не в своей пиковой точке.

Сквимминг, являющийся основной проблемой российских банков вообще, имеет свои уязвимости. В первую очередь, работает сквимминговое оборудование на картах с магнитной полосой, а вот чиповые карты мошенникам уже не по зубам. Как итог — за 1,5-2 года Сбербанк России хочет полностью перейти именно на такой, «неуязвимый», тип карточек.

А вот где тенденция банковских проблем имеет иной вектор, так это сфера кибератак: в 2013 году таковых было осуществлено 1214, однако достигла цели только их треть. И именно на эту треть в 400 кибератак припадало около 340 миллионов рублей. Зато в 2014 году попыток было осуществлено всего 585, а эффективными из низ оказались 162 попытки. Это уже меньше третей части на фоне уменьшения финансовых убытков: пока они достигают от кибермошеннечества, нацеленного на системы дистанционного банковского обслуживания (ДБО) 224 миллионов рублей.

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

70% всех таких краж совершаются на территории, подконтрольной пятерке представительств Сбербанка. В их число попади такие «счастливчики», как Уральский, Среднерусский, Юго-Западный, Байкальский и Волго-Русский госбанки. Но и здесь проблема Сбербанка имеет свое решение: при несанкционированном вскрытии автоматически происходит окрашивание купюр. С нападениями на инкассаторов когда-то справились именно подобной методикой, так что в Сбербанке России и сейчас в успехе не сомневаются.

Выделение потенциальных узких мест в информационной системе

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

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

В приведенном примере явно видны 3 пика активности системы, максимальный из которых приходится на 11 часов. Использован тип диаграммы с накоплением.

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

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

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

Продукты третьих фирм

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

Использование CASE-средств

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

Инфраструктура

Для проектирования и реализации необходимы аппаратные ресурсы и специальное программное обеспечение. Кроме того, требуется механизм, позволяющий контролировать создаваемую документацию и код. Эти вопросы лучше решать на ранних стадиях проектирования, а не на стадии разработки. Мы поговорим об этом ниже, в разделе «Проектирование процессов и кода». При групповой разработке вам понадобятся средства контроля согласованности кода. Если разработка идет под разными платформами (аппаратная платформа и ОС), то хорошим решением может оказаться PVCS. Для платформ Windows 98, NT, 2000 может оказаться приемлемым решение, предлагаемое Microsoft — MS Source Save. Кроме того, многие средства разработки также предоставляют возможности контроля исходного кода.

Проектирование базы данных

Построение модели данных

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

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

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

· разрешение всех дуг, подтипов и супертипов;

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

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

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

· реализация ограничений (ограничений и триггеров), отражающих все централизованно определенные бизнес-правила, генерация ограничений и триггеров;

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

· определение необходимых индексов, кластеров (если таковые реализованы в СУБД), определение горизонтальной фрагментации таблиц (если это реализовано в СУБД);

· оценка размеров всех таблиц, индексов, кластеров;

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

· определение пользователей базы данных, их уровней доступа, разработка и внедрение правил безопасности доступа, аудита (если это необходимо), создание пакетированных привилегий (в зависимости от реализации СУБД это роли или группы), синонимов;

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

· Подробнее на каждом из перечисленных пунктов мы остановимся в части «Схема базы данных».

«Узкие места» в локальных сетях

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

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

Как показывает многолетний опыт компании «ПроЛАН» в области оказания услуг по диагностике и тестированию сетей, вопросам локализации «узких мест» сети и особенно вопросам выявления недостатков прикладного ПО администраторы сетей уделяют недостаточно внимания. Утверждения типа «все и так работает, зачем нам какая-то диагностика» приходится слышать нередко. Многие администраторы под диагностикой сети понимают исключительно диагностику кабельной системы. Кроме того, зачастую действия администратора по устранению дефектов и/или улучшению работы сети основываются на интуиции, а не на достоверных данных о том, почему сеть работает плохо.

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

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

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

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

ЧТО ТАКОЕ «УЗКОЕ МЕСТО» СЕТИ

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

Наличие или отсутствие «узких мест» зависит от того, какое прикладное ПО используется в сети. В общем случае какой-либо архитектурный компонент сети нельзя считать «узким местом» без конкретизации ПО, для которого он таковым является. В одной и той же сети для разных типов прикладного ПО «узкими местами» могут быть разные архитектурные компоненты. Например, если для прикладного ПО на базе Fox Pro наиболее вероятным «узким местом» будет производительность канала связи или дисковой подсистемы сервера, то для прикладного ПО на базе Oracle — производительность процессора сервера.

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

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

«Узкое место» сети можно сравнить с полностью заполненной трубой (утилизация близка к естественному пределу — 100%), из-за чего остальные трубы оказываются незаполненными.

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

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

НЕДОСТАТОЧНАЯ ПРОПУСКНАЯ СПОСОБНОСТЬ ОБЩЕГО СЕТЕВОГО РЕСУРСА

Правило №1.1. Уровень утилизации общих сетевых ресурсов с одинаковой дисциплиной обслуживания заявок в хорошо сбалансированной сети не должен существенно отличаться.

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

Для канала связи, например, дисциплина обслуживания выражается в правиле: «Первым пришел, первым обслужен» (FIFO). Как только заявка поступает, она сразу выполняется. Если канал связи свободен, то станция сразу передает кадр; таким образом, при наличии заявки на обслуживание канал связи не простаивает.

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

Если уровни утилизации общих ресурсов существенно отличаются друг от друга, то такую сеть принято называть «плохо сбалансированной по нагрузке». В этом случае необходимо заменить активное оборудование и/или изменить архитектуру сети. Данная процедура называется «выравнивание нагрузки» (load balancing).

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

Предположим, что ваша сеть имеет архитектуру с компактной магистралью (collapsed backbone), как показано на Рисунке 2. Для того чтобы определить, какой из доменов сети (домен А на 10 Мбит/с или домен В на 100 Мбит/с) в большей степени влияет на время реакции прикладного ПО, загруженность этих доменов надо сравнить между собой. Несмотря на то что сравниваемые ресурсы имеют разную номинальную пропускную способность (10 Мбит/с и 100 Мбит/с), наибольшее влияние на время реакции прикладного ПО оказывает тот домен, значение утилизации которого выше.

Обращаем ваше внимание, что в рассмотренном примере еще нельзя сказать, что тот домен сети, который в большей степени (чем остальные) влияет на работу прикладного ПО, является «узким местом» сети. Найти именно «узкое место» сети можно, только оценив влияние всех общих ресурсов (а не только доменов сети) на работу ПО и определив, какой ресурс влияет в наибольшей степени. Если в рассмотренном примере «узким местом» оказывается, например, дисковая подсистема сервера, то утилизация доменов может быть относительно низкой.

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

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

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

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

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

Правило №1.2. Чтобы определить, какой общий ресурс является «узким местом» сети, вы должны точно знать, утилизация какого ресурса ближе других к допустимому или к естественному пределу.

Если в процессе измерений вы определили, что утилизация какого-то ресурса близка к естественному пределу (к 100%), то этот ресурс однозначно является «узким местом» сети. Обычно с интерпретацией результатов, в которых утилизация ресурсов близка к естественному пределу, особых проблем не возникает. Намного сложнее интерпретировать результаты, в которых утилизация общих ресурсов различна и далека от естественных пределов.

Допустимый предел утилизации (см. Правило №1.3) обычно меньше естественного (меньше 100%), а его значение зависит от многих условий.

Предположим, что вы измерили утилизацию всех общих ресурсов сети (изображенной на Рисунке 2) и определили, что утилизация домена А составила 19%, утилизация внутренней магистрали коммутатора — 26%, домена B — 12%, процессора сервера — 36%. Позволяют ли полученные данные сделать вывод о том, что «узким местом» является недостаточная производительность процессора сервера? Нет, так как эти ресурсы имеют разную дисциплину обслуживания заявок, и мы изначально не знаем, утилизация какого ресурса ближе других находится к допустимому пределу.

Таким образом, мы подошли к вопросу о том, как определить допустимый предел утилизации ресурса.

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

Из теории массового обслуживания известно, что в общем случае скорость выполнения операций в сети гиперболически зависит от утилизации общих ресурсов (см. Рисунок 3). За верхнее допустимое значение обычно принимается утилизация, при которой заканчивается «линейный» участок гиперболы. Однако крутизна кривой и протяженность «линейного» участка для разных типов ресурсов могут быть различны. Это означает, что допустимое значение утилизации (допустимый предел) для разных типов ресурсов различно.

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

Ряд анализаторов протоколов, например Observer компании Network Instru-

ments, имеют функцию генерации трафика (см. Рисунок 4). Изменяя параметры Packets/sec (число пакетов в секунду) и Packet size (размер пакета), вы можете варьировать интенсивность генерируемого анализатором трафика, а изменяя параметр destination (приемник) — направление генерируемого трафика. Зависимость между утилизацией ресурса и временем реакции можно оценить, измеряя время реакции прикладного ПО на фоне увеличения генерируемой нагрузки. Зная эту зависимость, вы можете определить, при какой утилизации ресурса заканчивается «линейный» участок гиперболы или какой утилизации ресурса соответствует требуемое время реакции прикладного ПО (например, 2 с, см. врезку «Какая сеть хороша?»). Это значение утилизации и будет являться допустимым пределом утилизации ресурса.

Определить допустимый предел утилизации различных компонентов сервера намного сложнее (см. раздел узкое место — «Производительность сервера»).

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

Как мы уже говорили выше, ликвидация «узкого места» не всегда достигает цели. Признаком целесообразности устранения «узкого места» является наличие в сети только одного «узкого места», и то только в том случае, если «расширение» «узкого места» позволит ускорить работу прикладного ПО (см. Правило №6.1).

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

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

Сеть развивается, число пользователей увеличивается, и вы, например, решили, не меняя сервера, заменить сеть Ethernet на сеть Fast Ethernet. В этом случае канал связи перестает быть «узким местом», но не дисковая подсистема сервера. Нагрузка на дисковую подсистему увеличится, и, следовательно, ее утилизация возрастет. Если при этом крутизна гиперболической зависимости времени реакции от утилизации дисковой подсистемы (см. Правило №1.3) больше, чем для канала связи, то скорость выполнения операций в сети уменьшится.

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

ПРОИЗВОДИТЕЛЬНОСТЬ СЕРВЕРА

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

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

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

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

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

В рамках данной статьи, ввиду объемности и сложности материала, мы не можем рассказать о том, как определить, какой конкретно компонент сервера является «узким местом». Эта задача решается только с использованием метода стрессового тестирования сети, о котором мы планируем рассказать в последующих публикациях. Тем, кого эта проблема интересует, мы рекомендуем прочесть книгу Расса Блейка «Optimizing Windows NT», которая входит в состав «Windows NT Resource Kit», издаваемого Microsoft Press.

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

Правило №2.1. Признаком перегрузки сервера NetWare является специальный пакет протокола NCP, который сервер высылает в ответ на повторный запрос от рабочей станции, если предыдущий запрос от той же рабочей станции еще обрабатывается сервером. Такие пакеты обычно называются Delay packet, Server busy replies или Being processed packet.

Отправив по протоколу NCP запрос к серверу NetWare на выполнение какой-то операции, рабочая станция включает тайм-аут и ждет от сервера ответа о выполнении этой операции. Если ответ не приходит в течение фиксированного времени (тайм-аута), то станция повторяет запрос для проверки того, что он не был потерян при передаче по сети. Получив повторный запрос от рабочей станции, сервер отвечает ей специальным пакетом, который, как мы говорили, называется Delay packet, Server busy replies или Being processed packet. Сервер как бы просит станцию не волноваться: «Запрос получен, но я не могу на него сейчас ответить». Получив пакет, рабочая станция обнуляет свой тайм-аут и продолжает ждать ответа от сервера. Наличие таких пакетов в сети свидетельствует о том, что сервер не успевает обрабатывать запросы от рабочих станций. Чем больше в сети подобных пакетов, тем сильнее перегружен сервер. Подробнее об этом можно прочесть в книге Лауры А. Чаппел и Дэна Е. Хейкса «Анализатор локальных сетей NetWare», изданной Novell PRESS.

Обычно анализаторы сетевых протоколов имеют специальный входной фильтр, позволяющий фиксировать наличие и определять число таких пакетов в сети (см. Рисунок 5). Установив значение параметров Number of server busy replies («Число ответов сервера о том, что он занят») и Averaging period («Период усреднения»), анализатор протоколов информирует вас, когда число ответов сервера о перегрузке за заданный промежуток времени превысит установленное значение.

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

Правило №2.2. Признаком перегрузки сервера является возросшее время ответа сервера на запросы рабочих станций.

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

Время реакции сервера автоматически определяется некоторыми анализаторами протоколов. В Observer время реакции каждого узла сети входит в состав статистики по каждой паре станций и называется latency (см. Рисунок 6).

БОЛЬШОЕ ЧИСЛО КОРОТКИХ КАДРОВ

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

Правило №3.1. Пропускная способность сети существенно зависит от типа сетевого трафика. Чем больше число коротких кадров, тем менее эффективно используется пропускная способность сети.

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

Пропускная способность канала связи (коммутаторов и концентраторов) существенно зависит от размера кадров. Чем большую долю в общем числе кадров занимают короткие кадры, тем менее эффективно используется пропускная способность канала связи. На Рисунке 7 пропускная способность сети Ethernet показана в зависимости от длины кадров (она была измерена утилитой perform3 компании Novell). Несмотря на то что вид кривой зависит от используемых сетевых адаптеров, снижение пропускной способности сети при уменьшении размера кадров характерно для всех типов сетей (Ethernet, Fast Ethernet, Token Ring, FDDI).

В этой связи измерение доли кадров конкретной длины приобретает большее значение. Такое измерение можно провести с помощью специальных утилит (например, psd.exe компании Novell) или анализатора протоколов. Анализатор Observer автоматически строит распределение кадров по длинам. Результат его работы показан на Рисунке 8.

РОСТ ЧИСЛА ШИРОКОВЕЩАТЕЛЬНЫХ ПАКЕТОВ

Правило №4.1. В соответствии с отраслевым стандартом де-факто число широковещательных и многоадресных кадров в сети не должно превышать 8—10% от общего числа кадров (Robert W. Buchanan, Jr, «The Art of Testing Network Systems»; Wiley Computer Publishing).

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

Если отношение числа широковещательных кадров к общему числу кадров больше 10%, то такой эффект называется «широковещательным штормом».

Широковещательный шторм может быть следствием дефектов оборудования или неправильной настройки параметров активного оборудования. Чаще всего это явление наблюдается в распределенных сетях NetWare, построенных на основе коммутаторов, или когда данные между сегментами или доменами сети могут передаваться более чем по одному потенциальному пути. Если один из коммутаторов такой сети не поддерживает протокол Spanning Tree (обычно IEEE 802.1d) или последний неправильно настроен либо сбоит, то в сети начинается неуправляемая циркуляция широковещательных кадров.

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

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

Данная задача хорошо решена в анализаторе протоколов Observer (см. Рисунок 9). Совмещенный график отображает долю (в процентах) широковещательных и многоадресных кадров как функцию утилизации канала связи. При этом цветом выделяется степень загрузки сети. Если цвет линий желтый, то утилизация сети менее установленного порога (обычно 5%). При такой утилизации доля широковещательных и групповых кадров особого интереса не представляет. При зеленом цвете линий утилизация сети высокая, но доля широковещательных и групповых кадров менее установленного порога (по умолчанию 10%). Если же цвет линий красный, то это означает, что утилизация канала связи и доля широковещательных и многоадресных кадров выше установленного порога. Это признак «широковещательного шторма».

НЕЭФФЕКТИВНЫЕ АЛГОРИТМЫ РАБОТЫ ПРИКЛАДНОГО ПО

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

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

Чтобы определить, насколько эффективно используются ресурсы сети, мы рекомендуем провести несколько экспериментов с типовыми задачами. Суть экспериментов заключается в одновременном запуске типовых задач на N (N = 1,2,3. ) рабочих станциях. Цель экспериментов — измерить время выполнения типовой задачи при различном числе станций и соответствующие значения утилизации сетевых ресурсов (канала связи, процессора сервера, процессоров рабочих станций и т. д.).

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

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

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

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

Если утилизация какого-то ресурса оказывается близка к естественному пределу его пропускной способности, то именно данный ресурс представляет собой «узкое место» для конкретной типовой задачи.

КАКОЕ «УЗКОЕ МЕСТО» СЛЕДУЕТ УСТРАНЯТЬ В ПЕРВУЮ ОЧЕРЕДЬ

Если вы определили, какой именно ресурс является «узким местом» вашей сети, то затем вы должны установить, как устранение этого «узкого места» повлияет на время реакции ПО.

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

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

Приходящуюся на канал связи долю времени (Дканала) можно установить, измерив утилизацию канала связи при одной работающей станции. Если в сети в момент измерения не будет других пользователей, то долю канала можно вычислить по следующей формуле:
Дканала = Утилизация канала/100

Чтобы определить, какая доля времени приходится на сервер, и при этом учесть вклад всех компонентов сервера (дисковой подсистемы, ОЗУ и др.), время выполнения типовой задачи следует измерить при одной и двух одновременно работающих станциях. В общем случае долю времени, которая приходится на сервер (Дсервера), можно вычислить по формуле:
Дсервера = ?(2*(T1/T2-1)-Дканала),
где Т1 и Т2 — время выполнения задачи при одной и двух одновременно работающих станциях соответственно.

Если считать, что основная задержка связана с процессором сервера, а вносимой остальными компонентами сервера задержкой можно пренебречь, то долю сервера можно принять пропорциональной утилизации процессора сервера. Доля сервера в этом случае будет определяться следующим образом:
Дсервера = Утилизация процессора сервера/100

Долю времени, которая приходится на рабочую станцию (Дстанции) можно оценить, как:
Дстанции = (1 - Дканала - Дсервера) 1/2

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

Если вы определили, предположим, что передача данных по каналу связи занимает 10% времени решения задачи (Дканала = 0,1), выполнение операций на сервере — 5% (Дсервера = 0,05), а на рабочей станции — 85% (Дстанции = 0,85), то какой бы высокой производительностью ни обладал ваш новый сервер, вы не получите ускорения в решении задачи более чем на 5%. Аналогично, если ваша сеть будет работать со скоростью света, вы все равно не получите ускорения в решении задачи более чем на 10%. В таких случаях модифицировать прежде всего следует рабочие станции (или алгоритмы работы прикладного ПО).

Сергей Семенович Юдицкий — генеральный директор ЗАО «ПроЛАН», с ним можно связаться по адресу: ssy@testlab.ipu.rssi.ru. Владислав Витальевич Борисенко — системный инженер ЗАО «ПроЛАН», с ним можно связаться по адресу: slw@testlab.ipu.rssi.ru. Виктор Сергеевич Подлазов — эксперт ЗАО «ПроЛАН».

ДВА ПОДХОДА К ОЦЕНКЕ КАЧЕСТВА СЕТИ

Какая сеть хороша?

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

Как показали исследования, проведенные группой американских психологов, время реакции прикладной системы для пользователей, работающих в диалоговом режиме, не должно превышать 2 секунды (William Stallings, «SNMP, SNMPv2, and CMIP. The Practical Guide to Network-Management Standards», Addison-Wesley Publishing Company). Если время реакции оказывается большим, то пользователи чувствуют себя некомфортно, быстро устают, часто делают ошибки, производительность их труда становится низкой.

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

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

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

Поделитесь материалом с коллегами и друзьями